From thomas.wuerthinger at oracle.com Mon Sep 2 06:04:56 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 2 Sep 2013 15:04:56 +0200 Subject: webrev that allows the compilation target runtime to be queried In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F9024F6@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F9024F6@SATLEXDAG02.amd.com> Message-ID: <3B6B0BE6-3CE3-4047-BDB1-DD2D6E96AAE7@oracle.com> Vasanth, Can you please upload the webrev/patch and send a link to it (the mailing list drops attachments)? Regarding the thread register: It is not a strict requirement that the current thread must always be in a certain register. One could also change Graal to load the current thread from some address on the stack whenever needed. - thomas On Aug 30, 2013, at 12:17 AM, "Venkatachalam, Vasanth" wrote: > Hi, > > Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. > An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. > This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. > > The attached patch provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. Christian, can you upload a webrev for this to the review site? > > In detail, the patch adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. > > We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. > > With this patch (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. > > We'd welcome feedback and suggestions about alternative solutions. > > Vasanth > From thomas.wuerthinger at oracle.com Mon Sep 2 07:28:04 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 2 Sep 2013 16:28:04 +0200 Subject: LoadCompressedPointer In-Reply-To: <521A917C.8080108@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D98F030@SATLEXDAG02.amd.com> <52128844.1090009@oracle.com> <8347E4BB-9087-4402-B1A5-CD2971979981@jku.at> <521A917C.8080108@oracle.com> Message-ID: <690A08BF-FF9D-419E-9F7C-13C5A793A06A@oracle.com> No, because compressed pointers are only available for 64-bit systems. Also, the AMD64Move instruction is only valid on a 64-bit platform. - thomas On Aug 26, 2013, at 1:21 AM, Christian Wimmer wrote: > But then the assertion also needs to cover Kind.Long for 32 bit systems, or not? > > -Christian > > > On 8/19/2013 11:57 PM, Lukas Stadler wrote: >> This is required - for compressed Klass* pointers in the object header. >> These are compressed pointers to non - garbage collected structures. >> >> - Lukas >> >> On Aug 19, 2013, at 11:04 PM, Mick Jordan wrote: >> >>> On 8/19/13 12:54 PM, Venkatachalam, Vasanth wrote: >>>> After a recent merge, I noticed some new logic in AMD64Move.LoadCompressedPointer() routine: >>>> >>>> assert kind = Kind.Object || kind = kind.Long; >>>> >>>> Can someone explain why we would allow kind = kind.Long? >>>> >>>> What cases would trigger a call to LoadCompressedPointer where kind = Kind.Long? >>>> >>>> >>> This is probably another case where a Word type (rewritten to Kind.long) is involved. I don't like it. >>> >>> Mick >>> >> > From tom.deneau at amd.com Tue Sep 3 05:52:13 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Sep 2013 12:52:13 +0000 Subject: compiling code that has never been interpreted Message-ID: For the HSAIL-based junit tests, we have the following general structure: 1. run a method in normal java mode 2. compile same method into HSAIL and dispatch 3. compare results If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? I can try to get igv graphs if needed. -- Tom From doug.simon at oracle.com Tue Sep 3 07:59:54 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Sep 2013 16:59:54 +0200 Subject: compiling code that has never been interpreted In-Reply-To: References: Message-ID: Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: > For the HSAIL-based junit tests, we have the following general structure: > > 1. run a method in normal java mode > > 2. compile same method into HSAIL and dispatch > > 3. compare results > > If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. > > Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? > > I can try to get igv graphs if needed. > > -- Tom > From tom.deneau at amd.com Tue Sep 3 08:21:27 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Sep 2013 15:21:27 +0000 Subject: compiling code that has never been interpreted In-Reply-To: References: Message-ID: Doug -- Thanks, yet this works. What is the reason that someone would want eagerResolving turned off? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, September 03, 2013 10:00 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiling code that has never been interpreted Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: > For the HSAIL-based junit tests, we have the following general structure: > > 1. run a method in normal java mode > > 2. compile same method into HSAIL and dispatch > > 3. compare results > > If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. > > Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? > > I can try to get igv graphs if needed. > > -- Tom > From Vasanth.Venkatachalam at amd.com Tue Sep 3 08:27:20 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 3 Sep 2013 15:27:20 +0000 Subject: webrev that allows the compilation target runtime to be queried In-Reply-To: <3B6B0BE6-3CE3-4047-BDB1-DD2D6E96AAE7@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73F9024F6@SATLEXDAG02.amd.com> <3B6B0BE6-3CE3-4047-BDB1-DD2D6E96AAE7@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73F9059AB@SATLEXDAG02.amd.com> Thomas, I need an account to be able to upload the webrev. Did you guys ever get that sorted out? If so, can you send me the details? Vasanth -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Monday, September 02, 2013 8:05 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: webrev that allows the compilation target runtime to be queried Vasanth, Can you please upload the webrev/patch and send a link to it (the mailing list drops attachments)? Regarding the thread register: It is not a strict requirement that the current thread must always be in a certain register. One could also change Graal to load the current thread from some address on the stack whenever needed. - thomas On Aug 30, 2013, at 12:17 AM, "Venkatachalam, Vasanth" wrote: > Hi, > > Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. > An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. > This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. > > The attached patch provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. Christian, can you upload a webrev for this to the review site? > > In detail, the patch adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. > > We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. > > With this patch (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. > > We'd welcome feedback and suggestions about alternative solutions. > > Vasanth > From doug.simon at oracle.com Tue Sep 3 08:28:43 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Sep 2013 17:28:43 +0200 Subject: compiling code that has never been interpreted In-Reply-To: References: Message-ID: On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" wrote: > Doug -- > > Thanks, yet this works. > What is the reason that someone would want eagerResolving turned off? Two reasons (that I can think of): 1. Prevent non-executed code paths causing extra class loading during compilation. 2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, September 03, 2013 10:00 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: compiling code that has never been interpreted > > Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. > > On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: > >> For the HSAIL-based junit tests, we have the following general structure: >> >> 1. run a method in normal java mode >> >> 2. compile same method into HSAIL and dispatch >> >> 3. compare results >> >> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. >> >> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? >> >> I can try to get igv graphs if needed. >> >> -- Tom >> > > > From thomas.wuerthinger at oracle.com Tue Sep 3 08:48:16 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 3 Sep 2013 17:48:16 +0200 Subject: webrev that allows the compilation target runtime to be queried In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F9059AB@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F9024F6@SATLEXDAG02.amd.com> <3B6B0BE6-3CE3-4047-BDB1-DD2D6E96AAE7@oracle.com> <5DD1503F815BD14889DC81D28643E3A73F9059AB@SATLEXDAG02.amd.com> Message-ID: <00D55B2C-966B-47B6-A53F-B6A6BEE8DE4C@oracle.com> I'll nominate you as an author on the Graal project. This will give you an OpenJDK account. - thomas On Sep 3, 2013, at 5:27 PM, "Venkatachalam, Vasanth" wrote: > Thomas, > > I need an account to be able to upload the webrev. Did you guys ever get that sorted out? If so, can you send me the details? > > Vasanth > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Monday, September 02, 2013 8:05 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev that allows the compilation target runtime to be queried > > Vasanth, > > Can you please upload the webrev/patch and send a link to it (the mailing list drops attachments)? > > Regarding the thread register: It is not a strict requirement that the current thread must always be in a certain register. One could also change Graal to load the current thread from some address on the stack whenever needed. > > - thomas > > On Aug 30, 2013, at 12:17 AM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. >> An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. >> This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. >> >> The attached patch provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. Christian, can you upload a webrev for this to the review site? >> >> In detail, the patch adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. >> >> We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. >> >> With this patch (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. >> >> We'd welcome feedback and suggestions about alternative solutions. >> >> Vasanth >> > > > From tom.deneau at amd.com Tue Sep 3 09:46:53 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Sep 2013 16:46:53 +0000 Subject: compiling code that has never been interpreted In-Reply-To: References: Message-ID: Doug -- I spoke too soon in saying that GraphBuilderConfiguration.getEagerDefault() solved our problems. There are still a few junit tests that fail if we compile never-previously-executed code even though we are using getEagerDefault. The failures are all variations of the nbody test. I can see the codegen differing very slightly. I will try to send examples. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, September 03, 2013 10:29 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiling code that has never been interpreted On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" wrote: > Doug -- > > Thanks, yet this works. > What is the reason that someone would want eagerResolving turned off? Two reasons (that I can think of): 1. Prevent non-executed code paths causing extra class loading during compilation. 2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, September 03, 2013 10:00 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: compiling code that has never been interpreted > > Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. > > On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: > >> For the HSAIL-based junit tests, we have the following general structure: >> >> 1. run a method in normal java mode >> >> 2. compile same method into HSAIL and dispatch >> >> 3. compare results >> >> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. >> >> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? >> >> I can try to get igv graphs if needed. >> >> -- Tom >> > > > From tom.deneau at amd.com Tue Sep 3 13:45:26 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Sep 2013 20:45:26 +0000 Subject: compiling code that has never been interpreted References: Message-ID: Doug -- False alarm, the nbody test related failures noted below were initialization problems in the junit tests. But getEagerDefault was necessary to resolve several other test failures. -- Tom -----Original Message----- From: Deneau, Tom Sent: Tuesday, September 03, 2013 11:47 AM To: 'Doug Simon' Cc: graal-dev at openjdk.java.net Subject: RE: compiling code that has never been interpreted Doug -- I spoke too soon in saying that GraphBuilderConfiguration.getEagerDefault() solved our problems. There are still a few junit tests that fail if we compile never-previously-executed code even though we are using getEagerDefault. The failures are all variations of the nbody test. I can see the codegen differing very slightly. I will try to send examples. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, September 03, 2013 10:29 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiling code that has never been interpreted On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" wrote: > Doug -- > > Thanks, yet this works. > What is the reason that someone would want eagerResolving turned off? Two reasons (that I can think of): 1. Prevent non-executed code paths causing extra class loading during compilation. 2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, September 03, 2013 10:00 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: compiling code that has never been interpreted > > Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. > > On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: > >> For the HSAIL-based junit tests, we have the following general structure: >> >> 1. run a method in normal java mode >> >> 2. compile same method into HSAIL and dispatch >> >> 3. compare results >> >> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. >> >> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? >> >> I can try to get igv graphs if needed. >> >> -- Tom >> > > > From tom.deneau at amd.com Tue Sep 3 14:12:07 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Sep 2013 21:12:07 +0000 Subject: compiling code that has never been interpreted In-Reply-To: References: Message-ID: Doug -- Can you explain briefly how a non-eager compilation is supposed to look and behave at runtime? For example, if the target method calls something in a class that has not yet been loaded. In our non-eager hsail compilations there was no indication that anything might be missing, but it's possible we weren't handling all the nodes correctly. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, September 03, 2013 10:29 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiling code that has never been interpreted On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" wrote: > Doug -- > > Thanks, yet this works. > What is the reason that someone would want eagerResolving turned off? Two reasons (that I can think of): 1. Prevent non-executed code paths causing extra class loading during compilation. 2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, September 03, 2013 10:00 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: compiling code that has never been interpreted > > Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. > > On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: > >> For the HSAIL-based junit tests, we have the following general structure: >> >> 1. run a method in normal java mode >> >> 2. compile same method into HSAIL and dispatch >> >> 3. compare results >> >> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. >> >> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? >> >> I can try to get igv graphs if needed. >> >> -- Tom >> > > > From doug.simon at oracle.com Tue Sep 3 14:43:43 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Sep 2013 23:43:43 +0200 Subject: compiling code that has never been interpreted In-Reply-To: References: Message-ID: On Sep 3, 2013, at 11:12 PM, "Deneau, Tom" wrote: > Doug -- > > Can you explain briefly how a non-eager compilation is supposed to look and behave at runtime? > For example, if the target method calls something in a class that has not yet been loaded. Instead of a compiled call, you should see a deopt at the unresolved call site (i.e., the position of the invoke bytecode). The method will then execute in the interpreter and if it becomes (or remains) hot, it will be recompiled. This time around, the call will most likely be compiled (assuming the first deopt reflected a meaning phase change in the application). > In our non-eager hsail compilations there was no indication that anything might be missing, but > it's possible we weren't handling all the nodes correctly. > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, September 03, 2013 10:29 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: compiling code that has never been interpreted > > On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> Thanks, yet this works. >> What is the reason that someone would want eagerResolving turned off? > > Two reasons (that I can think of): > > 1. Prevent non-executed code paths causing extra class loading during compilation. > 2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses. > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, September 03, 2013 10:00 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: compiling code that has never been interpreted >> >> Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work. >> >> On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" wrote: >> >>> For the HSAIL-based junit tests, we have the following general structure: >>> >>> 1. run a method in normal java mode >>> >>> 2. compile same method into HSAIL and dispatch >>> >>> 3. compare results >>> >>> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc. (We are compiling with the flag -G:+InlineEverything). We are running --vm server. >>> >>> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted? Or is this not supported? >>> >>> I can try to get igv graphs if needed. >>> >>> -- Tom >>> >> >> >> > > > From Vasanth.Venkatachalam at amd.com Wed Sep 4 07:19:06 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 4 Sep 2013 14:19:06 +0000 Subject: webrev that allows the compilation target runtime to be queried In-Reply-To: <00D55B2C-966B-47B6-A53F-B6A6BEE8DE4C@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73F9024F6@SATLEXDAG02.amd.com> <3B6B0BE6-3CE3-4047-BDB1-DD2D6E96AAE7@oracle.com> <5DD1503F815BD14889DC81D28643E3A73F9059AB@SATLEXDAG02.amd.com> <00D55B2C-966B-47B6-A53F-B6A6BEE8DE4C@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73F905BF3@SATLEXDAG02.amd.com> Can you give me an idea of how long this will take? We have multiple webrevs to submit. Vasanth -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, September 03, 2013 10:48 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: webrev that allows the compilation target runtime to be queried I'll nominate you as an author on the Graal project. This will give you an OpenJDK account. - thomas On Sep 3, 2013, at 5:27 PM, "Venkatachalam, Vasanth" wrote: > Thomas, > > I need an account to be able to upload the webrev. Did you guys ever get that sorted out? If so, can you send me the details? > > Vasanth > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Monday, September 02, 2013 8:05 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev that allows the compilation target runtime to be queried > > Vasanth, > > Can you please upload the webrev/patch and send a link to it (the mailing list drops attachments)? > > Regarding the thread register: It is not a strict requirement that the current thread must always be in a certain register. One could also change Graal to load the current thread from some address on the stack whenever needed. > > - thomas > > On Aug 30, 2013, at 12:17 AM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. >> An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. >> This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. >> >> The attached patch provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. Christian, can you upload a webrev for this to the review site? >> >> In detail, the patch adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. >> >> We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. >> >> With this patch (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. >> >> We'd welcome feedback and suggestions about alternative solutions. >> >> Vasanth >> > > > From christian.thalinger at oracle.com Wed Sep 4 12:37:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 Sep 2013 12:37:52 -0700 Subject: webrev that allows the compilation target runtime to be queried In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F905BF3@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F9024F6@SATLEXDAG02.amd.com> <3B6B0BE6-3CE3-4047-BDB1-DD2D6E96AAE7@oracle.com> <5DD1503F815BD14889DC81D28643E3A73F9059AB@SATLEXDAG02.amd.com> <00D55B2C-966B-47B6-A53F-B6A6BEE8DE4C@oracle.com> <5DD1503F815BD14889DC81D28643E3A73F905BF3@SATLEXDAG02.amd.com> Message-ID: <8BAB8EA8-74F3-418D-9C5B-DA50DCBD4E1B@oracle.com> On Sep 4, 2013, at 7:19 AM, "Venkatachalam, Vasanth" wrote: > Can you give me an idea of how long this will take? We have multiple webrevs to submit. Why don't you use Tom's account in the meantime? -- Chris > > Vasanth > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Tuesday, September 03, 2013 10:48 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev that allows the compilation target runtime to be queried > > I'll nominate you as an author on the Graal project. This will give you an OpenJDK account. - thomas > > On Sep 3, 2013, at 5:27 PM, "Venkatachalam, Vasanth" wrote: > >> Thomas, >> >> I need an account to be able to upload the webrev. Did you guys ever get that sorted out? If so, can you send me the details? >> >> Vasanth >> >> -----Original Message----- >> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >> Sent: Monday, September 02, 2013 8:05 AM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev that allows the compilation target runtime to be queried >> >> Vasanth, >> >> Can you please upload the webrev/patch and send a link to it (the mailing list drops attachments)? >> >> Regarding the thread register: It is not a strict requirement that the current thread must always be in a certain register. One could also change Graal to load the current thread from some address on the stack whenever needed. >> >> - thomas >> >> On Aug 30, 2013, at 12:17 AM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. >>> An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. >>> This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. >>> >>> The attached patch provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. Christian, can you upload a webrev for this to the review site? >>> >>> In detail, the patch adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. >>> >>> We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. >>> >>> With this patch (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. >>> >>> We'd welcome feedback and suggestions about alternative solutions. >>> >>> Vasanth >>> >> >> >> > > > From doug.simon at oracle.com Sat Sep 7 18:00:12 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 08 Sep 2013 01:00:12 +0000 Subject: hg: graal/graal: 56 new changesets Message-ID: <20130908010331.6061F62661@hg.openjdk.java.net> Changeset: 3662471dcfaa Author: Thomas Wuerthinger Date: 2013-09-01 19:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3662471dcfaa Introduce CompilerDirectives.ValueType annotation in Truffle API. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java Changeset: b36028c30a81 Author: Thomas Wuerthinger Date: 2013-09-01 19:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b36028c30a81 Allow escape analysis to ignore object identity correctness for types marked via the CompilerDirectives.ValueType annotation. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.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.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java Changeset: f778836e07c6 Author: Thomas Wuerthinger Date: 2013-09-01 21:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f778836e07c6 Fix for graph expansion in TruffleCache when the node in the worklist is already deleted. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 94ec1122be13 Author: Roland Schatz Date: 2013-09-02 14:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/94ec1122be13 Change architecture interface. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java Changeset: fc3a6fb4cf3d Author: Roland Schatz Date: 2013-09-02 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fc3a6fb4cf3d Support for PlatformKind in PhiResolver. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/PhiResolver.java Changeset: d2f31e6ddc35 Author: Bernhard Urban Date: 2013-08-29 20:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d2f31e6ddc35 LoweringTool: pass initial lastFixedNode to constructor ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: a116fb4875a6 Author: Bernhard Urban Date: 2013-08-30 15:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a116fb4875a6 SchedulePhase: remove special handling of localnodes ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: d90885b101c3 Author: Bernhard Urban Date: 2013-09-02 15:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d90885b101c3 ifCanonTest: unconnect replaced local nodes from frame state, to match expected graph ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfCanonicalizerTest.java Changeset: 8056b2a9865c Author: Bernhard Urban Date: 2013-09-02 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8056b2a9865c LocalNode: remove special handling, they should be reachable via inputs of other nodes if connected ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java Changeset: be283d587cfc Author: Doug Simon Date: 2013-09-02 16:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/be283d587cfc moved IntrinsificationsEnabled and IntrinsificationsDisabled to new GraalCompiler.Options class documented how GraalCompiler.positiveIntrinsificationsFilter field is used for fast path in shouldIntrinsify() ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java Changeset: 578fc20b9380 Author: Christian Humer Date: 2013-08-30 17:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/578fc20b9380 Truffle-DSL: fixed NPE if wrong invalid child type is declared. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java Changeset: e6645c18d154 Author: Christian Humer Date: 2013-08-30 17:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6645c18d154 Truffle-DSL: reduced generated code size by not generating primarily unused primitive type execute methods. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: d6a5ab791b0d Author: Christian Humer Date: 2013-09-02 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6a5ab791b0d Truffle-DSL: fixed a bug in grouping of abstract guards. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/GuardsTest.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TypeSystemTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationGroup.java Changeset: bb39b1bce748 Author: Christian Humer Date: 2013-09-02 15:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bb39b1bce748 Merge. Changeset: dcaf879d4a7e Author: Christian Humer Date: 2013-09-02 16:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dcaf879d4a7e Truffle-DSL: fixed a compiler warning for fields of type java.lang.Object. (GRAAL-434 #resolve) ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/NodeFieldTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 231958c9ddf9 Author: Christian Humer Date: 2013-09-02 20:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/231958c9ddf9 Merge. Changeset: 3110bea9a6b0 Author: Gilles Duboscq Date: 2013-09-02 11:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3110bea9a6b0 mx: add helper method for yes/no question ! mx/commands.py ! mxtool/mx.py Changeset: 38acec26d535 Author: Gilles Duboscq Date: 2013-09-02 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38acec26d535 If _installed_jdk is set, ask confirmation before building ! mx/commands.py Changeset: 8d4e5e08d83f Author: Gilles Duboscq Date: 2013-09-03 14:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d4e5e08d83f Fix graalCompilerToVM::initializeBytecode regarding bytecode rewritting for methods that are not rewritten. Use the BytecodeStream in a way that does not require pre-processing for breakpoints ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: dc3c8df55905 Author: Doug Simon Date: 2013-09-03 16:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dc3c8df55905 added support for pylint and fixed errors/warnings it found + mx/.pylintrc ! mx/commands.py ! mx/outputparser.py ! mx/sanitycheck.py + mxtool/.pylintrc ! mxtool/mx.py Changeset: 65d2f38c0aa5 Author: Doug Simon Date: 2013-09-03 22:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/65d2f38c0aa5 added timers for Truffle compilation pipeline ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 20b642493616 Author: Mick Jordan Date: 2013-09-03 14:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/20b642493616 CR-1368 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: 1f03076a121b Author: Mick Jordan Date: 2013-09-03 14:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1f03076a121b Merge Changeset: 9ea3658e7c5d Author: Mick Jordan Date: 2013-09-03 14:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ea3658e7c5d Merge Changeset: a3b39ab7c453 Author: Gilles Duboscq Date: 2013-09-03 18:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a3b39ab7c453 Make is_rewritten a guarantee in initializeBytecode ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 7cca436d600b Author: Gilles Duboscq Date: 2013-09-03 18:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7cca436d600b Add isLinked method to ResolvedJavaType ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.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/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: f521a1db1378 Author: Gilles Duboscq Date: 2013-09-03 18:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f521a1db1378 Avoid accessing the code of a method before it has been linked and verified. Add some javadoc to ResolvedJavaMethod.getCode ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: dbf968195ca1 Author: Gilles Duboscq Date: 2013-09-04 09:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dbf968195ca1 use iterable for LoopFragment.toHirBlocks rather than reify collections ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: d4537043ccc8 Author: Gilles Duboscq Date: 2013-09-04 10:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d4537043ccc8 mx: Remove debug printing in specjvm2008 ! mx/commands.py Changeset: dede53632f3e Author: Doug Simon Date: 2013-09-04 13:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dede53632f3e removed Node.modCount field (GRAAL-452) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 75a7d4b79b29 Author: Doug Simon Date: 2013-09-04 14:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75a7d4b79b29 added pylint command ! mx/.pylintrc ! mx/commands.py - mxtool/.pylintrc Changeset: db297343d44e Author: Doug Simon Date: 2013-09-04 14:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db297343d44e added pylint to gate ! mx/commands.py Changeset: c99e65785936 Author: bharadwaj Date: 2013-09-04 10:47 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c99e65785936 Improvements to PTX codegen; allows more PTX tests that run on the device to pass. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXParameterOp.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/gpu_ptx.hpp ! src/gpu/ptx/vm/kernelArguments.hpp Changeset: 8f500c7a510a Author: Doug Simon Date: 2013-09-05 00:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8f500c7a510a inlined NodeUsageList into Node (GRAAL-452) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeInputList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeSuccessorList.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeUsagesList.java Changeset: 6d221435fff9 Author: Gilles Duboscq Date: 2013-09-05 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6d221435fff9 Remove deprecated verify in InstanceOfDynamicNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfDynamicNode.java Changeset: be9e54fbb699 Author: Gilles Duboscq Date: 2013-09-05 10:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/be9e54fbb699 Use a better warning message for building with --installed-jdks set ! mx/commands.py Changeset: 331f7590b741 Author: Doug Simon Date: 2013-09-05 14:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/331f7590b741 modified Node.removeUsage to do less copying (GRAAL-452) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 6a1b7d28f2d4 Author: Doug Simon Date: 2013-09-05 16:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a1b7d28f2d4 replace usages().count() == 0 with usages().isEmpty() ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/RemoveValueProxyPhase.java Changeset: 86830ed062be Author: Doug Simon Date: 2013-09-05 20:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86830ed062be removed tradesoap from the gate - it's simply too unreliable ! mx/sanitycheck.py Changeset: 2d759e68c8ca Author: Doug Simon Date: 2013-09-05 20:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d759e68c8ca pylint only checks versioned python sources ! mx/commands.py Changeset: 8f0fb0ade839 Author: Michael Van De Vanter Date: 2013-09-05 15:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8f0fb0ade839 Truffle: add alternate Node/RootNode constructors with SourceSection argument. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java Changeset: 9021f7761457 Author: Christian Wimmer Date: 2013-09-05 16:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9021f7761457 Inlining only needs to consider invokes of Java methods, i.e., calls with a MethodCallTargetNode ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 7ce08e264abf Author: Christian Wimmer Date: 2013-09-05 16:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7ce08e264abf Fixed registers that flow into a block need to be inputs of the LabelOp, otherwise the register allocator can insert spill moves before the definition of a fixed register. ! 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 ! 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/src/com/oracle/graal/lir/StandardOp.java Changeset: 6317ef27930d Author: Christian Wimmer Date: 2013-09-05 17:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6317ef27930d Merge Changeset: edf875b3c091 Author: Doug Simon Date: 2013-09-06 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/edf875b3c091 use binary search when looking for the end of Node.extraUsages (GRAAL-452) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 601755e6848b Author: Gilles Duboscq Date: 2013-09-06 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/601755e6848b Allow getting modCount fo deleted nodes ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: 189baa5ea5f0 Author: Christian Humer Date: 2013-09-06 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/189baa5ea5f0 Truffle-DSL: extensions to the CodeTreeBuilder. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeBuilder.java Changeset: f15d955897b7 Author: Christian Humer Date: 2013-09-06 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f15d955897b7 Truffle-DSL: fixed message container was redirecting messages too often. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/MessageContainer.java Changeset: 90c45cbbf9de Author: Christian Humer Date: 2013-09-06 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/90c45cbbf9de Truffle-DSL: fixed a bug in isAssignable. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/Utils.java Changeset: e5b5a5cb0ac7 Author: Christian Humer Date: 2013-09-06 16:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5b5a5cb0ac7 Truffle-DSL: polymorphic test asserts now on any child node's parent. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest.java Changeset: 2fb276f5e3e9 Author: Christian Humer Date: 2013-09-06 16:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2fb276f5e3e9 Truffle-DSL: implemented implicit casts. + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ImplicitCastTest.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TypeSystemTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeChildData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/ImplicitCastData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/ImplicitCastParser.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemParser.java Changeset: f1c3f50ac36e Author: Christian Humer Date: 2013-09-06 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f1c3f50ac36e SL: added an implicit cast to SL-type system. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLTypes.java Changeset: cefd4cb3cb2d Author: Christian Humer Date: 2013-09-06 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cefd4cb3cb2d Merge. - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeUsagesList.java Changeset: 6014bd8d52ce Author: Christian Humer Date: 2013-09-06 16:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6014bd8d52ce Merge. Changeset: 794127021076 Author: Bernhard Urban Date: 2013-09-06 18:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/794127021076 pending exception: use locations on a write ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java Changeset: e12218338164 Author: Bernhard Urban Date: 2013-09-06 18:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e12218338164 SnippetTemplate: remove left over dead code elimination phase ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java From java at stefan-marr.de Sun Sep 8 15:20:37 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 9 Sep 2013 00:20:37 +0200 Subject: Optimizing Method Lookup in Truffle In-Reply-To: <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> Message-ID: Hi Thomas: On 10 Aug 2013, at 12:53, Thomas Wuerthinger wrote: > Stefan, > > One of the first steps towards speeding up the implementation is to cache information in the nodes that are useful for subsequent execution. The first candidate for this would be caching the receiverClass and the looked up Invokable instance in the MessageNode class. For this, you need two types of guards: Thanks for the hints. I finally got around to implement specialize MessageNodes that do inline caching [1]. I experimented with a simple monomophic cache and a polymorphic one. However, I have encountered a few difficulties along the way, and it is not yet working perfectly. The first thing I tried was to represent the check for whether the receiver's class is the cached one as an Assumption. Unfortunately, I ran into complains from the Graal stack that certain code paths were compiled which should not have been. So, I changed it to something that seems to be close to the advice you gave to Mark: if (currentRcvrClass == rcvrClass) { // cache hit return invokable.invoke(frame.pack(), rcvr, args); } else { // not a monomorpic send site CompilerDirectives.transferToInterpreter(); PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, arguments, selector, universe, rcvrClass, invokable, currentRcvrClass); this.replace(poly, "It is not a monomorpic send."); return doFullSend(frame, rcvr, args, currentRcvrClass); } A check of whether the invokable hasn't changed isn't included yet, because I got trouble again with invalidation of methods. First, I had issues with @Child/@Children annotations missing on the tree node fields, and adoptChild not being used consistently, but I figured that out. Would be great if Truffle could warn about such issues. I guess, a field in a Node subclass that is of the type of a Node is most likely to be a @Child, and it should most likely be assigned with the return value of adoptChild(.) instead of being assigned directly with the parameter. Since I got that wrong, some replace operations did not succeed completely, and I had uninitialized nodes executing more than once, which was unexpected. After fixing such issues, I now have a working version, but the Queens and Bounce benchmarks run very slowly because some method gets constantly recompiled. The output produced by the following command line is not exactly enlightening. ./mx.sh --vm server vm -XX:+TraceDeoptimization -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som Is there a way to obtain the name of the Method with a given id? Or correlate it with what could be the most likely cause? While you have been debugging these issues earlier for me, it would be great if you could give me some hints on how to debug them myself. What's the approach you would take to figure out the reasons for these invalidations? Thanks a lot Stefan [1] https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From D.Sturm42 at gmail.com Sun Sep 8 15:33:06 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Mon, 9 Sep 2013 00:33:06 +0200 Subject: AMD64Assembler.java:jcc Message-ID: Hi, I'm working on an Aarch64 (new 64-bit ARM ISA) backend at the moment and spend quite a bit of time looking through the two existing backends. The following looks like a bug to me: private void jcc(ConditionFlag cc, int jumpTarget, boolean forceDisp32) { int shortSize = 2; int longSize = 6; long disp = jumpTarget - codeBuffer.position(); [..] assert isInt(disp - longSize) : "must be 32bit offset (call4)"; jumpTarget and codeBuffer.position are both ints and the code probably wants to get the correct offset without integer overflow, but is missing a cast to long. It then goes on and asserts that disp is an int which right now is (almost) always true. On the other hand I'm not sure how it'd be possible for any of the two values to be negative, so it's probably only unnecessary code. -Daniel From chris at chrisseaton.com Mon Sep 9 03:30:38 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Mon, 9 Sep 2013 11:30:38 +0100 Subject: Optimizing Method Lookup in Truffle In-Reply-To: References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> Message-ID: It doesn't look like you assignSourceSection to your RootNode (Method class) anywhere. I think Truffle uses that source section to give a name to methods when in the trace outputs, so if you do that you may get the info you want. Chris On 8 September 2013 23:20, Stefan Marr wrote: > Hi Thomas: > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > Stefan, > > > > One of the first steps towards speeding up the implementation is to > cache information in the nodes that are useful for subsequent execution. > The first candidate for this would be caching the receiverClass and the > looked up Invokable instance in the MessageNode class. For this, you need > two types of guards: > > Thanks for the hints. I finally got around to implement specialize > MessageNodes that do inline caching [1]. > I experimented with a simple monomophic cache and a polymorphic one. > > However, I have encountered a few difficulties along the way, and it is > not yet working perfectly. > > The first thing I tried was to represent the check for whether the > receiver's class is the cached one as an Assumption. > Unfortunately, I ran into complains from the Graal stack that certain code > paths were compiled which should not have been. > So, I changed it to something that seems to be close to the advice you > gave to Mark: > > if (currentRcvrClass == rcvrClass) { // cache hit > return invokable.invoke(frame.pack(), rcvr, args); > } else { // not a monomorpic send site > CompilerDirectives.transferToInterpreter(); > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > arguments, selector, universe, rcvrClass, invokable, currentRcvrClass); > this.replace(poly, "It is not a monomorpic send."); > return doFullSend(frame, rcvr, args, currentRcvrClass); > } > > A check of whether the invokable hasn't changed isn't included yet, > because I got trouble again with invalidation of methods. > > First, I had issues with @Child/@Children annotations missing on the tree > node fields, and adoptChild not being used consistently, but I figured that > out. > Would be great if Truffle could warn about such issues. I guess, a field > in a Node subclass that is of the type of a Node is most likely to be a > @Child, and it should most likely be assigned with the return value of > adoptChild(.) instead of being assigned directly with the parameter. Since > I got that wrong, some replace operations did not succeed completely, and I > had uninitialized nodes executing more than once, which was unexpected. > > After fixing such issues, I now have a working version, but the Queens and > Bounce benchmarks run very slowly because some method gets constantly > recompiled. > The output produced by the following command line is not exactly > enlightening. > > ./mx.sh --vm server vm -XX:+TraceDeoptimization > -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes > som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > Is there a way to obtain the name of the Method with a given id? Or > correlate it with what could be the most likely cause? > While you have been debugging these issues earlier for me, it would be > great if you could give me some hints on how to debug them myself. > What's the approach you would take to figure out the reasons for these > invalidations? > > Thanks a lot > Stefan > > > [1] > https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From chris at chrisseaton.com Mon Sep 9 03:57:54 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Mon, 9 Sep 2013 11:57:54 +0100 Subject: Optimizing Method Lookup in Truffle In-Reply-To: References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> Message-ID: Sorry, then you also need to override toString in method. Eg https://github.com/smarr/TruffleSOM/pull/1 On 9 September 2013 11:30, Chris Seaton wrote: > It doesn't look like you assignSourceSection to your RootNode (Method > class) anywhere. I think Truffle uses that source section to give a name to > methods when in the trace outputs, so if you do that you may get the info > you want. > > Chris > > > On 8 September 2013 23:20, Stefan Marr wrote: > >> Hi Thomas: >> >> On 10 Aug 2013, at 12:53, Thomas Wuerthinger < >> thomas.wuerthinger at oracle.com> wrote: >> >> > Stefan, >> > >> > One of the first steps towards speeding up the implementation is to >> cache information in the nodes that are useful for subsequent execution. >> The first candidate for this would be caching the receiverClass and the >> looked up Invokable instance in the MessageNode class. For this, you need >> two types of guards: >> >> Thanks for the hints. I finally got around to implement specialize >> MessageNodes that do inline caching [1]. >> I experimented with a simple monomophic cache and a polymorphic one. >> >> However, I have encountered a few difficulties along the way, and it is >> not yet working perfectly. >> >> The first thing I tried was to represent the check for whether the >> receiver's class is the cached one as an Assumption. >> Unfortunately, I ran into complains from the Graal stack that certain >> code paths were compiled which should not have been. >> So, I changed it to something that seems to be close to the advice you >> gave to Mark: >> >> if (currentRcvrClass == rcvrClass) { // cache hit >> return invokable.invoke(frame.pack(), rcvr, args); >> } else { // not a monomorpic send site >> CompilerDirectives.transferToInterpreter(); >> PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, >> arguments, selector, universe, rcvrClass, invokable, >> currentRcvrClass); >> this.replace(poly, "It is not a monomorpic send."); >> return doFullSend(frame, rcvr, args, currentRcvrClass); >> } >> >> A check of whether the invokable hasn't changed isn't included yet, >> because I got trouble again with invalidation of methods. >> >> First, I had issues with @Child/@Children annotations missing on the tree >> node fields, and adoptChild not being used consistently, but I figured that >> out. >> Would be great if Truffle could warn about such issues. I guess, a field >> in a Node subclass that is of the type of a Node is most likely to be a >> @Child, and it should most likely be assigned with the return value of >> adoptChild(.) instead of being assigned directly with the parameter. Since >> I got that wrong, some replace operations did not succeed completely, and I >> had uninitialized nodes executing more than once, which was unexpected. >> >> After fixing such issues, I now have a working version, but the Queens >> and Bounce benchmarks run very slowly because some method gets constantly >> recompiled. >> The output produced by the following command line is not exactly >> enlightening. >> >> ./mx.sh --vm server vm -XX:+TraceDeoptimization >> -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes >> som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som >> >> Is there a way to obtain the name of the Method with a given id? Or >> correlate it with what could be the most likely cause? >> While you have been debugging these issues earlier for me, it would be >> great if you could give me some hints on how to debug them myself. >> What's the approach you would take to figure out the reasons for these >> invalidations? >> >> Thanks a lot >> Stefan >> >> >> [1] >> https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf >> >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > From doug.simon at oracle.com Mon Sep 9 03:58:26 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 9 Sep 2013 12:58:26 +0200 Subject: AMD64Assembler.java:jcc In-Reply-To: References: Message-ID: On Sep 9, 2013, at 12:33 AM, "D.Sturm" wrote: > Hi, > I'm working on an Aarch64 (new 64-bit ARM ISA) backend at the moment and > spend quite a bit of time looking through the two existing backends. The > following looks like a bug to me: > > private void jcc(ConditionFlag cc, int jumpTarget, boolean forceDisp32) { > int shortSize = 2; > int longSize = 6; > long disp = jumpTarget - codeBuffer.position(); > [..] > assert isInt(disp - longSize) : "must be 32bit offset (call4)"; > > jumpTarget and codeBuffer.position are both ints and the code probably > wants to get the correct offset without integer overflow, but is missing a > cast to long. It then goes on and asserts that disp is an int which right > now is (almost) always true. > > On the other hand I'm not sure how it'd be possible for any of the two > values to be negative, so it's probably only unnecessary code. You are right - neither jumpTarget nor codeBuffer.position() will ever be negative and hence no need for a cast to a long. -Doug From java at stefan-marr.de Mon Sep 9 04:36:23 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 9 Sep 2013 13:36:23 +0200 Subject: Optimizing Method Lookup in Truffle In-Reply-To: References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> Message-ID: <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> Hi Chris: Thanks, I fixed a couple of issues with nodes missing SourceSection info as well, and added the toString. That's a very useful hint. Didn't make that connection before. Guess I should not have used a name as generic as 'Method' to understand what the debug output meant. Now I see what is going on, and one of the offenders is the True>>ifTrue: method node. The method itself is defined as `ifTrue: block = ( ^block value )`. Another one is Block>>#whileTrue:. Both are most likely megamorphic nodes, and are probably not stabilizing as it would be desirable. How do you handle such cases in other languages? Thanks Stefan On 09 Sep 2013, at 12:57, Chris Seaton wrote: > Sorry, then you also need to override toString in method. > > Eg https://github.com/smarr/TruffleSOM/pull/1 > > > On 9 September 2013 11:30, Chris Seaton wrote: > It doesn't look like you assignSourceSection to your RootNode (Method class) anywhere. I think Truffle uses that source section to give a name to methods when in the trace outputs, so if you do that you may get the info you want. > > Chris > > > On 8 September 2013 23:20, Stefan Marr wrote: > Hi Thomas: > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger wrote: > > > Stefan, > > > > One of the first steps towards speeding up the implementation is to cache information in the nodes that are useful for subsequent execution. The first candidate for this would be caching the receiverClass and the looked up Invokable instance in the MessageNode class. For this, you need two types of guards: > > Thanks for the hints. I finally got around to implement specialize MessageNodes that do inline caching [1]. > I experimented with a simple monomophic cache and a polymorphic one. > > However, I have encountered a few difficulties along the way, and it is not yet working perfectly. > > The first thing I tried was to represent the check for whether the receiver's class is the cached one as an Assumption. > Unfortunately, I ran into complains from the Graal stack that certain code paths were compiled which should not have been. > So, I changed it to something that seems to be close to the advice you gave to Mark: > > if (currentRcvrClass == rcvrClass) { // cache hit > return invokable.invoke(frame.pack(), rcvr, args); > } else { // not a monomorpic send site > CompilerDirectives.transferToInterpreter(); > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > arguments, selector, universe, rcvrClass, invokable, currentRcvrClass); > this.replace(poly, "It is not a monomorpic send."); > return doFullSend(frame, rcvr, args, currentRcvrClass); > } > > A check of whether the invokable hasn't changed isn't included yet, because I got trouble again with invalidation of methods. > > First, I had issues with @Child/@Children annotations missing on the tree node fields, and adoptChild not being used consistently, but I figured that out. > Would be great if Truffle could warn about such issues. I guess, a field in a Node subclass that is of the type of a Node is most likely to be a @Child, and it should most likely be assigned with the return value of adoptChild(.) instead of being assigned directly with the parameter. Since I got that wrong, some replace operations did not succeed completely, and I had uninitialized nodes executing more than once, which was unexpected. > > After fixing such issues, I now have a working version, but the Queens and Bounce benchmarks run very slowly because some method gets constantly recompiled. > The output produced by the following command line is not exactly enlightening. > > ./mx.sh --vm server vm -XX:+TraceDeoptimization -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > Is there a way to obtain the name of the Method with a given id? Or correlate it with what could be the most likely cause? > While you have been debugging these issues earlier for me, it would be great if you could give me some hints on how to debug them myself. > What's the approach you would take to figure out the reasons for these invalidations? > > Thanks a lot > Stefan > > > [1] https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Mon Sep 9 04:57:32 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Mon, 9 Sep 2013 12:57:32 +0100 Subject: Optimizing Method Lookup in Truffle In-Reply-To: <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> Message-ID: I guess ifTrue is polymorphic because it's seeing both the True and False classes (that's how smalltalk works isn't it)? If that's the case you could have a variant of cached-message that is cached-message-iftrue that expects to get a Java boolean value and can actually use Java's if. It's like polymorphic-message but is more clever in that it looks at the boolean value rather than thinking about what class it is. Chris On 9 September 2013 12:36, Stefan Marr wrote: > Hi Chris: > > Thanks, I fixed a couple of issues with nodes missing SourceSection info > as well, and added the toString. > That's a very useful hint. Didn't make that connection before. Guess I > should not have used a name as generic as 'Method' to understand what the > debug output meant. > > Now I see what is going on, and one of the offenders is the True>>ifTrue: > method node. The method itself is defined as `ifTrue: block = ( ^block > value )`. > Another one is Block>>#whileTrue:. Both are most likely megamorphic nodes, > and are probably not stabilizing as it would be desirable. > How do you handle such cases in other languages? > > Thanks > Stefan > > On 09 Sep 2013, at 12:57, Chris Seaton wrote: > > > Sorry, then you also need to override toString in method. > > > > Eg https://github.com/smarr/TruffleSOM/pull/1 > > > > > > On 9 September 2013 11:30, Chris Seaton wrote: > > It doesn't look like you assignSourceSection to your RootNode (Method > class) anywhere. I think Truffle uses that source section to give a name to > methods when in the trace outputs, so if you do that you may get the info > you want. > > > > Chris > > > > > > On 8 September 2013 23:20, Stefan Marr wrote: > > Hi Thomas: > > > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > > > Stefan, > > > > > > One of the first steps towards speeding up the implementation is to > cache information in the nodes that are useful for subsequent execution. > The first candidate for this would be caching the receiverClass and the > looked up Invokable instance in the MessageNode class. For this, you need > two types of guards: > > > > Thanks for the hints. I finally got around to implement specialize > MessageNodes that do inline caching [1]. > > I experimented with a simple monomophic cache and a polymorphic one. > > > > However, I have encountered a few difficulties along the way, and it is > not yet working perfectly. > > > > The first thing I tried was to represent the check for whether the > receiver's class is the cached one as an Assumption. > > Unfortunately, I ran into complains from the Graal stack that certain > code paths were compiled which should not have been. > > So, I changed it to something that seems to be close to the advice you > gave to Mark: > > > > if (currentRcvrClass == rcvrClass) { // cache hit > > return invokable.invoke(frame.pack(), rcvr, args); > > } else { // not a monomorpic send site > > CompilerDirectives.transferToInterpreter(); > > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > > arguments, selector, universe, rcvrClass, invokable, > currentRcvrClass); > > this.replace(poly, "It is not a monomorpic send."); > > return doFullSend(frame, rcvr, args, currentRcvrClass); > > } > > > > A check of whether the invokable hasn't changed isn't included yet, > because I got trouble again with invalidation of methods. > > > > First, I had issues with @Child/@Children annotations missing on the > tree node fields, and adoptChild not being used consistently, but I figured > that out. > > Would be great if Truffle could warn about such issues. I guess, a field > in a Node subclass that is of the type of a Node is most likely to be a > @Child, and it should most likely be assigned with the return value of > adoptChild(.) instead of being assigned directly with the parameter. Since > I got that wrong, some replace operations did not succeed completely, and I > had uninitialized nodes executing more than once, which was unexpected. > > > > After fixing such issues, I now have a working version, but the Queens > and Bounce benchmarks run very slowly because some method gets constantly > recompiled. > > The output produced by the following command line is not exactly > enlightening. > > > > ./mx.sh --vm server vm -XX:+TraceDeoptimization > -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes > som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > > > Is there a way to obtain the name of the Method with a given id? Or > correlate it with what could be the most likely cause? > > While you have been debugging these issues earlier for me, it would be > great if you could give me some hints on how to debug them myself. > > What's the approach you would take to figure out the reasons for these > invalidations? > > > > Thanks a lot > > Stefan > > > > > > [1] > https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Mon Sep 9 05:20:48 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 9 Sep 2013 14:20:48 +0200 Subject: Optimizing Method Lookup in Truffle In-Reply-To: References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> Message-ID: <11F94A84-8E5B-4405-AD4C-B3F3435102B0@stefan-marr.de> Hi Chris: On 09 Sep 2013, at 13:57, Chris Seaton wrote: > I guess ifTrue is polymorphic because it's seeing both the True and False classes (that's how smalltalk works isn't it)? If that's the case you could have a variant of cached-message that is cached-message-iftrue that expects to get a Java boolean value and can actually use Java's if. It's like polymorphic-message but is more clever in that it looks at the boolean value rather than thinking about what class it is. I have to look into it further, but my intuition tells me that the body of #ifTrue: is the problem. The debug output talks about True>>#ifTrue: being invalidated. So, I guess, Graal/Truffle try to take this expression: `^block value` and inline it. `block` is here a lambda passed as a parameter. Typical code would look like this: (someVar > 5) ifTrue: [do something]. (i < 10) ifTrue: [do something else]. If Graal/Truffle constantly try to inline different blocks that would lead to such ongoing recompilations, I guess. With the polymorpic inline cache, I guess, I am kind of close to the cached-message-iftrue you propose. That behavior also only started to pop up with the inline caches. So, I guess the problem is rather the block than the polymorphic #ifTrue send itself. Best regards Stefan > > Chris > > > On 9 September 2013 12:36, Stefan Marr wrote: > Hi Chris: > > Thanks, I fixed a couple of issues with nodes missing SourceSection info as well, and added the toString. > That's a very useful hint. Didn't make that connection before. Guess I should not have used a name as generic as 'Method' to understand what the debug output meant. > > Now I see what is going on, and one of the offenders is the True>>ifTrue: method node. The method itself is defined as `ifTrue: block = ( ^block value )`. > Another one is Block>>#whileTrue:. Both are most likely megamorphic nodes, and are probably not stabilizing as it would be desirable. > How do you handle such cases in other languages? > > Thanks > Stefan > > On 09 Sep 2013, at 12:57, Chris Seaton wrote: > > > Sorry, then you also need to override toString in method. > > > > Eg https://github.com/smarr/TruffleSOM/pull/1 > > > > > > On 9 September 2013 11:30, Chris Seaton wrote: > > It doesn't look like you assignSourceSection to your RootNode (Method class) anywhere. I think Truffle uses that source section to give a name to methods when in the trace outputs, so if you do that you may get the info you want. > > > > Chris > > > > > > On 8 September 2013 23:20, Stefan Marr wrote: > > Hi Thomas: > > > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger wrote: > > > > > Stefan, > > > > > > One of the first steps towards speeding up the implementation is to cache information in the nodes that are useful for subsequent execution. The first candidate for this would be caching the receiverClass and the looked up Invokable instance in the MessageNode class. For this, you need two types of guards: > > > > Thanks for the hints. I finally got around to implement specialize MessageNodes that do inline caching [1]. > > I experimented with a simple monomophic cache and a polymorphic one. > > > > However, I have encountered a few difficulties along the way, and it is not yet working perfectly. > > > > The first thing I tried was to represent the check for whether the receiver's class is the cached one as an Assumption. > > Unfortunately, I ran into complains from the Graal stack that certain code paths were compiled which should not have been. > > So, I changed it to something that seems to be close to the advice you gave to Mark: > > > > if (currentRcvrClass == rcvrClass) { // cache hit > > return invokable.invoke(frame.pack(), rcvr, args); > > } else { // not a monomorpic send site > > CompilerDirectives.transferToInterpreter(); > > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > > arguments, selector, universe, rcvrClass, invokable, currentRcvrClass); > > this.replace(poly, "It is not a monomorpic send."); > > return doFullSend(frame, rcvr, args, currentRcvrClass); > > } > > > > A check of whether the invokable hasn't changed isn't included yet, because I got trouble again with invalidation of methods. > > > > First, I had issues with @Child/@Children annotations missing on the tree node fields, and adoptChild not being used consistently, but I figured that out. > > Would be great if Truffle could warn about such issues. I guess, a field in a Node subclass that is of the type of a Node is most likely to be a @Child, and it should most likely be assigned with the return value of adoptChild(.) instead of being assigned directly with the parameter. Since I got that wrong, some replace operations did not succeed completely, and I had uninitialized nodes executing more than once, which was unexpected. > > > > After fixing such issues, I now have a working version, but the Queens and Bounce benchmarks run very slowly because some method gets constantly recompiled. > > The output produced by the following command line is not exactly enlightening. > > > > ./mx.sh --vm server vm -XX:+TraceDeoptimization -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > > > Is there a way to obtain the name of the Method with a given id? Or correlate it with what could be the most likely cause? > > While you have been debugging these issues earlier for me, it would be great if you could give me some hints on how to debug them myself. > > What's the approach you would take to figure out the reasons for these invalidations? > > > > Thanks a lot > > Stefan > > > > > > [1] https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Mon Sep 9 07:05:17 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Mon, 9 Sep 2013 15:05:17 +0100 Subject: Optimizing Method Lookup in Truffle In-Reply-To: <11F94A84-8E5B-4405-AD4C-B3F3435102B0@stefan-marr.de> References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> <11F94A84-8E5B-4405-AD4C-B3F3435102B0@stefan-marr.de> Message-ID: Ah, I see what you mean. To get around this you will probably have to look at cloning your implementation of ifTrue for each call site. Then each call site calls a different copy of the implementation of ifTrue, which can independently specialise. I haven't done this myself, but I know it's an anticipated use-case of Truffle, and is probably mentioned in the papers. Chris On 9 September 2013 13:20, Stefan Marr wrote: > Hi Chris: > > On 09 Sep 2013, at 13:57, Chris Seaton wrote: > > > I guess ifTrue is polymorphic because it's seeing both the True and > False classes (that's how smalltalk works isn't it)? If that's the case you > could have a variant of cached-message that is cached-message-iftrue that > expects to get a Java boolean value and can actually use Java's if. It's > like polymorphic-message but is more clever in that it looks at the boolean > value rather than thinking about what class it is. > > I have to look into it further, but my intuition tells me that the body of > #ifTrue: is the problem. > The debug output talks about True>>#ifTrue: being invalidated. > So, I guess, Graal/Truffle try to take this expression: `^block value` > and inline it. > `block` is here a lambda passed as a parameter. Typical code would look > like this: > > (someVar > 5) ifTrue: [do something]. > (i < 10) ifTrue: [do something else]. > > If Graal/Truffle constantly try to inline different blocks that would lead > to such ongoing recompilations, I guess. > > With the polymorpic inline cache, I guess, I am kind of close to the > cached-message-iftrue you propose. That behavior also only started to pop > up with the inline caches. So, I guess the problem is rather the block than > the polymorphic #ifTrue send itself. > > Best regards > Stefan > > > > > > Chris > > > > > > On 9 September 2013 12:36, Stefan Marr wrote: > > Hi Chris: > > > > Thanks, I fixed a couple of issues with nodes missing SourceSection info > as well, and added the toString. > > That's a very useful hint. Didn't make that connection before. Guess I > should not have used a name as generic as 'Method' to understand what the > debug output meant. > > > > Now I see what is going on, and one of the offenders is the > True>>ifTrue: method node. The method itself is defined as `ifTrue: block > = ( ^block value )`. > > Another one is Block>>#whileTrue:. Both are most likely megamorphic > nodes, and are probably not stabilizing as it would be desirable. > > How do you handle such cases in other languages? > > > > Thanks > > Stefan > > > > On 09 Sep 2013, at 12:57, Chris Seaton wrote: > > > > > Sorry, then you also need to override toString in method. > > > > > > Eg https://github.com/smarr/TruffleSOM/pull/1 > > > > > > > > > On 9 September 2013 11:30, Chris Seaton wrote: > > > It doesn't look like you assignSourceSection to your RootNode (Method > class) anywhere. I think Truffle uses that source section to give a name to > methods when in the trace outputs, so if you do that you may get the info > you want. > > > > > > Chris > > > > > > > > > On 8 September 2013 23:20, Stefan Marr wrote: > > > Hi Thomas: > > > > > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > > > > > Stefan, > > > > > > > > One of the first steps towards speeding up the implementation is to > cache information in the nodes that are useful for subsequent execution. > The first candidate for this would be caching the receiverClass and the > looked up Invokable instance in the MessageNode class. For this, you need > two types of guards: > > > > > > Thanks for the hints. I finally got around to implement specialize > MessageNodes that do inline caching [1]. > > > I experimented with a simple monomophic cache and a polymorphic one. > > > > > > However, I have encountered a few difficulties along the way, and it > is not yet working perfectly. > > > > > > The first thing I tried was to represent the check for whether the > receiver's class is the cached one as an Assumption. > > > Unfortunately, I ran into complains from the Graal stack that certain > code paths were compiled which should not have been. > > > So, I changed it to something that seems to be close to the advice you > gave to Mark: > > > > > > if (currentRcvrClass == rcvrClass) { // cache hit > > > return invokable.invoke(frame.pack(), rcvr, args); > > > } else { // not a monomorpic send site > > > CompilerDirectives.transferToInterpreter(); > > > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > > > arguments, selector, universe, rcvrClass, invokable, > currentRcvrClass); > > > this.replace(poly, "It is not a monomorpic send."); > > > return doFullSend(frame, rcvr, args, currentRcvrClass); > > > } > > > > > > A check of whether the invokable hasn't changed isn't included yet, > because I got trouble again with invalidation of methods. > > > > > > First, I had issues with @Child/@Children annotations missing on the > tree node fields, and adoptChild not being used consistently, but I figured > that out. > > > Would be great if Truffle could warn about such issues. I guess, a > field in a Node subclass that is of the type of a Node is most likely to be > a @Child, and it should most likely be assigned with the return value of > adoptChild(.) instead of being assigned directly with the parameter. Since > I got that wrong, some replace operations did not succeed completely, and I > had uninitialized nodes executing more than once, which was unexpected. > > > > > > After fixing such issues, I now have a working version, but the Queens > and Bounce benchmarks run very slowly because some method gets constantly > recompiled. > > > The output produced by the following command line is not exactly > enlightening. > > > > > > ./mx.sh --vm server vm -XX:+TraceDeoptimization > -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes > som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > > > > > Is there a way to obtain the name of the Method with a given id? Or > correlate it with what could be the most likely cause? > > > While you have been debugging these issues earlier for me, it would be > great if you could give me some hints on how to debug them myself. > > > What's the approach you would take to figure out the reasons for these > invalidations? > > > > > > Thanks a lot > > > Stefan > > > > > > > > > [1] > https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > > > > > > > -- > > > Stefan Marr > > > Software Languages Lab > > > Vrije Universiteit Brussel > > > Pleinlaan 2 / B-1050 Brussels / Belgium > > > http://soft.vub.ac.be/~smarr > > > Phone: +32 2 629 2974 > > > Fax: +32 2 629 3525 > > > > > > > > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Mon Sep 9 07:31:47 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 9 Sep 2013 16:31:47 +0200 Subject: Optimizing Method Lookup in Truffle In-Reply-To: References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> <11F94A84-8E5B-4405-AD4C-B3F3435102B0@stefan-marr.de> Message-ID: <52A46B64-F228-45D1-BEDC-2ABEB46E192B@stefan-marr.de> Hi: On 09 Sep 2013, at 16:05, Chris Seaton wrote: > Ah, I see what you mean. To get around this you will probably have to look at cloning your implementation of ifTrue for each call site. Then each call site calls a different copy of the implementation of ifTrue, which can independently specialise. I haven't done this myself, but I know it's an anticipated use-case of Truffle, and is probably mentioned in the papers. Yes, that sounds about right. I was thinking in the same direction, but I am wondering whether there are already 'proven' approaches. Methods taking blocks aren't exactly uncommon, and I anticipate a greater need for such node inlining specializations. So, I would like to avoid hardcoding special cases for the boolean #ifTrue: and #ifFalse: because the library contains more of these cases, #whileTrue: being just another example. Browsing through the Truffle API, if found the InlinableCallSite and InlinedCallSite interfaces. That sounds interesting, but gripping through the graal repository doesn't yield any uses. Would the idea be to implement these interfaces for instance in the Method node class to enable such inlining/specialization? Thanks Stefan > > Chris > > > > > On 9 September 2013 13:20, Stefan Marr wrote: > Hi Chris: > > On 09 Sep 2013, at 13:57, Chris Seaton wrote: > > > I guess ifTrue is polymorphic because it's seeing both the True and False classes (that's how smalltalk works isn't it)? If that's the case you could have a variant of cached-message that is cached-message-iftrue that expects to get a Java boolean value and can actually use Java's if. It's like polymorphic-message but is more clever in that it looks at the boolean value rather than thinking about what class it is. > > I have to look into it further, but my intuition tells me that the body of #ifTrue: is the problem. > The debug output talks about True>>#ifTrue: being invalidated. > So, I guess, Graal/Truffle try to take this expression: `^block value` and inline it. > `block` is here a lambda passed as a parameter. Typical code would look like this: > > (someVar > 5) ifTrue: [do something]. > (i < 10) ifTrue: [do something else]. > > If Graal/Truffle constantly try to inline different blocks that would lead to such ongoing recompilations, I guess. > > With the polymorpic inline cache, I guess, I am kind of close to the cached-message-iftrue you propose. That behavior also only started to pop up with the inline caches. So, I guess the problem is rather the block than the polymorphic #ifTrue send itself. > > Best regards > Stefan > > > > > > Chris > > > > > > On 9 September 2013 12:36, Stefan Marr wrote: > > Hi Chris: > > > > Thanks, I fixed a couple of issues with nodes missing SourceSection info as well, and added the toString. > > That's a very useful hint. Didn't make that connection before. Guess I should not have used a name as generic as 'Method' to understand what the debug output meant. > > > > Now I see what is going on, and one of the offenders is the True>>ifTrue: method node. The method itself is defined as `ifTrue: block = ( ^block value )`. > > Another one is Block>>#whileTrue:. Both are most likely megamorphic nodes, and are probably not stabilizing as it would be desirable. > > How do you handle such cases in other languages? > > > > Thanks > > Stefan > > > > On 09 Sep 2013, at 12:57, Chris Seaton wrote: > > > > > Sorry, then you also need to override toString in method. > > > > > > Eg https://github.com/smarr/TruffleSOM/pull/1 > > > > > > > > > On 9 September 2013 11:30, Chris Seaton wrote: > > > It doesn't look like you assignSourceSection to your RootNode (Method class) anywhere. I think Truffle uses that source section to give a name to methods when in the trace outputs, so if you do that you may get the info you want. > > > > > > Chris > > > > > > > > > On 8 September 2013 23:20, Stefan Marr wrote: > > > Hi Thomas: > > > > > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger wrote: > > > > > > > Stefan, > > > > > > > > One of the first steps towards speeding up the implementation is to cache information in the nodes that are useful for subsequent execution. The first candidate for this would be caching the receiverClass and the looked up Invokable instance in the MessageNode class. For this, you need two types of guards: > > > > > > Thanks for the hints. I finally got around to implement specialize MessageNodes that do inline caching [1]. > > > I experimented with a simple monomophic cache and a polymorphic one. > > > > > > However, I have encountered a few difficulties along the way, and it is not yet working perfectly. > > > > > > The first thing I tried was to represent the check for whether the receiver's class is the cached one as an Assumption. > > > Unfortunately, I ran into complains from the Graal stack that certain code paths were compiled which should not have been. > > > So, I changed it to something that seems to be close to the advice you gave to Mark: > > > > > > if (currentRcvrClass == rcvrClass) { // cache hit > > > return invokable.invoke(frame.pack(), rcvr, args); > > > } else { // not a monomorpic send site > > > CompilerDirectives.transferToInterpreter(); > > > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > > > arguments, selector, universe, rcvrClass, invokable, currentRcvrClass); > > > this.replace(poly, "It is not a monomorpic send."); > > > return doFullSend(frame, rcvr, args, currentRcvrClass); > > > } > > > > > > A check of whether the invokable hasn't changed isn't included yet, because I got trouble again with invalidation of methods. > > > > > > First, I had issues with @Child/@Children annotations missing on the tree node fields, and adoptChild not being used consistently, but I figured that out. > > > Would be great if Truffle could warn about such issues. I guess, a field in a Node subclass that is of the type of a Node is most likely to be a @Child, and it should most likely be assigned with the return value of adoptChild(.) instead of being assigned directly with the parameter. Since I got that wrong, some replace operations did not succeed completely, and I had uninitialized nodes executing more than once, which was unexpected. > > > > > > After fixing such issues, I now have a working version, but the Queens and Bounce benchmarks run very slowly because some method gets constantly recompiled. > > > The output produced by the following command line is not exactly enlightening. > > > > > > ./mx.sh --vm server vm -XX:+TraceDeoptimization -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > > > > > Is there a way to obtain the name of the Method with a given id? Or correlate it with what could be the most likely cause? > > > While you have been debugging these issues earlier for me, it would be great if you could give me some hints on how to debug them myself. > > > What's the approach you would take to figure out the reasons for these invalidations? > > > > > > Thanks a lot > > > Stefan > > > > > > > > > [1] https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > > > > > > > -- > > > Stefan Marr > > > Software Languages Lab > > > Vrije Universiteit Brussel > > > Pleinlaan 2 / B-1050 Brussels / Belgium > > > http://soft.vub.ac.be/~smarr > > > Phone: +32 2 629 2974 > > > Fax: +32 2 629 3525 > > > > > > > > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Mon Sep 9 09:06:38 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Mon, 9 Sep 2013 17:06:38 +0100 Subject: Optimizing Method Lookup in Truffle In-Reply-To: <52A46B64-F228-45D1-BEDC-2ABEB46E192B@stefan-marr.de> References: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de> <52017F8B.7060605@jku.at> <52022EFF.2000904@jku.at> <5202786D.4030600@jku.at> <9276D3D3-BD9D-4C49-8531-16C8BFE8E6BB@oracle.com> <5202C17C.80407@jku.at> <76466C39-567E-4577-87E8-82E1572F4806@stefan-marr.de> <4404D2E4-BCE2-4384-9E9A-0A7C985B5E33@oracle.com> <57D65196-7289-4194-AFDE-06FB687681DD@stefan-marr.de> <11F94A84-8E5B-4405-AD4C-B3F3435102B0@stefan-marr.de> <52A46B64-F228-45D1-BEDC-2ABEB46E192B@stefan-marr.de> Message-ID: I haven't used InlinableCallSite or InlinedCallSite - you'll need someone else to comment on that. But when I say inlining I mean doing it yourself, at the level of nodes. So your ifTrue method has no local variables, so you can actually have an @Child in your inlined-call-site node that refers directly to a copy of the entire callee tree - so there is no Truffle call site at all - it's just a bigger tree and Truffle doesn't know or care that this sub-tree came from somewhere else. You are right that you probably want to carefully think through a system for managing this inlining, and not doing it adhoc for just a few methods. Again, other people might be able to give you more experience there. Chris On 9 September 2013 15:31, Stefan Marr wrote: > Hi: > > On 09 Sep 2013, at 16:05, Chris Seaton wrote: > > > Ah, I see what you mean. To get around this you will probably have to > look at cloning your implementation of ifTrue for each call site. Then each > call site calls a different copy of the implementation of ifTrue, which can > independently specialise. I haven't done this myself, but I know it's an > anticipated use-case of Truffle, and is probably mentioned in the papers. > > Yes, that sounds about right. > I was thinking in the same direction, but I am wondering whether there are > already 'proven' approaches. > > Methods taking blocks aren't exactly uncommon, and I anticipate a greater > need for such node inlining specializations. > So, I would like to avoid hardcoding special cases for the boolean > #ifTrue: and #ifFalse: because the library contains more of these cases, > #whileTrue: being just another example. > > Browsing through the Truffle API, if found the InlinableCallSite and > InlinedCallSite interfaces. That sounds interesting, but gripping through > the graal repository doesn't yield any uses. > > Would the idea be to implement these interfaces for instance in the Method > node class to enable such inlining/specialization? > > Thanks > Stefan > > > > > > > > Chris > > > > > > > > > > On 9 September 2013 13:20, Stefan Marr wrote: > > Hi Chris: > > > > On 09 Sep 2013, at 13:57, Chris Seaton wrote: > > > > > I guess ifTrue is polymorphic because it's seeing both the True and > False classes (that's how smalltalk works isn't it)? If that's the case you > could have a variant of cached-message that is cached-message-iftrue that > expects to get a Java boolean value and can actually use Java's if. It's > like polymorphic-message but is more clever in that it looks at the boolean > value rather than thinking about what class it is. > > > > I have to look into it further, but my intuition tells me that the body > of #ifTrue: is the problem. > > The debug output talks about True>>#ifTrue: being invalidated. > > So, I guess, Graal/Truffle try to take this expression: `^block value` > and inline it. > > `block` is here a lambda passed as a parameter. Typical code would look > like this: > > > > (someVar > 5) ifTrue: [do something]. > > (i < 10) ifTrue: [do something else]. > > > > If Graal/Truffle constantly try to inline different blocks that would > lead to such ongoing recompilations, I guess. > > > > With the polymorpic inline cache, I guess, I am kind of close to the > cached-message-iftrue you propose. That behavior also only started to pop > up with the inline caches. So, I guess the problem is rather the block than > the polymorphic #ifTrue send itself. > > > > Best regards > > Stefan > > > > > > > > > > Chris > > > > > > > > > On 9 September 2013 12:36, Stefan Marr wrote: > > > Hi Chris: > > > > > > Thanks, I fixed a couple of issues with nodes missing SourceSection > info as well, and added the toString. > > > That's a very useful hint. Didn't make that connection before. Guess I > should not have used a name as generic as 'Method' to understand what the > debug output meant. > > > > > > Now I see what is going on, and one of the offenders is the > True>>ifTrue: method node. The method itself is defined as `ifTrue: block > = ( ^block value )`. > > > Another one is Block>>#whileTrue:. Both are most likely megamorphic > nodes, and are probably not stabilizing as it would be desirable. > > > How do you handle such cases in other languages? > > > > > > Thanks > > > Stefan > > > > > > On 09 Sep 2013, at 12:57, Chris Seaton wrote: > > > > > > > Sorry, then you also need to override toString in method. > > > > > > > > Eg https://github.com/smarr/TruffleSOM/pull/1 > > > > > > > > > > > > On 9 September 2013 11:30, Chris Seaton > wrote: > > > > It doesn't look like you assignSourceSection to your RootNode > (Method class) anywhere. I think Truffle uses that source section to give a > name to methods when in the trace outputs, so if you do that you may get > the info you want. > > > > > > > > Chris > > > > > > > > > > > > On 8 September 2013 23:20, Stefan Marr wrote: > > > > Hi Thomas: > > > > > > > > On 10 Aug 2013, at 12:53, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > > > > > > > Stefan, > > > > > > > > > > One of the first steps towards speeding up the implementation is > to cache information in the nodes that are useful for subsequent execution. > The first candidate for this would be caching the receiverClass and the > looked up Invokable instance in the MessageNode class. For this, you need > two types of guards: > > > > > > > > Thanks for the hints. I finally got around to implement specialize > MessageNodes that do inline caching [1]. > > > > I experimented with a simple monomophic cache and a polymorphic one. > > > > > > > > However, I have encountered a few difficulties along the way, and it > is not yet working perfectly. > > > > > > > > The first thing I tried was to represent the check for whether the > receiver's class is the cached one as an Assumption. > > > > Unfortunately, I ran into complains from the Graal stack that > certain code paths were compiled which should not have been. > > > > So, I changed it to something that seems to be close to the advice > you gave to Mark: > > > > > > > > if (currentRcvrClass == rcvrClass) { // cache hit > > > > return invokable.invoke(frame.pack(), rcvr, args); > > > > } else { // not a monomorpic send site > > > > CompilerDirectives.transferToInterpreter(); > > > > PolymorpicMessageNode poly = new PolymorpicMessageNode(receiver, > > > > arguments, selector, universe, rcvrClass, invokable, > currentRcvrClass); > > > > this.replace(poly, "It is not a monomorpic send."); > > > > return doFullSend(frame, rcvr, args, currentRcvrClass); > > > > } > > > > > > > > A check of whether the invokable hasn't changed isn't included yet, > because I got trouble again with invalidation of methods. > > > > > > > > First, I had issues with @Child/@Children annotations missing on the > tree node fields, and adoptChild not being used consistently, but I figured > that out. > > > > Would be great if Truffle could warn about such issues. I guess, a > field in a Node subclass that is of the type of a Node is most likely to be > a @Child, and it should most likely be assigned with the return value of > adoptChild(.) instead of being assigned directly with the parameter. Since > I got that wrong, some replace operations did not succeed completely, and I > had uninitialized nodes executing more than once, which was unexpected. > > > > > > > > After fixing such issues, I now have a working version, but the > Queens and Bounce benchmarks run very slowly because some method gets > constantly recompiled. > > > > The output produced by the following command line is not exactly > enlightening. > > > > > > > > ./mx.sh --vm server vm -XX:+TraceDeoptimization > -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes > som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Queens.som > > > > > > > > Is there a way to obtain the name of the Method with a given id? Or > correlate it with what could be the most likely cause? > > > > While you have been debugging these issues earlier for me, it would > be great if you could give me some hints on how to debug them myself. > > > > What's the approach you would take to figure out the reasons for > these invalidations? > > > > > > > > Thanks a lot > > > > Stefan > > > > > > > > > > > > [1] > https://github.com/smarr/TruffleSOM/commit/a1769ac439b2219006a3b888fe7c672b0f65eadf > > > > > > > > > > > > -- > > > > Stefan Marr > > > > Software Languages Lab > > > > Vrije Universiteit Brussel > > > > Pleinlaan 2 / B-1050 Brussels / Belgium > > > > http://soft.vub.ac.be/~smarr > > > > Phone: +32 2 629 2974 > > > > Fax: +32 2 629 3525 > > > > > > > > > > > > > > > > > > -- > > > Stefan Marr > > > Software Languages Lab > > > Vrije Universiteit Brussel > > > Pleinlaan 2 / B-1050 Brussels / Belgium > > > http://soft.vub.ac.be/~smarr > > > Phone: +32 2 629 2974 > > > Fax: +32 2 629 3525 > > > > > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From Vasanth.Venkatachalam at amd.com Mon Sep 9 09:27:50 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 9 Sep 2013 16:27:50 +0000 Subject: question about calling convention changes Message-ID: <5DD1503F815BD14889DC81D28643E3A73F90C681@SATLEXDAG02.amd.com> Hi, I'm looking for some guidance on changes I'm implementing to get my HSAIL backend to use a calling convention that's more aligned with the convention that HSAIL uses. In HSAIL, function parameters are passed in memory (in an Arg segment) instead of in registers. In the prologue of the function, the caller then loads these arguments from the Arg segment into registers. The code of the function prologue would ook like this: function &bar (arg_s32 %_result) ( arg_s32 %_arg0, arg_s32 %_arg1 ) { ld_arg_s32 $s0, [%_arg0]; //load arguments into registers. ld_arg_s32 $s1, [%_arg1]; To put things in context, the function would be called like this: { arg_s32 %_methodArg_0; //declare memory for the first param arg_s32 %_methodArg_1; //declare memory for the second param arg_s32 %_outVal; //declare memory for the result st_arg_s32 $s0, [%_methodArg_0]; //store to the memory location for the first param st_arg_s32 $s1, [%_methodArg_1]; //store to the memory location for the second param call &bar (%_outVal) (%_methodArg_0, %_methodArg_1); //call the function. ld_arg_s32 $s0, [%_outVal]; //load the result. } As a first step to have Graal emit the proper code in the function prologue, I switched it to use a stack-based calling convention instead of register based. To do this I modified getHSAILCompilationResult to call registerConfig.getCallingConvention( ...Boolean stackOnly) with the stackOnly parameter set to true. When I first made this change, Graal was generating the above loads from the stack instead of the arg segments. So I added extra logic to intercept the loads that are happening in the function prologue and treat them specially so that they load from the arg segment instead of the stack. To do this, I overrode LIRGenerator.emitPrologue() inside HSAiLLIRGenerator so that it passes a Boolean param isPrologue to the emitMove( ) function, which in turn invokes the MoveToRegOp() constructor with the same param, indicating that the move belongs to the prologue. I then made some changes in HSAILMove.emitCode( ) so that it passes this Boolean arg to the code generation routine HSAILMove.move (...Boolean isPrologue ), so that these moves result in a different codegen. As expected, Graal is creating MoveToRegOp nodes in emitPrologue( ) for each for the function params with the above Boolean param set to true. However, it isn't generating the proper code for the very last param. What I find is that for the last param, emitCode( ) is calling HSAILMove.move( ) with the isPrologue parameter set to false. Debugging this issue I found that somewhere down the road, Graal is inserting a moveToReg node (which by default has the isPrologue field set to false) in the cnain of calls MoveResolver.insert( ) -> spillMoveFactory.createMove( ). I suspect this extraneously added movetoRegOp may be the culprit, but I'm not sure how to work around this. Any suggestions? Also, 1) Is my overall approach correct for what I'm trying to do? 2) In the case of a kernel function, the last parameter has to be treated specially. Instead of generating a load for it as above, we need to generate a workitemabsid instruction. Do people have suggestions on where I can add some logic to intercept the last parameter and treat it special when emitting code for the prologue? Vasanth From bharadwaj.yadavalli at oracle.com Mon Sep 9 12:37:45 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 09 Sep 2013 15:37:45 -0400 Subject: question about calling convention changes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F90C681@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F90C681@SATLEXDAG02.amd.com> Message-ID: <522E2389.2050407@oracle.com> Hi Vasanth, On 9/9/2013 12:27 PM, Venkatachalam, Vasanth wrote: > > I'm looking for some guidance on changes I'm implementing to get my > HSAIL backend to use a calling convention that's more aligned with > the convention that HSAIL uses. > I have not seen the HSAIL backend implementation. I am assuming that you have defined a AMD64HotSpotGraalRuntime, CallingConvention and register configuration etc to represent HSAIL. <...> The issues you appear to be addressing during HSAIL codegen seem similar to those that we've been working on for PTX codegen - although, at present, we only emit code for PTX _kernel_ entry prologue (we do not generate PTX _functions_ yet but would expect the basic technique to be similar). > As expected, Graal is creating MoveToRegOp nodes in emitPrologue( ) > for each for the function params with the above Boolean param set to > true. > > However, it isn't generating the proper code for the very last param. > What I find is that for the last param, emitCode( ) is calling > HSAILMove.move( ) with the isPrologue parameter set to false. > > Debugging this issue I found that somewhere down the road, Graal is > inserting a moveToReg node (which by default has the isPrologue field > set to false) in the cnain of calls MoveResolver.insert( ) -> > spillMoveFactory.createMove( ). I suspect this extraneously added > movetoRegOp may be the culprit, but I'm not sure how to work around > this. Any suggestions? > Not sure where that additional moveToReOp is coming from but one place that I encountered such situation is visitReturn() and have an overridden PTXLIRGenerator::visitReturn() to handle this. > Also, > > 1)Is my overall approach correct for what I'm trying to do? > I think overriding emitPrologue() to provide the appropriate implementation for HSAIL architecture is the right way to handle the issue. > 2)In the case of a kernel function, the last parameter has to be > treated specially. Instead of generating a load for it as above, we > need to generate a workitemabsid instruction. Do people have > suggestions on where I can add some logic to intercept the last > parameter and treat it special when emitting code for the prologue? > You may find it informative to look at PTXILIRGenerator()::emitPrologue() and PTXLIRGenerator::visitReturn(). Hope that helps. Bharadwaj From Vasanth.Venkatachalam at amd.com Mon Sep 9 13:17:35 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 9 Sep 2013 20:17:35 +0000 Subject: question about calling convention changes In-Reply-To: <522E2389.2050407@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73F90C681@SATLEXDAG02.amd.com> <522E2389.2050407@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73F90E738@SATLEXDAG02.amd.com> Thanks for the reply. I was actually about to reply to my own email. Upon closer inspection, I think the real solution here is to add support for a CallingConvention model that's based on parameters being passed via an arg segment. Currently Graal supports either a register-based model or a stack-based model, but HSAIL uses a different model altogether. Function params are not passed in registers or on the stack. They are instead passed via an Arg segment in memory, as described in my earlier email below. So rather than trying to get all this to work using the existing approach of stackslots, I'm proposing to add the support for an arg-segment based calling convention. I think what this will require will be to override HSAILRegisterConfig.getCallingConvention( ) to support this third type of calling convention. The basic idea would be to provide a numbering scheme to keep track of each of the function parameters (instead of using stack slots). The rest of Graal would need to be made aware of these parameters and their locations so that optimization phases don't do anything funny with them. We'd welcome people's feedback on whether this approach sounds reasonable. And Bharadwaj, I'll examine the PTX files you mentioned to see if I can leverage anything from there. Vasanth From: Bharadwaj Yadavalli [mailto:bharadwaj.yadavalli at oracle.com] Sent: Monday, September 09, 2013 2:38 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: question about calling convention changes Hi Vasanth, On 9/9/2013 12:27 PM, Venkatachalam, Vasanth wrote: I'm looking for some guidance on changes I'm implementing to get my HSAIL backend to use a calling convention that's more aligned with the convention that HSAIL uses. I have not seen the HSAIL backend implementation. I am assuming that you have defined a AMD64HotSpotGraalRuntime, CallingConvention and register configuration etc to represent HSAIL. <...> The issues you appear to be addressing during HSAIL codegen seem similar to those that we've been working on for PTX codegen - although, at present, we only emit code for PTX _kernel_ entry prologue (we do not generate PTX _functions_ yet but would expect the basic technique to be similar). As expected, Graal is creating MoveToRegOp nodes in emitPrologue( ) for each for the function params with the above Boolean param set to true. However, it isn't generating the proper code for the very last param. What I find is that for the last param, emitCode( ) is calling HSAILMove.move( ) with the isPrologue parameter set to false. Debugging this issue I found that somewhere down the road, Graal is inserting a moveToReg node (which by default has the isPrologue field set to false) in the cnain of calls MoveResolver.insert( ) -> spillMoveFactory.createMove( ). I suspect this extraneously added movetoRegOp may be the culprit, but I'm not sure how to work around this. Any suggestions? Not sure where that additional moveToReOp is coming from but one place that I encountered such situation is visitReturn() and have an overridden PTXLIRGenerator::visitReturn() to handle this. Also, 1) Is my overall approach correct for what I'm trying to do? I think overriding emitPrologue() to provide the appropriate implementation for HSAIL architecture is the right way to handle the issue. 2) In the case of a kernel function, the last parameter has to be treated specially. Instead of generating a load for it as above, we need to generate a workitemabsid instruction. Do people have suggestions on where I can add some logic to intercept the last parameter and treat it special when emitting code for the prologue? You may find it informative to look at PTXILIRGenerator()::emitPrologue() and PTXLIRGenerator::visitReturn(). Hope that helps. Bharadwaj From tom.deneau at amd.com Mon Sep 9 14:29:16 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 9 Sep 2013 21:29:16 +0000 Subject: atomic add Message-ID: HSAIL has an atomic_add instruction. I would like this instruction to be emitted when we see something like AtomicInteger atomicInt = new AtomicInteger(); xxx = atomicInt.getAndAdd(amount); What are the steps necessary to get this to happen? I would prefer not to go thru a cas for this. (I see on amd64 that the above code maps to a lock cmpxchg sequence) -- Tom From lukas.stadler at jku.at Tue Sep 10 00:33:34 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Tue, 10 Sep 2013 09:33:34 +0200 Subject: atomic add In-Reply-To: References: Message-ID: <6C02D400-CEA6-400E-8EB9-B87DD99AFC96@jku.at> Currently this is handled by the intrinsification of Unsafe.compareAndSwapInt, where it's too late to easily see that it's supposed to be an addition. You could add a substitution class AtomicIntegerSubstitution (similar to UnsafeSubstitution) with a substitution for the add method and use an AtomicAddNode (just like the unsafe substitution uses a CompareAndSwapNode). That node needs to be lowered to an LIR op that does the atomic add. - Lukas On Sep 9, 2013, at 23:29, "Deneau, Tom" wrote: > HSAIL has an atomic_add instruction. I would like this instruction to be emitted when we see something like > > AtomicInteger atomicInt = new AtomicInteger(); > xxx = atomicInt.getAndAdd(amount); > > What are the steps necessary to get this to happen? > > I would prefer not to go thru a cas for this. > (I see on amd64 that the above code maps to a lock cmpxchg sequence) > > -- Tom > > From Vasanth.Venkatachalam at amd.com Tue Sep 10 11:23:10 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 10 Sep 2013 18:23:10 +0000 Subject: webrev: workaround for threadRegister handling Message-ID: <5DD1503F815BD14889DC81D28643E3A73F910961@SATLEXDAG02.amd.com> Hi, We've submitted the following webrev to http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ Please review it. Details: Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. This webrev provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. In detail, the webrev adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. With this webrev (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. We'd welcome feedback and suggestions about alternative solutions. Vasanth From doug.simon at oracle.com Tue Sep 10 11:22:05 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 10 Sep 2013 18:22:05 +0000 Subject: hg: graal/graal: 34 new changesets Message-ID: <20130910182459.1D8A1626D1@hg.openjdk.java.net> Changeset: 63b4694d3627 Author: Doug Simon Date: 2013-09-09 13:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/63b4694d3627 split DebugHistogram printing out into separate service ! graal/com.oracle.graal.debug.test/src/com/oracle/graal/debug/test/DebugHistogramTest.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugHistogram.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramAsciiPrinter.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: a771cc1f10f5 Author: Doug Simon Date: 2013-09-09 17:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a771cc1f10f5 added DebugHistogram printer that emits R statements to instantiate a vector of named values corresponding to the histogram ! graal/com.oracle.graal.debug.test/src/com/oracle/graal/debug/test/DebugHistogramTest.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramRPrinter.java Changeset: 8a2664ad5c55 Author: Doug Simon Date: 2013-09-09 17:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a2664ad5c55 replaced computed internal name for java.lang.System with a constant to workaround deadlock issue involving class initializer of HotSpotResolvedJavaField (CR-1405) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 5d5007c9a5aa Author: Christian Humer Date: 2013-09-08 13:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d5007c9a5aa Truffle-DSL: fixed a if bug target parameters and executes accidently do not match. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 8d52ef9ab876 Author: Bernhard Urban Date: 2013-09-09 11:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d52ef9ab876 Graph: fix index of array access in usageModCount() ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: 7ce149d349c9 Author: Bernhard Urban Date: 2013-09-09 19:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7ce149d349c9 fix usage of IterableNodeType, as some verions of javac seems to have problems with it ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/MaterializeFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/VerifyNoIntrinsicsLeftPhase.java Changeset: e08a9328ce92 Author: Andreas Woess Date: 2013-09-09 22:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e08a9328ce92 Truffle-DSL: allow multiple implicit casts with the same source type. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemParser.java Changeset: c106320fab79 Author: Doug Simon Date: 2013-09-10 00:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c106320fab79 updated README_GRAAL.txt to reflect recent mx changes ! README_GRAAL.txt Changeset: ae00dd0ff81e Author: Doug Simon Date: 2013-09-10 14:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae00dd0ff81e made methods for accessing HotSpot VM options static so they can be used without a HotSpotVMConfig object ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Changeset: 1aa56a2fb08b Author: Doug Simon Date: 2013-09-10 14:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1aa56a2fb08b fix spelling error ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: e1309fc4d17f Author: Doug Simon Date: 2013-09-10 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e1309fc4d17f ensure Debug.enable() is called before any DebugTimer or DebugMetric objects are requested ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: 6b6c6e5d0fc2 Author: Doug Simon Date: 2013-09-10 15:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b6c6e5d0fc2 added support for DebugMetric and DebugTimer objects to be unconditionally enabled (GRAAL-195) ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugMetric.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugTimer.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/MetricImpl.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerCloseable.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: 9d9c944f2940 Author: Doug Simon Date: 2013-09-10 15:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d9c944f2940 removed side effect of -XX:+CITime on -G:Meter and -G:Time (GRAAL-195) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 4cf51b630049 Author: Doug Simon Date: 2013-09-10 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4cf51b630049 re-enabled -G:+DumpOnError ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java Changeset: e231671f39d0 Author: Roland Schatz Date: 2013-09-09 10:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e231671f39d0 Try constant folding in canonicalizer even if tryInferStamp didn't change anything. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: aa9ce8d56771 Author: Roland Schatz Date: 2013-09-10 11:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aa9ce8d56771 New methods for incremental canonicalization. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! 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.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java Changeset: c69df2e602f4 Author: Roland Schatz Date: 2013-09-10 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c69df2e602f4 Use CanonicalizerPhase.applyIncremental in InliningPhase. ! 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/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.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/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.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/tiers/HighTierContext.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java Changeset: ae27f6ac3374 Author: Roland Schatz Date: 2013-09-10 13:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae27f6ac3374 Avoid direct usage of CanonicalizerPhase.Instance in tests. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LoopUnswitchTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ScalarTypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StraighteningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java Changeset: 2f6734f8126a Author: Roland Schatz Date: 2013-09-10 13:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f6734f8126a Avoid direct usage of CanonicalizerPhase.Instance in replacements processing. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: f6cb27e8c9ee Author: Roland Schatz Date: 2013-09-10 13:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6cb27e8c9ee Avoid direct usage of CanonicalizerPhase.Instance in partial evaluator. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/InlineTrivialGettersPhase.java Changeset: 5bbc028f4507 Author: Roland Schatz Date: 2013-09-10 13:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5bbc028f4507 Pass canonicalizer into EffectsPhase. ! 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/EarlyReadEliminationTest.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/PEAReadEliminationTest.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/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EarlyReadEliminationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java Changeset: a63b63822183 Author: Roland Schatz Date: 2013-09-10 14:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a63b63822183 Pass canonicalizer into loop transformations. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopFullUnrollPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 8a3d99fc36cf Author: Roland Schatz Date: 2013-09-10 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a3d99fc36cf Pass canonicalizer into tail duplication. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.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 Changeset: 50577f991923 Author: Roland Schatz Date: 2013-09-10 14:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/50577f991923 Pass canonicalizer into IterativeConditionalEliminationPhase. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IterativeConditionalEliminationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java Changeset: 00672122f256 Author: Roland Schatz Date: 2013-09-10 15:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/00672122f256 Make inner class CanonicalizerPhase.Instance private. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 809609e6abe6 Author: Roland Schatz Date: 2013-09-10 17:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/809609e6abe6 Update changed nodes in incremental canonicalizer. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: d85a75b1b214 Author: Gilles Duboscq Date: 2013-09-10 09:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d85a75b1b214 The lowering of FixedGuardNode is independent of the runtime ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: 81ebb0719dc5 Author: Gilles Duboscq Date: 2013-09-10 11:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/81ebb0719dc5 Replace the many asNode methods with one on ValueNode and one on FixedNode ! 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/FixedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FloatingGuardedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.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/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.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/FloatingAccessNode.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/ValueAnchorNode.java Changeset: ae619d70bf4b Author: Gilles Duboscq Date: 2013-09-10 11:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae619d70bf4b Rename LoweringType to GuardsPhase and make it an attribute of StructuredGraphs ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! 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.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.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/replacements/CallSiteTargetNode.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/UnsafeArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.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/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.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/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NormalizeCompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BranchProbabilityNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/OSRStartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessIndexedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.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.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/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadExceptionObjectNode.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/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewMultiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/SelfReplacingMethodCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Lowerable.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.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.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.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerExactArithmeticSplitNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverInlineMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java Changeset: 5ce62ee0fed7 Author: Gilles Duboscq Date: 2013-09-10 14:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ce62ee0fed7 Remove ShortCircuitAndNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitAndNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitBooleanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ExpandLogicPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java Changeset: 454dc34d041c Author: Gilles Duboscq Date: 2013-09-10 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/454dc34d041c Simplify ExpandLogicPhase after ShortCircuitAndNode removal Fix probability computation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ExpandLogicPhase.java Changeset: 9e12e51fe7b2 Author: Gilles Duboscq Date: 2013-09-10 16:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e12e51fe7b2 Add helper methods with negations for inputs in LogicNode. Use helper method in CheckCastNode lowering ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 69881bec003c Author: Gilles Duboscq Date: 2013-09-10 16:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69881bec003c Fix some comment formatting and spelling ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BinaryNode.java Changeset: 65cedae2647e Author: Gilles Duboscq Date: 2013-09-10 19:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/65cedae2647e Merge ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! 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.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitAndNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitBooleanNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java From christian.thalinger at oracle.com Tue Sep 10 11:32:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Sep 2013 11:32:08 -0700 Subject: question about calling convention changes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F90E738@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F90C681@SATLEXDAG02.amd.com> <522E2389.2050407@oracle.com> <5DD1503F815BD14889DC81D28643E3A73F90E738@SATLEXDAG02.amd.com> Message-ID: <3AABFB8B-7289-46C9-9B81-269E9A80862C@oracle.com> On Sep 9, 2013, at 1:17 PM, "Venkatachalam, Vasanth" wrote: > Thanks for the reply. I was actually about to reply to my own email. > > Upon closer inspection, I think the real solution here is to add support for a CallingConvention model that's based on parameters being passed via an arg segment. > > Currently Graal supports either a register-based model or a stack-based model, but HSAIL uses a different model altogether. Function params are not passed in registers or on the stack. They are instead passed via an Arg segment in memory, as described in my earlier email below. So rather than trying to get all this to work using the existing approach of stackslots, I'm proposing to add the support for an arg-segment based calling convention. > > I think what this will require will be to override HSAILRegisterConfig.getCallingConvention( ) to support this third type of calling convention. The basic idea would be to provide a numbering scheme to keep track of each of the function parameters (instead of using stack slots). The rest of Graal would need to be made aware of these parameters and their locations so that optimization phases don't do anything funny with them. > > We'd welcome people's feedback on whether this approach sounds reasonable. And Bharadwaj, I'll examine the PTX files you mentioned to see if I can leverage anything from there. Maybe adding another calling convention type isn't so bad after all but I'd need to see some code how this would be handled. The easiest way I think would be to do the regular register calling convention and map it to memory slots in the argument segment. You are already doing a lot of parameter related stuff in HSAILBackend.emitCode. Since you have to load them into registers anyway you can use the allocated registers right away. -- Chris > > Vasanth > > From: Bharadwaj Yadavalli [mailto:bharadwaj.yadavalli at oracle.com] > Sent: Monday, September 09, 2013 2:38 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: question about calling convention changes > > Hi Vasanth, > On 9/9/2013 12:27 PM, Venkatachalam, Vasanth wrote: > > I'm looking for some guidance on changes I'm implementing to get my HSAIL backend to use a calling convention that's more aligned with the convention that HSAIL uses. > > I have not seen the HSAIL backend implementation. I am assuming that you have defined a AMD64HotSpotGraalRuntime, CallingConvention and register configuration etc to represent HSAIL. > > <...> > > The issues you appear to be addressing during HSAIL codegen seem similar to those that we've been working on for PTX codegen - although, at present, we only emit code for PTX _kernel_ entry prologue (we do not generate PTX _functions_ yet but would expect the basic technique to be similar). > > > As expected, Graal is creating MoveToRegOp nodes in emitPrologue( ) for each for the function params with the above Boolean param set to true. > However, it isn't generating the proper code for the very last param. What I find is that for the last param, emitCode( ) is calling HSAILMove.move( ) with the isPrologue parameter set to false. > > Debugging this issue I found that somewhere down the road, Graal is inserting a moveToReg node (which by default has the isPrologue field set to false) in the cnain of calls MoveResolver.insert( ) -> spillMoveFactory.createMove( ). I suspect this extraneously added movetoRegOp may be the culprit, but I'm not sure how to work around this. Any suggestions? > > > Not sure where that additional moveToReOp is coming from but one place that I encountered such situation is visitReturn() and have an overridden PTXLIRGenerator::visitReturn() to handle this. > > > Also, > > > 1) Is my overall approach correct for what I'm trying to do? > > I think overriding emitPrologue() to provide the appropriate implementation for HSAIL architecture is the right way to handle the issue. > > > > 2) In the case of a kernel function, the last parameter has to be treated specially. Instead of generating a load for it as above, we need to generate a workitemabsid instruction. Do people have suggestions on where I can add some logic to intercept the last parameter and treat it special when emitting code for the prologue? > > > You may find it informative to look at PTXILIRGenerator()::emitPrologue() and PTXLIRGenerator::visitReturn(). > > Hope that helps. > > Bharadwaj From Vasanth.Venkatachalam at amd.com Tue Sep 10 11:38:01 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 10 Sep 2013 18:38:01 +0000 Subject: webrev for register decoupling changes Message-ID: <5DD1503F815BD14889DC81D28643E3A73F910987@SATLEXDAG02.amd.com> Hi, Graal's register allocator was previously calling into the x86 runtime to get register numbers to be used for generating HSAIL code. The x86 register numbers were getting translated into the corresponding HSAIL register mnemonics in the assembler. This small webrev allows the register allocator to work with the HSAIL register configuration for getting register numbers to be used for generating HSAIL code. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-registerdecoupling/webrev/ Note: HSAIL uses a special calling convention where function params are passed in an arg segment in memory. Currently Graal only supports a choice between a register-based or stack-based calling convention. We have yet to add support for an arg-segment based calling convention. This will be forthcoming in a later patch. However, the current patch makes the code generation more accurate from the point of view of the HSAIL register configuration. Please review and provide your feedback. Vasanth From tom.deneau at amd.com Tue Sep 10 16:06:50 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Sep 2013 23:06:50 +0000 Subject: overriding NewObject snippets Message-ID: For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. What is the right way to do this? -- Tom From java at stefan-marr.de Tue Sep 10 16:20:08 2013 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 11 Sep 2013 01:20:08 +0200 Subject: How to do AST inlining of method calls? Message-ID: Hi: I am experimenting with AST inlining in the TruffleSOM implementation and would like to know what the suggested best practices are. I started to inline monomorphic message sends in order to avoid issues with mega-morphic send sites typically found when evaluating blocks (lambdas). Now I am wondering how far that inlining logic should be pushed. I attempted to just duplicate the relevant AST subtree and leave the nodes themselves more or less untouched. Specifically, this means, I still rely on a frame to be constructed in a new InlinedMonomorphicMessageNode, which I introduced. This approach allows me to preserve the semantics of having a frame, and with it access to the same Smalltalk local variables as previously, even so the AST nodes are inlined in the monomorphic all site. Another problem this design solves is the catching of the same control flow exceptions as the method node that got replaced. Especially, the non-local return still needs to be treated correctly, I think, even with inlining. Currently, my main issue with this naive approach is that I still need to create a VirtualFrame object. This is possible with the frame factory given to the inline(.) method of the InlinableCallSite interface, but it causes problems with the Graal/Truffle compiler. The VerifyFrameDoesNotEscapePhase causes issues, because it sees the frame creation and complains about the fact that the new frame is given to a method call. The executeInlined(..) method below is the relevant fragment. private Object executeInlined(final PackedFrame caller, final Object rcvr, final Object[] args) { final VirtualFrame frame = frameFactory.create( inlinedMethod.getFrameDescriptor(), caller, new Arguments(rcvr, args)); final FrameOnStackMarker marker = Misc.initializeFrame(frame.materialize(), inlinedMethod.getArgumentSlots(), universe.nilObject); return Misc.sendSiteExecution(marker, frame, methodBody); // this or any of the `executeGeneric(VirtualFrame)` calls in it are problematic } So, now the question for me is whether I should avoid the frame creation in the first place, and instead should try to rewrite all nodes that rely on frame access, or whether there is another common solution in other Truffle languages to such issues. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From andreas.woess at jku.at Tue Sep 10 17:31:06 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 11 Sep 2013 02:31:06 +0200 Subject: How to do AST inlining of method calls? In-Reply-To: References: Message-ID: <522FB9CA.4000705@jku.at> Answers inline. On 11.09.2013 01:20, Stefan Marr wrote: > Hi: > > I am experimenting with AST inlining in the TruffleSOM implementation and would like to know what the suggested best practices are. > > I started to inline monomorphic message sends in order to avoid issues with mega-morphic send sites typically found when evaluating blocks (lambdas). > > Now I am wondering how far that inlining logic should be pushed. > I attempted to just duplicate the relevant AST subtree and leave the nodes themselves more or less untouched. > Specifically, this means, I still rely on a frame to be constructed in a new InlinedMonomorphicMessageNode, which I introduced. > This approach allows me to preserve the semantics of having a frame, and with it access to the same Smalltalk local variables as previously, even so the AST nodes are inlined in the monomorphic all site. Another problem this design solves is the catching of the same control flow exceptions as the method node that got replaced. Especially, the non-local return still needs to be treated correctly, I think, even with inlining. This is the correct approach. Note that you should duplicate the tree in its uninitialized state (e.g. in the constructor of the method root node and keep a copy there) so that the inlined tree specializes for that particular call. > Currently, my main issue with this naive approach is that I still need to create a VirtualFrame object. > This is possible with the frame factory given to the inline(.) method of the InlinableCallSite interface, but it causes problems with the Graal/Truffle compiler. The VerifyFrameDoesNotEscapePhase causes issues, because it sees the frame creation and complains about the fact that the new frame is given to a method call. The executeInlined(..) method below is the relevant fragment. Again, this is this the right way. You should get a stack trace with the approximate location of the problem. > private Object executeInlined(final PackedFrame caller, final Object rcvr, > final Object[] args) { > final VirtualFrame frame = frameFactory.create( > inlinedMethod.getFrameDescriptor(), caller, new Arguments(rcvr, args)); > > final FrameOnStackMarker marker = Misc.initializeFrame(frame.materialize(), > inlinedMethod.getArgumentSlots(), > universe.nilObject); > return Misc.sendSiteExecution(marker, frame, methodBody); // this or any of the `executeGeneric(VirtualFrame)` calls in it are problematic > } The executeInlined method should still get the old VirtualFrame as a parameter so that the Partial Evaluator will process the method and pick up the new virtual frame. Hope this helps. I also wonder why you immediately materialize the frame for initializeFrame; this shouldn't be necessary. Regarding your last email, you might want to consider rewriting control structures / well-known messages like ifTrue, whileTrue, etc. to specialized nodes instead of going through a normal call, e.g. a WhileTrueNode with inlined condition and block. - andreas From java at stefan-marr.de Wed Sep 11 07:33:50 2013 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 11 Sep 2013 16:33:50 +0200 Subject: Initializing Truffle frames | Was: How to do AST inlining of method calls? In-Reply-To: <522FB9CA.4000705@jku.at> References: <522FB9CA.4000705@jku.at> Message-ID: <126D7D80-44CA-4A7B-AD13-2D311186B8F8@stefan-marr.de> Hi Andreas: On 11 Sep 2013, at 02:31, Andreas Woess wrote: > I also wonder why you immediately materialize the frame for initializeFrame; this shouldn't be necessary. I am not sure, but I think Thomas suggested that originally. Now, looking at it and trying to understand VerifyFrameDoesNotEscapePhase line 49-53, I think the reason for using a materialized frame is that I need to initialize the frame object with arguments. The relevant code is [1]: So, each frame contains self, a marker object that tells me whether the frame is still alive/available, the method's arguments and temporary fields required during execution of the method. These need to be all initialized based on the arguments object. @ExplodeLoop private FrameOnStackMarker initializeFrame(MaterializedFrame frame) { Object[] args = frame.getArguments(Arguments.class).arguments; try { for (int i = 0; i < argumentSlots.length; i++) { frame.setObject(argumentSlots[i], args[i]); } frame.setObject(selfSlot, frame.getArguments(Arguments.class).self); FrameOnStackMarker marker = new FrameOnStackMarker(); frame.setObject(nonLocalReturnMarker, marker); for (int i = 0; i < temporarySlots.length; i++) { frame.setObject(temporarySlots[i], universe.nilObject); } return marker; } catch (FrameSlotTypeException e) { throw new RuntimeException("Should not happen, since we only have one type currently!"); } } I think, I remember that Thomas suggested to change this approach in order to allow for specialization based on number of arguments and temporaries, I suppose. Am not entirely sure thought. Also, I don't see how that would lead the arguments and self to be compile time constants, which is what I understand is what VerifyFrameDoesNotEscapePhase is checking for in the second part. > Regarding your last email, you might want to consider rewriting control > structures / well-known messages like ifTrue, whileTrue, etc. to > specialized nodes instead of going through a normal call, e.g. a > WhileTrueNode with inlined condition and block. I would like to avoid that for the moment. Once I get the inlining working, I would rather like to experiment with getting rid of boxing integers :) Thanks Stefan [1] https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/Method.java#L89 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From doug.simon at oracle.com Wed Sep 11 07:54:18 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Sep 2013 16:54:18 +0200 Subject: webrev: workaround for threadRegister handling In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F910961@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F910961@SATLEXDAG02.amd.com> Message-ID: <858B32E5-1C24-4678-ABF1-D529A7CF04C8@oracle.com> Hi Vasanth, I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. -Doug On Sep 10, 2013, at 8:23 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We've submitted the following webrev to http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ > > Please review it. > > Details: > > Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for. > An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime. > This logic works when where the host runtime is the same as the runtime that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL. > > This webrev provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. > In detail, the webrev adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior. > > We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out. > > With this webrev (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL. > > We'd welcome feedback and suggestions about alternative solutions. > > Vasanth > > From doug.simon at oracle.com Wed Sep 11 08:06:05 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Sep 2013 17:06:05 +0200 Subject: overriding NewObject snippets In-Reply-To: References: Message-ID: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. -Doug On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: > For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. > What is the right way to do this? > > -- Tom From D.Sturm42 at gmail.com Wed Sep 11 08:19:17 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 11 Sep 2013 17:19:17 +0200 Subject: @Alive vs. @Use Annotation Message-ID: What is the difference between these two? Does @Alive mean I can only write the value to a @Def register if that value has already been certainly overwritten by a @Use value? (or use it for things like comparisons where I don't write to any register?) This would explain why AMD64ControlFlow.CondMoveOp declares trueValue as @Alive and falseValue as @Use, but then AMD64ControlFlow.FloatCondMoveOp defines both trueValue and falseValue as @Alive although the code is otherwise identical to CondMoveOp. Also this doesn't explain why x and y are @Use in AMD64Compare.CompareOp. -Daniel From tom.deneau at amd.com Wed Sep 11 08:32:08 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 11 Sep 2013 15:32:08 +0000 Subject: overriding NewObject snippets In-Reply-To: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> Message-ID: Doug -- Right, your answer to Vasanth made sense for my question as well. Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, September 11, 2013 10:06 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: overriding NewObject snippets This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. -Doug On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: > For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. > What is the right way to do this? > > -- Tom From doug.simon at oracle.com Wed Sep 11 08:41:25 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Sep 2013 17:41:25 +0200 Subject: @Alive vs. @Use Annotation In-Reply-To: References: Message-ID: <3736B0E9-B346-4E62-9F42-E833CC34B5F0@oracle.com> The javadoc for the LIRInstruction.OperandMode constants should explain these annotations. On Sep 11, 2013, at 5:19 PM, "D.Sturm" wrote: > What is the difference between these two? Does @Alive mean I can only write > the value to a @Def register if that value has already been certainly > overwritten by a @Use value? (or use it for things like comparisons where I > don't write to any register?) > > This would explain why AMD64ControlFlow.CondMoveOp declares trueValue as > @Alive and falseValue as @Use, but then AMD64ControlFlow.FloatCondMoveOp > defines both trueValue and falseValue as @Alive although the code is > otherwise identical to CondMoveOp. > > Also this doesn't explain why x and y are @Use in AMD64Compare.CompareOp. > > > -Daniel From D.Sturm42 at gmail.com Wed Sep 11 08:52:46 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 11 Sep 2013 17:52:46 +0200 Subject: @Alive vs. @Use Annotation In-Reply-To: <3736B0E9-B346-4E62-9F42-E833CC34B5F0@oracle.com> References: <3736B0E9-B346-4E62-9F42-E833CC34B5F0@oracle.com> Message-ID: It does, but I can't understand how the explanation maps with the usage in some situations. For example why the difference in annotation for trueValue between FloatCondMoveOp and CondMoveOp in AMD64ControlFlow although the code is otherwise identical? And why not use @Alive for AMD64Compare.CompareOp? On 11 September 2013 17:41, Doug Simon wrote: > The javadoc for the LIRInstruction.OperandMode constants should explain > these annotations. > > On Sep 11, 2013, at 5:19 PM, "D.Sturm" wrote: > > > What is the difference between these two? Does @Alive mean I can only > write > > the value to a @Def register if that value has already been certainly > > overwritten by a @Use value? (or use it for things like comparisons > where I > > don't write to any register?) > > > > This would explain why AMD64ControlFlow.CondMoveOp declares trueValue as > > @Alive and falseValue as @Use, but then AMD64ControlFlow.FloatCondMoveOp > > defines both trueValue and falseValue as @Alive although the code is > > otherwise identical to CondMoveOp. > > > > Also this doesn't explain why x and y are @Use in AMD64Compare.CompareOp. > > > > > > -Daniel > > From tom.deneau at amd.com Wed Sep 11 08:54:32 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 11 Sep 2013 15:54:32 +0000 Subject: overriding NewObject snippets In-Reply-To: References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> Message-ID: Glancing at HotSpotRuntime, yes, probably all the snippets will have to be overridden but there are clearly some things we would want to reuse such as getArrayBaseOffset getArrayIndexScale etc. For that reason I would think we would want to subclass HotSpotRuntime (I did not see a PTXHotSpotRuntime by the way). -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, September 11, 2013 10:44 AM To: Deneau, Tom Subject: Re: overriding NewObject snippets On Sep 11, 2013, at 5:32 PM, "Deneau, Tom" wrote: > Doug -- > > Right, your answer to Vasanth made sense for my question as well. > > Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? Only HotSpotRuntime ;-) I'm also thinking that PTXHotSpotRuntime should not subclass HotSpotRuntime (and should thus be renamed to something like PTXRuntime). -Doug > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 10:06 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: overriding NewObject snippets > > This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. > > There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. > > -Doug > > On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: > >> For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. >> What is the right way to do this? >> >> -- Tom > > > From christian.wimmer at oracle.com Wed Sep 11 08:59:54 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 11 Sep 2013 08:59:54 -0700 Subject: @Alive vs. @Use Annotation In-Reply-To: References: Message-ID: <5230937A.9090802@oracle.com> On 09/11/2013 08:19 AM, D.Sturm wrote: > What is the difference between these two? Does @Alive mean I can only write > the value to a @Def register if that value has already been certainly > overwritten by a @Use value? (or use it for things like comparisons where I > don't write to any register?) Sorry, I cannot really parse this question. > This would explain why AMD64ControlFlow.CondMoveOp declares trueValue as > @Alive and falseValue as @Use, but then AMD64ControlFlow.FloatCondMoveOp > defines both trueValue and falseValue as @Alive although the code is > otherwise identical to CondMoveOp. > > Also this doesn't explain why x and y are @Use in AMD64Compare.CompareOp. You have to look at the machine code generated for the different compare operations, so you have to look at the different machine code that is generated for the operations. If an input register is still used after an output register is already written, then clearly these two must be separate registers. This means that the input is @Alive. If you don't mind if an input gets the same register as an output, then the input can be @Use. -Christian From doug.simon at oracle.com Wed Sep 11 09:31:30 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Sep 2013 18:31:30 +0200 Subject: overriding NewObject snippets In-Reply-To: References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> Message-ID: <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 On Sep 11, 2013, at 5:54 PM, "Deneau, Tom" wrote: > Glancing at HotSpotRuntime, > yes, probably all the snippets will have to be overridden > but there are clearly some things we would want to reuse such as > getArrayBaseOffset > getArrayIndexScale > etc. Those methods are static in HotSpotRuntime so subclassing is not necessary. > For that reason I would think we would want to subclass HotSpotRuntime I think it's better not to subclass but to delegate. Since I think this is the way PTX should go as well, we should probably provide a DelegatingRuntime class to simplify the GPU specific backends. > (I did not see a PTXHotSpotRuntime by the way). It's in a recently added project: https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 You need to re-run 'mx eclipseinit' and import the new project. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 10:44 AM > To: Deneau, Tom > Subject: Re: overriding NewObject snippets > > > On Sep 11, 2013, at 5:32 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> Right, your answer to Vasanth made sense for my question as well. >> >> Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? > > Only HotSpotRuntime ;-) > > I'm also thinking that PTXHotSpotRuntime should not subclass HotSpotRuntime (and should thus be renamed to something like PTXRuntime). > > -Doug > >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, September 11, 2013 10:06 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: overriding NewObject snippets >> >> This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. >> >> There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. >> >> -Doug >> >> On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: >> >>> For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. >>> What is the right way to do this? >>> >>> -- Tom >> >> >> > > > From tom.deneau at amd.com Wed Sep 11 09:40:58 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 11 Sep 2013 16:40:58 +0000 Subject: overriding NewObject snippets In-Reply-To: <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> Message-ID: Doug -- The URL you mention here requires a username and password... https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, September 11, 2013 11:32 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: overriding NewObject snippets https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 On Sep 11, 2013, at 5:54 PM, "Deneau, Tom" wrote: > Glancing at HotSpotRuntime, > yes, probably all the snippets will have to be overridden but there > are clearly some things we would want to reuse such as > getArrayBaseOffset > getArrayIndexScale > etc. Those methods are static in HotSpotRuntime so subclassing is not necessary. > For that reason I would think we would want to subclass HotSpotRuntime I think it's better not to subclass but to delegate. Since I think this is the way PTX should go as well, we should probably provide a DelegatingRuntime class to simplify the GPU specific backends. > (I did not see a PTXHotSpotRuntime by the way). It's in a recently added project: https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 You need to re-run 'mx eclipseinit' and import the new project. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 10:44 AM > To: Deneau, Tom > Subject: Re: overriding NewObject snippets > > > On Sep 11, 2013, at 5:32 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> Right, your answer to Vasanth made sense for my question as well. >> >> Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? > > Only HotSpotRuntime ;-) > > I'm also thinking that PTXHotSpotRuntime should not subclass HotSpotRuntime (and should thus be renamed to something like PTXRuntime). > > -Doug > >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, September 11, 2013 10:06 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: overriding NewObject snippets >> >> This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. >> >> There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. >> >> -Doug >> >> On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: >> >>> For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. >>> What is the right way to do this? >>> >>> -- Tom >> >> >> > > > From doug.simon at oracle.com Wed Sep 11 10:01:12 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Sep 2013 19:01:12 +0200 Subject: overriding NewObject snippets In-Reply-To: References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> Message-ID: Sorry. This one will work: http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 On Sep 11, 2013, at 6:40 PM, "Deneau, Tom" wrote: > Doug -- > > The URL you mention here requires a username and password... > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 11:32 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: overriding NewObject snippets > > > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 > > On Sep 11, 2013, at 5:54 PM, "Deneau, Tom" wrote: > >> Glancing at HotSpotRuntime, >> yes, probably all the snippets will have to be overridden but there >> are clearly some things we would want to reuse such as >> getArrayBaseOffset >> getArrayIndexScale >> etc. > > Those methods are static in HotSpotRuntime so subclassing is not necessary. > >> For that reason I would think we would want to subclass HotSpotRuntime > > I think it's better not to subclass but to delegate. Since I think this is the way PTX should go as well, we should probably provide a DelegatingRuntime class to simplify the GPU specific backends. > >> (I did not see a PTXHotSpotRuntime by the way). > > It's in a recently added project: > > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 > > You need to re-run 'mx eclipseinit' and import the new project. > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, September 11, 2013 10:44 AM >> To: Deneau, Tom >> Subject: Re: overriding NewObject snippets >> >> >> On Sep 11, 2013, at 5:32 PM, "Deneau, Tom" wrote: >> >>> Doug -- >>> >>> Right, your answer to Vasanth made sense for my question as well. >>> >>> Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? >> >> Only HotSpotRuntime ;-) >> >> I'm also thinking that PTXHotSpotRuntime should not subclass HotSpotRuntime (and should thus be renamed to something like PTXRuntime). >> >> -Doug >> >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Wednesday, September 11, 2013 10:06 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: overriding NewObject snippets >>> >>> This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. >>> >>> There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. >>> >>> -Doug >>> >>> On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: >>> >>>> For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. >>>> What is the right way to do this? >>>> >>>> -- Tom >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Wed Sep 11 10:00:38 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 11 Sep 2013 17:00:38 +0000 Subject: hg: graal/graal: 20 new changesets Message-ID: <20130911170204.794D962722@hg.openjdk.java.net> Changeset: 516b93ccf7c9 Author: Doug Simon Date: 2013-09-10 21:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/516b93ccf7c9 pass the value of the -XX:+CITime VM option explicitly to HotSpotOptions.finalize() ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: 9652640fae42 Author: Doug Simon Date: 2013-09-10 21:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9652640fae42 tightened option verifier to check all class initializers in the hierarchy of a class that declares at least one @Option ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java Changeset: a8132e3fd0d8 Author: Doug Simon Date: 2013-09-10 21:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a8132e3fd0d8 further improvements to README_GRAAL.txt ! README_GRAAL.txt Changeset: 12f1d5fe0133 Author: Mick Jordan Date: 2013-09-03 16:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/12f1d5fe0133 CR-1364 ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 2afda67175e9 Author: Mick Jordan Date: 2013-09-03 16:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2afda67175e9 Merge ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 797b5ea46a90 Author: Mick Jordan Date: 2013-09-07 12:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/797b5ea46a90 Merge - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeUsagesList.java - mxtool/.pylintrc Changeset: e460aa80fa46 Author: Mick Jordan Date: 2013-09-09 10:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e460aa80fa46 Merge Changeset: 4dbd3e3adda6 Author: Mick Jordan Date: 2013-09-10 09:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4dbd3e3adda6 Merge Changeset: c47153857827 Author: Mick Jordan Date: 2013-09-10 14:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c47153857827 Merge - CR1368: add beforeInline callback to snippet instantiation - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitAndNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitBooleanNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 3d358ea11300 Author: Mick Jordan Date: 2013-09-10 16:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3d358ea11300 allow backend to specify spill slot size ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64FrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java Changeset: 003be97acdda Author: Mick Jordan Date: 2013-09-10 16:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/003be97acdda Merge Changeset: 91e5f927af63 Author: bharadwaj Date: 2013-09-10 22:39 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 Initial implementation of PTXRuntime (RegisterConfig, PTX description etc); guarded with new flag UseGPU. Specify -XX:+UseGPU to exercise this new implementation. ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.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.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXParameterOp.java ! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java ! mx/projects ! src/gpu/ptx/vm/gpu_ptx.cpp - src/gpu/ptx/vm/kernelArguments.cpp - src/gpu/ptx/vm/kernelArguments.hpp + src/gpu/ptx/vm/ptxKernelArguments.cpp + src/gpu/ptx/vm/ptxKernelArguments.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/runtime/globals.hpp Changeset: 723796685546 Author: Michael Haupt Date: 2013-09-11 09:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/723796685546 more verbose output for eclipseinit if it cannot place workingsets.xml in Eclipse metadata location ! mxtool/mx.py Changeset: ecbeceacca98 Author: Doug Simon Date: 2013-09-10 22:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ecbeceacca98 changed default for -G:DebugValueSummary to "Name" ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java Changeset: d9342daa5078 Author: Doug Simon Date: 2013-09-10 22:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d9342daa5078 added timer for each phase; imposed regex pattern check on phase names ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: 60f4c505993e Author: Doug Simon Date: 2013-09-10 22:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/60f4c505993e remove global phase metric, replaced with per-phase metrics ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: ceecc37b44d7 Author: Doug Simon Date: 2013-09-11 09:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ceecc37b44d7 Merge. - src/gpu/ptx/vm/kernelArguments.cpp - src/gpu/ptx/vm/kernelArguments.hpp Changeset: 73dbd282ad3a Author: Doug Simon Date: 2013-09-11 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/73dbd282ad3a Merge. Changeset: 152b4146f05b Author: Andreas Woess Date: 2013-09-10 19:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/152b4146f05b Truffle-DSL: fix implicit cast bug. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 943f1863e1c1 Author: Roland Schatz Date: 2013-09-11 16:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/943f1863e1c1 Early exit from ReentrantNodeIterator. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java From D.Sturm42 at gmail.com Wed Sep 11 11:42:08 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 11 Sep 2013 20:42:08 +0200 Subject: @Alive vs. @Use Annotation Message-ID: > If an input register is still used after an output register is already > written, then clearly these two must be separate registers. This means > that the input is @Alive. > If you don't mind if an input gets the same register as an output, then > the input can be @Use. Makes sense, thanks! -Daniel From tom.deneau at amd.com Wed Sep 11 15:55:35 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 11 Sep 2013 22:55:35 +0000 Subject: overriding NewObject snippets In-Reply-To: <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> Message-ID: Doug and others... OK, this DelegatingRuntime infrastructure sounds like a great idea. When do you think something like this will be available? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, September 11, 2013 11:32 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: overriding NewObject snippets https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 On Sep 11, 2013, at 5:54 PM, "Deneau, Tom" wrote: > Glancing at HotSpotRuntime, > yes, probably all the snippets will have to be overridden but there > are clearly some things we would want to reuse such as > getArrayBaseOffset > getArrayIndexScale > etc. Those methods are static in HotSpotRuntime so subclassing is not necessary. > For that reason I would think we would want to subclass HotSpotRuntime I think it's better not to subclass but to delegate. Since I think this is the way PTX should go as well, we should probably provide a DelegatingRuntime class to simplify the GPU specific backends. > (I did not see a PTXHotSpotRuntime by the way). It's in a recently added project: https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 You need to re-run 'mx eclipseinit' and import the new project. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 10:44 AM > To: Deneau, Tom > Subject: Re: overriding NewObject snippets > > > On Sep 11, 2013, at 5:32 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> Right, your answer to Vasanth made sense for my question as well. >> >> Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? > > Only HotSpotRuntime ;-) > > I'm also thinking that PTXHotSpotRuntime should not subclass HotSpotRuntime (and should thus be renamed to something like PTXRuntime). > > -Doug > >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, September 11, 2013 10:06 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: overriding NewObject snippets >> >> This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. >> >> There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. >> >> -Doug >> >> On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: >> >>> For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. >>> What is the right way to do this? >>> >>> -- Tom >> >> >> > > > From doug.simon at oracle.com Thu Sep 12 03:24:45 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 12 Sep 2013 10:24:45 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <20130912102522.3D1E26274D@hg.openjdk.java.net> Changeset: 3676540f71cf Author: Mick Jordan Date: 2013-09-11 21:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3676540f71cf Allow mxtool suites to be in separate repositories (CR-1367) ! mx/commands.py ! mxtool/mx.py Changeset: 4f69a5189e77 Author: bharadwaj Date: 2013-09-11 17:02 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4f69a5189e77 Create runtime object based on GPUIL type newly added to gpu class; some code refactoring. ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/os_gpu/bsd_ptx/vm/gpu_bsd.cpp ! src/os_gpu/linux_ptx/vm/gpu_linux.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/runtime/gpu.cpp ! src/share/vm/runtime/gpu.hpp Changeset: d351a72596a9 Author: Doug Simon Date: 2013-09-12 09:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d351a72596a9 added DelegatingMetaAccessProvider, DelegatingCodeCacheProvider, DelegatingGraalCodeCacheProvider + graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingGraalCodeCacheProvider.java Changeset: b5d2a23b7f6b Author: Doug Simon Date: 2013-09-12 11:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5d2a23b7f6b gave different name to per-phase timer and metric ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java From doug.simon at oracle.com Thu Sep 12 03:26:36 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 Sep 2013 12:26:36 +0200 Subject: overriding NewObject snippets In-Reply-To: References: <2D220C88-90D7-4F28-B991-ECC79A91D10B@oracle.com> <8ECCBAB3-41F7-481A-8AAD-66E99AE4F4F9@oracle.com> Message-ID: <48EEE1C3-23CD-40D4-9CE5-18A4179FA8EC@oracle.com> On Sep 12, 2013, at 12:55 AM, "Deneau, Tom" wrote: > Doug and others... > > OK, this DelegatingRuntime infrastructure sounds like a great idea. > When do you think something like this will be available? Now: http://hg.openjdk.java.net/graal/graal/rev/d351a72596a9 -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 11:32 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: overriding NewObject snippets > > > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 > > On Sep 11, 2013, at 5:54 PM, "Deneau, Tom" wrote: > >> Glancing at HotSpotRuntime, >> yes, probably all the snippets will have to be overridden but there >> are clearly some things we would want to reuse such as >> getArrayBaseOffset >> getArrayIndexScale >> etc. > > Those methods are static in HotSpotRuntime so subclassing is not necessary. > >> For that reason I would think we would want to subclass HotSpotRuntime > > I think it's better not to subclass but to delegate. Since I think this is the way PTX should go as well, we should probably provide a DelegatingRuntime class to simplify the GPU specific backends. > >> (I did not see a PTXHotSpotRuntime by the way). > > It's in a recently added project: > > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/91e5f927af63 > > You need to re-run 'mx eclipseinit' and import the new project. > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, September 11, 2013 10:44 AM >> To: Deneau, Tom >> Subject: Re: overriding NewObject snippets >> >> >> On Sep 11, 2013, at 5:32 PM, "Deneau, Tom" wrote: >> >>> Doug -- >>> >>> Right, your answer to Vasanth made sense for my question as well. >>> >>> Are there any existing overrides of the GraalCodeCacheProvider class that we can look at as templates? >> >> Only HotSpotRuntime ;-) >> >> I'm also thinking that PTXHotSpotRuntime should not subclass HotSpotRuntime (and should thus be renamed to something like PTXRuntime). >> >> -Doug >> >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Wednesday, September 11, 2013 10:06 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: overriding NewObject snippets >>> >>> This is related to the message I sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/. >>> >>> There needs to be separate GraalCodeCacheProvider subclass for HSAIL that defines and uses it's own snippets. It can always delegate to the HotSpotRuntime snippets but I suspect most of theme won't be reusable for HSAIL. >>> >>> -Doug >>> >>> On Sep 11, 2013, at 1:06 AM, "Deneau, Tom" wrote: >>> >>>> For the HSAIL backend, I want to override some of the existing NewObjectSnippets with some different java code. >>>> What is the right way to do this? >>>> >>>> -- Tom >>> >>> >>> >> >> >> > > > From java at stefan-marr.de Thu Sep 12 04:23:38 2013 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 12 Sep 2013 13:23:38 +0200 Subject: How to do AST inlining of method calls? In-Reply-To: <522FB9CA.4000705@jku.at> References: <522FB9CA.4000705@jku.at> Message-ID: <3609B51E-6A59-479D-9924-65E8A0151A4D@stefan-marr.de> Hi: On 11 Sep 2013, at 02:31, Andreas Woess wrote: > On 11.09.2013 01:20, Stefan Marr wrote: >> Specifically, this means, I still rely on a frame to be constructed in a new InlinedMonomorphicMessageNode, which I introduced. >> This approach allows me to preserve the semantics of having a frame, and with it access to the same Smalltalk local variables as previously, even so the AST nodes are inlined in the monomorphic all site. Another problem this design solves is the catching of the same control flow exceptions as the method node that got replaced. Especially, the non-local return still needs to be treated correctly, I think, even with inlining. > This is the correct approach. Note that you should duplicate the tree in > its uninitialized state (e.g. in the constructor of the method root node > and keep a copy there) so that the inlined tree specializes for that > particular call. Right, that's what I do. Currently, the only specialization is for monomorphic and polymorphic sends. And the copying of tree nodes for message sends will create an uninitialized message send node. >> Currently, my main issue with this naive approach is that I still need to create a VirtualFrame object. >> This is possible with the frame factory given to the inline(.) method of the InlinableCallSite interface, but it causes problems with the Graal/Truffle compiler. The VerifyFrameDoesNotEscapePhase causes issues, because it sees the frame creation and complains about the fact that the new frame is given to a method call. The executeInlined(..) method below is the relevant fragment. > Again, this is this the right way. You should get a stack trace with the > approximate location of the problem. After experimenting more with this, and trying to understand what the issue is, I start to belief that the heuristic encoded in VerifyFrameDoesNotEscapePhase is just to simple. After removing the check for passing the frame on to a method, the benchmarks run to completion. So, I have the feeling (but without being very confident) that I use the frame classes in a more or less correct way. I am wondering whether there could just be an annotation that tells the check in VerifyFrameDoesNotEscapePhase that a frame passed to a certain method is not problematic? The reason why I think that the heuristic is too simple is that method call boundaries are a to strong constrained. Since not all calls are inlined in the graph, the check becomes restrictively conservative. I experimented with just duplicating code to give the check more information, but as soon as I get to a truly polymeric send site, I still get into trouble? I wonder why such a simple issue is not problematic in the other Truffle-based languages being implemented. Could I annotate the frame creation with something that marks it as unproblematic? For others interested in the code for inlining methods, the following commit should be the most relevant piece: https://github.com/smarr/TruffleSOM/commit/1edba8692fd0a0ffe78510f45597c6f8a8a6cadf The cloning of nodes is introduced here: https://github.com/smarr/TruffleSOM/commit/851549ac9d04315a755a1851a002e7b1bd96e55c Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From java at stefan-marr.de Thu Sep 12 14:43:12 2013 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 12 Sep 2013 23:43:12 +0200 Subject: Truffle and support for a class name 'Object' Message-ID: <8F953FA7-E0A0-4912-8D5D-8E630EB0A86C@stefan-marr.de> Dear all: I would like to request a feature: Could you please support the class name 'Object' for guest language implementations? Or, could you put a big red warning into the Truffle FAQ to avoid it? If you would consider solution 1, this patch might be useful for some people: diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java index b94912e..e97517d 100644 --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java @@ -137,6 +137,10 @@ public final class OrganizedImports { private String createDeclaredTypeName(Element enclosedElement, DeclaredType type) { String name = type.asElement().getSimpleName().toString(); + if ("Object".equals(name)) { + return getQualifiedName(type); + } + if (needsImport(enclosedElement, type)) { TypeMirror usedByType = simpleNamesUsed.get(name); if (usedByType == null) { I had a similar patch for Utils.getDeclaredName() which might not be necessary anymore. However, this one in OrganizedImports is necessary to generate proper specialized classes when using the Truffle-DSL for type specializations. As mentioned with the original patch, this is also only a work-around. A proper solution might require to check for name clashes directly. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From thomas.wuerthinger at oracle.com Thu Sep 12 15:02:26 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 13 Sep 2013 00:02:26 +0200 Subject: Truffle and support for a class name 'Object' In-Reply-To: <8F953FA7-E0A0-4912-8D5D-8E630EB0A86C@stefan-marr.de> References: <8F953FA7-E0A0-4912-8D5D-8E630EB0A86C@stefan-marr.de> Message-ID: Thanks for the report. We will add support for checking name clashes. In general, we would like to suggest the use of class name prefixes for language implementations to avoid clashes with the Java standard library or other guest language implementations. - thomas On Sep 12, 2013, at 11:43 PM, Stefan Marr wrote: > Dear all: > > I would like to request a feature: > > Could you please support the class name 'Object' for guest language implementations? > Or, could you put a big red warning into the Truffle FAQ to avoid it? > > If you would consider solution 1, this patch might be useful for some people: > > diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java > index b94912e..e97517d 100644 > --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java > +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java > @@ -137,6 +137,10 @@ public final class OrganizedImports { > private String createDeclaredTypeName(Element enclosedElement, DeclaredType type) { > String name = type.asElement().getSimpleName().toString(); > > + if ("Object".equals(name)) { > + return getQualifiedName(type); > + } > + > if (needsImport(enclosedElement, type)) { > TypeMirror usedByType = simpleNamesUsed.get(name); > if (usedByType == null) { > > > I had a similar patch for Utils.getDeclaredName() which might not be necessary anymore. > However, this one in OrganizedImports is necessary to generate proper specialized classes when using the Truffle-DSL for type specializations. > > As mentioned with the original patch, this is also only a work-around. A proper solution might require to check for name clashes directly. > > Thanks > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > From tom.deneau at amd.com Fri Sep 13 09:47:23 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Sep 2013 16:47:23 +0000 Subject: questions on Word operations Message-ID: I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. The new method would look like: public Word atomicGetAndAddWord(int offset, int delta) { } So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. A couple of questions: * Is the following a legal body for such a method? I see that it compiles but is it legal to call toObject() on a Word value? As used in the snippet the Word value would be the pointer returned by thread(). I noticed there is no unsafe.getAndAddLong(long address, long delta), only unsafe.getAndAddLong(Object o, long offset, long delta) return box(unsafe.getAndAddLong(toObject(), offset, delta)); * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? * What is the purpose of the locationIdentity parameter on some of the word operations such as @Operation(opcode = Opcode.READ) public Word readWord(WordBase offset, LocationIdentity locationIdentity) { return box(unsafe.getAddress(add((Word) offset).unbox())); } -- Tom From christian.wimmer at oracle.com Fri Sep 13 10:19:05 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Fri, 13 Sep 2013 10:19:05 -0700 Subject: questions on Word operations In-Reply-To: References: Message-ID: <52334909.70403@oracle.com> All functions on word types (everything implementing the interface WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. Can you explain what your final goal is? -Christian On 09/13/2013 09:47 AM, Deneau, Tom wrote: > I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. > > The new method would look like: > > public Word atomicGetAndAddWord(int offset, int delta) { > > } > > So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. > > A couple of questions: > > * Is the following a legal body for such a method? I see that it compiles but is it legal to call toObject() on a Word value? As used in the snippet the Word value would be the pointer returned by thread(). I noticed there is no unsafe.getAndAddLong(long address, long delta), only unsafe.getAndAddLong(Object o, long offset, long delta) > > return box(unsafe.getAndAddLong(toObject(), offset, delta)); > > * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? > > > * What is the purpose of the locationIdentity parameter on some of the word operations such as > > @Operation(opcode = Opcode.READ) > public Word readWord(WordBase offset, LocationIdentity locationIdentity) { > return box(unsafe.getAddress(add((Word) offset).unbox())); > } > > -- Tom > From tom.deneau at amd.com Fri Sep 13 11:30:53 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Sep 2013 18:30:53 +0000 Subject: questions on Word operations In-Reply-To: <52334909.70403@oracle.com> References: <52334909.70403@oracle.com> Message-ID: Christian -- Yes, I should have stated the final goal and maybe there is a better way to do what we want to do... We want to support object allocation from an HSA GPU. (or at least to get an idea whether it is worth supporting it). At a high level, there would be a bunch of TLABS available for the gpu to use. For the initial prototype these could be the TLABs from actual java "donor threads" whose only purpose is to supply their TLAB (the java donor threads wouldn't allocate into their own TLAB). Since the HSA GPU has the same view of memory as the cpu, we thought perhaps we could just use the non-atomic pointer bump snippet that is used with HotspotRuntime. We confirmed this works for small numbers of workitems but the high parallelism of the gpu means an unreasonably high number of donor threads would be needed for the general case. So we are now experimenting with multiple GPU workitems sharing a TLAB and allocatin using an atomic pointer bump. We know the HSAIL code we want to end up with, but I just don't have any experience with Graal Snippets and such to make graal emit this HSAIL code (as you can tell from my questions). But maybe there is an easier way to get graal to emit this allocation code? -- Tom -----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, September 13, 2013 12:19 PM To: graal-dev at openjdk.java.net Subject: Re: questions on Word operations All functions on word types (everything implementing the interface WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. Can you explain what your final goal is? -Christian On 09/13/2013 09:47 AM, Deneau, Tom wrote: > I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. > > The new method would look like: > > public Word atomicGetAndAddWord(int offset, int delta) { > > } > > So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. > > A couple of questions: > > * Is the following a legal body for such a method? I see that it > compiles but is it legal to call toObject() on a Word value? As used > in the snippet the Word value would be the pointer returned by > thread(). I noticed there is no unsafe.getAndAddLong(long address, > long delta), only unsafe.getAndAddLong(Object o, long offset, long > delta) > > return box(unsafe.getAndAddLong(toObject(), offset, > delta)); > > * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? > > > * What is the purpose of the locationIdentity parameter on some > of the word operations such as > > @Operation(opcode = Opcode.READ) > public Word readWord(WordBase offset, LocationIdentity locationIdentity) { > return box(unsafe.getAddress(add((Word) offset).unbox())); > } > > -- Tom > From christian.wimmer at oracle.com Sat Sep 14 16:29:33 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Sat, 14 Sep 2013 16:29:33 -0700 Subject: questions on Word operations In-Reply-To: References: <52334909.70403@oracle.com> Message-ID: <5234F15D.3050808@oracle.com> Tom, So you want to use a atomicGetAndAdd instruction from a snippet, similarly to the CompareAndSwap that is already in Graal (because it is accessible via sun.misc.Unsafe). I would say the easiest way is to create a new AtomicGetAndAddNode, and provide the proper lowering to a new LIR Operation. You can access the new node from a snippet via a node intrinsic - a method annotated with @NodeIntrinsic in the node class. The parameter list of the node intrinsic corresponds with the constructor parameters of the node class, and the pre-processing that Graal is doing for the snippet replaces the call to the node intrinsic method with an actual node instance. -Christian On 9/13/2013 11:30 AM, Deneau, Tom wrote: > Christian -- > > Yes, I should have stated the final goal and maybe there is a better way to do what we want to do... > > We want to support object allocation from an HSA GPU. (or at least to get an idea whether it is worth supporting it). > > At a high level, there would be a bunch of TLABS available for the gpu to use. > For the initial prototype these could be the TLABs from actual java "donor threads" whose only purpose is to supply their TLAB > (the java donor threads wouldn't allocate into their own TLAB). > > Since the HSA GPU has the same view of memory as the cpu, we thought perhaps we could > just use the non-atomic pointer bump snippet that is used with HotspotRuntime. > We confirmed this works for small numbers of workitems but the high parallelism of > the gpu means an unreasonably high number of donor threads would be needed for the general case. > > So we are now experimenting with multiple GPU workitems sharing a TLAB and allocatin using an atomic pointer bump. > We know the HSAIL code we want to end up with, but I just don't have any experience with > Graal Snippets and such to make graal emit this HSAIL code (as you can tell from my questions). > > But maybe there is an easier way to get graal to emit this allocation code? > > -- Tom > > > -----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, September 13, 2013 12:19 PM > To: graal-dev at openjdk.java.net > Subject: Re: questions on Word operations > > All functions on word types (everything implementing the interface > WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. > > Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. > > Can you explain what your final goal is? > > -Christian > > > On 09/13/2013 09:47 AM, Deneau, Tom wrote: >> I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. >> >> The new method would look like: >> >> public Word atomicGetAndAddWord(int offset, int delta) { >> >> } >> >> So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. >> >> A couple of questions: >> >> * Is the following a legal body for such a method? I see that it >> compiles but is it legal to call toObject() on a Word value? As used >> in the snippet the Word value would be the pointer returned by >> thread(). I noticed there is no unsafe.getAndAddLong(long address, >> long delta), only unsafe.getAndAddLong(Object o, long offset, long >> delta) >> >> return box(unsafe.getAndAddLong(toObject(), offset, >> delta)); >> >> * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? >> >> >> * What is the purpose of the locationIdentity parameter on some >> of the word operations such as >> >> @Operation(opcode = Opcode.READ) >> public Word readWord(WordBase offset, LocationIdentity locationIdentity) { >> return box(unsafe.getAddress(add((Word) offset).unbox())); >> } >> >> -- Tom >> > > From doug.simon at oracle.com Sat Sep 14 18:00:12 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 15 Sep 2013 01:00:12 +0000 Subject: hg: graal/graal: 26 new changesets Message-ID: <20130915010148.3EF266283A@hg.openjdk.java.net> Changeset: 103795ab699d Author: Andreas Woess Date: 2013-09-12 12:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/103795ab699d gpu.cpp: fix warning: not all control paths return a value ! src/share/vm/runtime/gpu.cpp Changeset: 5f532ea846fb Author: Doug Simon Date: 2013-09-12 14:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f532ea846fb applied changes to basic-graal that were made in a downstream repo ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/LogicPTXTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultSourceSection.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java Changeset: a27678c47948 Author: Doug Simon Date: 2013-09-12 16:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a27678c47948 made Debug.ENABLED static (i.e. a compile-time constant) ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java Changeset: 54dff87002e0 Author: Doug Simon Date: 2013-09-12 17:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/54dff87002e0 check that Debug has not been initialized before HotSpotOptions.finalizeOptions() is called ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java Changeset: bf7c26dc56e1 Author: Andreas Woess Date: 2013-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bf7c26dc56e1 TruffleCache: use frame state values to check argument stamps; iterating over local nodes is no longer sufficient since e231671f39d0. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 57674ff0f7e2 Author: Andreas Woess Date: 2013-09-12 19:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/57674ff0f7e2 Merge Changeset: 3f706be38bf9 Author: Andreas Woess Date: 2013-09-12 19:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f706be38bf9 Truffle: compilation final array support. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceLoadFinalPhase.java Changeset: dc35a8134f4a Author: Doug Simon Date: 2013-09-12 22:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dc35a8134f4a removed "ScopeTime" timer ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java Changeset: 0d10c6717edf Author: Doug Simon Date: 2013-09-12 23:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d10c6717edf fixed TimerImpl to account for (i.e., deduct) all nested timers, not just the most recent one ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: 7f513590ac06 Author: Morris Meyer Date: 2013-09-12 18:02 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7f513590ac06 Rename PTX ArrayTest + graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java Changeset: aba82698c86d Author: Morris Meyer Date: 2013-09-12 18:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/aba82698c86d Rename PTX ArrayTest ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java Changeset: 60e3fe0fe939 Author: Mick Jordan Date: 2013-09-12 19:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/60e3fe0fe939 mxtool: fix eclipseinit to use project suite dir for included suites ! mxtool/mx.py Changeset: 46e708738717 Author: Roland Schatz Date: 2013-09-13 11:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/46e708738717 Remove invalid assertion in ReentrantNodeIterator. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java Changeset: ccf047a30f18 Author: Chris Seaton Date: 2013-09-13 13:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ccf047a30f18 Truffle: NodeUtil.getNthParent. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 5d6ff483a5e9 Author: Gilles Duboscq Date: 2013-09-11 10:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d6ff483a5e9 Strengthen and simplify ConditionTest ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionTest.java Changeset: 3c2dc8364696 Author: Gilles Duboscq Date: 2013-09-11 10:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c2dc8364696 CheckCastNode.canonical should not assume that tool.assumptions is not null ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 94a28e1b2c86 Author: Gilles Duboscq Date: 2013-09-11 15:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/94a28e1b2c86 Add a test to ConditionalEliminationTest ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java Changeset: 340e67bf1758 Author: Gilles Duboscq Date: 2013-09-13 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/340e67bf1758 Rename GuardsPhase to GuardsStage to avoid confusion with existing Phases ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.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.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerExactArithmeticSplitNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java Changeset: 1ca5e39d0433 Author: Gilles Duboscq Date: 2013-09-13 15:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ca5e39d0433 Add javadoc to GuardsStage and FrameStateAssignmentPhase ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: febd01be55e0 Author: Doug Simon Date: 2013-09-13 15:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/febd01be55e0 moved 'conditional' field and related methods down in DebugValue ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugValue.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/MetricImpl.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: a0da0bff042e Author: Doug Simon Date: 2013-09-13 15:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0da0bff042e made TimerImpl respect conditional flag (GRAAL-470) ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: 103e4438bb19 Author: Doug Simon Date: 2013-09-13 15:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/103e4438bb19 added support for accumulative times to TimerImpl ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: 1aed684853f6 Author: Doug Simon Date: 2013-09-13 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1aed684853f6 refactored IterableNodeType into a top level type to avoid problems it was causing for javac and JDT (CR-1408) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.graph.test/src/com/oracle/graal/graph/test/TypedNodeIteratorTest.java ! graal/com.oracle.graal.graph.test/src/com/oracle/graal/graph/test/TypedNodeIteratorTest2.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/IterableNodeType.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.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/ControlSinkNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EntryMarkerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.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/LocalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.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/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.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/OSRLocalNode.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/ValueAnchorNode.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/AbstractNewArrayNode.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.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.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/NewInstanceNode.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/EscapeObjectState.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InsertStateAfterPlaceholderPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/BailoutNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerExactArithmeticNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverInlineMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/MaterializeFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/VerifyNoIntrinsicsLeftPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializedObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java Changeset: 625662f170ee Author: Doug Simon Date: 2013-09-13 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/625662f170ee Merge. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java Changeset: a0566c8dcabf Author: Doug Simon Date: 2013-09-13 17:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0566c8dcabf removed IterableNodeType from some classes for which typed node iterators were never used or were only used in tests ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.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/TypeSystemTest.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.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopExitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.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.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/CheckCastTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/BailoutNode.java Changeset: bff2b88444f5 Author: Morris Meyer Date: 2013-09-14 17:31 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/bff2b88444f5 Start of PTX array passing ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java + graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlTest.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.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXParameterOp.java ! src/gpu/ptx/vm/gpu_ptx.cpp From michal.warecki at gmail.com Mon Sep 16 03:08:28 2013 From: michal.warecki at gmail.com (=?ISO-8859-2?Q?Micha=B3_Warecki?=) Date: Mon, 16 Sep 2013 12:08:28 +0200 Subject: Epiphany support in Graal In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D93785B@SATLEXDAG02.amd.com> References: <51FBF206.2090807@oracle.com> <52093C24.7010009@oracle.com> <1FC28B48-EF2B-4EC0-B3B7-0DC0CA3E1E25@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D93785B@SATLEXDAG02.amd.com> Message-ID: Hi again, Did Tom return from vacations? I'm very interested in details about dispatch mechanism for HSAIL. For Epiphany I'm thinking about using JNR for native calls which are responsible for assembly dispatch. Best, Micha? 2013/8/14 Venkatachalam, Vasanth > Michal- > > Tom Deneau worked on the dispatch mechanism for HSAIL. He's currently on > vacation. When he gets back next week, we should be able to provide you > with more details about the dispatch that will be useful for what you're > trying to do. > > Vasanth > > > >> > > >> -----Original Message----- > > >> From: graal-dev-bounces at openjdk.java.net [mailto: > > >> graal-dev-bounces at openjdk.java.net] On Behalf Of Frost, Gary > > >> Sent: Monday, August 12, 2013 3:16 PM > > >> To: morris.meyer at oracle.com; Micha? Warecki > > >> Cc: graal-dev at openjdk.java.net > > >> Subject: RE: Epiphany support in Graal > > >> > > >> I definitely think we need to find a way to extract the common API > > >> out > > of > > >> these accelerator style dispatches. > > >> > > >> Ultimately this should indeed be pushed up to something like > > >> com.oracle.graal.xxx.CompileAndDispatch > > >> > > >> Maybe between Tom, Vasanth, Michal, Morris, Christian and Bharadwaj > > >> we could propose a strawman API. It might be difficult to capture > > >> an API which supports coherent memory access style of HSA, with the > > >> buffer > > copy, > > >> dispatch and retrieve style of PTX. Maybe Morris can help by > > >> describing the dispatch style for Epiphany. Does it require > > >> buffers to be copied > > from > > >> the host to the accelerator? > > >> > > >> Gary > > >> > > >> -----Original Message----- > > >> From: graal-dev-bounces at openjdk.java.net [mailto: > > >> graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer > > >> Sent: Monday, August 12, 2013 2:49 PM > > >> To: Micha? Warecki > > >> Cc: graal-dev at openjdk.java.net > > >> Subject: Re: Epiphany support in Graal > > >> > > >> Michal, > > >> > > >> There was a bit discussion in the list regarding com.amd.sumatra a > > >> month or two back. We are rooting graal work in com.oracle.graal > > >> per a > > decision > > >> from Thomas Wuerthinger. > > >> > > >> Bharadwaj, Christian T. and myself have Graal-PTX running on > > >> hardware on the moment - and we would like to make sure common code > > >> for parallel execution moves forward in a way that pushes a common > > >> capability > > forward. > > >> > > >> --mm > > >> > > >> On 8/12/13, 3:06 PM, Micha? Warecki wrote: > > >>> Hi guys! > > >>> > > >>> I see that com.amd.sumatra.Sumatra interface and > > >>> com.oracle.graal.compiler.hsail.CompileAndDispatch have same > > >>> methods and probably will be used for the same purpose. > > >>> I'd like to create Epiphany code dispatcher in exactly the same > > >>> way, so my question is: does it make sense to move > > >>> com.oracle.graal.compiler.hsail.CompileAndDispatch interface to > > >>> com.oracle.graal.compiler or create separate, common package for > that? > > >>> > > >>> Best, > > >>> Micha? > > >>> > > >>> > > >>> 2013/8/4 Micha? Warecki > >>> > > > >>> > > >>> Thanks for the great answers! A lot ofvery interesting work to > do:-) > > >>> If anyone is interested in developing this Graal and Sumatra > > >>> extension, I'm going to share it on some public repository within > > >>> a few weeks/months. > > >>> > > >>> Best, > > >>> Micha? > > >>> > > >>> > > >>> 2013/8/2 Morris Meyer > >>> > > > >>> > > >>> This looks like an interesting architecture. The reference > > >>> manual is a missing the actual encoding of instructions, but > > >>> from what you have here I would suggest that you look at the > > >>> SPARC assembler classes in graal first - and then look at the > > >>> PTX and HSAIL architectures. > > >>> > > >>> Christian Thalinger and I worked the SPARC assembler - and the > > >>> class structure of each instruction allows for superclass > > >>> assertions on the specific formats, as well as being able to > > >>> re-work in the instruction stream if offsets fall outside > > >>> small immediate ranges. > > >>> > > >>> The PTX architecture in graal has the initial > > >>> ExternalCompilationResult path - which allows for Graal to > > >>> invoke the compiled PTX kernels and still have a host-native > > >>> compiled result. Graal does interpreter vs compiled snippet > > >>> unit testing - and we would like to augment this as we push > > >>> into GPU, APU and architectures such as Epiphany. > > >>> > > >>> We still have more work to do on moving to handle multiple > > >>> heterogeneous architectures. > > >>> > > >>> We are also working to add the sort of upstream parallel > > >>> work-enabling code that allows the compiler and APIs recognize > > >>> and gain useful work from external compilation resources. > > >>> > > >>> Warm regards, > > >>> > > >>> --morris > > >>> > > >>> > > >>> On 8/2/13, 1:56 AM, Micha? Warecki wrote: > > >>> > > >>> Hi all! > > >>> > > >>> I just want to make sure that Graal is the correct project > > >>> to start with. > > >>> I'd like to create bytecode to Epiphany architecture asm > > >>> compiler. > > >>> > > >>> Epiphany is a multicore RISC based architecture [1] that > > >>> aims to be an > > >>> accelerator (not the host CPU) unit. Epiphany architecture > > >>> is used in > > >>> Parallella computer (ARM is the host CPU) [2]. > > >>> > > >>> What I want to achieve is to compile and send to epiphany > > >>> only part of a > > >>> Java program to be processed in a parallel way. Probably I > > >>> will try to > > >>> integrate it with Sumarta project. > > >>> > > >>> Example use case: > > >>> > > >>> Streams.intRange(0, in.length).parallel().forEach( id -> > > >>> {c[id]=a[id]+b[id];}); > > >>> > > >>> // c[id]=a[id]+b[id]; -> This code will be executed on > > >>> Epiphany. "id" > > >>> is the identifier of a core. > > >>> > > >>> > > >>> Is Graal the correct project to implement such bytecode to > > >>> epiphany asm > > >>> compiler? I am inexperienced in this area... Any ideas > > >>> about this? > > >>> > > >>> Best, > > >>> Micha? > > >>> > > >>> > > >>> [1] http://www.adapteva.com/introduction/ > > >>> > > >>> http://www.adapteva.com/wp-content/uploads/2012/10/epiphany_arch_r > > >>> efer > > >>> ence_3.12.10.03.pdf > > >>> > > >>> [2] http://www.parallella.org/ > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > From bernhard.urban at jku.at Mon Sep 16 05:04:32 2013 From: bernhard.urban at jku.at (Bernhard Urban) Date: Mon, 16 Sep 2013 14:04:32 +0200 Subject: Truffle and support for a class name 'Object' In-Reply-To: References: <8F953FA7-E0A0-4912-8D5D-8E630EB0A86C@stefan-marr.de> Message-ID: <5236F3D0.7000906@jku.at> There's also a nice example in the book "Java Puzzlers" [1] why it's generally not a good idea to use names from classes living in java.lang. [1] http://www.javapuzzlers.com/java-puzzlers-sampler.pdf (Page 16) On 09/13/2013 12:02 AM, Thomas Wuerthinger wrote: > Thanks for the report. We will add support for checking name clashes. In general, we would like to suggest the use of class name prefixes for language implementations to avoid clashes with the Java standard library or other guest language implementations. - thomas > > On Sep 12, 2013, at 11:43 PM, Stefan Marr wrote: > >> Dear all: >> >> I would like to request a feature: >> >> Could you please support the class name 'Object' for guest language implementations? >> Or, could you put a big red warning into the Truffle FAQ to avoid it? >> >> If you would consider solution 1, this patch might be useful for some people: >> >> diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java >> index b94912e..e97517d 100644 >> --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java >> +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java >> @@ -137,6 +137,10 @@ public final class OrganizedImports { >> private String createDeclaredTypeName(Element enclosedElement, DeclaredType type) { >> String name = type.asElement().getSimpleName().toString(); >> >> + if ("Object".equals(name)) { >> + return getQualifiedName(type); >> + } >> + >> if (needsImport(enclosedElement, type)) { >> TypeMirror usedByType = simpleNamesUsed.get(name); >> if (usedByType == null) { >> >> >> I had a similar patch for Utils.getDeclaredName() which might not be necessary anymore. >> However, this one in OrganizedImports is necessary to generate proper specialized classes when using the Truffle-DSL for type specializations. >> >> As mentioned with the original patch, this is also only a work-around. A proper solution might require to check for name clashes directly. >> >> Thanks >> Stefan >> >> >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> > From tom.deneau at amd.com Mon Sep 16 10:01:34 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Sep 2013 17:01:34 +0000 Subject: Question about mark words in allocated objects Message-ID: We are experimenting with an HSA device doing object allocation. In our prototype, there is one or more idle Java threads acting as a "donor threads", in that each donates its TLAB. In the simple case below, there is only one donor thread. Since there can be more HSA device workitems than there are donor threads, the workitems use atomic operations to bump the tlab.top pointer of a donor thread. The usual graal code then takes over to fill in the contents of the allocated item, including the mark word, class pointer, etc. In our usual junit test cases, we run the "kernel function" sequentially on the CPU and then as an HSA kernel on the GPU and compare results. This is a "--vm server" run so the CPU side is not going thru graal In my test case, I am using a JNI function to print out the full object contents including the header after the "kernel" completes. The atomic pointer bumps seem to work correctly but I've noticed a slight difference in the header contents. Since we are running with the default UseBiasedLocking enabled, I can see that when the object is initialized from the "prototype mark word", it is initialized with the value 5 (I assume this means anonymously biased?). I have noticed that when we run normal sequential Java and print out the mark word after the kernel has run, the mark word has a value of 1 (unlocked). But if the kernel has run on the GPU and we print out the mark word, it is still 5 in each object. The rest of the object contents matches between the CPU and GPU Runs. Where does the mark word get changed from 5 to 1 on the cpu side? -- Tom From doug.simon at oracle.com Mon Sep 16 11:35:21 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Sep 2013 20:35:21 +0200 Subject: Question about mark words in allocated objects In-Reply-To: References: Message-ID: On Sep 16, 2013, at 7:01 PM, "Deneau, Tom" wrote: > We are experimenting with an HSA device doing object allocation. > > In our prototype, there is one or more idle Java threads acting as a "donor threads", in that each donates its TLAB. > In the simple case below, there is only one donor thread. > > Since there can be more HSA device workitems than there are donor threads, the workitems use atomic operations to bump the tlab.top pointer of a donor thread. The usual graal code then takes over to fill in the contents of the allocated item, including the mark word, class pointer, etc. > In our usual junit test cases, we run the "kernel function" sequentially on the CPU and then as an HSA kernel on the GPU and compare results. This is a "--vm server" run so the CPU side is not going thru graal > > In my test case, I am using a JNI function to print out the full object contents including the header after the "kernel" completes. The atomic pointer bumps seem to work correctly but I've noticed a slight difference in the header contents. > > Since we are running with the default UseBiasedLocking enabled, I can see that when the object is initialized from the "prototype mark word", it is initialized with the value 5 (I assume this means anonymously biased?). It means biasable but unlocked (see HotSpotReplacementsUtil.biasedLockPattern() and its usage in MonitorSnippets). > I have noticed that when we run normal sequential Java and print out the mark word after the kernel has run, the mark word has a value of 1 (unlocked). But if the kernel has run on the GPU and we print out the mark word, it is still 5 in each object. The rest of the object contents matches between the CPU and GPU Runs. > > Where does the mark word get changed from 5 to 1 on the cpu side? This is almost certainly due to the delayed initialization of biased locking - see BiasedLocking::init (in biasedLocking.cpp). Try adding -XX:BiasedLockingStartupDelay=0 as a VM option. -Doug From tom.deneau at amd.com Mon Sep 16 11:39:37 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Sep 2013 18:39:37 +0000 Subject: Question about mark words in allocated objects In-Reply-To: References: Message-ID: Doug -- Yes, that was it. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, September 16, 2013 1:35 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: Question about mark words in allocated objects On Sep 16, 2013, at 7:01 PM, "Deneau, Tom" wrote: > We are experimenting with an HSA device doing object allocation. > > In our prototype, there is one or more idle Java threads acting as a "donor threads", in that each donates its TLAB. > In the simple case below, there is only one donor thread. > > Since there can be more HSA device workitems than there are donor threads, the workitems use atomic operations to bump the tlab.top pointer of a donor thread. The usual graal code then takes over to fill in the contents of the allocated item, including the mark word, class pointer, etc. > In our usual junit test cases, we run the "kernel function" sequentially on the CPU and then as an HSA kernel on the GPU and compare results. This is a "--vm server" run so the CPU side is not going thru graal > > In my test case, I am using a JNI function to print out the full object contents including the header after the "kernel" completes. The atomic pointer bumps seem to work correctly but I've noticed a slight difference in the header contents. > > Since we are running with the default UseBiasedLocking enabled, I can see that when the object is initialized from the "prototype mark word", it is initialized with the value 5 (I assume this means anonymously biased?). It means biasable but unlocked (see HotSpotReplacementsUtil.biasedLockPattern() and its usage in MonitorSnippets). > I have noticed that when we run normal sequential Java and print out the mark word after the kernel has run, the mark word has a value of 1 (unlocked). But if the kernel has run on the GPU and we print out the mark word, it is still 5 in each object. The rest of the object contents matches between the CPU and GPU Runs. > > Where does the mark word get changed from 5 to 1 on the cpu side? This is almost certainly due to the delayed initialization of biased locking - see BiasedLocking::init (in biasedLocking.cpp). Try adding -XX:BiasedLockingStartupDelay=0 as a VM option. -Doug From thomas.wuerthinger at oracle.com Wed Sep 18 07:17:56 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 18 Sep 2013 16:17:56 +0200 Subject: How to do AST inlining of method calls? In-Reply-To: <3609B51E-6A59-479D-9924-65E8A0151A4D@stefan-marr.de> References: <522FB9CA.4000705@jku.at> <3609B51E-6A59-479D-9924-65E8A0151A4D@stefan-marr.de> Message-ID: <8F431EA8-8E0E-4273-B02E-27D07F765B25@oracle.com> Stefan, there are three ways to work with Truffle frames: a) VirtualFrame instances that are guaranteed to be virtualised and therefore have severe restrictions. b) MaterializedFrame instances that can be used like normal Java objects. c) PackedFrame instances that speculate on not being used by the method they are transferred to. It is always possible to create a MaterializedFrame instance from a VirtualFrame instance via a call to Frame.materialize [1]. However, it should be avoided wherever possible as the performance of virtual frames is an order of magnitude better than the performance of materialised frames. The reasons for the restrictions around virtual frame is to provide a predictable performance experience when dealing with frames. In the problem you describe below, the main question is why the method with the frame as a parameter cannot be inlined. Can you send the command line for triggering the problem? - thomas [1] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/com.oracle.truffle.api/javadoc/com/oracle/truffle/api/frame/Frame.html#materialize() On Sep 12, 2013, at 1:23 PM, Stefan Marr wrote: > Hi: > > On 11 Sep 2013, at 02:31, Andreas Woess wrote: > >> On 11.09.2013 01:20, Stefan Marr wrote: >>> Specifically, this means, I still rely on a frame to be constructed in a new InlinedMonomorphicMessageNode, which I introduced. >>> This approach allows me to preserve the semantics of having a frame, and with it access to the same Smalltalk local variables as previously, even so the AST nodes are inlined in the monomorphic all site. Another problem this design solves is the catching of the same control flow exceptions as the method node that got replaced. Especially, the non-local return still needs to be treated correctly, I think, even with inlining. >> This is the correct approach. Note that you should duplicate the tree in >> its uninitialized state (e.g. in the constructor of the method root node >> and keep a copy there) so that the inlined tree specializes for that >> particular call. > > Right, that's what I do. Currently, the only specialization is for monomorphic and polymorphic sends. > And the copying of tree nodes for message sends will create an uninitialized message send node. > > >>> Currently, my main issue with this naive approach is that I still need to create a VirtualFrame object. >>> This is possible with the frame factory given to the inline(.) method of the InlinableCallSite interface, but it causes problems with the Graal/Truffle compiler. The VerifyFrameDoesNotEscapePhase causes issues, because it sees the frame creation and complains about the fact that the new frame is given to a method call. The executeInlined(..) method below is the relevant fragment. >> Again, this is this the right way. You should get a stack trace with the >> approximate location of the problem. > > After experimenting more with this, and trying to understand what the issue is, I start to belief that the heuristic encoded in VerifyFrameDoesNotEscapePhase is just to simple. After removing the check for passing the frame on to a method, the benchmarks run to completion. So, I have the feeling (but without being very confident) that I use the frame classes in a more or less correct way. > > I am wondering whether there could just be an annotation that tells the check in VerifyFrameDoesNotEscapePhase that a frame passed to a certain method is not problematic? > The reason why I think that the heuristic is too simple is that method call boundaries are a to strong constrained. Since not all calls are inlined in the graph, the check becomes restrictively conservative. I experimented with just duplicating code to give the check more information, but as soon as I get to a truly polymeric send site, I still get into trouble? > > I wonder why such a simple issue is not problematic in the other Truffle-based languages being implemented. Could I annotate the frame creation with something that marks it as unproblematic? > > > For others interested in the code for inlining methods, the following commit should be the most relevant piece: https://github.com/smarr/TruffleSOM/commit/1edba8692fd0a0ffe78510f45597c6f8a8a6cadf > The cloning of nodes is introduced here: https://github.com/smarr/TruffleSOM/commit/851549ac9d04315a755a1851a002e7b1bd96e55c > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > From andreas.woess at jku.at Wed Sep 18 07:41:45 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 18 Sep 2013 16:41:45 +0200 Subject: Initializing Truffle frames | Was: How to do AST inlining of method calls? In-Reply-To: <126D7D80-44CA-4A7B-AD13-2D311186B8F8@stefan-marr.de> References: <522FB9CA.4000705@jku.at> <126D7D80-44CA-4A7B-AD13-2D311186B8F8@stefan-marr.de> Message-ID: <5239BBA9.3000706@jku.at> The problem is probably what VerifyFrameDoesNotEscapePhase 49-53 says: the FrameSlot parameter is not a compile-time constant. While that assertion might be overly restrictive here since you actually do materialize it, that doesn't change the fact that one shouldn't access virtual frames with a non-constant FrameSlot parameter. Looks like the problem here is that the contents of the argumentSlots and temporarySlots array aren't constant-folded (yet). Worry not, we have changes in the pipeline that will probably fix this without changing your code. You should remove the materialize() then. - andreas On 11.09.2013 16:33, Stefan Marr wrote: > Hi Andreas: > > On 11 Sep 2013, at 02:31, Andreas Woess wrote: > >> I also wonder why you immediately materialize the frame for initializeFrame; this shouldn't be necessary. > I am not sure, but I think Thomas suggested that originally. > Now, looking at it and trying to understand VerifyFrameDoesNotEscapePhase line 49-53, I think the reason for using a materialized frame is that I need to initialize the frame object with arguments. > The relevant code is [1]: > So, each frame contains self, a marker object that tells me whether the frame is still alive/available, the method's arguments and temporary fields required during execution of the method. These need to be all initialized based on the arguments object. > > @ExplodeLoop > private FrameOnStackMarker initializeFrame(MaterializedFrame frame) { > Object[] args = frame.getArguments(Arguments.class).arguments; > try { > for (int i = 0; i < argumentSlots.length; i++) { > frame.setObject(argumentSlots[i], args[i]); > } > > frame.setObject(selfSlot, frame.getArguments(Arguments.class).self); > > FrameOnStackMarker marker = new FrameOnStackMarker(); > frame.setObject(nonLocalReturnMarker, marker); > > for (int i = 0; i < temporarySlots.length; i++) { > frame.setObject(temporarySlots[i], universe.nilObject); > } > > return marker; > } catch (FrameSlotTypeException e) { > throw new RuntimeException("Should not happen, since we only have one type currently!"); > } > } > > I think, I remember that Thomas suggested to change this approach in order to allow for specialization based on number of arguments and temporaries, I suppose. > Am not entirely sure thought. > Also, I don't see how that would lead the arguments and self to be compile time constants, which is what I understand is what VerifyFrameDoesNotEscapePhase is checking for in the second part. > >> Regarding your last email, you might want to consider rewriting control >> structures / well-known messages like ifTrue, whileTrue, etc. to >> specialized nodes instead of going through a normal call, e.g. a >> WhileTrueNode with inlined condition and block. > I would like to avoid that for the moment. > Once I get the inlining working, I would rather like to experiment with getting rid of boxing integers :) > > Thanks > Stefan > > [1] https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/Method.java#L89 > > > From D.Sturm42 at gmail.com Wed Sep 18 11:17:25 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 18 Sep 2013 20:17:25 +0200 Subject: Callee-saved registers Message-ID: What is the best way to handle callee saved registers in the backend? This doesn't seem to be handled by the register allocator already (since AMD64 declares all registers caller saved and SPARC has its handy register windows). The easiest solution seems to introduce a placeholder LIR instruction in the prologue and make sure to spill all destroyed registers there on the stack and then restore them at the exit points. But that is obviously not especially efficient if there's more than one exit point (I'd have to save/restore all potentially destroyed registers). So is there some way to get the register allocator to spill callee-saved registers before using them and then restoring them at the end? -Daniel From christian.wimmer at oracle.com Wed Sep 18 11:50:15 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 18 Sep 2013 11:50:15 -0700 Subject: Callee-saved registers In-Reply-To: References: Message-ID: <5239F5E7.2010304@oracle.com> When you define callee-saved registers in your calling convention, the method prologue/epilogue code (the FrameContext.enter/leave) methods do the spilling and reloading. Not overly efficient, but it should work. HotSpot (at least on x86) does not use callee saved registers to simplify the internal systems, so are you sure you really need them? -Christian On 09/18/2013 11:17 AM, D.Sturm wrote: > What is the best way to handle callee saved registers in the backend? This > doesn't seem to be handled by the register allocator already (since AMD64 > declares all registers caller saved and SPARC has its handy register > windows). > > The easiest solution seems to introduce a placeholder LIR instruction in > the prologue and make sure to spill all destroyed registers there on the > stack and then restore them at the exit points. But that is obviously not > especially efficient if there's more than one exit point (I'd have to > save/restore all potentially destroyed registers). > > > So is there some way to get the register allocator to spill callee-saved > registers before using them and then restoring them at the end? > > -Daniel > From D.Sturm42 at gmail.com Wed Sep 18 12:22:49 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 18 Sep 2013 21:22:49 +0200 Subject: Callee-saved registers Message-ID: I saw that AMD64 has some (dead) code there in the FrameContext, but for large numbers of registers that can be pretty inefficient, especially for smaller methods (the official ARM Aarch64 ABI specifies 20 callee-saved registers, so that'd be a lot of possibly unnecessary save/restore.. and also blow up the stack frame excessively). I assume I could use caller-saved registers only (and make the easy optimization for external calls to save only the necessary subset), but with the large number of registers available that doesn't seem too efficient, although with enough inlining it probably wouldn't matter too much. Would it be possible to insert a LIRNode in the prologue that stores all callee-saved registers in an array with @Alive annotation and do the same for all epilogue instructions? Wouldn't that cause the RegisterAllocator to spill the registers if necessary? -Daniel From christian.wimmer at oracle.com Wed Sep 18 13:07:30 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 18 Sep 2013 13:07:30 -0700 Subject: Callee-saved registers In-Reply-To: References: Message-ID: <523A0802.40503@oracle.com> On 09/18/2013 12:22 PM, D.Sturm wrote: > I saw that AMD64 has some (dead) code there in the FrameContext, but for > large numbers of registers that can be pretty inefficient, especially > for smaller methods (the official ARM Aarch64 ABI specifies 20 > callee-saved registers, so that'd be a lot of possibly unnecessary > save/restore.. and also blow up the stack frame excessively). > > I assume I could use caller-saved registers only (and make the easy > optimization for external calls to save only the necessary subset), but > with the large number of registers available that doesn't seem too > efficient, although with enough inlining it probably wouldn't matter too > much. The ABI that HotSpot uses internally has nothing to do with the "official" ABI for an architecture or platform. So you have to check what HotSpot expects you to do - since you certainly do not want to make changes to the HotSpot runtime. > Would it be possible to insert a LIRNode in the prologue that stores all > callee-saved registers in an array with @Alive annotation and do the > same for all epilogue instructions? Wouldn't that cause the > RegisterAllocator to spill the registers if necessary? No, there is currently no support in the register allocator for things like that. Basically, you need to find out if a register is used at all, and only spill it then in the prologue/epilogue. It shouldn't be difficult to find out if a register was ever used, but it is not implemented yet. -Christian From D.Sturm42 at gmail.com Wed Sep 18 13:35:45 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 18 Sep 2013 22:35:45 +0200 Subject: Callee-saved registers In-Reply-To: <523A0802.40503@oracle.com> References: <523A0802.40503@oracle.com> Message-ID: > The ABI that HotSpot uses internally has nothing to do with the "official" ABI for an architecture or platform. So you have to check what HotSpot expects you to do - since you certainly do not want to make changes to the HotSpot runtime. Ok, I'll have to check what the people working on the HotSpot ARMv8 port are doing then, I assumed they'd follow the documented ABI but clearly since we control the whole platform that's not necessary (apart from JNI calls?). > No, there is currently no support in the register allocator for things like that. Basically, you need to find out if a register is used at all, and only spill it then in the prologue/epilogue. It shouldn't be difficult to find out if a register was ever used, but it is not implemented yet. Still not the most efficient solution because we'd have to always consider the worst case (i.e. if there's one path that uses 30 callee saved registers we have to spill all of them even if other paths only need 5). Wouldn't it be possible to tell the allocator that there are values in callee-saved registers that are alive across the whole method? Apart from a bit of bookkeeping to know the original position of each variable to restore it correctly, that seems relatively easy, or am I missing something? -Daniel From christian.wimmer at oracle.com Thu Sep 19 09:40:14 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Thu, 19 Sep 2013 09:40:14 -0700 Subject: Callee-saved registers In-Reply-To: References: <523A0802.40503@oracle.com> Message-ID: <523B28EE.5040004@oracle.com> On 09/18/2013 01:35 PM, D.Sturm wrote: > > The ABI that HotSpot uses internally has nothing to do with the > "official" ABI for an architecture or platform. So you have to check > what HotSpot expects you to do - since you certainly do not want to make > changes to the HotSpot runtime. > Ok, I'll have to check what the people working on the HotSpot ARMv8 port > are doing then, I assumed they'd follow the documented ABI but clearly > since we control the whole platform that's not necessary (apart from JNI > calls?). Again: No, HotSpot does not usually follow the documented native ABI, and you want do not want to change the HotSpot ABI (even if you think it is ridiculously inefficient). Calls from Java code no native code (JNI calls and runtime calls) are expensive anyway because of the thread state management (a stack walk must be able to walk all Java frames and skip all native frames). The different calling convention does not really matter for these calls. > > No, there is currently no support in the register allocator for > things like that. Basically, you need to find out if a register is used > at all, and only spill it then in the prologue/epilogue. It shouldn't be > difficult to find out if a register was ever used, but it is not > implemented yet. > Still not the most efficient solution because we'd have to always > consider the worst case (i.e. if there's one path that uses 30 callee > saved registers we have to spill all of them even if other paths only > need 5). Wouldn't it be possible to tell the allocator that there are > values in callee-saved registers that are alive across the whole method? > Apart from a bit of bookkeeping to know the original position of each > variable to restore it correctly, that seems relatively easy, or am I > missing something? There are ways to make callee save registers more efficient, but don't worry about that until everything else works. It is an optimization, not an essential feature. And yes, I have some ideas on how to implement it and I'm happy to discuss it with you when the time comes. -Christian From doug.simon at oracle.com Thu Sep 19 09:51:58 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 19 Sep 2013 16:51:58 +0000 Subject: hg: graal/graal: 95 new changesets Message-ID: <20130919165732.1432762969@hg.openjdk.java.net> Changeset: 3f8bb25fb0a1 Author: Andreas Woess Date: 2013-09-14 20:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f8bb25fb0a1 IGV: workaround for disappearing search bar. ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/EditorTopComponent.java Changeset: 136eaa90ef41 Author: Andreas Woess Date: 2013-09-14 20:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/136eaa90ef41 Truffle: make NodeUtil class final and its unsafe field private. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 126e20d36563 Author: Andreas Woess Date: 2013-09-14 21:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/126e20d36563 Truffle IGV printer: add edge labels. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/GraphPrintVisitor.java Changeset: 269e6794e1ec Author: Andreas Woess Date: 2013-09-15 02:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/269e6794e1ec Truffle: Frame restructuring. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/FrameWithoutBoxingSubstitutions.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/FrameSlotTypeSpecializationTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReturnTypeSpecializationTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlotImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameUtil.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultFrameTypeConversion.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultMaterializedFrame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadLocalNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WriteLocalNode.java Changeset: fe748819e31c Author: Doug Simon Date: 2013-09-15 16:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe748819e31c removed the IterableNodeType marker interface from BlockPlaceholderNode (GRAAL-471) ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 68c0e475d14f Author: Doug Simon Date: 2013-09-15 16:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/68c0e475d14f removed the IterableNodeType marker interface from CommitAllocationNode (GRAAL-471) ! 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.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java Changeset: d37316952262 Author: Doug Simon Date: 2013-09-15 16:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d37316952262 removed the IterableNodeType marker interface from ControlSinkNode (GRAAL-471) ! 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: 5507e2824bc6 Author: Doug Simon Date: 2013-09-15 16:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5507e2824bc6 added metric to count IterableNodeTypes (GRAAL-471) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! mx/projects Changeset: 2bd626188d31 Author: Thomas Wuerthinger Date: 2013-09-05 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2bd626188d31 Introduce TruffleMinInvokeThreshold flag. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: e9fc19eb3efb Author: Thomas Wuerthinger Date: 2013-09-13 23:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e9fc19eb3efb Merge. - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayTest.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitAndNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitBooleanNode.java - src/gpu/ptx/vm/kernelArguments.cpp - src/gpu/ptx/vm/kernelArguments.hpp Changeset: 2278d53b4d38 Author: Thomas Wuerthinger Date: 2013-09-15 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2278d53b4d38 New way of handling skipped exceptions in the graph builder. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 8f8f6afeb97a Author: Thomas Wuerthinger Date: 2013-09-15 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8f8f6afeb97a New caching mechanism in TruffleCache for better compilation performance. Clean up of partial evaluator phases. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/OptimisticOptimizations.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/InlineTrivialGettersPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceLoadFinalPhase.java Changeset: a21a54b7ead1 Author: Thomas Wuerthinger Date: 2013-09-15 16:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a21a54b7ead1 Early return from node replacement. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 4ab1f371adc8 Author: Thomas Wuerthinger Date: 2013-09-15 16:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4ab1f371adc8 Do not assign new source section if replacing node already has source section assigned. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: e8dfad9a424f Author: Thomas Wuerthinger Date: 2013-09-15 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e8dfad9a424f Merge. - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 932252b772c3 Author: Thomas Wuerthinger Date: 2013-09-15 18:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/932252b772c3 Merge. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 44d5989ae745 Author: Thomas Wuerthinger Date: 2013-09-15 19:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/44d5989ae745 Merge. Changeset: f091e0d6f4f3 Author: Thomas Wuerthinger Date: 2013-09-15 22:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f091e0d6f4f3 Disallow add for global value numberable node types. Introduce addWithoutUnique. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.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/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.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/LoadFieldNode.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/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.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/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializedObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 64a9ed9f1e8d Author: Thomas Wuerthinger Date: 2013-09-16 01:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/64a9ed9f1e8d Introduce NodeClass.isLeafNode(). Avoid cloning of leaf nodes if equal node is found in destination graph. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 317036da1f29 Author: Thomas Wuerthinger Date: 2013-09-16 01:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/317036da1f29 Improve global value numbering algorithm. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 58b2ae907046 Author: Thomas Wuerthinger Date: 2013-09-16 01:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58b2ae907046 Fix LoadJavaMirrorWithKlassPhase to use new node addition constraints. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java Changeset: 6f2435671a70 Author: Thomas Wuerthinger Date: 2013-09-16 02:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f2435671a70 Correct test. ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/InstanceOfTest.java Changeset: 74ea8747b43a Author: Thomas Wuerthinger Date: 2013-09-16 10:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/74ea8747b43a Add PhiNode in InliningUtil with addWithoutUnique. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 01512eb1ae7b Author: Bernhard Urban Date: 2013-09-16 15:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01512eb1ae7b bootstrap: print number of compiled methods ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! mx/sanitycheck.py Changeset: ec7aad9dfc47 Author: Doug Simon Date: 2013-09-16 13:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec7aad9dfc47 made 'mx build' refresh IDE configs automatically ! .hgignore ! mxtool/mx.py Changeset: b9e963c44ed5 Author: Doug Simon Date: 2013-09-16 16:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b9e963c44ed5 removed the IterableNodeType marker interface from ReturnNode (GRAAL-471) ! 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/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.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/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InsertStateAfterPlaceholderPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/SafepointInsertionPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: f8a87f3fab5a Author: Doug Simon Date: 2013-09-16 17:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f8a87f3fab5a removed the IterableNodeType marker interface from (Read|Write|ArrayRangeWrite|LoweredCompareAndSwap)Node (GRAAL-471) ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.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/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java Changeset: 929a03fbbbaf Author: Doug Simon Date: 2013-09-16 17:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/929a03fbbbaf Merge. Changeset: d213be26ffb4 Author: Doug Simon Date: 2013-09-16 19:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d213be26ffb4 added metric to count number of times a typed node iterator is used per IterableNodeType (GRAAL-471) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 775e139362d8 Author: Doug Simon Date: 2013-09-16 19:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/775e139362d8 removed the IterableNodeType marker interface from SafepointNode (GRAAL-471) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java Changeset: 2b2de196d8f9 Author: Doug Simon Date: 2013-09-16 19:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2b2de196d8f9 fixed SafepointInsertionPhase to add safepoints for return nodes (if necessary) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/SafepointInsertionPhase.java Changeset: 3967f9f306f8 Author: Thomas Wuerthinger Date: 2013-09-16 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3967f9f306f8 Factor usages of getNodeClass(). ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 8e1e41cd2c75 Author: Thomas Wuerthinger Date: 2013-09-16 19:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e1e41cd2c75 Common out code for frame state constructors. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java Changeset: 05230c6c8d52 Author: Thomas Wuerthinger Date: 2013-09-16 19:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05230c6c8d52 Small improvement to Graph.copy performance. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: a625d254e137 Author: Thomas Wuerthinger Date: 2013-09-16 19:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a625d254e137 Avoid allocation of replacement hashmap in addDuplicates and also in InliningUtil.inline. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentWhole.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 891fa65ef9ec Author: Thomas Wuerthinger Date: 2013-09-16 19:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/891fa65ef9ec Merge. Changeset: 3522f7c99c5f Author: Thomas Wuerthinger Date: 2013-09-16 20:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3522f7c99c5f Allow null DuplicationReplacement in addDuplicates. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 25de2c04c956 Author: Thomas Wuerthinger Date: 2013-09-16 20:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/25de2c04c956 Small performance improvement to inlining. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 1c5bc8307c76 Author: Thomas Wuerthinger Date: 2013-09-16 20:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c5bc8307c76 Merge. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 8505bcff4bdc Author: Thomas Wuerthinger Date: 2013-09-16 23:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8505bcff4bdc New graph duplication mechanism that allows in-place fixing of edges. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 77d9f12797c5 Author: Thomas Wuerthinger Date: 2013-09-17 00:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77d9f12797c5 Use NodeMap in inlining utility when number of nodes is high. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeMap.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeNodeMap.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.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/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 435c8b984680 Author: Thomas Wuerthinger Date: 2013-09-17 01:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/435c8b984680 Distinguish inputs and successors in in-place updates. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 9d341b6e47e5 Author: Thomas Wuerthinger Date: 2013-09-17 02:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d341b6e47e5 Correct custom clone implementations after change of Node base class clone method. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java Changeset: 89e9476040de Author: Roland Schatz Date: 2013-09-17 10:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/89e9476040de Support for sub-graphs in IGV. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputNode.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Diagram.java ! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Figure.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/widgets/FigureWidget.java Changeset: f7a09339e29b Author: Thomas Wuerthinger Date: 2013-09-17 16:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7a09339e29b Do not create type profile proxies for receiver objects if optimistic optimization UseTypeCheckHints is disabled. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 524d0a0a47b8 Author: Thomas Wuerthinger Date: 2013-09-17 17:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/524d0a0a47b8 New algorithm for Truffle tree expansion. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 39f98ffd187f Author: Thomas Wuerthinger Date: 2013-09-17 17:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/39f98ffd187f Fix compiler warnings. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 976ebd1973d1 Author: Christian Wimmer Date: 2013-09-17 10:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/976ebd1973d1 The runtime might not always be able to report an array length ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestMetaAccessProvider.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java ! 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/java/ArrayLengthNode.java Changeset: 7aed6a236e0b Author: Morris Meyer Date: 2013-09-17 14:26 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7aed6a236e0b class-for-instruction PTXAssembler ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/LogicPTXTest.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.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! mx/projects Changeset: 7e661dbea359 Author: Andreas Woess Date: 2013-09-17 22:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7e661dbea359 Truffle: always expand methods with virtual frame receiver. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 7a987d8147c2 Author: Thomas Wuerthinger Date: 2013-09-17 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a987d8147c2 Do not inline into OptimizedCallTarget.call. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java Changeset: 13b3c8cd5e52 Author: Andreas Woess Date: 2013-09-17 22:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13b3c8cd5e52 Merge. Changeset: facb442de5db Author: Doug Simon Date: 2013-09-17 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/facb442de5db added support for specifying the JDK version in which a library becomes redundant (e.g., nashorn.jar) ! mxtool/mx.py Changeset: 0d3b767e5356 Author: Doug Simon Date: 2013-09-17 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d3b767e5356 removed the IterableNodeType marker interface from InvokeNode (GRAAL-471) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 8d0303d8dbde Author: Mick Jordan Date: 2013-09-17 16:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8d0303d8dbde make GreedyInliningPolicy/ExactInlineInfo public, allow optional null check suppression on inline ! 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: 657079bf6174 Author: Thomas Wuerthinger Date: 2013-09-17 23:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/657079bf6174 Create GuardNode instead of FixedGuardNode when lowering GuardingPiNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java Changeset: 1870ea57e814 Author: Thomas Wuerthinger Date: 2013-09-17 23:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1870ea57e814 Remove Lowering interface from DeoptimizeNode and UnwindNode. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java Changeset: 8b3a2258b368 Author: Thomas Wuerthinger Date: 2013-09-17 23:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b3a2258b368 Remove unused allocated graph in snippet instantiation. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 693b06f5d8a6 Author: Thomas Wuerthinger Date: 2013-09-18 00:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/693b06f5d8a6 Directly lower checkcast nodes introduced when lowering store indexed instructions. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 226ef8ab5bc0 Author: Thomas Wuerthinger Date: 2013-09-18 00:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/226ef8ab5bc0 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: e9cf2b37c713 Author: Thomas Wuerthinger Date: 2013-09-18 00:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e9cf2b37c713 Merge. Changeset: 7f8c80e31750 Author: Thomas Wuerthinger Date: 2013-09-18 02:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7f8c80e31750 Fix GuardingPiNode to preserve checkcast semantics also if value of checkcast is unused. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java Changeset: 56e59e384dc1 Author: Thomas Wuerthinger Date: 2013-09-18 02:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56e59e384dc1 Merge. Changeset: 4eec2ac671c2 Author: Christian Wimmer Date: 2013-09-17 18:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4eec2ac671c2 Refactor the WordTypeVerificationPhase to use fewer graph iterations, and invoke it a fewer places ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.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/CStringNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CurrentJavaThreadNode.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/DimensionsNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorCounterNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeVerificationPhase.java Changeset: 03fe11f5f186 Author: S.Bharadwaj Yadavalli Date: 2013-09-17 23:35 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 PTX Codegen: predicate register materialization and declaration; conditional branch generation; fix register declaration. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.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.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXCompare.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java ! src/share/vm/graal/graalVMToCompiler.cpp Changeset: 528ab536b403 Author: Doug Simon Date: 2013-09-18 10:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/528ab536b403 changed iteration over InvokeNodes in a graph to avoid Graph.getNodes() (GRAAL-471) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: e29743466d00 Author: Doug Simon Date: 2013-09-18 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e29743466d00 fixed regression in mx.py ! mxtool/mx.py Changeset: 6e8df0ca2879 Author: Roland Schatz Date: 2013-09-18 12:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e8df0ca2879 Fix LocalNode dumping in CFGPrinter. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 300ee6e4fe14 Author: Christian Wimmer Date: 2013-09-18 12:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/300ee6e4fe14 Improve performance of WordTypeRewriterPhase ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: de32cc4379a4 Author: Doug Simon Date: 2013-09-18 21:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de32cc4379a4 removed unsupported option ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java Changeset: 23d91654c363 Author: Doug Simon Date: 2013-09-18 21:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23d91654c363 completed renaming GuardsPhase to GuardsStage ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.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.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerExactArithmeticSplitNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java Changeset: cfca65c7cf02 Author: Thomas Wuerthinger Date: 2013-09-18 23:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cfca65c7cf02 Do not propagate state over loop exits in conditional elimination phase as the phase does not insert proxy nodes. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Changeset: f6f5fceef2ce Author: Thomas Wuerthinger Date: 2013-09-19 01:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6f5fceef2ce Simpler but more efficient version of Truffle graph cache. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 9c9bc8c6a0df Author: Thomas Wuerthinger Date: 2013-09-19 01:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c9bc8c6a0df Merge. Changeset: 8fa3a9f1dda4 Author: Thomas Wuerthinger Date: 2013-09-19 01:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8fa3a9f1dda4 Simplifications to the partial evaluator. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 8d8a7d7f0259 Author: Thomas Wuerthinger Date: 2013-09-19 01:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d8a7d7f0259 Remove permanent flag on ValueAnchorNode. Memory aware scheduling fixes the problem with synchronized method return values. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.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/ValueAnchorCleanupPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java Changeset: f12b418ebc74 Author: Thomas Wuerthinger Date: 2013-09-19 02:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f12b418ebc74 Allow only single input for value anchors. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.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/TailDuplicationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ValueAnchorCleanupPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java Changeset: 0d16339188ef Author: Thomas Wuerthinger Date: 2013-09-19 04:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d16339188ef Improvements to the Truffle cache. + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ClassSubstitutions.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/SlowPathExceptionSubstitutions.java Changeset: 972f2e2c797a Author: Thomas Wuerthinger Date: 2013-09-19 04:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/972f2e2c797a Fix a bug in the escape analysis of pi nodes. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: cb81a0f3407c Author: Thomas Wuerthinger Date: 2013-09-19 05:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cb81a0f3407c Fix PartialEscapeAnalysisTest. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java Changeset: 100e196f8728 Author: Gilles Duboscq Date: 2013-09-17 16:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/100e196f8728 ScheduledNodeIterator needs to be able to reconnect even if something is inserted after the last fixed node of a block when there is only one successor ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ScheduledNodeIterator.java Changeset: bffe5758c209 Author: Gilles Duboscq Date: 2013-09-17 17:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bffe5758c209 Snippets processing in ArrayCopyNode and ObjectCloneNode need proper scoping ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java Changeset: 8a3b59397044 Author: Gilles Duboscq Date: 2013-09-17 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a3b59397044 The SnippetFrameStateCleanupPhase now sets invalid framestates on the paths of side effecting instruction except for the last one where an AFTER_BCI is used. Remove InsertStateAfterPlaceholderPhase - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InsertStateAfterPlaceholderPhase.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/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetFrameStateCleanupPhase.java Changeset: f679f5411fd7 Author: Gilles Duboscq Date: 2013-09-18 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f679f5411fd7 Better handling of methods which have no line number or variable name tables. Force local/stack sizes to report 0 for native and abstract methods Make TestResolvedJavaMethod getMaxStackSizeTest a bit more flexible ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 0b1f0763bb18 Author: Gilles Duboscq Date: 2013-09-18 18:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b1f0763bb18 Use earliest schedule for guards ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: b4480517a44d Author: Gilles Duboscq Date: 2013-09-18 18:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4480517a44d Disable StaticIntSpillTest until HSAIL backend problem is resolved ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticIntSpillTest.java Changeset: 5a6d1d2a6522 Author: Gilles Duboscq Date: 2013-09-19 10:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a6d1d2a6522 Disable StaticDoubleSpillTest until HSAIL backend problem is resolved ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillTest.java Changeset: ff05c78a7f64 Author: Christian Wirth Date: 2013-09-19 10:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff05c78a7f64 use time passed to decide what methods to compile or inline + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: 9b8e3b2986c5 Author: Christian Wirth Date: 2013-09-19 10:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b8e3b2986c5 add two options for compilation decisions based on time passed ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: c8d0d5ff846e Author: Christian Wirth Date: 2013-09-19 10:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c8d0d5ff846e Merged - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InsertStateAfterPlaceholderPhase.java Changeset: 45570e4fe8a9 Author: Gilles Duboscq Date: 2013-09-19 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45570e4fe8a9 Group Deoptimization which have the same FrameState ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java Changeset: 3e4482a06170 Author: Gilles Duboscq Date: 2013-09-19 13:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e4482a06170 Exit loops for deopts that miss loop exits in DeoptimizationGroupingPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java Changeset: 271ffa2d36b3 Author: Thomas Wuerthinger Date: 2013-09-19 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/271ffa2d36b3 Clean up value anchors connected to fixed nodes. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java Changeset: 7778a0f2999a Author: Thomas Wuerthinger Date: 2013-09-19 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7778a0f2999a Run partial escape analysis on Truffle cache methods. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: fdd2cdeb933c Author: Thomas Wuerthinger Date: 2013-09-19 16:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fdd2cdeb933c Merge. From D.Sturm42 at gmail.com Thu Sep 19 10:36:39 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Thu, 19 Sep 2013 19:36:39 +0200 Subject: Callee-saved registers In-Reply-To: <523B28EE.5040004@oracle.com> References: <523A0802.40503@oracle.com> <523B28EE.5040004@oracle.com> Message-ID: > Again: No, HotSpot does not usually follow the documented native ABI, and you want do not want to change the HotSpot ABI (even if you think it is ridiculously inefficient). Didn't want to make that sound so negative :-) Also since we're so aggressively inlining there shouldn't be many really small functions around where it would make a big difference. > There are ways to make callee save registers more efficient, but don't worry about that until everything else works. It is an optimization, not an essential feature. And yes, I have some ideas on how to implement it and I'm happy to discuss it with you when the time comes. Absolutely, I already implemented the purely caller-saved version which should work fine for now. When I get everything working, that would be interesting to see if such a change to the calling convention would actually make any measurable difference or not. But you're right that it shouldn't have a high priority for me. -Daniel From doug.simon at oracle.com Thu Sep 19 11:56:28 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 19 Sep 2013 18:56:28 +0000 Subject: hg: graal/graal: Fix partial evaluator to not inline SlowPath methods. Message-ID: <20130919185636.86B6E62988@hg.openjdk.java.net> Changeset: a66adc07e1d6 Author: Thomas Wuerthinger Date: 2013-09-19 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a66adc07e1d6 Fix partial evaluator to not inline SlowPath methods. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java From Vasanth.Venkatachalam at amd.com Fri Sep 20 12:12:01 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 20 Sep 2013 19:12:01 +0000 Subject: webrev for register decoupling changes Message-ID: <5DD1503F815BD14889DC81D28643E3A73F916512@SATLEXDAG02.amd.com> Hi, We never received feedback on this webrev. I'd like to remind people to please review this and provide your feedback. These changes are along the lines of what Thomas Wuerthinger recommended to allow the HSAIL register configuration to be used, namely by overriding Backend.newFrameMap( ) in HSAILBackend.. Vasanth From: Venkatachalam, Vasanth Sent: Tuesday, September 10, 2013 1:38 PM To: graal-dev at openjdk.java.net Subject: webrev for register decoupling changes Hi, Graal's register allocator was previously calling into the x86 runtime to get register numbers to be used for generating HSAIL code. The x86 register numbers were getting translated into the corresponding HSAIL register mnemonics in the assembler. This small webrev allows the register allocator to work with the HSAIL register configuration for getting register numbers to be used for generating HSAIL code. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-registerdecoupling/webrev/ Note: HSAIL uses a special calling convention where function params are passed in an arg segment in memory. Currently Graal only supports a choice between a register-based or stack-based calling convention. We have yet to add support for an arg-segment based calling convention. This will be forthcoming in a later patch. However, the current patch makes the code generation more accurate from the point of view of the HSAIL register configuration. Please review and provide your feedback. Vasanth From doug.simon at oracle.com Fri Sep 20 12:24:32 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 20 Sep 2013 21:24:32 +0200 Subject: webrev for register decoupling changes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F916512@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F916512@SATLEXDAG02.amd.com> Message-ID: <21CFAF92-35AF-4F0B-A11C-0D8A061D9D24@oracle.com> Looks good to me. BTW, I assume you received my feedback on http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/? Just want to make sure I didn't forget to press "Send" on that message ;-) -Doug On Sep 20, 2013, at 9:12 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We never received feedback on this webrev. I'd like to remind people to please review this and provide your feedback. > These changes are along the lines of what Thomas Wuerthinger recommended to allow the HSAIL register configuration to be used, namely by overriding Backend.newFrameMap( ) in HSAILBackend.. > > Vasanth > > From: Venkatachalam, Vasanth > Sent: Tuesday, September 10, 2013 1:38 PM > To: graal-dev at openjdk.java.net > Subject: webrev for register decoupling changes > > Hi, > > Graal's register allocator was previously calling into the x86 runtime to get register numbers to be used for generating HSAIL code. > The x86 register numbers were getting translated into the corresponding HSAIL register mnemonics in the assembler. > > This small webrev allows the register allocator to work with the HSAIL register configuration for getting register numbers to be used for generating HSAIL code. > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-registerdecoupling/webrev/ > > Note: HSAIL uses a special calling convention where function params are passed in an arg segment in memory. Currently Graal only supports a choice between a register-based or stack-based calling convention. We have yet to add support for an arg-segment based calling convention. This will be forthcoming in a later patch. However, the current patch makes the code generation more accurate from the point of view of the HSAIL register configuration. > > Please review and provide your feedback. > > Vasanth > > From Vasanth.Venkatachalam at amd.com Fri Sep 20 12:26:16 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 20 Sep 2013 19:26:16 +0000 Subject: webrev for register decoupling changes In-Reply-To: <21CFAF92-35AF-4F0B-A11C-0D8A061D9D24@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73F916512@SATLEXDAG02.amd.com> <21CFAF92-35AF-4F0B-A11C-0D8A061D9D24@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73F91653A@SATLEXDAG02.amd.com> Thanks, Doug. Yes, we did receive your feedback on the other patch and are scoping out the changes you recommended. Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, September 20, 2013 2:25 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: webrev for register decoupling changes Looks good to me. BTW, I assume you received my feedback on http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/? Just want to make sure I didn't forget to press "Send" on that message ;-) -Doug On Sep 20, 2013, at 9:12 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We never received feedback on this webrev. I'd like to remind people to please review this and provide your feedback. > These changes are along the lines of what Thomas Wuerthinger recommended to allow the HSAIL register configuration to be used, namely by overriding Backend.newFrameMap( ) in HSAILBackend.. > > Vasanth > > From: Venkatachalam, Vasanth > Sent: Tuesday, September 10, 2013 1:38 PM > To: graal-dev at openjdk.java.net > Subject: webrev for register decoupling changes > > Hi, > > Graal's register allocator was previously calling into the x86 runtime to get register numbers to be used for generating HSAIL code. > The x86 register numbers were getting translated into the corresponding HSAIL register mnemonics in the assembler. > > This small webrev allows the register allocator to work with the HSAIL register configuration for getting register numbers to be used for generating HSAIL code. > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-registerdecoupling/webrev/ > > Note: HSAIL uses a special calling convention where function params are passed in an arg segment in memory. Currently Graal only supports a choice between a register-based or stack-based calling convention. We have yet to add support for an arg-segment based calling convention. This will be forthcoming in a later patch. However, the current patch makes the code generation more accurate from the point of view of the HSAIL register configuration. > > Please review and provide your feedback. > > Vasanth > > From Vasanth.Venkatachalam at amd.com Fri Sep 20 12:39:37 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 20 Sep 2013 19:39:37 +0000 Subject: webrev for register decoupling changes Message-ID: <5DD1503F815BD14889DC81D28643E3A73F916568@SATLEXDAG02.amd.com> Please attribute the changes to Vasanth Venkatachalam. The message can be: These changes allow the HSAIL register configuration to be used by the register allocator. The main change was to override Backend.newFrameMap() in HSAILBackend to use the HSAIL register configuration. Thanks, Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, September 20, 2013 2:34 PM To: Venkatachalam, Vasanth Subject: Re: webrev for register decoupling changes BTW, I'll push through these changes once you let me know who to attribute in the commit message as well as the message itself. On Sep 20, 2013, at 9:12 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We never received feedback on this webrev. I'd like to remind people to please review this and provide your feedback. > These changes are along the lines of what Thomas Wuerthinger recommended to allow the HSAIL register configuration to be used, namely by overriding Backend.newFrameMap( ) in HSAILBackend.. > > Vasanth > > From: Venkatachalam, Vasanth > Sent: Tuesday, September 10, 2013 1:38 PM > To: graal-dev at openjdk.java.net > Subject: webrev for register decoupling changes > > Hi, > > Graal's register allocator was previously calling into the x86 runtime to get register numbers to be used for generating HSAIL code. > The x86 register numbers were getting translated into the corresponding HSAIL register mnemonics in the assembler. > > This small webrev allows the register allocator to work with the HSAIL register configuration for getting register numbers to be used for generating HSAIL code. > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-registerdecoupling/webrev/ > > Note: HSAIL uses a special calling convention where function params are passed in an arg segment in memory. Currently Graal only supports a choice between a register-based or stack-based calling convention. We have yet to add support for an arg-segment based calling convention. This will be forthcoming in a later patch. However, the current patch makes the code generation more accurate from the point of view of the HSAIL register configuration. > > Please review and provide your feedback. > > Vasanth > > From doug.simon at oracle.com Sat Sep 21 18:00:18 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 22 Sep 2013 01:00:18 +0000 Subject: hg: graal/graal: 20 new changesets Message-ID: <20130922010220.C787162A16@hg.openjdk.java.net> Changeset: d8f291981d75 Author: Morris Meyer Date: 2013-09-19 15:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d8f291981d75 PTX assembler Register -> Variable conversion ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAddress.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java + graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXStateSpace.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! 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/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/LogicPTXTest.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.lir.ptx/src/com/oracle/graal/lir/ptx/PTXAddressValue.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMove.java ! mx/projects Changeset: 03c781923573 Author: Doug Simon Date: 2013-09-19 23:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/03c781923573 made snippet and substitution graphs lower themselves before being inlined ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.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/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.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/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.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.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/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: cb5df1879500 Author: Doug Simon Date: 2013-09-19 23:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cb5df1879500 added warning about ignored forced graph dump ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java Changeset: 5c43ea890efa Author: Roland Schatz Date: 2013-09-20 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5c43ea890efa Specialized asNode for FixedWithNextNode and FloatingNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatingNode.java Changeset: 9c9683970656 Author: Roland Schatz Date: 2013-09-20 13:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c9683970656 Allow multiple NodeChangedListeners. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: 63ca7ec7440f Author: Morris Meyer Date: 2013-09-20 10:31 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/63ca7ec7440f PTX assembler load, store and parameter refactoring ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXCompare.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXParameterOp.java Changeset: 2c590fb9d695 Author: Morris Meyer Date: 2013-09-20 13:20 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2c590fb9d695 Turn off MonitorTest.test7 ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MonitorTest.java Changeset: aa10794f1574 Author: Doug Simon Date: 2013-09-20 21:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aa10794f1574 better reporting of failures during multi-threaded tests ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: b8695542d41b Author: Doug Simon Date: 2013-09-20 21:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b8695542d41b added HSAIL register configuration The main change was to override Backend.newFrameMap() in HSAILBackend to use the HSAIL register configuration. Contributed-by: Vasanth Venkatachalam ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java + graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAILRegisterConfig.java Changeset: a402610bc52b Author: Doug Simon Date: 2013-09-20 23:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a402610bc52b made compilation ID allocation in tests be atomic ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: ed54ddfa393d Author: Doug Simon Date: 2013-09-20 23:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed54ddfa393d re-enabled MonitorTest.test7 ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MonitorTest.java Changeset: 85b846b31690 Author: Andreas Woess Date: 2013-09-20 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85b846b31690 Truffle-DSL: automatically generate copy constructor if super constructor expects only SourceSection parameter. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java Changeset: c287d13cb8b0 Author: Andreas Woess Date: 2013-09-21 04:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c287d13cb8b0 Truffle-DSL: use clone() for copying node arrays in copy constructor. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 0ba840567fba Author: Andreas Woess Date: 2013-09-21 04:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0ba840567fba Merge Changeset: ea4e9cbaa0c9 Author: Bernhard Urban Date: 2013-09-19 21:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ea4e9cbaa0c9 UnsafeArrayCopyNode: location identity must be ANY_LOCATION as it lowers to snippets containing nodes with ANY_LOCATION ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java Changeset: 661e10237142 Author: Bernhard Urban Date: 2013-09-19 21:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/661e10237142 FloatingReadPhase: add interface to access memory state + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java Changeset: a66ecc6a6393 Author: Bernhard Urban Date: 2013-09-21 08:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a66ecc6a6393 FloatingReadPhase: add MemoryState information to graph + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java Changeset: db8cf3957e5b Author: Bernhard Urban Date: 2013-09-19 21:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db8cf3957e5b FloatingReadNode: setter for lastLocationAccess ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java Changeset: a27fcd670725 Author: Bernhard Urban Date: 2013-09-21 08:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a27fcd670725 SnippetTemplate: use FloatingReadPhase to store MemoryMap at ReturnNodes in order to connect the snippet graph properly when inlining it ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: bf7f09417f76 Author: Bernhard Urban Date: 2013-09-21 08:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bf7f09417f76 move MemoryMap to API package + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MemoryMap.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java From thomas.wuerthinger at oracle.com Mon Sep 23 08:23:47 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 23 Sep 2013 17:23:47 +0200 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli Message-ID: I hereby nominate Bharadwaj Yadavalli to Graal committer. Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 Votes are due October 7, 6:00 pm CET. Only current Graal committers are eligible to vote on this nomination [1]. For Lazy Consensus voting instructions, see [2]. - thomas [1] http://openjdk.java.net/census#graal [2] http://openjdk.java.net/projects/#committer-vote From andreas.woess at jku.at Mon Sep 23 08:32:52 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Mon, 23 Sep 2013 17:32:52 +0200 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: <52405F24.70406@jku.at> Vote: yes On 23.09.2013 17:23, Thomas Wuerthinger wrote: > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Mon Sep 23 09:24:04 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 23 Sep 2013 18:24:04 +0200 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: Vote: yes On Sep 23, 2013, at 5:23 PM, Thomas Wuerthinger wrote: > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From lukas.stadler at jku.at Mon Sep 23 12:19:18 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Mon, 23 Sep 2013 21:19:18 +0200 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: Vote: yes Am 23.09.2013 um 17:23 schrieb Thomas Wuerthinger : > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From christian.thalinger at oracle.com Mon Sep 23 23:55:11 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 23 Sep 2013 23:55:11 -0700 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: Vote: yes On Sep 23, 2013, at 8:23 AM, Thomas Wuerthinger wrote: > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From christian.wimmer at oracle.com Wed Sep 25 10:51:31 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 25 Sep 2013 10:51:31 -0700 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: <524322A3.3070604@oracle.com> vote: yes On 09/23/2013 08:23 AM, Thomas Wuerthinger wrote: > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote > From duboscq at ssw.jku.at Thu Sep 26 02:46:55 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 26 Sep 2013 11:46:55 +0200 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: Vote: yes On Mon, Sep 23, 2013 at 5:23 PM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source > base. His most notable contributions are to Graal's PTX backend for > offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From roland.schatz at oracle.com Thu Sep 26 04:03:30 2013 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 26 Sep 2013 13:03:30 +0200 Subject: CFV: New Graal Committer: Bharadwaj Yadavalli In-Reply-To: References: Message-ID: <52441482.5000600@oracle.com> Vote: yes On 09/23/2013 05:23 PM, Thomas Wuerthinger wrote: > I hereby nominate Bharadwaj Yadavalli to Graal committer. > > Bharadwaj has made numerous contributions to the Graal OpenJDK source base. His most notable contributions are to Graal's PTX backend for offloading Java to the GPU, e.g.: > - http://hg.openjdk.java.net/graal/graal/rev/03fe11f5f186 > - http://hg.openjdk.java.net/graal/graal/rev/91e5f927af63 > - http://hg.openjdk.java.net/graal/graal/rev/1cd1f8ff70a1 > > Votes are due October 7, 6:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From D.Sturm42 at gmail.com Sat Sep 28 15:55:24 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sun, 29 Sep 2013 00:55:24 +0200 Subject: volatile read and writes Message-ID: The Aarch64 ISA allows to fold most memory barriers into special load and store instructions - similar to IA64. That means we can get away with only explicitly generating StoreLoad barriers and use load-acquire/store-release for volatile read/writes and when publishing newly constructed objects with final fields. What is the best approach for getting this information when generating load/stores or maybe during a peephole optimization? There's a lastLocationAccess for the FloatingReadNode which should point to a MembarNode if it's a volatile read (and there's a next field for storenodes which should do the same), but that seems rather fragile. - Daniel From doug.simon at oracle.com Sat Sep 28 18:00:36 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 29 Sep 2013 01:00:36 +0000 Subject: hg: graal/graal: 70 new changesets Message-ID: <20130929010448.0E51762BD6@hg.openjdk.java.net> Changeset: 29de278b7c1b Author: Andreas Woess Date: 2013-09-22 02:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/29de278b7c1b Truffle-DSL: fix type equals test with javac. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java Changeset: 7e7edb86fb43 Author: Christian Wimmer Date: 2013-09-23 14:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7e7edb86fb43 Refactor the handling of unsafe casts to distinguish between word-object-conversions, PiNode-like type information, and real unsafe casts. ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.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/LoadExceptionObjectSnippets.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/ObjectSubstitutions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeArrayCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.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/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeClassSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java + graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 095325ccbf9a Author: Doug Simon Date: 2013-09-24 00:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/095325ccbf9a removed dumping overhead during inlining when dumping is not active ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 6e734982f89f Author: Doug Simon Date: 2013-09-24 00:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e734982f89f fixed concurrency issue in lowering of MacroNode replacement graphs ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: bbcb72443066 Author: Doug Simon Date: 2013-09-24 00:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bbcb72443066 renames: Graph.inputChanged -> inputChangedListener, Graph.usagesDroppedZero -> usagesDroppedToZeroListener ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 78e6109ee411 Author: Mick Jordan Date: 2013-09-23 21:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/78e6109ee411 mx refactoring for split-repo suites; should have no effect on existing repos ! mx/commands.py ! mxtool/mx.py Changeset: ec058ce90a3d Author: Mick Jordan Date: 2013-09-23 21:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ec058ce90a3d pylint fixes ! mx/commands.py Changeset: 4ac92e735a16 Author: Mick Jordan Date: 2013-09-23 21:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4ac92e735a16 pylint fixes (retry) ! mx/commands.py Changeset: 8bcd76c3f23b Author: Mick Jordan Date: 2013-09-23 22:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8bcd76c3f23b mx.py whitespace fixes ! mxtool/mx.py Changeset: ce0b00597980 Author: Doug Simon Date: 2013-09-24 08:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce0b00597980 made safepoint-on-return use specialized HotSpot runtime support for such safepoints (which have no debug info attached) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.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 + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64SafepointOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotReturnOp.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotSafepointOp.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoopSafepointInsertionPhase.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/SafepointInsertionPhase.java ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp Changeset: 3b25f37d5561 Author: Doug Simon Date: 2013-09-24 10:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3b25f37d5561 fixed poll-on-return for SPARC ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotReturnOp.java Changeset: 099748a1a931 Author: Doug Simon Date: 2013-09-24 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/099748a1a931 added parentheses for clarity ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotReturnOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotReturnOp.java Changeset: 8f6917d1205f Author: Gilles Duboscq Date: 2013-09-24 10:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8f6917d1205f IntegerStamp.toString: print full mask ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java Changeset: 5814f30f0baf Author: Gilles Duboscq Date: 2013-09-24 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5814f30f0baf No need for empty line after class declaration ! mx/eclipse-settings/org.eclipse.jdt.core.prefs Changeset: c2d8e5813925 Author: Bernhard Urban Date: 2013-09-24 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c2d8e5813925 PiNode: fix NPE in assertion ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: c9c3f8efe6a9 Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9c3f8efe6a9 FloatingReadPhase: add attribute to graph about application of FloatingReadPhase to this graph ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: ac252c4c920b Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ac252c4c920b FloatingReadPhase: use enum for describing the execution mode of the phase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: e53399f1b2cd Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e53399f1b2cd SnippetTemplate: add assertions regarding memory kills ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 427cbe2bd615 Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/427cbe2bd615 SerialWriteBarrier: use GC_CARD_LOCATION instead of ANY_LOCATION ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 7c4595b7ef3a Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c4595b7ef3a NewInstanceNode: use INIT_LOCATION; NewArrayNode: use INIT_LOCATION and ARRAY_LENGTH_LOCATION ! 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 Changeset: e6688490223e Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6688490223e HotSpotRuntime: use HUB_LOCATION for hub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 93df2e25b59f Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/93df2e25b59f DynamicNewArrayNode: use INIT_LOCATION for runtime call ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 4e2be0ab31a9 Author: Bernhard Urban Date: 2013-09-24 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4e2be0ab31a9 NewMultiArrayNode: use INIT_LOCATION instead of ANY_LOCATION ! 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 Changeset: f6eb4866d558 Author: Bernhard Urban Date: 2013-09-24 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6eb4866d558 G1 Barriers: don't use ANY_LOCATION ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: b04b94b71649 Author: Morris Meyer Date: 2013-09-24 14:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b04b94b71649 Finished PTX assembler and Register -> Variable conversion ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CallingConvention.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAddress.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.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/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.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXAddressValue.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMove.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRIntrospection.java ! mx/projects Changeset: 5da106dae769 Author: Bernhard Urban Date: 2013-09-24 21:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5da106dae769 WriteBarrierSnipppets: make locations visible to other packages ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: f3e5cbd1efae Author: Mick Jordan Date: 2013-09-24 21:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f3e5cbd1efae move pylint to mxtool - mx/.pylintrc ! mx/commands.py + mxtool/.pylintrc ! mxtool/mx.py Changeset: aed07e3d070f Author: Mick Jordan Date: 2013-09-24 21:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aed07e3d070f Merge Changeset: d55fb90c1f12 Author: Christos Kotselidis Date: 2013-09-25 09:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d55fb90c1f12 Move barriers in hotspot specific package ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ArrayRangeWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1ArrayRangePostWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1ArrayRangePreWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1ReferentFieldReadBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/SerialArrayRangeWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/SerialWriteBarrier.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ArrayRangeWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePostWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePreWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PostWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ReferentFieldReadBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialArrayRangeWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java Changeset: f517fefa7545 Author: Christos Kotselidis Date: 2013-09-25 10:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f517fefa7545 Refactor write barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ArrayRangeWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1ReferentFieldReadBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/SerialWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java Changeset: 492766ec345a Author: Christos Kotselidis Date: 2013-09-25 10:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/492766ec345a Rewrite write barrier addition phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: 106bd0ff2498 Author: Doug Simon Date: 2013-09-25 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/106bd0ff2498 add support for a node to canonicalize itself to a ControlSinkNode ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 9c98944c040b Author: Doug Simon Date: 2013-09-25 12:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c98944c040b make GuardingPiNode canonicalize to a deopt when the guard is guaranteed to fail ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java Changeset: a2958b7bf83f Author: Doug Simon Date: 2013-09-25 12:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a2958b7bf83f add "sun4u" as a valid identifier for the SPARC architecture ! mx/commands.py Changeset: 713a08116e97 Author: Gilles Duboscq Date: 2013-09-24 16:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/713a08116e97 Fix SnippetFrameStateCleanupPhase's handling of Merges: if there is no statesplit after a merge, the last statesplit inside the merges's incomming branches should get an AFTER_BCI Use a stronger assert in DebugInfoBuilder.computeFrameForState ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetFrameStateCleanupPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 4f0e0602c1c7 Author: Gilles Duboscq Date: 2013-09-25 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f0e0602c1c7 AMD64HotSpotLIRGenerator: ignore InfopointNodes with AFTER_BCI ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 4fc75b6ca3dd Author: Gilles Duboscq Date: 2013-09-25 12:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4fc75b6ca3dd Introduce NodeWithState for nodes that hold some VirtualState. Use this interface in the required special cases (Scheduling and PEA) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractStateSplit.java ! 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/StateSplit.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/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreIndexedNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeWithState.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: 88d8b348914b Author: Gilles Duboscq Date: 2013-09-25 12:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88d8b348914b Make InfopointNode a NodeWithState, it is not a StateSplit anymore ! 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 ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.java Changeset: bc3bb6c6ca70 Author: Gilles Duboscq Date: 2013-09-25 12:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bc3bb6c6ca70 Nodes that extend AbstractStateSplit do not need to implement StateSplit again ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.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/CompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java Changeset: 70f43f67cdcb Author: Gilles Duboscq Date: 2013-09-25 13:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/70f43f67cdcb StubForeignCallNode is not a DeoptimizingNode ! 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/StubForeignCallNode.java Changeset: 45e8bf81205d Author: Gilles Duboscq Date: 2013-09-25 13:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45e8bf81205d Remove unused AbstractCallNode - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractCallNode.java Changeset: 9ddd8704a65b Author: Doug Simon Date: 2013-09-19 23:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9ddd8704a65b removed creation of intermediate ArrayLengthNode when lowering [Load|Store]IndexedNodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: ca9c16735da8 Author: Doug Simon Date: 2013-09-20 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca9c16735da8 removed creation of intermediate LoadHubNode when lowering StoreIndexedNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: b2c74b9fd4ab Author: Doug Simon Date: 2013-09-24 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2c74b9fd4ab Merge. - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64SafepointOp.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeArrayCastNode.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/SafepointInsertionPhase.java Changeset: 56c3ec12a79c Author: Doug Simon Date: 2013-09-25 12:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56c3ec12a79c Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ArrayRangeWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePostWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePreWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PostWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ReferentFieldReadBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialArrayRangeWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java - mx/.pylintrc Changeset: 9c4c197aa6e8 Author: Doug Simon Date: 2013-09-25 21:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c4c197aa6e8 Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractCallNode.java Changeset: 65dbed1fdf46 Author: Doug Simon Date: 2013-09-25 21:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/65dbed1fdf46 be verbose when the JDK specified by --installed-jdks is missing ! mx/commands.py Changeset: 2fbb9fd55dde Author: Doug Simon Date: 2013-09-25 21:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2fbb9fd55dde made lowering recursive instead of iterative ! 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/WriteBarrier.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/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.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/spi/Lowerable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertNode.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/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverInlineMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java Changeset: 4c96ccce3772 Author: twisti Date: 2013-09-25 13:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4c96ccce3772 SPARC: added CodeInstaller::pd_relocate_poll ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp Changeset: a28f24553ffa Author: Christian Wimmer Date: 2013-09-25 17:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a28f24553ffa Improvements to recent unsafe cast node changes ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: 63ee8dea4b80 Author: Andreas Woess Date: 2013-09-26 03:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/63ee8dea4b80 TruffleCache: do not cut off ControlFlowException constructors. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 82c4106741f7 Author: Bernhard Urban Date: 2013-09-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/82c4106741f7 SnippetTemplate: avoid two getNodes() in assertions. comment fix and renames ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: eb2def6529bc Author: Bernhard Urban Date: 2013-09-25 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eb2def6529bc HSAIL, SPARC: fix some occurrences of object identity, using equals() instead ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAddress.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILAddressValue.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 60f6d5939941 Author: Bernhard Urban Date: 2013-09-26 08:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/60f6d5939941 LoweringPhase: add comment ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: 73a886a9564a Author: Gilles Duboscq Date: 2013-09-26 11:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/73a886a9564a Make AbstractBeginNode a IterableNodeType and use this in ControlFlowGraph ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 14904566a4b2 Author: Roland Schatz Date: 2013-09-26 13:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/14904566a4b2 Use 32 byte code alignment for Graal on x86. ! src/cpu/x86/vm/globals_x86.hpp Changeset: 039b133ded75 Author: Andreas Woess Date: 2013-09-25 16:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/039b133ded75 fix endless recursion in _find_eclipse_wsroot on windows when eclipse workspace is not in repository path. ! mxtool/mx.py Changeset: 0c4d7b468dd7 Author: Andreas Woess Date: 2013-09-25 17:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c4d7b468dd7 include isValid in Assumption.toString(); minor javadoc fix. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameDescriptor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/AbstractAssumption.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/UnexpectedResultException.java Changeset: c7769440afd8 Author: Andreas Woess Date: 2013-09-25 17:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c7769440afd8 improve NodeUtil.cloneNode. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 91a676d0bbbe Author: Andreas Woess Date: 2013-09-26 13:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91a676d0bbbe Truffle: add not-in-frame assumption feature. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameDescriptor.java Changeset: ec90fc830e45 Author: Andreas Woess Date: 2013-09-26 13:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec90fc830e45 Merge Changeset: 4937347fa343 Author: Andreas Woess Date: 2013-09-26 16:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4937347fa343 Truffle: approximate source location for "illegal recursive call". ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 9af8b109ec0f Author: Andreas Woess Date: 2013-09-26 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9af8b109ec0f Truffle: force slow path on StringBuilder methods. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 22d47c2c74e9 Author: Andreas Woess Date: 2013-09-26 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/22d47c2c74e9 Merge Changeset: 43bc62c78f77 Author: Doug Simon Date: 2013-09-26 22:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/43bc62c78f77 attempt to canonicalize array length access when lowering array load|store operations ! 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.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java Changeset: 8db5e8c4f542 Author: Christian Wimmer Date: 2013-09-26 15:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8db5e8c4f542 Provide object read/write methods similar to Pointer.readXxxx/writeXxx that do not require casts to Word first, and use them in relevant places ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/ArrayCopyGeneric.java + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java + graal/com.oracle.graal.word/src/com/oracle/graal/word/ObjectAccess.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 4bae51f0c888 Author: Christos Kotselidis Date: 2013-09-27 12:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4bae51f0c888 Augment Write Barrier counters ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 793743715dc1 Author: Michael Haupt Date: 2013-09-27 16:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/793743715dc1 put Node.getEncapsulatedSourceSection() on slow path ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: 1cb614d6d25b Author: Christos Kotselidis Date: 2013-09-27 19:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1cb614d6d25b Readjust branch probabilities of G1 Barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: aeeab846e98c Author: Christos Kotselidis Date: 2013-09-27 19:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aeeab846e98c Merge