From tom.deneau at amd.com Wed Jan 2 09:40:23 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 2 Jan 2013 17:40:23 +0000 Subject: Question about redirecting a compilation Message-ID: As part of an experiment we'd like some Java code, say method Foo() to get redirected to some native code when either 1. the caller of Foo() gets compiled by C2 2. or Foo() itself gets compiled by C2. I know how to do Bullet 1 above by defining Foo as an intrinsic but what is the best way to do #2? -- Tom From vladimir.kozlov at oracle.com Wed Jan 2 10:35:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Jan 2013 10:35:21 -0800 Subject: Question about redirecting a compilation In-Reply-To: References: Message-ID: <50E47DE9.2010506@oracle.com> May be I don't understand your question but C2 can compile top method into intrinsic (it does not need to be called from compiled method). Look on code for vmIntrinsics::_Reference_get in compile.cpp. Vladimir On 1/2/13 9:40 AM, Deneau, Tom wrote: > As part of an experiment we'd like some Java code, say method Foo() to get redirected to some native code when either > > 1. the caller of Foo() gets compiled by C2 > > 2. or Foo() itself gets compiled by C2. > > I know how to do Bullet 1 above by defining Foo as an intrinsic but what is the best way to do #2? > > -- Tom > > > From tom.deneau at amd.com Wed Jan 2 12:35:30 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 2 Jan 2013 20:35:30 +0000 Subject: Question about redirecting a compilation Message-ID: Vladimir -- I saw that special case code for Reference_get and tried to do the same for my case. The native routine in my case is not a leaf, and I hit a problem when it was trying to use GraphKit::add_safepoint_edges, It seems there was no _method defined in the jvms. Here is the relevant part of the stack. #5 0x00007ffff6d66c7e in JVMState::method (this=0x7ffff02f4e18) at src/share/vm/opto/callnode.hpp:252 #6 0x00007ffff7090a21 in should_reexecute_implied_by_bytecode (jvms=0x7ffff02f4e18, is_anewarray=false) at src/share/vm/opto/graphKit.cpp:810 #7 0x00007ffff7090c8d in GraphKit::add_safepoint_edges (this=0x7fffd49a9ce0, call=0x7fffb0149c48, must_throw=false) at src/share/vm/opto/graphKit.cpp:877 #8 0x00007ffff70958d5 in GraphKit::make_runtime_call (this=0x7fffd49a9ce0, flags=5, call_type=0x7ffff0265488, -- Tom Date: Wed, 02 Jan 2013 10:35:21 -0800 From: Vladimir Kozlov Subject: Re: Question about redirecting a compilation To: sumatra-dev at openjdk.java.net Message-ID: <50E47DE9.2010506 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed May be I don't understand your question but C2 can compile top method into intrinsic (it does not need to be called from compiled method). Look on code for vmIntrinsics::_Reference_get in compile.cpp. Vladimir On 1/2/13 9:40 AM, Deneau, Tom wrote: > As part of an experiment we'd like some Java code, say method Foo() to > get redirected to some native code when either > > 1. the caller of Foo() gets compiled by C2 > > 2. or Foo() itself gets compiled by C2. > > I know how to do Bullet 1 above by defining Foo as an intrinsic but what is the best way to do #2? > > -- Tom > > > From vladimir.kozlov at oracle.com Thu Jan 3 00:15:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 00:15:03 -0800 Subject: Question about redirecting a compilation In-Reply-To: References: Message-ID: <50E53E07.8050200@oracle.com> I see. You can't use that mechanism if method can go into safepoint. You can add java wrapper method to make sure we compile caller so case 1. will be enough, at least for your experiment. An other approach. We have StackWalkCompPolicy old code (we don't use it anymore) in compilationPolicy.cpp which try to compile caller first. You can try to adapt it for this method. Vladimir On 1/2/13 12:35 PM, Deneau, Tom wrote: > Vladimir -- > > I saw that special case code for Reference_get and tried to do the same for my case. > The native routine in my case is not a leaf, and I hit a problem when it was trying to use GraphKit::add_safepoint_edges, > It seems there was no _method defined in the jvms. > > Here is the relevant part of the stack. > > #5 0x00007ffff6d66c7e in JVMState::method (this=0x7ffff02f4e18) at src/share/vm/opto/callnode.hpp:252 > #6 0x00007ffff7090a21 in should_reexecute_implied_by_bytecode (jvms=0x7ffff02f4e18, is_anewarray=false) at src/share/vm/opto/graphKit.cpp:810 > #7 0x00007ffff7090c8d in GraphKit::add_safepoint_edges (this=0x7fffd49a9ce0, call=0x7fffb0149c48, must_throw=false) at src/share/vm/opto/graphKit.cpp:877 > #8 0x00007ffff70958d5 in GraphKit::make_runtime_call (this=0x7fffd49a9ce0, flags=5, call_type=0x7ffff0265488, > > -- Tom > > Date: Wed, 02 Jan 2013 10:35:21 -0800 > From: Vladimir Kozlov > Subject: Re: Question about redirecting a compilation > To: sumatra-dev at openjdk.java.net > Message-ID: <50E47DE9.2010506 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > May be I don't understand your question but C2 can compile top method into intrinsic (it does not need to be called from compiled method). > Look on code for vmIntrinsics::_Reference_get in compile.cpp. > > Vladimir > > On 1/2/13 9:40 AM, Deneau, Tom wrote: >> As part of an experiment we'd like some Java code, say method Foo() to >> get redirected to some native code when either >> >> 1. the caller of Foo() gets compiled by C2 >> >> 2. or Foo() itself gets compiled by C2. >> >> I know how to do Bullet 1 above by defining Foo as an intrinsic but what is the best way to do #2? >> >> -- Tom >> >> >> > > > From Vasanth.Venkatachalam at amd.com Fri Jan 4 14:24:50 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 4 Jan 2013 22:24:50 +0000 Subject: changes to Hotspot to support multiple targets Message-ID: <5DD1503F815BD14889DC81D28643E3A7329D244B@sausexdag06.amd.com> Hi Ivan, Thanks for the reply. As a quick prototype, we are trying to modify the C2 compiler to generate the instructions of the new ISA, while C1 and the interpreter still generate x86. We were planning to do this by creating a new directory src/cpu/ where we would move all the C2 arch-specific files (which we will modify to emit code for the new target), while keeping the rest of the files in the x86/ directory intact, which will be used by the interpreter and C1. We have two questions: 1) What changes are needed to the build process so that we can build Hotspot? 2) What changes are needed to ensure that the C2 compiler looks in the new target directory for the arch specific files, instead of looking in the old x86/ directory? Vasanth -----Original Message----- From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev-bounces at openjdk.java.net] On Behalf Of Ivan Krylov Sent: Sunday, December 16, 2012 2:16 PM To: sumatra-dev at openjdk.java.net Subject: Re: changes to Hotspot to support multiple targets This is indeed a non-typical target for the Hotspot. AFAIK, Hotspot does not support heterogeneous targets of any kind. I'd suggest to implement as a first step support for the interpreter-only that would force compilation for the GPU-suitable code (whever is used to mark a given method or branch "GPU-suitable"). While for x86 the transition from interpreter to compiled code happens with OSR (on-stack replacement) in case of sumatra it would be a call to the SC to start execution. For some simple compute-intensive examples this could be a good proof of concept because the host code gets called just once and will be interpreted anyway and the compute-intensive code gets compilet for GPS and executed for GPU. At the later stage a new target would need be set up (call it HSA). Thanks, Ivan On 12-Dec-12 20:51, Venkatachalam, Vasanth wrote: > Hotspot supports generating code for a single ISA (e.g., x86) at a time. However, to have the flexibility of executing code on either the CPU or the GPU, the compilers and code generators for both targets would need to coexist and communicate with each other. > > Do people have ideas on how this change can be implemented in Hotspot? > > Vasanth > > > -- > Vasanth Venkatachalam > AMD Runtimes > (512)602-6177 > From ivan.p.krylov at gmail.com Wed Jan 9 06:27:01 2013 From: ivan.p.krylov at gmail.com (Ivan Krylov) Date: Wed, 09 Jan 2013 18:27:01 +0400 Subject: changes to Hotspot to support multiple targets In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7329D244B@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7329D244B@sausexdag06.amd.com> Message-ID: <50ED7E35.1010704@gmail.com> Hi Vasanth, I just pulled the fresh jdk8 tree and I see that the build system for HotSpot was re-written since I my last commit to HotSpot. My previous knowledge of the build system is no longer relevant. Perhaps someone else from this DL can help but otherwise I can look into this shortly. Thanks, Ivan 05.01.2013 2:24, Venkatachalam, Vasanth wrote: > Hi Ivan, > > Thanks for the reply. > > As a quick prototype, we are trying to modify the C2 compiler to generate the instructions of the new ISA, while C1 and the interpreter still generate x86. We were planning to do this by creating a new directory src/cpu/ where we would move all the C2 arch-specific files (which we will modify to emit code for the new target), while keeping the rest of the files in the x86/ directory intact, which will be used by the interpreter and C1. > > We have two questions: > > 1) What changes are needed to the build process so that we can build Hotspot? > 2) What changes are needed to ensure that the C2 compiler looks in the new target directory for the arch specific files, instead of looking in the old x86/ directory? > > Vasanth > > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev-bounces at openjdk.java.net] On Behalf Of Ivan Krylov > Sent: Sunday, December 16, 2012 2:16 PM > To: sumatra-dev at openjdk.java.net > Subject: Re: changes to Hotspot to support multiple targets > > This is indeed a non-typical target for the Hotspot. AFAIK, Hotspot does > not support heterogeneous targets of any kind. I'd suggest to implement > as a first step support for the interpreter-only that would force > compilation for the GPU-suitable code (whever is used to mark a given > method or branch "GPU-suitable"). While for x86 the transition from > interpreter to compiled code happens with OSR (on-stack replacement) in > case of sumatra it would be a call to the SC to start execution. > For some simple compute-intensive examples this could be a good proof of > concept because the host code gets called just once and will be > interpreted anyway and the compute-intensive code gets compilet for GPS > and executed for GPU. > At the later stage a new target would need be set up (call it HSA). > > Thanks, > Ivan > > On 12-Dec-12 20:51, Venkatachalam, Vasanth wrote: >> Hotspot supports generating code for a single ISA (e.g., x86) at a time. However, to have the flexibility of executing code on either the CPU or the GPU, the compilers and code generators for both targets would need to coexist and communicate with each other. >> >> Do people have ideas on how this change can be implemented in Hotspot? >> >> Vasanth >> >> >> -- >> Vasanth Venkatachalam >> AMD Runtimes >> (512)602-6177 >> > > From john.r.rose at oracle.com Wed Jan 9 17:51:37 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jan 2013 17:51:37 -0800 Subject: Setting up the Mercurial Repositories for Sumatra In-Reply-To: References: <20678.37067.386362.461868@oracle.com> <55C6CF35-B200-49A8-A936-1982E5385C68@oracle.com> Message-ID: <6625EFA6-0564-4869-9691-440F2316E8E8@oracle.com> OK, I think we've aired out the issues enough to start building repos for Sumatra. Let's start with sumatra/{sumatra-dev/scratch,sumatra-dev/{hotspot,jdk,langtools,...}}, snapped from jdk8/jdk8 (scratch is empty). We'll eventually enable branches in it. (This might take a little longer, to modify the server scripts.) The scratch repo can be used (or not) to hold patches, if necessary. It can also hold small standalone experiments (code trees). We can build the "stable" sumatra/sumatra repo later, when we have some stable stuff to put into it. ? John On Dec 7, 2012, at 4:54 PM, John Rose wrote: > A. We need a stable prototype which can be built using standard procedures. > B. We need a "sandbox" or "workbench" for maybe-throwaway experiments in modifying the JVM and JDK (not to interfere with A). > C. We need a part of the "workbench" to share flat files, small proofs of concept, and other ad hoc resources (not to interfere with A or B). > D. We do not need direct mergability into jdk8 (same as lambda repos, which do not merge up directly, and does not need to pass jcheck). > E. The workbench version of things needs to be malleable by simultaneous independent workers. > F. However, workbench experiments should be shareable, when the workers want to collaborate. > G. Successful, maturing experiments should be shareable with a wider audience, by moving changesets to the stable prototoype (A). > H. Eventually (as with Project Lambda) the prototype can be moved (after further development) into the main jdk source base (JDK 9 or whichever). > I. Unlike big projects like HotSpot, Sumatra will not grow very large, and so does not need a high level of codification and formality. > J. We will (per OpenJDK) distinguish the roles of author, committer, and reviewer. > > In concrete terms, we think this comes to something like the following repositories: > > A. http://hg.openjdk.java.net/sumatra/sumatra/{hotspot,jdk,langtools,...} (cloned from jdk8, buildable & testable, occasionally refreshed and rebased) > > B. http://hg.openjdk.java.net/sumatra/sumatra-dev/{hotspot,jdk,langtools} (bundle of independent branches, occasionally rebased on A) > > C. http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch (initially empty workbench shelf, for sharing artifacts other than JDK source changes) > From Gary.Frost at amd.com Wed Jan 9 18:58:26 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Thu, 10 Jan 2013 02:58:26 +0000 Subject: Setting up the Mercurial Repositories for Sumatra In-Reply-To: <6625EFA6-0564-4869-9691-440F2316E8E8@oracle.com> Message-ID: John This is good news. Here at AMD we have built some local mercurial repositories (clones of project Lambda for java.util.stream.* experiments, and JDK 8 for more general lambda experiments) and have some code we have been playing with that we would like to share. So my guess is we should be able to make some of this code generally available as soon as the Sumatra repositories are available. Gary On 1/9/13 7:51 PM, "John Rose" wrote: >OK, I think we've aired out the issues enough to start building repos for >Sumatra. > >Let's start with >sumatra/{sumatra-dev/scratch,sumatra-dev/{hotspot,jdk,langtools,...}}, >snapped from jdk8/jdk8 (scratch is empty). > >We'll eventually enable branches in it. (This might take a little >longer, to modify the server scripts.) > >The scratch repo can be used (or not) to hold patches, if necessary. It >can also hold small standalone experiments (code trees). > >We can build the "stable" sumatra/sumatra repo later, when we have some >stable stuff to put into it. > >? John > >On Dec 7, 2012, at 4:54 PM, John Rose wrote: > >> A. We need a stable prototype which can be built using standard >>procedures. >> B. We need a "sandbox" or "workbench" for maybe-throwaway experiments >>in modifying the JVM and JDK (not to interfere with A). >> C. We need a part of the "workbench" to share flat files, small proofs >>of concept, and other ad hoc resources (not to interfere with A or B). >> D. We do not need direct mergability into jdk8 (same as lambda repos, >>which do not merge up directly, and does not need to pass jcheck). >> E. The workbench version of things needs to be malleable by >>simultaneous independent workers. >> F. However, workbench experiments should be shareable, when the workers >>want to collaborate. >> G. Successful, maturing experiments should be shareable with a wider >>audience, by moving changesets to the stable prototoype (A). >> H. Eventually (as with Project Lambda) the prototype can be moved >>(after further development) into the main jdk source base (JDK 9 or >>whichever). >> I. Unlike big projects like HotSpot, Sumatra will not grow very large, >>and so does not need a high level of codification and formality. >> J. We will (per OpenJDK) distinguish the roles of author, committer, >>and reviewer. >> >> In concrete terms, we think this comes to something like the following >>repositories: >> >> A. >>http://hg.openjdk.java.net/sumatra/sumatra/{hotspot,jdk,langtools,...} >>(cloned from jdk8, buildable & testable, occasionally refreshed and >>rebased) >> >> B. >>http://hg.openjdk.java.net/sumatra/sumatra-dev/{hotspot,jdk,langtools} >>(bundle of independent branches, occasionally rebased on A) >> >> C. http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch (initially >>empty workbench shelf, for sharing artifacts other than JDK source >>changes) >> > From eric.caspole at amd.com Thu Jan 10 15:33:50 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Thu, 10 Jan 2013 18:33:50 -0500 Subject: configure jdk new build on win 7 enterprise In-Reply-To: <1357859397.67140.YahooMailClassic@web162606.mail.bf1.yahoo.com> References: <1357859397.67140.YahooMailClassic@web162606.mail.bf1.yahoo.com> Message-ID: <50EF4FDE.10104@amd.com> Hi everyone, I am trying to get something ready for eventual contribution in to sumatra, and I would like to check my code works on Windows. This is the first time I am building the JDK on Windows using the new build. I have installed the complete latest cygwin, but the configure does not like the gmake in cygwin. This is Windows 7 enterprise SP1 and I . My error output is shown below. Does anyone know the fix for this or what else needs to be installed? I have set up the system like I was otherwise using to build just hotspot (not the whole JDK) a few months ago with Windows SDK 7.1. I'll keep searching in the build-dev list but I have not found anything yet. Thanks for any advice, Eric ========= AparapiTest at AparapiTest-PC /cygdrive/c/Users/AparapiTest/views/sumatra-dev $ sh ./configure Running generated-configure.sh configure: Configuration created at Thu Jan 10 15:38:38 CST 2013. configure: configure script generated at timestamp 1355963953. checking for basename... /usr/bin/basename ... checking for pkgadd... no checking for gmake... /cygdrive/c/Perl/c/bin/gmake configure: Testing potential make at /cygdrive/c/Perl/c/bin/gmake, found using gmake in PATH at /cygdrive/c/Perl/c/bin/gmake, but it is not for cygwin (it says: Built for x86_64-w64-mingw32). Ignoring. checking for make... no configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 AparapiTest at AparapiTest-PC /cygdrive/c/Users/AparapiTest/views/sumatra-dev $ uname -a CYGWIN_NT-6.1-WOW64 AparapiTest-PC 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin From Gary.Frost at amd.com Thu Jan 10 17:22:10 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Fri, 11 Jan 2013 01:22:10 +0000 Subject: configure jdk new build on win 7 enterprise In-Reply-To: <50EF4FDE.10104@amd.com> Message-ID: So is the gmake file (under Perl) really gnu make? Have you downloaded the cygwin make package. My guess is the binary under perl/c is not really make. Maybe they want you to rename gnu make to gmake so that it is picked up instead of microsofts own make. From http://cygwin.com/packages/make/make-3.81-2 It sure looks like cygwins make is called make.exe not gmake.exe?. Confusing. Gary On 1/10/13 5:33 PM, "Eric Caspole" wrote: >Hi everyone, >I am trying to get something ready for eventual contribution in to >sumatra, and I would like to check my code works on Windows. > >This is the first time I am building the JDK on Windows using the new >build. > >I have installed the complete latest cygwin, but the configure does not >like the gmake in cygwin. This is Windows 7 enterprise SP1 and I . > >My error output is shown below. > >Does anyone know the fix for this or what else needs to be installed? > >I have set up the system like I was otherwise using to build just >hotspot (not the whole JDK) a few months ago with Windows SDK 7.1. > >I'll keep searching in the build-dev list but I have not found anything >yet. >Thanks for any advice, >Eric > > >========= > >AparapiTest at AparapiTest-PC /cygdrive/c/Users/AparapiTest/views/sumatra-dev >$ sh ./configure >Running generated-configure.sh >configure: Configuration created at Thu Jan 10 15:38:38 CST 2013. >configure: configure script generated at timestamp 1355963953. >checking for basename... /usr/bin/basename > >... > >checking for pkgadd... no >checking for gmake... /cygdrive/c/Perl/c/bin/gmake >configure: Testing potential make at /cygdrive/c/Perl/c/bin/gmake, found >using gmake in PATH > at /cygdrive/c/Perl/c/bin/gmake, but it is not for cygwin (it says: >Built for x86_64-w64-mingw32). Ignoring. >checking for make... no >configure: error: Cannot find GNU make 3.81 or newer! Please put it in >the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. >configure exiting with result code 1 > >AparapiTest at AparapiTest-PC /cygdrive/c/Users/AparapiTest/views/sumatra-dev >$ uname -a >CYGWIN_NT-6.1-WOW64 AparapiTest-PC 1.7.17(0.262/5/3) 2012-10-19 14:39 >i686 Cygwin > > > > > > > From tom.deneau at amd.com Thu Jan 10 17:22:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 Jan 2013 01:22:25 +0000 Subject: TieredCompilation question Message-ID: I will display my ignorance of TieredCompilation here. :) I think I am seeing the following but I am not positive... Let's say method MA calls MB calls MC. MC gets compiled at C2 level. Everything works well and the MC method compiled at C2 gets called several hundred times. Now method MA gets compiled at level 3 in C1. This C1 compilation of MA decides to inline MB and then MC into its C1 compilation. So it no longer uses the C2 compilation of MC?? In my particular case MC had called some intrinsic routines which were only defined as intrinsics in C2. So the net effect of being compiled at C1 when it was inlined into MA was that we lose those intrinsics. Is this how TieredCompilation is supposed to work? I should add here that the early compilation of MC at C2 level was in my case artificially forced by some code I added to Hotspot (so I might have missed something in setting that up). With Tiered off, this all worked nicely of course. -- Tom From vladimir.kozlov at oracle.com Thu Jan 10 17:59:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jan 2013 17:59:07 -0800 Subject: TieredCompilation question In-Reply-To: References: Message-ID: <50EF71EB.5080207@oracle.com> You step on your own mine :) Yes, it has such pathology for inlined by C1 methods. The assumption is that when C2 will compile MA it will also inline MB and MC. You can try to lower Tier4CompileThreshold. Vladimir On 1/10/13 5:22 PM, Deneau, Tom wrote: > I will display my ignorance of TieredCompilation here. :) > I think I am seeing the following but I am not positive... > > Let's say method MA calls MB calls MC. > MC gets compiled at C2 level. > Everything works well and the MC method compiled at C2 gets called several hundred times. > > Now method MA gets compiled at level 3 in C1. > This C1 compilation of MA decides to inline MB and then MC into its C1 compilation. > So it no longer uses the C2 compilation of MC?? > > In my particular case MC had called some intrinsic routines which were only defined as intrinsics in C2. > So the net effect of being compiled at C1 when it was inlined into MA was that we lose those intrinsics. > > Is this how TieredCompilation is supposed to work? > > I should add here that the early compilation of MC at C2 level was in my case artificially forced by some code I added to Hotspot (so I might have missed something in setting that up). > > With Tiered off, this all worked nicely of course. > > -- Tom > From tom.deneau at amd.com Thu Jan 10 20:31:21 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 Jan 2013 04:31:21 +0000 Subject: TieredCompilation question In-Reply-To: <50EF71EB.5080207@oracle.com> References: <50EF71EB.5080207@oracle.com> Message-ID: So the assumption is that MC inlined into MA will be better than calling a C2-compiled version of MC? I suppose it is also possible to forbid inlining of MC, so it would have to call the compiled version? -- Tom -----Original Message----- From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, January 10, 2013 7:59 PM To: sumatra-dev at openjdk.java.net Subject: Re: TieredCompilation question You step on your own mine :) Yes, it has such pathology for inlined by C1 methods. The assumption is that when C2 will compile MA it will also inline MB and MC. You can try to lower Tier4CompileThreshold. Vladimir On 1/10/13 5:22 PM, Deneau, Tom wrote: > I will display my ignorance of TieredCompilation here. :) > I think I am seeing the following but I am not positive... > > Let's say method MA calls MB calls MC. > MC gets compiled at C2 level. > Everything works well and the MC method compiled at C2 gets called several hundred times. > > Now method MA gets compiled at level 3 in C1. > This C1 compilation of MA decides to inline MB and then MC into its C1 compilation. > So it no longer uses the C2 compilation of MC?? > > In my particular case MC had called some intrinsic routines which were only defined as intrinsics in C2. > So the net effect of being compiled at C1 when it was inlined into MA was that we lose those intrinsics. > > Is this how TieredCompilation is supposed to work? > > I should add here that the early compilation of MC at C2 level was in my case artificially forced by some code I added to Hotspot (so I might have missed something in setting that up). > > With Tiered off, this all worked nicely of course. > > -- Tom > From duboscq at ssw.jku.at Fri Jan 11 01:49:05 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 11 Jan 2013 10:49:05 +0100 Subject: TieredCompilation question In-Reply-To: References: <50EF71EB.5080207@oracle.com> Message-ID: I rather think that even though inlining MC into MA may be slower than calling the C2-compiled MC, it should not matter too much since it's a transitory state. In the end MA should be compiled using C2 and the assumption is that MC will get inlined in this compilation too. And anyway, if it does not then it would be back to calling the C2-compiled MC. If you want to avoid compilation of a method by C1 altogether you could try Method::set_not_c1_compilable() that way C1 would neither try to compile it or try to inline it. -Gilles On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom wrote: > So the assumption is that MC inlined into MA will be better than calling a > C2-compiled version of MC? > > I suppose it is also possible to forbid inlining of MC, so it would have > to call the compiled version? > > -- Tom > > > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto: > sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, January 10, 2013 7:59 PM > To: sumatra-dev at openjdk.java.net > Subject: Re: TieredCompilation question > > You step on your own mine :) > > Yes, it has such pathology for inlined by C1 methods. The assumption is > that when C2 will compile MA it will also inline MB and MC. You can try > to lower Tier4CompileThreshold. > > Vladimir > > On 1/10/13 5:22 PM, Deneau, Tom wrote: > > I will display my ignorance of TieredCompilation here. :) > > I think I am seeing the following but I am not positive... > > > > Let's say method MA calls MB calls MC. > > MC gets compiled at C2 level. > > Everything works well and the MC method compiled at C2 gets called > several hundred times. > > > > Now method MA gets compiled at level 3 in C1. > > This C1 compilation of MA decides to inline MB and then MC into its C1 > compilation. > > So it no longer uses the C2 compilation of MC?? > > > > In my particular case MC had called some intrinsic routines which were > only defined as intrinsics in C2. > > So the net effect of being compiled at C1 when it was inlined into MA > was that we lose those intrinsics. > > > > Is this how TieredCompilation is supposed to work? > > > > I should add here that the early compilation of MC at C2 level was in my > case artificially forced by some code I added to Hotspot (so I might have > missed something in setting that up). > > > > With Tiered off, this all worked nicely of course. > > > > -- Tom > > > > > On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom wrote: > So the assumption is that MC inlined into MA will be better than calling a > C2-compiled version of MC? > > I suppose it is also possible to forbid inlining of MC, so it would have > to call the compiled version? > > -- Tom > > > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto: > sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, January 10, 2013 7:59 PM > To: sumatra-dev at openjdk.java.net > Subject: Re: TieredCompilation question > > You step on your own mine :) > > Yes, it has such pathology for inlined by C1 methods. The assumption is > that when C2 will compile MA it will also inline MB and MC. You can try > to lower Tier4CompileThreshold. > > Vladimir > > On 1/10/13 5:22 PM, Deneau, Tom wrote: > > I will display my ignorance of TieredCompilation here. :) > > I think I am seeing the following but I am not positive... > > > > Let's say method MA calls MB calls MC. > > MC gets compiled at C2 level. > > Everything works well and the MC method compiled at C2 gets called > several hundred times. > > > > Now method MA gets compiled at level 3 in C1. > > This C1 compilation of MA decides to inline MB and then MC into its C1 > compilation. > > So it no longer uses the C2 compilation of MC?? > > > > In my particular case MC had called some intrinsic routines which were > only defined as intrinsics in C2. > > So the net effect of being compiled at C1 when it was inlined into MA > was that we lose those intrinsics. > > > > Is this how TieredCompilation is supposed to work? > > > > I should add here that the early compilation of MC at C2 level was in my > case artificially forced by some code I added to Hotspot (so I might have > missed something in setting that up). > > > > With Tiered off, this all worked nicely of course. > > > > -- Tom > > > > > From eric.caspole at amd.com Fri Jan 11 08:07:55 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Fri, 11 Jan 2013 11:07:55 -0500 Subject: configure jdk new build on win 7 enterprise In-Reply-To: References: Message-ID: <50F038DB.9020307@amd.com> Yes it was something like that. Although my original install of cygwin took more than an hour downloading stuff from the web, it did not install make or zip by default, so I went back and added them in a second install step. It is starting the build now, we'll see. On 01/10/2013 08:22 PM, Frost, Gary wrote: > So is the gmake file (under Perl) really gnu make? > > Have you downloaded the cygwin make package. My guess is the binary under > perl/c is not really make. Maybe they want you to rename gnu make to > gmake so that it is picked up instead of microsofts own make. > > From > http://cygwin.com/packages/make/make-3.81-2 > > > It sure looks like cygwins make is called make.exe not gmake.exe?. > > Confusing. > > Gary > > > > On 1/10/13 5:33 PM, "Eric Caspole" wrote: > >> Hi everyone, >> I am trying to get something ready for eventual contribution in to >> sumatra, and I would like to check my code works on Windows. >> >> This is the first time I am building the JDK on Windows using the new >> build. >> >> I have installed the complete latest cygwin, but the configure does not >> like the gmake in cygwin. This is Windows 7 enterprise SP1 and I . >> >> My error output is shown below. >> >> Does anyone know the fix for this or what else needs to be installed? >> >> I have set up the system like I was otherwise using to build just >> hotspot (not the whole JDK) a few months ago with Windows SDK 7.1. >> >> I'll keep searching in the build-dev list but I have not found anything >> yet. >> Thanks for any advice, >> Eric >> >> >> ========= >> >> AparapiTest at AparapiTest-PC /cygdrive/c/Users/AparapiTest/views/sumatra-dev >> $ sh ./configure >> Running generated-configure.sh >> configure: Configuration created at Thu Jan 10 15:38:38 CST 2013. >> configure: configure script generated at timestamp 1355963953. >> checking for basename... /usr/bin/basename >> >> ... >> >> checking for pkgadd... no >> checking for gmake... /cygdrive/c/Perl/c/bin/gmake >> configure: Testing potential make at /cygdrive/c/Perl/c/bin/gmake, found >> using gmake in PATH >> at /cygdrive/c/Perl/c/bin/gmake, but it is not for cygwin (it says: >> Built for x86_64-w64-mingw32). Ignoring. >> checking for make... no >> configure: error: Cannot find GNU make 3.81 or newer! Please put it in >> the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. >> configure exiting with result code 1 >> >> AparapiTest at AparapiTest-PC /cygdrive/c/Users/AparapiTest/views/sumatra-dev >> $ uname -a >> CYGWIN_NT-6.1-WOW64 AparapiTest-PC 1.7.17(0.262/5/3) 2012-10-19 14:39 >> i686 Cygwin >> >> >> >> >> >> >> > From tom.deneau at amd.com Fri Jan 11 08:47:30 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 Jan 2013 16:47:30 +0000 Subject: TieredCompilation question In-Reply-To: References: <50EF71EB.5080207@oracle.com> Message-ID: I tried Method::set_dont_inline(). It was a little unclear whether that affected only C1 or both C1 and C2. I like your suggestion better. Question: if MC had already been compiled as C2, I am assuming it would never then get compiled by C1, is that correct? -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Friday, January 11, 2013 3:39 AM To: Deneau, Tom Cc: Vladimir Kozlov; sumatra-dev at openjdk.java.net Subject: Re: TieredCompilation question I rather think that even though inlining MC into MA may be slower than calling the C2-compiled MC, it should not matter too much since it's a transitory state. In the end MA should be compiled using C2 and the assumption is that MC will get inlined in this compilation too. And anyway, if it does not then it would be back to calling the C2-compiled MC. If you want to avoid compilation of a method by C1 altogether you could try Method::set_not_c1_compilable() that way C1 would neither try to compile it or try to inline it. Gilles On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom > wrote: So the assumption is that MC inlined into MA will be better than calling a C2-compiled version of MC? I suppose it is also possible to forbid inlining of MC, so it would have to call the compiled version? -- Tom -----Original Message----- From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, January 10, 2013 7:59 PM To: sumatra-dev at openjdk.java.net Subject: Re: TieredCompilation question You step on your own mine :) Yes, it has such pathology for inlined by C1 methods. The assumption is that when C2 will compile MA it will also inline MB and MC. You can try to lower Tier4CompileThreshold. Vladimir On 1/10/13 5:22 PM, Deneau, Tom wrote: > I will display my ignorance of TieredCompilation here. :) > I think I am seeing the following but I am not positive... > > Let's say method MA calls MB calls MC. > MC gets compiled at C2 level. > Everything works well and the MC method compiled at C2 gets called several hundred times. > > Now method MA gets compiled at level 3 in C1. > This C1 compilation of MA decides to inline MB and then MC into its C1 compilation. > So it no longer uses the C2 compilation of MC?? > > In my particular case MC had called some intrinsic routines which were only defined as intrinsics in C2. > So the net effect of being compiled at C1 when it was inlined into MA was that we lose those intrinsics. > > Is this how TieredCompilation is supposed to work? > > I should add here that the early compilation of MC at C2 level was in my case artificially forced by some code I added to Hotspot (so I might have missed something in setting that up). > > With Tiered off, this all worked nicely of course. > > -- Tom > From tom.deneau at amd.com Fri Jan 11 08:51:32 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 Jan 2013 16:51:32 +0000 Subject: TieredCompilation question In-Reply-To: References: <50EF71EB.5080207@oracle.com> Message-ID: Gilles -- I agree it is a transitory state, it was just very strange because in my case the C2 compiled MC was an order of magnitude faster so the transitory state was noticeable: ? started out slow (interpreted) ? a child of MC caused MC itself to be compiled at C2 so things sped up noticeably. ? Then things slowed down again when the C1 compile kicked in. -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Friday, January 11, 2013 3:39 AM To: Deneau, Tom Cc: Vladimir Kozlov; sumatra-dev at openjdk.java.net Subject: Re: TieredCompilation question I rather think that even though inlining MC into MA may be slower than calling the C2-compiled MC, it should not matter too much since it's a transitory state. In the end MA should be compiled using C2 and the assumption is that MC will get inlined in this compilation too. And anyway, if it does not then it would be back to calling the C2-compiled MC. If you want to avoid compilation of a method by C1 altogether you could try Method::set_not_c1_compilable() that way C1 would neither try to compile it or try to inline it. Gilles On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom > wrote: So the assumption is that MC inlined into MA will be better than calling a C2-compiled version of MC? I suppose it is also possible to forbid inlining of MC, so it would have to call the compiled version? -- Tom -----Original Message----- From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, January 10, 2013 7:59 PM To: sumatra-dev at openjdk.java.net Subject: Re: TieredCompilation question You step on your own mine :) Yes, it has such pathology for inlined by C1 methods. The assumption is that when C2 will compile MA it will also inline MB and MC. You can try to lower Tier4CompileThreshold. Vladimir On 1/10/13 5:22 PM, Deneau, Tom wrote: > I will display my ignorance of TieredCompilation here. :) > I think I am seeing the following but I am not positive... > > Let's say method MA calls MB calls MC. > MC gets compiled at C2 level. > Everything works well and the MC method compiled at C2 gets called several hundred times. > > Now method MA gets compiled at level 3 in C1. > This C1 compilation of MA decides to inline MB and then MC into its C1 compilation. > So it no longer uses the C2 compilation of MC?? > > In my particular case MC had called some intrinsic routines which were only defined as intrinsics in C2. > So the net effect of being compiled at C1 when it was inlined into MA was that we lose those intrinsics. > > Is this how TieredCompilation is supposed to work? > > I should add here that the early compilation of MC at C2 level was in my case artificially forced by some code I added to Hotspot (so I might have missed something in setting that up). > > With Tiered off, this all worked nicely of course. > > -- Tom > From duboscq at ssw.jku.at Fri Jan 11 08:56:25 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 11 Jan 2013 17:56:25 +0100 Subject: TieredCompilation question In-Reply-To: References: <50EF71EB.5080207@oracle.com> Message-ID: MC could get deoptimized and its invocation counter reset, so it's not safe to assume that a method will not get recompiled just because it has already been compiled by C2. Whatever happens set_not_c1_compilable() should prevent any C1 compilation or inlining, it could just get re-compiled by C2. On Fri, Jan 11, 2013 at 5:47 PM, Tom Deneau wrote: > I tried Method::set_dont_inline(). It was a little unclear whether that > affected only C1 or both C1 and C2. I like your suggestion better.**** > > ** ** > > Question: if MC had already been compiled as C2, I am assuming it would > never then get compiled by C1, is that correct?**** > > ** ** > > -- Tom**** > > ** ** > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Friday, January 11, 2013 3:39 AM > *To:* Deneau, Tom > *Cc:* Vladimir Kozlov; sumatra-dev at openjdk.java.net > *Subject:* Re: TieredCompilation question**** > > ** ** > > I rather think that even though inlining MC into MA may be slower than > calling the C2-compiled MC, it should not matter too much since it's a > transitory state.**** > > In the end MA should be compiled using C2 and the assumption is that MC > will get inlined in this compilation too. And anyway, if it does not then > it would be back to calling the C2-compiled MC.**** > > ** ** > > If you want to avoid compilation of a method by C1 altogether you could > try Method::set_not_c1_compilable() that way C1 would neither try to > compile it or try to inline it.**** > > ** ** > > Gilles**** > > ** ** > > On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom wrote:** > ** > > So the assumption is that MC inlined into MA will be better than calling a > C2-compiled version of MC? > > I suppose it is also possible to forbid inlining of MC, so it would have > to call the compiled version? > > -- Tom**** > > > > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto: > sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, January 10, 2013 7:59 PM > To: sumatra-dev at openjdk.java.net > Subject: Re: TieredCompilation question > > You step on your own mine :) > > Yes, it has such pathology for inlined by C1 methods. The assumption is > that when C2 will compile MA it will also inline MB and MC. You can try > to lower Tier4CompileThreshold. > > Vladimir > > On 1/10/13 5:22 PM, Deneau, Tom wrote: > > I will display my ignorance of TieredCompilation here. :) > > I think I am seeing the following but I am not positive... > > > > Let's say method MA calls MB calls MC. > > MC gets compiled at C2 level. > > Everything works well and the MC method compiled at C2 gets called > several hundred times. > > > > Now method MA gets compiled at level 3 in C1. > > This C1 compilation of MA decides to inline MB and then MC into its C1 > compilation. > > So it no longer uses the C2 compilation of MC?? > > > > In my particular case MC had called some intrinsic routines which were > only defined as intrinsics in C2. > > So the net effect of being compiled at C1 when it was inlined into MA > was that we lose those intrinsics. > > > > Is this how TieredCompilation is supposed to work? > > > > I should add here that the early compilation of MC at C2 level was in my > case artificially forced by some code I added to Hotspot (so I might have > missed something in setting that up). > > > > With Tiered off, this all worked nicely of course. > > > > -- Tom > > > > **** > > ** ** > From vladimir.x.ivanov at oracle.com Fri Jan 11 10:05:34 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Jan 2013 21:05:34 +0300 Subject: TieredCompilation question In-Reply-To: References: <50EF71EB.5080207@oracle.com> Message-ID: <50F0546E.1080309@oracle.com> Tom, > Question: if MC had already been compiled as C2, I am assuming it would never then get compiled by C1, is that correct? Yes, level 4 is a dead-end (unless the method is invalidated and then recompiled again). Best regards, Vladimir Ivanov On 1/11/13 7:47 PM, Deneau, Tom wrote: > I tried Method::set_dont_inline(). It was a little unclear whether that affected only C1 or both C1 and C2. I like your suggestion better. > > Question: if MC had already been compiled as C2, I am assuming it would never then get compiled by C1, is that correct? > > -- Tom > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq > Sent: Friday, January 11, 2013 3:39 AM > To: Deneau, Tom > Cc: Vladimir Kozlov; sumatra-dev at openjdk.java.net > Subject: Re: TieredCompilation question > > I rather think that even though inlining MC into MA may be slower than calling the C2-compiled MC, it should not matter too much since it's a transitory state. > In the end MA should be compiled using C2 and the assumption is that MC will get inlined in this compilation too. And anyway, if it does not then it would be back to calling the C2-compiled MC. > > If you want to avoid compilation of a method by C1 altogether you could try Method::set_not_c1_compilable() that way C1 would neither try to compile it or try to inline it. > > Gilles > > On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom > wrote: > So the assumption is that MC inlined into MA will be better than calling a C2-compiled version of MC? > > I suppose it is also possible to forbid inlining of MC, so it would have to call the compiled version? > > -- Tom > > > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, January 10, 2013 7:59 PM > To: sumatra-dev at openjdk.java.net > Subject: Re: TieredCompilation question > > You step on your own mine :) > > Yes, it has such pathology for inlined by C1 methods. The assumption is > that when C2 will compile MA it will also inline MB and MC. You can try > to lower Tier4CompileThreshold. > > Vladimir > > On 1/10/13 5:22 PM, Deneau, Tom wrote: >> I will display my ignorance of TieredCompilation here. :) >> I think I am seeing the following but I am not positive... >> >> Let's say method MA calls MB calls MC. >> MC gets compiled at C2 level. >> Everything works well and the MC method compiled at C2 gets called several hundred times. >> >> Now method MA gets compiled at level 3 in C1. >> This C1 compilation of MA decides to inline MB and then MC into its C1 compilation. >> So it no longer uses the C2 compilation of MC?? >> >> In my particular case MC had called some intrinsic routines which were only defined as intrinsics in C2. >> So the net effect of being compiled at C1 when it was inlined into MA was that we lose those intrinsics. >> >> Is this how TieredCompilation is supposed to work? >> >> I should add here that the early compilation of MC at C2 level was in my case artificially forced by some code I added to Hotspot (so I might have missed something in setting that up). >> >> With Tiered off, this all worked nicely of course. >> >> -- Tom >> > > From eric.caspole at amd.com Fri Jan 11 14:08:48 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Fri, 11 Jan 2013 17:08:48 -0500 Subject: configure jdk new build on win 7 enterprise In-Reply-To: <50F038DB.9020307@amd.com> References: <50F038DB.9020307@amd.com> Message-ID: <50F08D70.9090307@amd.com> Just FYI, I found this very good page showing how to do it: http://java.net/projects/adoptopenjdk/pages/BuildWindows Eric On 01/11/2013 11:07 AM, Eric Caspole wrote: > Yes it was something like that. Although my original install of cygwin > took more than an hour downloading stuff from the web, it did not > install make or zip by default, so I went back and added them in a > second install step. > > It is starting the build now, we'll see. > > > On 01/10/2013 08:22 PM, Frost, Gary wrote: >> So is the gmake file (under Perl) really gnu make? >> >> Have you downloaded the cygwin make package. My guess is the binary >> under >> perl/c is not really make. Maybe they want you to rename gnu make to >> gmake so that it is picked up instead of microsofts own make. >> >> From >> http://cygwin.com/packages/make/make-3.81-2 >> >> >> It sure looks like cygwins make is called make.exe not gmake.exe?. >> >> Confusing. >> >> Gary >> >> >> >> On 1/10/13 5:33 PM, "Eric Caspole" wrote: >> >>> Hi everyone, >>> I am trying to get something ready for eventual contribution in to >>> sumatra, and I would like to check my code works on Windows. >>> >>> This is the first time I am building the JDK on Windows using the new >>> build. >>> >>> I have installed the complete latest cygwin, but the configure does not >>> like the gmake in cygwin. This is Windows 7 enterprise SP1 and I . >>> >>> My error output is shown below. >>> >>> Does anyone know the fix for this or what else needs to be installed? >>> >>> I have set up the system like I was otherwise using to build just >>> hotspot (not the whole JDK) a few months ago with Windows SDK 7.1. >>> >>> I'll keep searching in the build-dev list but I have not found anything >>> yet. >>> Thanks for any advice, >>> Eric >>> >>> >>> ========= >>> >>> AparapiTest at AparapiTest-PC >>> /cygdrive/c/Users/AparapiTest/views/sumatra-dev >>> $ sh ./configure >>> Running generated-configure.sh >>> configure: Configuration created at Thu Jan 10 15:38:38 CST 2013. >>> configure: configure script generated at timestamp 1355963953. >>> checking for basename... /usr/bin/basename >>> >>> ... >>> >>> checking for pkgadd... no >>> checking for gmake... /cygdrive/c/Perl/c/bin/gmake >>> configure: Testing potential make at /cygdrive/c/Perl/c/bin/gmake, found >>> using gmake in PATH >>> at /cygdrive/c/Perl/c/bin/gmake, but it is not for cygwin (it says: >>> Built for x86_64-w64-mingw32). Ignoring. >>> checking for make... no >>> configure: error: Cannot find GNU make 3.81 or newer! Please put it in >>> the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. >>> configure exiting with result code 1 >>> >>> AparapiTest at AparapiTest-PC >>> /cygdrive/c/Users/AparapiTest/views/sumatra-dev >>> $ uname -a >>> CYGWIN_NT-6.1-WOW64 AparapiTest-PC 1.7.17(0.262/5/3) 2012-10-19 14:39 >>> i686 Cygwin >>> >>> >>> >>> >>> >>> >>> >> > > From tom.deneau at amd.com Mon Jan 14 15:04:42 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 14 Jan 2013 23:04:42 +0000 Subject: Thoughts on triggering GPU redirection Message-ID: Given a call to some library API, we'll call it ParallelFor, which specifies a range of integers and a lambda expression to execute across that range, we want to eventually redirect it to a GPU execution. The java code for ParallelFor will likely spin off a bunch of threads where the work is done. We've been experimenting with different ways of triggering that redirection. To keep things simple in the discussion below, let's assume TieredCompilation is off. The first triggering strategy was simple, when ParalleFor itself gets marked for compilation by C2, we could look up the stack to find our caller, cause the caller to be compiled and the call to ParallelFor could be intrinsifed to go to some native method which executes the equivalent code on the GPU. But maybe you want to trigger sooner than that. ParallelFor may be called with a large range, each element of the range executing a lambdain the worker threads. So when the lambda gets hot enough to be compiled (which will happen much sooner), that could also be a trigger. The stack at the time of the lambda compilation will be in one of the worker threads so we'd have to find the ParallelFor caller back int the "main" thread that spun off the worker threads, get that to compile, etc. Both of the above strategies might work OK when there is one ParallelFor call site but in general we might not be able to track the lambda executions or the ParallelFor execution itself to any particular call sites. An alternative would be to keep counters per call site where ParallelFor is called in the interpreter. We could count for instance not just # of calls, but total # of range elements or whatever other statistics we wanted. When the statistics at that site overflow, we trigger the compilation of the ParallelFor caller (up one level on the stack) and mark that particular call site for intrinsic redirection. Thus, we avoid having to guess which call sites contributed the counts. Is the above something feasible for the interpreter to be made to do? -- Tom Deneau From duboscq at ssw.jku.at Fri Jan 11 01:39:40 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 11 Jan 2013 09:39:40 -0000 Subject: TieredCompilation question In-Reply-To: References: <50EF71EB.5080207@oracle.com> Message-ID: I rather think that even though inlining MC into MA may be slower than calling the C2-compiled MC, it should not matter too much since it's a transitory state. In the end MA should be compiled using C2 and the assumption is that MC will get inlined in this compilation too. And anyway, if it does not then it would be back to calling the C2-compiled MC. If you want to avoid compilation of a method by C1 altogether you could try Method::set_not_c1_compilable() that way C1 would neither try to compile it or try to inline it. Gilles On Fri, Jan 11, 2013 at 5:31 AM, Deneau, Tom wrote: > So the assumption is that MC inlined into MA will be better than calling a > C2-compiled version of MC? > > I suppose it is also possible to forbid inlining of MC, so it would have > to call the compiled version? > > -- Tom > > > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto: > sumatra-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, January 10, 2013 7:59 PM > To: sumatra-dev at openjdk.java.net > Subject: Re: TieredCompilation question > > You step on your own mine :) > > Yes, it has such pathology for inlined by C1 methods. The assumption is > that when C2 will compile MA it will also inline MB and MC. You can try > to lower Tier4CompileThreshold. > > Vladimir > > On 1/10/13 5:22 PM, Deneau, Tom wrote: > > I will display my ignorance of TieredCompilation here. :) > > I think I am seeing the following but I am not positive... > > > > Let's say method MA calls MB calls MC. > > MC gets compiled at C2 level. > > Everything works well and the MC method compiled at C2 gets called > several hundred times. > > > > Now method MA gets compiled at level 3 in C1. > > This C1 compilation of MA decides to inline MB and then MC into its C1 > compilation. > > So it no longer uses the C2 compilation of MC?? > > > > In my particular case MC had called some intrinsic routines which were > only defined as intrinsics in C2. > > So the net effect of being compiled at C1 when it was inlined into MA > was that we lose those intrinsics. > > > > Is this how TieredCompilation is supposed to work? > > > > I should add here that the early compilation of MC at C2 level was in my > case artificially forced by some code I added to Hotspot (so I might have > missed something in setting that up). > > > > With Tiered off, this all worked nicely of course. > > > > -- Tom > > > > >