From tom.deneau at amd.com Tue Feb 5 08:02:16 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 5 Feb 2013 16:02:16 +0000 Subject: hg.openjdk.java.net/sumatra/sumatra-* Message-ID: Hi -- I noticed there are sumatra repositories at http://hg.openjdk.java.net/sumatra/sumatra-dev/ and http://hg.openjdk.java.net/sumatra/sumatra-dev-gate Could someone at Oracle * explain the difference between the two trees, sumatra-dev and sumatra-dev-gate * confirm whether these are able to be committed to * and if they are ready, review what policy we will use for committing including what form of branching we will use. -- Tom Deneau From john.r.rose at oracle.com Tue Feb 5 13:41:32 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Feb 2013 13:41:32 -0800 Subject: hg.openjdk.java.net/sumatra/sumatra-* In-Reply-To: References: Message-ID: On Feb 5, 2013, at 8:02 AM, "Deneau, Tom" wrote: > I noticed there are sumatra repositories at > http://hg.openjdk.java.net/sumatra/sumatra-dev/ > and > http://hg.openjdk.java.net/sumatra/sumatra-dev-gate > > Could someone at Oracle > * explain the difference between the two trees, sumatra-dev and sumatra-dev-gate The *-dev-gate repos are for writing and the *-dev repos are for reading. This is normal for OpndJDK; see: http://openjdk.java.net/guide/repositories.html#term http://openjdk.java.net/guide/ > * confirm whether these are able to be committed to I plan to commit a trial README file to make sure things are mutable. Here is a draft of the content: https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo Please edit! (Tom, you are a wiki editor, BTW.) > * and if they are ready, review what policy we will use for committing > including what form of branching we will use. That's partly up to us, especially what we put into the scratch repo. ? John From tom.deneau at amd.com Mon Feb 11 07:19:50 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 11 Feb 2013 15:19:50 +0000 Subject: hg.openjdk.java.net/sumatra/sumatra-* In-Reply-To: References: Message-ID: John -- The wiki page https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo looks like a good start. I will make some edits to it later regarding named branches once we figure out what the server can support. You mentioned some server config will be required, how does that get done? One other question was the occasional pulling form the latest jdk8 into sumatra-dev. Is that something that any committer can do, or does it happen automatically at some frequency? Does the pulling from jdk8 follow the usual path of going first into sumatra-dev-gate and finally into sumatra-dev? -- Tom > -----Original Message----- > From: John Rose [mailto:john.r.rose at oracle.com] > Sent: Tuesday, February 05, 2013 3:42 PM > To: Deneau, Tom > Cc: sumatra-dev at openjdk.java.net > Subject: Re: hg.openjdk.java.net/sumatra/sumatra-* > > On Feb 5, 2013, at 8:02 AM, "Deneau, Tom" wrote: > > > I noticed there are sumatra repositories at > > http://hg.openjdk.java.net/sumatra/sumatra-dev/ > > and > > http://hg.openjdk.java.net/sumatra/sumatra-dev-gate > > > > Could someone at Oracle > > * explain the difference between the two trees, sumatra-dev and sumatra- > dev-gate > > The *-dev-gate repos are for writing and the *-dev repos are for reading. > This is normal for OpndJDK; see: > http://openjdk.java.net/guide/repositories.html#term > http://openjdk.java.net/guide/ > > > * confirm whether these are able to be committed to > > I plan to commit a trial README file to make sure things are mutable. > > Here is a draft of the content: > https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo > > Please edit! (Tom, you are a wiki editor, BTW.) > > > * and if they are ready, review what policy we will use for committing > > including what form of branching we will use. > > > That's partly up to us, especially what we put into the scratch repo. > > - John > From Vasanth.Venkatachalam at amd.com Mon Feb 11 15:30:27 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 11 Feb 2013 23:30:27 +0000 Subject: using Graal for a dual-ISA prototype Message-ID: <5DD1503F815BD14889DC81D28643E3A7329F0E0D@sausexdag06.amd.com> Hi, We're thinking of leveraging the Graal OpenJDK project to develop a prototype dual-ISA code generation framework for Sumatra. http://openjdk.java.net/projects/graal/ Our main idea is that the Hotspot Server JVM will compile the routines that are meant to execute on the CPU, while Graal will intercept and generate GPU-specific code for the few routines that need to execute on the GPU. We thought this approach would lead to a faster prototype and allow us to retain most of Hotspot's existing functionality, as opposed to the riskier approach of writing an entire C2 backend from scratch. We have built Graal and run a few test cases using SPECjbb2005. All the runs completed successfully. We are digging deeper into Graal to understand what hooks we need to modify so that Graal intercepts the compilation of routines that need to execute on the GPU. We'll keep you informed and ask questions as this work progresses. If anyone has feedback, let us know. Vasanth From christian.thalinger at oracle.com Mon Feb 11 18:24:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Feb 2013 18:24:20 -0800 Subject: using Graal for a dual-ISA prototype In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7329F0E0D@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7329F0E0D@sausexdag06.amd.com> Message-ID: On Feb 11, 2013, at 3:30 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We're thinking of leveraging the Graal OpenJDK project to develop a prototype dual-ISA code generation framework for Sumatra. > > http://openjdk.java.net/projects/graal/ > > Our main idea is that the Hotspot Server JVM will compile the routines that are meant to execute on the CPU, while Graal will intercept and generate GPU-specific code for the few routines that need to execute on the GPU. We thought this approach would lead to a faster prototype and allow us to retain most of Hotspot's existing functionality, as opposed to the riskier approach of writing an entire C2 backend from scratch. > > We have built Graal and run a few test cases using SPECjbb2005. All the runs completed successfully. > We are digging deeper into Graal to understand what hooks we need to modify so that Graal intercepts the compilation of routines that need to execute on the GPU. > > We'll keep you informed and ask questions as this work progresses. If anyone has feedback, let us know. I'm also working on getting Graal to emit code for GPUs. As a first prototype I took the PTX architecture and implemented initial support in Graal. The prototype is now able to compile specially annotated methods to PTX code and dump in on the screen (no execution). My plan is to push what I have into the Graal repository this week so that other people can pick up the work and implement other architectures, like HSAIL. -- Chris > > Vasanth From john.r.rose at oracle.com Tue Feb 12 00:56:53 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 12 Feb 2013 08:56:53 +0000 Subject: hg: sumatra/sumatra-dev/scratch: admin: new readme file Message-ID: <20130212085654.07D16479CC@hg.openjdk.java.net> Changeset: 57f29527f157 Author: jrose Date: 2013-02-12 00:56 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch/rev/57f29527f157 admin: new readme file + README-SUMATRA From john.r.rose at oracle.com Tue Feb 12 02:09:20 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Feb 2013 02:09:20 -0800 Subject: hg.openjdk.java.net/sumatra/sumatra-* In-Reply-To: References: Message-ID: <0940A372-8FFB-4EAC-A3C8-BAD9CED9855F@oracle.com> On Feb 11, 2013, at 7:19 AM, "Deneau, Tom" wrote: > The wiki page https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo > looks like a good start. I will make some edits to it later regarding named branches once > we figure out what the server can support. Good; thanks for looking at that! I pushed this file which points at it: http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch/raw-file/tip/README-SUMATRA > You mentioned some server config will be required, > how does that get done? John Coomes helps run the hg.ojn server. He is the one who set us up in the first place. Probably the next step is to make a dummy branch in sumatra-dev/scratch and try to push it. > One other question was the occasional pulling form the latest jdk8 into sumatra-dev. > Is that something that any committer can do, or does it happen automatically at some frequency? No, it's not automatic. In a typical child (downstream) repository, local modifications have to be reconciled with incoming changes from the parent repository. This require some manual gatekeeping. For the hotspot repos, this is done by rotating assignment within the Oracle workgroup. I don't have an immediate proposal for when and how to do the same for sumatra-dev. > Does the pulling from jdk8 follow the usual path of going first into sumatra-dev-gate and finally into sumatra-dev? Yes, it will. No changes go directly into the non-gate repo. Moving forward, I expect we will want to populate sumatra-dev/scratch with various small experiments, such as the foreign-array mechanism David Chase is working on. For something larger-scale like Graal or Aparapi, we need to decide whether (and how) we want to either import it (as a downstream child or a one-time copy) or else maintain a MQ patch set on top of it. ? John From Vasanth.Venkatachalam at amd.com Tue Feb 12 13:35:42 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 12 Feb 2013 21:35:42 +0000 Subject: using Graal for a dual-ISA prototype In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7329F0E0D@sausexdag06.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A7329F31AF@sausexdag06.amd.com> Christian, Thanks for the update. I've started to explore the Graal source. Can you tell me what files I should start looking at so that I can better identify the changes I will have to make (to support other architectures) once your work gets checked in? Vasanth -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, February 11, 2013 8:24 PM To: Venkatachalam, Vasanth Cc: sumatra-dev at openjdk.java.net Subject: Re: using Graal for a dual-ISA prototype On Feb 11, 2013, at 3:30 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We're thinking of leveraging the Graal OpenJDK project to develop a prototype dual-ISA code generation framework for Sumatra. > > http://openjdk.java.net/projects/graal/ > > Our main idea is that the Hotspot Server JVM will compile the routines that are meant to execute on the CPU, while Graal will intercept and generate GPU-specific code for the few routines that need to execute on the GPU. We thought this approach would lead to a faster prototype and allow us to retain most of Hotspot's existing functionality, as opposed to the riskier approach of writing an entire C2 backend from scratch. > > We have built Graal and run a few test cases using SPECjbb2005. All the runs completed successfully. > We are digging deeper into Graal to understand what hooks we need to modify so that Graal intercepts the compilation of routines that need to execute on the GPU. > > We'll keep you informed and ask questions as this work progresses. If anyone has feedback, let us know. I'm also working on getting Graal to emit code for GPUs. As a first prototype I took the PTX architecture and implemented initial support in Graal. The prototype is now able to compile specially annotated methods to PTX code and dump in on the screen (no execution). My plan is to push what I have into the Graal repository this week so that other people can pick up the work and implement other architectures, like HSAIL. -- Chris > > Vasanth From christian.thalinger at oracle.com Wed Feb 13 16:10:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Feb 2013 16:10:15 -0800 Subject: using Graal for a dual-ISA prototype In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7329F31AF@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7329F0E0D@sausexdag06.amd.com> <5DD1503F815BD14889DC81D28643E3A7329F31AF@sausexdag06.amd.com> Message-ID: On Feb 12, 2013, at 1:35 PM, "Venkatachalam, Vasanth" wrote: > Christian, > > Thanks for the update. I've started to explore the Graal source. Can you tell me what files I should start looking at so that I can better identify the changes I will have to make (to support other architectures) once your work gets checked in? Here is the first cut of my PTX changes: http://cr.openjdk.java.net/~twisti/0000000/ This should give you an idea of what is required. Note: it includes the PTXAssembler.java but this one is generated from the ISA description: http://cr.openjdk.java.net/~twisti/0000000/ptx.isad -- Chris > > Vasanth > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, February 11, 2013 8:24 PM > To: Venkatachalam, Vasanth > Cc: sumatra-dev at openjdk.java.net > Subject: Re: using Graal for a dual-ISA prototype > > > On Feb 11, 2013, at 3:30 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> We're thinking of leveraging the Graal OpenJDK project to develop a prototype dual-ISA code generation framework for Sumatra. >> >> http://openjdk.java.net/projects/graal/ >> >> Our main idea is that the Hotspot Server JVM will compile the routines that are meant to execute on the CPU, while Graal will intercept and generate GPU-specific code for the few routines that need to execute on the GPU. We thought this approach would lead to a faster prototype and allow us to retain most of Hotspot's existing functionality, as opposed to the riskier approach of writing an entire C2 backend from scratch. >> >> We have built Graal and run a few test cases using SPECjbb2005. All the runs completed successfully. >> We are digging deeper into Graal to understand what hooks we need to modify so that Graal intercepts the compilation of routines that need to execute on the GPU. >> >> We'll keep you informed and ask questions as this work progresses. If anyone has feedback, let us know. > > I'm also working on getting Graal to emit code for GPUs. As a first prototype I took the PTX architecture and implemented initial support in Graal. The prototype is now able to compile specially annotated methods to PTX code and dump in on the screen (no execution). > > My plan is to push what I have into the Graal repository this week so that other people can pick up the work and implement other architectures, like HSAIL. > > -- Chris > >> >> Vasanth > > > From tom.deneau at amd.com Mon Feb 18 08:52:01 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 18 Feb 2013 16:52:01 +0000 Subject: sharing graal experiments Message-ID: A repository question... Some sumatra folks are or will be doing some experiments under the graal tree. How should these be made available to the rest of the Sumatra team? * would we make our own Sumatra-dev/graal fork of the graal repository ? * or would we share such things in some way under the existing graal repository? * or share them as patches to graal posted in our "scratch" directory. I would vote for the first option above but am open to other opinions. -- Tom From thomas.wuerthinger at oracle.com Mon Feb 18 09:37:20 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 18 Feb 2013 09:37:20 -0800 Subject: sharing graal experiments In-Reply-To: References: Message-ID: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> Tom, I'd suggest a combination of option 1 and 2: Experiments go into a sumatra-dev/graal fork. Stable changes to Graal to make it a more suitable compiler for the GPU are added to graal/graal. We can help making those changes. The Graal repository is a fork of the HotSpot repository. So, pulling in changes from graal/graal into sumatra/sumatra-dev/hotspot should work. - thomas On Feb 18, 2013, at 8:52 AM, "Deneau, Tom" wrote: > A repository question... > > Some sumatra folks are or will be doing some experiments under the graal tree. How should these be made available to the rest of the Sumatra team? > > * would we make our own Sumatra-dev/graal fork of the graal repository ? > > * or would we share such things in some way under the existing graal repository? > > * or share them as patches to graal posted in our "scratch" directory. > > I would vote for the first option above but am open to other opinions. > > -- Tom From christian.thalinger at oracle.com Mon Feb 18 12:09:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Feb 2013 12:09:55 -0800 Subject: sharing graal experiments In-Reply-To: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> Message-ID: <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> On Feb 18, 2013, at 9:37 AM, Thomas Wuerthinger wrote: > Tom, > > I'd suggest a combination of option 1 and 2: Experiments go into a sumatra-dev/graal fork. Stable changes to Graal to make it a more suitable compiler for the GPU are added to graal/graal. We can help making those changes. I concur. The PTX port should go into graal/graal because it's the first GPU architecture for Graal and it will be helpful to make infrastructure changes based on what we need for that. Other GPU architectures can go to sumatra/sumatra-dev/hotspot first and later be integrated in graal/graal. -- Chris > > The Graal repository is a fork of the HotSpot repository. So, pulling in changes from graal/graal into sumatra/sumatra-dev/hotspot should work. > > - thomas > > On Feb 18, 2013, at 8:52 AM, "Deneau, Tom" wrote: > >> A repository question... >> >> Some sumatra folks are or will be doing some experiments under the graal tree. How should these be made available to the rest of the Sumatra team? >> >> * would we make our own Sumatra-dev/graal fork of the graal repository ? >> >> * or would we share such things in some way under the existing graal repository? >> >> * or share them as patches to graal posted in our "scratch" directory. >> >> I would vote for the first option above but am open to other opinions. >> >> -- Tom > From tom.deneau at amd.com Mon Feb 18 12:46:15 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 18 Feb 2013 20:46:15 +0000 Subject: sharing graal experiments In-Reply-To: <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> Message-ID: Just to make sure I understand, you are saying we do not need to create a separate sumatra/sumatra-dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will occasionally be synced with graal/graal and graal/graal will occasionally be synced with some development version of hotspot. -- Tom > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, February 18, 2013 2:10 PM > To: Thomas Wuerthinger > Cc: Deneau, Tom; graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: sharing graal experiments > > > On Feb 18, 2013, at 9:37 AM, Thomas Wuerthinger > wrote: > > > Tom, > > > > I'd suggest a combination of option 1 and 2: Experiments go into a sumatra- > dev/graal fork. Stable changes to Graal to make it a more suitable compiler > for the GPU are added to graal/graal. We can help making those changes. > > I concur. The PTX port should go into graal/graal because it's the first GPU > architecture for Graal and it will be helpful to make infrastructure changes > based on what we need for that. > > Other GPU architectures can go to sumatra/sumatra-dev/hotspot first and later > be integrated in graal/graal. > > -- Chris > > > > > The Graal repository is a fork of the HotSpot repository. So, pulling in > changes from graal/graal into sumatra/sumatra-dev/hotspot should work. > > > > - thomas > > > > On Feb 18, 2013, at 8:52 AM, "Deneau, Tom" wrote: > > > >> A repository question... > >> > >> Some sumatra folks are or will be doing some experiments under the graal > tree. How should these be made available to the rest of the Sumatra team? > >> > >> * would we make our own Sumatra-dev/graal fork of the graal > repository ? > >> > >> * or would we share such things in some way under the existing > graal repository? > >> > >> * or share them as patches to graal posted in our "scratch" > directory. > >> > >> I would vote for the first option above but am open to other opinions. > >> > >> -- Tom > > > From thomas.wuerthinger at oracle.com Mon Feb 18 13:30:24 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 18 Feb 2013 13:30:24 -0800 Subject: sharing graal experiments In-Reply-To: References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> Message-ID: <6388DC64-D0F2-4ABB-9D33-90082D5F47A0@oracle.com> Yes, correct. That would work from our perspective. We sync graal/graal with hsx/hsx25/hotspot approximately once a month. - thomas On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: > Just to make sure I understand, > you are saying we do not need to create a separate sumatra/sumatra-dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will occasionally be synced with graal/graal > and graal/graal will occasionally be synced with some development version of hotspot. > > -- Tom > > >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Monday, February 18, 2013 2:10 PM >> To: Thomas Wuerthinger >> Cc: Deneau, Tom; graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: sharing graal experiments >> >> >> On Feb 18, 2013, at 9:37 AM, Thomas Wuerthinger >> wrote: >> >>> Tom, >>> >>> I'd suggest a combination of option 1 and 2: Experiments go into a sumatra- >> dev/graal fork. Stable changes to Graal to make it a more suitable compiler >> for the GPU are added to graal/graal. We can help making those changes. >> >> I concur. The PTX port should go into graal/graal because it's the first GPU >> architecture for Graal and it will be helpful to make infrastructure changes >> based on what we need for that. >> >> Other GPU architectures can go to sumatra/sumatra-dev/hotspot first and later >> be integrated in graal/graal. >> >> -- Chris >> >>> >>> The Graal repository is a fork of the HotSpot repository. So, pulling in >> changes from graal/graal into sumatra/sumatra-dev/hotspot should work. >>> >>> - thomas >>> >>> On Feb 18, 2013, at 8:52 AM, "Deneau, Tom" wrote: >>> >>>> A repository question... >>>> >>>> Some sumatra folks are or will be doing some experiments under the graal >> tree. How should these be made available to the rest of the Sumatra team? >>>> >>>> * would we make our own Sumatra-dev/graal fork of the graal >> repository ? >>>> >>>> * or would we share such things in some way under the existing >> graal repository? >>>> >>>> * or share them as patches to graal posted in our "scratch" >> directory. >>>> >>>> I would vote for the first option above but am open to other opinions. >>>> >>>> -- Tom >>> >> > > From christian.thalinger at oracle.com Mon Feb 18 14:26:33 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Feb 2013 14:26:33 -0800 Subject: sharing graal experiments In-Reply-To: References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> Message-ID: <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: > Just to make sure I understand, > you are saying we do not need to create a separate sumatra/sumatra-dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will occasionally be synced with graal/graal > and graal/graal will occasionally be synced with some development version of hotspot. Yes, that's what I thought would work best. Not sure if John has other plans. -- Chris > > -- Tom > > >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Monday, February 18, 2013 2:10 PM >> To: Thomas Wuerthinger >> Cc: Deneau, Tom; graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: sharing graal experiments >> >> >> On Feb 18, 2013, at 9:37 AM, Thomas Wuerthinger >> wrote: >> >>> Tom, >>> >>> I'd suggest a combination of option 1 and 2: Experiments go into a sumatra- >> dev/graal fork. Stable changes to Graal to make it a more suitable compiler >> for the GPU are added to graal/graal. We can help making those changes. >> >> I concur. The PTX port should go into graal/graal because it's the first GPU >> architecture for Graal and it will be helpful to make infrastructure changes >> based on what we need for that. >> >> Other GPU architectures can go to sumatra/sumatra-dev/hotspot first and later >> be integrated in graal/graal. >> >> -- Chris >> >>> >>> The Graal repository is a fork of the HotSpot repository. So, pulling in >> changes from graal/graal into sumatra/sumatra-dev/hotspot should work. >>> >>> - thomas >>> >>> On Feb 18, 2013, at 8:52 AM, "Deneau, Tom" wrote: >>> >>>> A repository question... >>>> >>>> Some sumatra folks are or will be doing some experiments under the graal >> tree. How should these be made available to the rest of the Sumatra team? >>>> >>>> * would we make our own Sumatra-dev/graal fork of the graal >> repository ? >>>> >>>> * or would we share such things in some way under the existing >> graal repository? >>>> >>>> * or share them as patches to graal posted in our "scratch" >> directory. >>>> >>>> I would vote for the first option above but am open to other opinions. >>>> >>>> -- Tom >>> >> > > From john.r.rose at oracle.com Mon Feb 18 15:28:45 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 18 Feb 2013 15:28:45 -0800 Subject: sharing graal experiments In-Reply-To: <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> Message-ID: <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> On Feb 18, 2013, at 2:26 PM, Christian Thalinger wrote: > On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: > >> Just to make sure I understand, >> you are saying we do not need to create a separate sumatra/sumatra-dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will occasionally be synced with graal/graal >> and graal/graal will occasionally be synced with some development version of hotspot. > > Yes, that's what I thought would work best. Not sure if John has other plans. This will work. It does not conflict with any other use of sumatra-dev that I am envisioning. The plan of record for sumatra-dev is here: https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo I have only one hesitation: This move, of incorporating an advanced development project like Graal, can be done for at most one repo. Is there any other OpenJDK repo. that we would want to incorporate? I think not. If it were 12 months ago, we might want to tie more closely to lambda/collections repos. But there is no circumstance like that today. What do you think? ? John From john.r.rose at oracle.com Mon Feb 18 15:47:36 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 18 Feb 2013 15:47:36 -0800 Subject: sharing graal experiments In-Reply-To: <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> Message-ID: <1B79C840-FDD9-4B0D-9310-B0BB76871E1A@oracle.com> On Feb 18, 2013, at 3:28 PM, John Rose wrote: > It does not conflict with any other use of sumatra-dev that I am envisioning. P.S. A quick check shows that sumatra-dev/hotspot is already contained in graal. -------- cd ~/Projects/sumatra/hotspot/ -------- hg in comparing with http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot searching for changes no changes found -------- hg out http://hg.openjdk.java.net/graal/graal/hotspot comparing with http://hg.openjdk.java.net/graal/graal/hotspot searching for changes no changes found -------- hg in http://hg.openjdk.java.net/jdk8/jdk8/hotspot | wc 1056 3525 32796 -------- hg in -l1 http://hg.openjdk.java.net/jdk8/jdk8/hotspot comparing with http://hg.openjdk.java.net/jdk8/jdk8/hotspot searching for changes changeset: 3947:cd962e15c08e parent: 3940:6a1fc440b396 user: amurillo date: Fri Dec 21 10:27:49 2012 -0800 summary: 8005382: new hotspot build - hs25-b15 -------- From john.r.rose at oracle.com Mon Feb 18 19:30:45 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 18 Feb 2013 19:30:45 -0800 Subject: sharing graal experiments In-Reply-To: <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> Message-ID: <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> On Feb 18, 2013, at 3:28 PM, John Rose wrote: > On Feb 18, 2013, at 2:26 PM, Christian Thalinger wrote: > >> On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: >> >>> Just to make sure I understand, >>> you are saying we do not need to create a separate sumatra/sumatra-dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will occasionally be synced with graal/graal >>> and graal/graal will occasionally be synced with some development version of hotspot. >> >> Yes, that's what I thought would work best. Not sure if John has other plans. > > This will work. It does not conflict with any other use of sumatra-dev that I am envisioning. > > The plan of record for sumatra-dev is here: > https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo > > I have only one hesitation: This move, of incorporating an advanced development project like Graal, can be done for at most one repo. Is there any other OpenJDK repo. that we would want to incorporate? I think not. If it were 12 months ago, we might want to tie more closely to lambda/collections repos. But there is no circumstance like that today. What do you think? One more thought: How about if we have graal/graal copied into sumatra-dev/graal, keeping the existing copy of jdk8/hotspot also. Upside: There will always be a known-good snapshot of the whole jdk8/* forest, and builds will be known to work modulo local changes (whether on branches or not). For graal-based experiments we would expect developers to remove the "stock" hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot). Downsides: Redundancy (although the hotspot and graal repos would be near duplicates). Uncertainty as to where to host branches (stock hotspot vs. graal). ? John From tom.deneau at amd.com Tue Feb 19 07:30:48 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 19 Feb 2013 15:30:48 +0000 Subject: sharing graal experiments In-Reply-To: <1B79C840-FDD9-4B0D-9310-B0BB76871E1A@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <1B79C840-FDD9-4B0D-9310-B0BB76871E1A@oracle.com> Message-ID: so will someone be pulling from graal into Sumatra-dev/hotspot then to bring them in sync? -- Tom > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev- > bounces at openjdk.java.net] On Behalf Of John Rose > Sent: Monday, February 18, 2013 5:48 PM > To: Christian Thalinger > Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: sharing graal experiments > > On Feb 18, 2013, at 3:28 PM, John Rose wrote: > > > It does not conflict with any other use of sumatra-dev that I am > envisioning. > > P.S. A quick check shows that sumatra-dev/hotspot is already contained in > graal. > > -------- > cd ~/Projects/sumatra/hotspot/ > -------- > hg in > comparing with http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot > searching for changes > no changes found > -------- > hg out http://hg.openjdk.java.net/graal/graal/hotspot > comparing with http://hg.openjdk.java.net/graal/graal/hotspot > searching for changes > no changes found > -------- > hg in http://hg.openjdk.java.net/jdk8/jdk8/hotspot | wc > 1056 3525 32796 > -------- > hg in -l1 http://hg.openjdk.java.net/jdk8/jdk8/hotspot > comparing with http://hg.openjdk.java.net/jdk8/jdk8/hotspot > searching for changes > changeset: 3947:cd962e15c08e > parent: 3940:6a1fc440b396 > user: amurillo > date: Fri Dec 21 10:27:49 2012 -0800 > summary: 8005382: new hotspot build - hs25-b15 > > -------- > From tom.deneau at amd.com Tue Feb 19 08:02:54 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 19 Feb 2013 16:02:54 +0000 Subject: sharing graal experiments In-Reply-To: <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> Message-ID: I agree with John's hesitation. I would want to be able to build the whole jdk image, including a hotspot, from the root. I don't know whether the build tools would support having a graal flavor in place of the normal hotspot. -- Tom > -----Original Message----- > From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev- > bounces at openjdk.java.net] On Behalf Of John Rose > Sent: Monday, February 18, 2013 9:31 PM > To: Christian Thalinger > Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: sharing graal experiments > > On Feb 18, 2013, at 3:28 PM, John Rose wrote: > > > On Feb 18, 2013, at 2:26 PM, Christian Thalinger > wrote: > > > >> On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: > >> > >>> Just to make sure I understand, > >>> you are saying we do not need to create a separate sumatra/sumatra- > dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will > occasionally be synced with graal/graal > >>> and graal/graal will occasionally be synced with some development version > of hotspot. > >> > >> Yes, that's what I thought would work best. Not sure if John has other > plans. > > > > This will work. It does not conflict with any other use of sumatra-dev > that I am envisioning. > > > > The plan of record for sumatra-dev is here: > > https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo > > > > I have only one hesitation: This move, of incorporating an advanced > development project like Graal, can be done for at most one repo. Is there > any other OpenJDK repo. that we would want to incorporate? I think not. If > it were 12 months ago, we might want to tie more closely to > lambda/collections repos. But there is no circumstance like that today. > What do you think? > > One more thought: How about if we have graal/graal copied into sumatra- > dev/graal, keeping the existing copy of jdk8/hotspot also. > > Upside: There will always be a known-good snapshot of the whole jdk8/* > forest, and builds will be known to work modulo local changes (whether on > branches or not). > > For graal-based experiments we would expect developers to remove the "stock" > hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot). > > Downsides: Redundancy (although the hotspot and graal repos would be near > duplicates). Uncertainty as to where to host branches (stock hotspot vs. > graal). > > - John From thomas.wuerthinger at oracle.com Tue Feb 19 09:26:25 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 19 Feb 2013 09:26:25 -0800 Subject: sharing graal experiments In-Reply-To: References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> Message-ID: Tom, The graal repository contains a normal hotspot version. For building the plain hotspot version, there would not need to be any updates to the build tools. Only if building the Java sources of Graal should be included, there would have to be changes. - thomas On Feb 19, 2013, at 8:02 AM, "Deneau, Tom" wrote: > I agree with John's hesitation. > I would want to be able to build the whole jdk image, including a hotspot, from the root. > I don't know whether the build tools would support having a graal flavor in place of the normal hotspot. > > -- Tom > >> -----Original Message----- >> From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev- >> bounces at openjdk.java.net] On Behalf Of John Rose >> Sent: Monday, February 18, 2013 9:31 PM >> To: Christian Thalinger >> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >> Subject: Re: sharing graal experiments >> >> On Feb 18, 2013, at 3:28 PM, John Rose wrote: >> >>> On Feb 18, 2013, at 2:26 PM, Christian Thalinger >> wrote: >>> >>>> On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: >>>> >>>>> Just to make sure I understand, >>>>> you are saying we do not need to create a separate sumatra/sumatra- >> dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will >> occasionally be synced with graal/graal >>>>> and graal/graal will occasionally be synced with some development version >> of hotspot. >>>> >>>> Yes, that's what I thought would work best. Not sure if John has other >> plans. >>> >>> This will work. It does not conflict with any other use of sumatra-dev >> that I am envisioning. >>> >>> The plan of record for sumatra-dev is here: >>> https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo >>> >>> I have only one hesitation: This move, of incorporating an advanced >> development project like Graal, can be done for at most one repo. Is there >> any other OpenJDK repo. that we would want to incorporate? I think not. If >> it were 12 months ago, we might want to tie more closely to >> lambda/collections repos. But there is no circumstance like that today. >> What do you think? >> >> One more thought: How about if we have graal/graal copied into sumatra- >> dev/graal, keeping the existing copy of jdk8/hotspot also. >> >> Upside: There will always be a known-good snapshot of the whole jdk8/* >> forest, and builds will be known to work modulo local changes (whether on >> branches or not). >> >> For graal-based experiments we would expect developers to remove the "stock" >> hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot). >> >> Downsides: Redundancy (although the hotspot and graal repos would be near >> duplicates). Uncertainty as to where to host branches (stock hotspot vs. >> graal). >> >> - John > From christian.thalinger at oracle.com Tue Feb 19 11:35:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Feb 2013 11:35:20 -0800 Subject: sharing graal experiments In-Reply-To: References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> Message-ID: On Feb 19, 2013, at 9:26 AM, Thomas Wuerthinger wrote: > Tom, > > The graal repository contains a normal hotspot version. For building the plain hotspot version, there would not need to be any updates to the build tools. Only if building the Java sources of Graal should be included, there would have to be changes. As Thomas already said you can build a stock (non-graal) HotSpot out of the graal repository. Another thing I mentioned to Thomas yesterday is that we probably need some Makefile or ant build.xml that builds us Graal into a graal.jar on command line. The existing mx script might be nice for developing on you own laptop/workstation but when it comes to integrated testing it might be difficult to get the required Python version installed on all machines. -- Chris > > - thomas > > On Feb 19, 2013, at 8:02 AM, "Deneau, Tom" wrote: > >> I agree with John's hesitation. >> I would want to be able to build the whole jdk image, including a hotspot, from the root. >> I don't know whether the build tools would support having a graal flavor in place of the normal hotspot. >> >> -- Tom >> >>> -----Original Message----- >>> From: sumatra-dev-bounces at openjdk.java.net [mailto:sumatra-dev- >>> bounces at openjdk.java.net] On Behalf Of John Rose >>> Sent: Monday, February 18, 2013 9:31 PM >>> To: Christian Thalinger >>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>> Subject: Re: sharing graal experiments >>> >>> On Feb 18, 2013, at 3:28 PM, John Rose wrote: >>> >>>> On Feb 18, 2013, at 2:26 PM, Christian Thalinger >>> wrote: >>>> >>>>> On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" wrote: >>>>> >>>>>> Just to make sure I understand, >>>>>> you are saying we do not need to create a separate sumatra/sumatra- >>> dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will >>> occasionally be synced with graal/graal >>>>>> and graal/graal will occasionally be synced with some development version >>> of hotspot. >>>>> >>>>> Yes, that's what I thought would work best. Not sure if John has other >>> plans. >>>> >>>> This will work. It does not conflict with any other use of sumatra-dev >>> that I am envisioning. >>>> >>>> The plan of record for sumatra-dev is here: >>>> https://wikis.oracle.com/display/HotSpotInternals/SumatraRepositoryInfo >>>> >>>> I have only one hesitation: This move, of incorporating an advanced >>> development project like Graal, can be done for at most one repo. Is there >>> any other OpenJDK repo. that we would want to incorporate? I think not. If >>> it were 12 months ago, we might want to tie more closely to >>> lambda/collections repos. But there is no circumstance like that today. >>> What do you think? >>> >>> One more thought: How about if we have graal/graal copied into sumatra- >>> dev/graal, keeping the existing copy of jdk8/hotspot also. >>> >>> Upside: There will always be a known-good snapshot of the whole jdk8/* >>> forest, and builds will be known to work modulo local changes (whether on >>> branches or not). >>> >>> For graal-based experiments we would expect developers to remove the "stock" >>> hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot). >>> >>> Downsides: Redundancy (although the hotspot and graal repos would be near >>> duplicates). Uncertainty as to where to host branches (stock hotspot vs. >>> graal). >>> >>> - John >> > From john.r.rose at oracle.com Wed Feb 20 17:45:37 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 20 Feb 2013 17:45:37 -0800 Subject: sharing graal experiments In-Reply-To: References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <1B79C840-FDD9-4B0D-9310-B0BB76871E1A@oracle.com> Message-ID: On Feb 19, 2013, at 7:30 AM, "Deneau, Tom" wrote: > so will someone be pulling from graal into Sumatra-dev/hotspot then to bring them in sync? Yes, "someone" meaning one or more Sumatra committers. We'll have to agree on a schedule and probably a rotating gatekeeper duty. ? John From john.r.rose at oracle.com Wed Feb 20 17:48:35 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 20 Feb 2013 17:48:35 -0800 Subject: sharing graal experiments In-Reply-To: <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> Message-ID: On Feb 18, 2013, at 7:30 PM, John Rose wrote: > One more thought: How about if we have graal/graal copied into sumatra-dev/graal, keeping the existing copy of jdk8/hotspot also. > > Upside: There will always be a known-good snapshot of the whole jdk8/* forest, and builds will be known to work modulo local changes (whether on branches or not). > > For graal-based experiments we would expect developers to remove the "stock" hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot). > > Downsides: Redundancy (although the hotspot and graal repos would be near duplicates). Uncertainty as to where to host branches (stock hotspot vs. graal). Having slept on this idea, I like it. We'll have a "matched set" of jdk8, plus graal. We'll need a custom build procedure that will take the hotspot sources from graal instead of the standard jdk8/hotspot. http://hg.openjdk.java.net/sumatra/sumatra-dev/{jdk,hotspot,...} http://hg.openjdk.java.net/sumatra/sumatra-dev/graal http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch Any objections to making the graal repo this way? ? John From christian.thalinger at oracle.com Thu Feb 21 11:33:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Feb 2013 11:33:59 -0800 Subject: sharing graal experiments In-Reply-To: References: <1B2538FB-0D04-4EDF-B3E5-748EB956FA8F@oracle.com> <4C87B3DD-4DEB-4DB2-B258-6DB6A3C63F8C@oracle.com> <5ED3D45F-180E-4054-8DB1-DD444AA5FF91@oracle.com> <6F7B768D-5A2F-4E87-BCD7-001F25E670C3@oracle.com> <562A1D12-1615-42A0-ACC7-6B2090A4CAF2@oracle.com> Message-ID: On Feb 20, 2013, at 5:48 PM, John Rose wrote: > On Feb 18, 2013, at 7:30 PM, John Rose wrote: > >> One more thought: How about if we have graal/graal copied into sumatra-dev/graal, keeping the existing copy of jdk8/hotspot also. >> >> Upside: There will always be a known-good snapshot of the whole jdk8/* forest, and builds will be known to work modulo local changes (whether on branches or not). >> >> For graal-based experiments we would expect developers to remove the "stock" hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot). >> >> Downsides: Redundancy (although the hotspot and graal repos would be near duplicates). Uncertainty as to where to host branches (stock hotspot vs. graal). > > Having slept on this idea, I like it. We'll have a "matched set" of jdk8, plus graal. We'll need a custom build procedure that will take the hotspot sources from graal instead of the standard jdk8/hotspot. > > http://hg.openjdk.java.net/sumatra/sumatra-dev/{jdk,hotspot,...} > http://hg.openjdk.java.net/sumatra/sumatra-dev/graal > http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch > > Any objections to making the graal repo this way? Not an objection but the graal repository should always be able to build stock hotspot. So when we pull the whole jdk8 forest we also get the latest hotspot changes into sumatra-dev/hotspot (which is a clone of graal/graal). -- Chris > > ? John From thomas.wuerthinger at oracle.com Thu Feb 21 15:29:38 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 21 Feb 2013 15:29:38 -0800 Subject: PTX example Message-ID: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> Vasanth, I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). - thomas running tests in com.oracle.graal.compiler.ptx.test JUnit version 4.8 .0: int .entry test1Snippet ( .param .u32 param0 ) { .reg .pred %p; .reg .u32 %r<16>; L87: mov.s32 %r0, %r6; add.s32 %r0, %r0, 1; exit; } result=com.oracle.graal.api.code.CompilationResult at 665df3c6 Time: 0.03 OK (1 test) From christian.thalinger at oracle.com Thu Feb 21 18:42:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Feb 2013 18:42:06 -0800 Subject: PTX example In-Reply-To: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> Message-ID: On Feb 21, 2013, at 3:29 PM, Thomas Wuerthinger wrote: > Vasanth, > > I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". > Great! Thanks. -- Chris > Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). > > - thomas > > running tests in com.oracle.graal.compiler.ptx.test > JUnit version 4.8 > .0: int > .entry test1Snippet ( > .param .u32 param0 > ) { > .reg .pred %p; > .reg .u32 %r<16>; > L87: > mov.s32 %r0, %r6; > add.s32 %r0, %r0, 1; > exit; > } > > result=com.oracle.graal.api.code.CompilationResult at 665df3c6 > > Time: 0.03 > > OK (1 test) From Vasanth.Venkatachalam at amd.com Fri Feb 22 09:06:37 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 22 Feb 2013 17:06:37 +0000 Subject: PTX example In-Reply-To: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Hi Thomas, Thanks for this update. I will test your example as soon as I can. Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? Vasanth -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Thursday, February 21, 2013 5:30 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: PTX example Vasanth, I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). - thomas running tests in com.oracle.graal.compiler.ptx.test JUnit version 4.8 .0: int .entry test1Snippet ( .param .u32 param0 ) { .reg .pred %p; .reg .u32 %r<16>; L87: mov.s32 %r0, %r6; add.s32 %r0, %r0, 1; exit; } result=com.oracle.graal.api.code.CompilationResult at 665df3c6 Time: 0.03 OK (1 test) From thomas.wuerthinger at oracle.com Fri Feb 22 10:45:02 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 22 Feb 2013 10:45:02 -0800 Subject: PTX example In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Message-ID: There is no global flag as there could be any number of Graal instances running each targeting a different ISA. In the unit test example, I create a new instance of the type PTXBackend in the method BasicPTXTest.test. This defines the configuration object that specifies the way code is generated by Graal. In general, you can take a look at the classes with "PTX" or the packages with "ptx" in the name to see what has been added for the new ISA. We will do some further refactorings and simplifications as we learn more about the requirements of GPU architectures. - thomas On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: > Hi Thomas, > > Thanks for this update. I will test your example as soon as I can. > > Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? > > Vasanth > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Thursday, February 21, 2013 5:30 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: PTX example > > Vasanth, > > I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". > > Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). > > - thomas > > running tests in com.oracle.graal.compiler.ptx.test > JUnit version 4.8 > .0: int > .entry test1Snippet ( > .param .u32 param0 > ) { > .reg .pred %p; > .reg .u32 %r<16>; > L87: > mov.s32 %r0, %r6; > add.s32 %r0, %r0, 1; > exit; > } > > result=com.oracle.graal.api.code.CompilationResult at 665df3c6 > > Time: 0.03 > > OK (1 test) > From christian.thalinger at oracle.com Fri Feb 22 10:59:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 10:59:09 -0800 Subject: PTX example In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Message-ID: On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: > Hi Thomas, > > Thanks for this update. I will test your example as soon as I can. > > Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java @@ -141,7 +159,21 @@ HotSpotBackend backend = createBackend(); GraalOptions.StackShadowPages = config.stackShadowPages; - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); + // TODO GraalRuntime needs to support multiple compilers + { + //protected TargetDescription createTarget() { + final int wordSize = 8; + final int stackFrameAlignment = 16; + final int stackBias = 0; + final int implicitNullCheckLimit = 4096; + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); + + //protected HotSpotBackend createBackend() { + Backend ptxbackend = new PTXBackend(getRuntime(), target); + + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); + } if (GraalOptions.CacheGraphs) { cache = new HotSpotGraphCache(); } -- Chris > > Vasanth > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Thursday, February 21, 2013 5:30 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: PTX example > > Vasanth, > > I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". > > Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). > > - thomas > > running tests in com.oracle.graal.compiler.ptx.test > JUnit version 4.8 > .0: int > .entry test1Snippet ( > .param .u32 param0 > ) { > .reg .pred %p; > .reg .u32 %r<16>; > L87: > mov.s32 %r0, %r6; > add.s32 %r0, %r0, 1; > exit; > } > > result=com.oracle.graal.api.code.CompilationResult at 665df3c6 > > Time: 0.03 > > OK (1 test) > From thomas.wuerthinger at oracle.com Fri Feb 22 11:05:35 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 22 Feb 2013 11:05:35 -0800 Subject: PTX example In-Reply-To: References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Message-ID: Yes, Graal only supports one instance that is used for compiling the methods that are scheduled by HotSpot when running Graal as the default compiler for HotSpot. However, in case Graal is running in "hosted mode", you can have any number of instances, and you can explicitly invoke the compiler with a specific backend as shown in the unit test. - thomas On Feb 22, 2013, at 10:59 AM, Christian Thalinger wrote: > > On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: > >> Hi Thomas, >> >> Thanks for this update. I will test your example as soon as I can. >> >> Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? > > Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: > > diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > @@ -141,7 +159,21 @@ > > HotSpotBackend backend = createBackend(); > GraalOptions.StackShadowPages = config.stackShadowPages; > - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); > +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); > + // TODO GraalRuntime needs to support multiple compilers > + { > + //protected TargetDescription createTarget() { > + final int wordSize = 8; > + final int stackFrameAlignment = 16; > + final int stackBias = 0; > + final int implicitNullCheckLimit = 4096; > + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); > + > + //protected HotSpotBackend createBackend() { > + Backend ptxbackend = new PTXBackend(getRuntime(), target); > + > + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); > + } > if (GraalOptions.CacheGraphs) { > cache = new HotSpotGraphCache(); > } > > -- Chris > >> >> Vasanth >> >> -----Original Message----- >> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >> Sent: Thursday, February 21, 2013 5:30 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: PTX example >> >> Vasanth, >> >> I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". >> >> Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). >> >> - thomas >> >> running tests in com.oracle.graal.compiler.ptx.test >> JUnit version 4.8 >> .0: int >> .entry test1Snippet ( >> .param .u32 param0 >> ) { >> .reg .pred %p; >> .reg .u32 %r<16>; >> L87: >> mov.s32 %r0, %r6; >> add.s32 %r0, %r0, 1; >> exit; >> } >> >> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 >> >> Time: 0.03 >> >> OK (1 test) >> > From christian.thalinger at oracle.com Fri Feb 22 11:09:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 11:09:16 -0800 Subject: PTX example In-Reply-To: References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Message-ID: <319DCEFD-5ED2-4968-AE4B-FF2DFB0AF81B@oracle.com> On Feb 22, 2013, at 11:05 AM, Thomas Wuerthinger wrote: > Yes, Graal only supports one instance that is used for compiling the methods that are scheduled by HotSpot when running Graal as the default compiler for HotSpot. However, in case Graal is running in "hosted mode", you can have any number of instances, and you can explicitly invoke the compiler with a specific backend as shown in the unit test. Right. Maybe I wasn't clear enough. I just wanted to throw out this piece of code because I don't know what exactly Vasanth is trying to do. -- Chris > > - thomas > > On Feb 22, 2013, at 10:59 AM, Christian Thalinger wrote: > >> >> On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Thomas, >>> >>> Thanks for this update. I will test your example as soon as I can. >>> >>> Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? >> >> Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: >> >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> @@ -141,7 +159,21 @@ >> >> HotSpotBackend backend = createBackend(); >> GraalOptions.StackShadowPages = config.stackShadowPages; >> - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >> +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >> + // TODO GraalRuntime needs to support multiple compilers >> + { >> + //protected TargetDescription createTarget() { >> + final int wordSize = 8; >> + final int stackFrameAlignment = 16; >> + final int stackBias = 0; >> + final int implicitNullCheckLimit = 4096; >> + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); >> + >> + //protected HotSpotBackend createBackend() { >> + Backend ptxbackend = new PTXBackend(getRuntime(), target); >> + >> + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); >> + } >> if (GraalOptions.CacheGraphs) { >> cache = new HotSpotGraphCache(); >> } >> >> -- Chris >> >>> >>> Vasanth >>> >>> -----Original Message----- >>> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >>> Sent: Thursday, February 21, 2013 5:30 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>> Subject: PTX example >>> >>> Vasanth, >>> >>> I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". >>> >>> Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). >>> >>> - thomas >>> >>> running tests in com.oracle.graal.compiler.ptx.test >>> JUnit version 4.8 >>> .0: int >>> .entry test1Snippet ( >>> .param .u32 param0 >>> ) { >>> .reg .pred %p; >>> .reg .u32 %r<16>; >>> L87: >>> mov.s32 %r0, %r6; >>> add.s32 %r0, %r0, 1; >>> exit; >>> } >>> >>> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 >>> >>> Time: 0.03 >>> >>> OK (1 test) >>> >> > From Vasanth.Venkatachalam at amd.com Fri Feb 22 11:14:27 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 22 Feb 2013 19:14:27 +0000 Subject: PTX example In-Reply-To: <319DCEFD-5ED2-4968-AE4B-FF2DFB0AF81B@oracle.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> <319DCEFD-5ED2-4968-AE4B-FF2DFB0AF81B@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A7329F9118@sausexdag06.amd.com> Hi Christian, Just to clarify what I'm doing. I have a partial implementation of an HSAIL assembler which I'm trying to get up and running. I've made the changes to generate the Assembler file (using your tool), and the LIR file (which invokes the appropriate assembler routines for each Node). I want to be able to run a small demo app (e.g., add two numbers) and see the HSAIL code generated. Since the work required for each ISA is pretty similar, I was going to use the test case that Thomas checked in to get a better feel what further work I would need to do to take my HSAIL prototype running. I'll probably want to write a test case similar to yours but generating HSAIL code. Vasanth -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Friday, February 22, 2013 1:09 PM To: Thomas Wuerthinger Cc: Venkatachalam, Vasanth; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: PTX example On Feb 22, 2013, at 11:05 AM, Thomas Wuerthinger wrote: > Yes, Graal only supports one instance that is used for compiling the methods that are scheduled by HotSpot when running Graal as the default compiler for HotSpot. However, in case Graal is running in "hosted mode", you can have any number of instances, and you can explicitly invoke the compiler with a specific backend as shown in the unit test. Right. Maybe I wasn't clear enough. I just wanted to throw out this piece of code because I don't know what exactly Vasanth is trying to do. -- Chris > > - thomas > > On Feb 22, 2013, at 10:59 AM, Christian Thalinger wrote: > >> >> On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Thomas, >>> >>> Thanks for this update. I will test your example as soon as I can. >>> >>> Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? >> >> Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: >> >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> @@ -141,7 +159,21 @@ >> >> HotSpotBackend backend = createBackend(); >> GraalOptions.StackShadowPages = config.stackShadowPages; >> - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >> +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >> + // TODO GraalRuntime needs to support multiple compilers >> + { >> + //protected TargetDescription createTarget() { >> + final int wordSize = 8; >> + final int stackFrameAlignment = 16; >> + final int stackBias = 0; >> + final int implicitNullCheckLimit = 4096; >> + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); >> + >> + //protected HotSpotBackend createBackend() { >> + Backend ptxbackend = new PTXBackend(getRuntime(), target); >> + >> + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); >> + } >> if (GraalOptions.CacheGraphs) { >> cache = new HotSpotGraphCache(); >> } >> >> -- Chris >> >>> >>> Vasanth >>> >>> -----Original Message----- >>> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >>> Sent: Thursday, February 21, 2013 5:30 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>> Subject: PTX example >>> >>> Vasanth, >>> >>> I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". >>> >>> Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). >>> >>> - thomas >>> >>> running tests in com.oracle.graal.compiler.ptx.test >>> JUnit version 4.8 >>> .0: int >>> .entry test1Snippet ( >>> .param .u32 param0 >>> ) { >>> .reg .pred %p; >>> .reg .u32 %r<16>; >>> L87: >>> mov.s32 %r0, %r6; >>> add.s32 %r0, %r0, 1; >>> exit; >>> } >>> >>> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 >>> >>> Time: 0.03 >>> >>> OK (1 test) >>> >> > From christian.thalinger at oracle.com Fri Feb 22 11:25:18 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 11:25:18 -0800 Subject: PTX example In-Reply-To: References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Message-ID: On Feb 22, 2013, at 11:05 AM, Thomas Wuerthinger wrote: > Yes, Graal only supports one instance that is used for compiling the methods that are scheduled by HotSpot when running Graal as the default compiler for HotSpot. However, in case Graal is running in "hosted mode", you can have any number of instances, and you can explicitly invoke the compiler with a specific backend as shown in the unit test. Btw. I had that problem already last week. When I'm trying to run the compiler directly I get this exception: java.lang.IllegalAccessError: Runtime does not expose required capability com.oracle.graal.nodes.spi.GraalCodeCacheProvider at com.oracle.graal.api.runtime.Graal.getRequiredCapability(Graal.java:57) at com.oracle.graal.compiler.test.GraalCompilerTest.(GraalCompilerTest.java:76) at com.oracle.graal.compiler.ptx.test.BasicPTXTest.(BasicPTXTest.java:42) -- Chris > > - thomas > > On Feb 22, 2013, at 10:59 AM, Christian Thalinger wrote: > >> >> On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Thomas, >>> >>> Thanks for this update. I will test your example as soon as I can. >>> >>> Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? >> >> Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: >> >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >> @@ -141,7 +159,21 @@ >> >> HotSpotBackend backend = createBackend(); >> GraalOptions.StackShadowPages = config.stackShadowPages; >> - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >> +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >> + // TODO GraalRuntime needs to support multiple compilers >> + { >> + //protected TargetDescription createTarget() { >> + final int wordSize = 8; >> + final int stackFrameAlignment = 16; >> + final int stackBias = 0; >> + final int implicitNullCheckLimit = 4096; >> + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); >> + >> + //protected HotSpotBackend createBackend() { >> + Backend ptxbackend = new PTXBackend(getRuntime(), target); >> + >> + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); >> + } >> if (GraalOptions.CacheGraphs) { >> cache = new HotSpotGraphCache(); >> } >> >> -- Chris >> >>> >>> Vasanth >>> >>> -----Original Message----- >>> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >>> Sent: Thursday, February 21, 2013 5:30 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>> Subject: PTX example >>> >>> Vasanth, >>> >>> I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". >>> >>> Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). >>> >>> - thomas >>> >>> running tests in com.oracle.graal.compiler.ptx.test >>> JUnit version 4.8 >>> .0: int >>> .entry test1Snippet ( >>> .param .u32 param0 >>> ) { >>> .reg .pred %p; >>> .reg .u32 %r<16>; >>> L87: >>> mov.s32 %r0, %r6; >>> add.s32 %r0, %r0, 1; >>> exit; >>> } >>> >>> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 >>> >>> Time: 0.03 >>> >>> OK (1 test) >>> >> > From thomas.wuerthinger at oracle.com Fri Feb 22 11:34:50 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 22 Feb 2013 11:34:50 -0800 Subject: PTX example In-Reply-To: References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> Message-ID: <805138C3-91DD-42A3-ACAE-6ABD07D25122@oracle.com> The error below indicates that you are running on a plain HotSpot VM version that does not have Graal enabled. You might be missing "./mx.sh --vm server build" for compiling the HotSpot server version that includes the Graal hooks. - thomas On Feb 22, 2013, at 11:25 AM, Christian Thalinger wrote: > > On Feb 22, 2013, at 11:05 AM, Thomas Wuerthinger wrote: > >> Yes, Graal only supports one instance that is used for compiling the methods that are scheduled by HotSpot when running Graal as the default compiler for HotSpot. However, in case Graal is running in "hosted mode", you can have any number of instances, and you can explicitly invoke the compiler with a specific backend as shown in the unit test. > > Btw. I had that problem already last week. When I'm trying to run the compiler directly I get this exception: > > java.lang.IllegalAccessError: Runtime does not expose required capability com.oracle.graal.nodes.spi.GraalCodeCacheProvider > at com.oracle.graal.api.runtime.Graal.getRequiredCapability(Graal.java:57) > at com.oracle.graal.compiler.test.GraalCompilerTest.(GraalCompilerTest.java:76) > at com.oracle.graal.compiler.ptx.test.BasicPTXTest.(BasicPTXTest.java:42) > > -- Chris > >> >> - thomas >> >> On Feb 22, 2013, at 10:59 AM, Christian Thalinger wrote: >> >>> >>> On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi Thomas, >>>> >>>> Thanks for this update. I will test your example as soon as I can. >>>> >>>> Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? >>> >>> Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: >>> >>> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >>> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >>> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >>> @@ -141,7 +159,21 @@ >>> >>> HotSpotBackend backend = createBackend(); >>> GraalOptions.StackShadowPages = config.stackShadowPages; >>> - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >>> +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >>> + // TODO GraalRuntime needs to support multiple compilers >>> + { >>> + //protected TargetDescription createTarget() { >>> + final int wordSize = 8; >>> + final int stackFrameAlignment = 16; >>> + final int stackBias = 0; >>> + final int implicitNullCheckLimit = 4096; >>> + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); >>> + >>> + //protected HotSpotBackend createBackend() { >>> + Backend ptxbackend = new PTXBackend(getRuntime(), target); >>> + >>> + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); >>> + } >>> if (GraalOptions.CacheGraphs) { >>> cache = new HotSpotGraphCache(); >>> } >>> >>> -- Chris >>> >>>> >>>> Vasanth >>>> >>>> -----Original Message----- >>>> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >>>> Sent: Thursday, February 21, 2013 5:30 PM >>>> To: Venkatachalam, Vasanth >>>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>>> Subject: PTX example >>>> >>>> Vasanth, >>>> >>>> I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". >>>> >>>> Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). >>>> >>>> - thomas >>>> >>>> running tests in com.oracle.graal.compiler.ptx.test >>>> JUnit version 4.8 >>>> .0: int >>>> .entry test1Snippet ( >>>> .param .u32 param0 >>>> ) { >>>> .reg .pred %p; >>>> .reg .u32 %r<16>; >>>> L87: >>>> mov.s32 %r0, %r6; >>>> add.s32 %r0, %r0, 1; >>>> exit; >>>> } >>>> >>>> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 >>>> >>>> Time: 0.03 >>>> >>>> OK (1 test) >>>> >>> >> > From christian.thalinger at oracle.com Fri Feb 22 11:52:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 11:52:28 -0800 Subject: PTX example In-Reply-To: <805138C3-91DD-42A3-ACAE-6ABD07D25122@oracle.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> <805138C3-91DD-42A3-ACAE-6ABD07D25122@oracle.com> Message-ID: <957CDFDB-B905-4222-B540-0F189354395B@oracle.com> On Feb 22, 2013, at 11:34 AM, Thomas Wuerthinger wrote: > The error below indicates that you are running on a plain HotSpot VM version that does not have Graal enabled. Ahh, that makes sense. Thanks. -- Chris > You might be missing "./mx.sh --vm server build" for compiling the HotSpot server version that includes the Graal hooks. > > - thomas > > On Feb 22, 2013, at 11:25 AM, Christian Thalinger wrote: > >> >> On Feb 22, 2013, at 11:05 AM, Thomas Wuerthinger wrote: >> >>> Yes, Graal only supports one instance that is used for compiling the methods that are scheduled by HotSpot when running Graal as the default compiler for HotSpot. However, in case Graal is running in "hosted mode", you can have any number of instances, and you can explicitly invoke the compiler with a specific backend as shown in the unit test. >> >> Btw. I had that problem already last week. When I'm trying to run the compiler directly I get this exception: >> >> java.lang.IllegalAccessError: Runtime does not expose required capability com.oracle.graal.nodes.spi.GraalCodeCacheProvider >> at com.oracle.graal.api.runtime.Graal.getRequiredCapability(Graal.java:57) >> at com.oracle.graal.compiler.test.GraalCompilerTest.(GraalCompilerTest.java:76) >> at com.oracle.graal.compiler.ptx.test.BasicPTXTest.(BasicPTXTest.java:42) >> >> -- Chris >> >>> >>> - thomas >>> >>> On Feb 22, 2013, at 10:59 AM, Christian Thalinger wrote: >>> >>>> >>>> On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> Thanks for this update. I will test your example as soon as I can. >>>>> >>>>> Can you explain how to switch the ISA that Graal generates code for? For example, if I wanted to switch from using x86 as the backend(the default) to using SPARC, PTX or my own ISA, what would I have to modify? Is there a command line parameter (to be applied at build or run time) for specifying the target ISA? >>>> >>>> Since Graal only supports one compiler instance right now you have to instantiate the right GraalCompiler. Something hacky like this: >>>> >>>> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >>>> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >>>> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java >>>> @@ -141,7 +159,21 @@ >>>> >>>> HotSpotBackend backend = createBackend(); >>>> GraalOptions.StackShadowPages = config.stackShadowPages; >>>> - compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >>>> +// compiler = new GraalCompiler(getRuntime(), getTarget(), backend); >>>> + // TODO GraalRuntime needs to support multiple compilers >>>> + { >>>> + //protected TargetDescription createTarget() { >>>> + final int wordSize = 8; >>>> + final int stackFrameAlignment = 16; >>>> + final int stackBias = 0; >>>> + final int implicitNullCheckLimit = 4096; >>>> + TargetDescription target = new TargetDescription(new PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, config.vmPageSize, wordSize, true, true); >>>> + >>>> + //protected HotSpotBackend createBackend() { >>>> + Backend ptxbackend = new PTXBackend(getRuntime(), target); >>>> + >>>> + compiler = new GraalCompiler(getRuntime(), target, ptxbackend); >>>> + } >>>> if (GraalOptions.CacheGraphs) { >>>> cache = new HotSpotGraphCache(); >>>> } >>>> >>>> -- Chris >>>> >>>>> >>>>> Vasanth >>>>> >>>>> -----Original Message----- >>>>> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >>>>> Sent: Thursday, February 21, 2013 5:30 PM >>>>> To: Venkatachalam, Vasanth >>>>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>>>> Subject: PTX example >>>>> >>>>> Vasanth, >>>>> >>>>> I've committed and pushed the basic PTX example. After running "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" you should get the output I pasted in below. The "--vm server" flag means that you are using Graal in hosted mode running on top of HotSpot's server compiler. You can also start the unit test from within Eclipse after generating Eclipse project files with "./mx.sh ideinit". >>>>> >>>>> Note that the example is still very basic and we'll need more restructuring of the compiler backend to nicely work with GPU architectures. But we have to start with *something* ;). >>>>> >>>>> - thomas >>>>> >>>>> running tests in com.oracle.graal.compiler.ptx.test >>>>> JUnit version 4.8 >>>>> .0: int >>>>> .entry test1Snippet ( >>>>> .param .u32 param0 >>>>> ) { >>>>> .reg .pred %p; >>>>> .reg .u32 %r<16>; >>>>> L87: >>>>> mov.s32 %r0, %r6; >>>>> add.s32 %r0, %r0, 1; >>>>> exit; >>>>> } >>>>> >>>>> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 >>>>> >>>>> Time: 0.03 >>>>> >>>>> OK (1 test) >>>>> >>>> >>> >> > From gilwooden at gmail.com Fri Feb 22 23:24:38 2013 From: gilwooden at gmail.com (Gilles Duboscq) Date: Sat, 23 Feb 2013 08:24:38 +0100 Subject: PTX example In-Reply-To: <957CDFDB-B905-4222-B540-0F189354395B@oracle.com> References: <3DFB0DAD-5996-4000-BD27-B6D404CD58DE@oracle.com> <5DD1503F815BD14889DC81D28643E3A7329F9031@sausexdag06.amd.com> <805138C3-91DD-42A3-ACAE-6ABD07D25122@oracle.com> <957CDFDB-B905-4222-B540-0F189354395B@oracle.com> Message-ID: I think we should strip out the original server vm when we copy the jdk directory in mx so that if you try to do --vm server without building it first you get an error. If you really need the original server vm you can then still do --vm server0 On Fri, Feb 22, 2013 at 8:52 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Feb 22, 2013, at 11:34 AM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > The error below indicates that you are running on a plain HotSpot VM > version that does not have Graal enabled. > > Ahh, that makes sense. Thanks. -- Chris > > > You might be missing "./mx.sh --vm server build" for compiling the > HotSpot server version that includes the Graal hooks. > > > > - thomas > > > > On Feb 22, 2013, at 11:25 AM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > > > >> > >> On Feb 22, 2013, at 11:05 AM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > >> > >>> Yes, Graal only supports one instance that is used for compiling the > methods that are scheduled by HotSpot when running Graal as the default > compiler for HotSpot. However, in case Graal is running in "hosted mode", > you can have any number of instances, and you can explicitly invoke the > compiler with a specific backend as shown in the unit test. > >> > >> Btw. I had that problem already last week. When I'm trying to run the > compiler directly I get this exception: > >> > >> java.lang.IllegalAccessError: Runtime does not expose required > capability com.oracle.graal.nodes.spi.GraalCodeCacheProvider > >> at > com.oracle.graal.api.runtime.Graal.getRequiredCapability(Graal.java:57) > >> at > com.oracle.graal.compiler.test.GraalCompilerTest.(GraalCompilerTest.java:76) > >> at > com.oracle.graal.compiler.ptx.test.BasicPTXTest.(BasicPTXTest.java:42) > >> > >> -- Chris > >> > >>> > >>> - thomas > >>> > >>> On Feb 22, 2013, at 10:59 AM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > >>> > >>>> > >>>> On Feb 22, 2013, at 9:06 AM, "Venkatachalam, Vasanth" < > Vasanth.Venkatachalam at amd.com> wrote: > >>>> > >>>>> Hi Thomas, > >>>>> > >>>>> Thanks for this update. I will test your example as soon as I can. > >>>>> > >>>>> Can you explain how to switch the ISA that Graal generates code for? > For example, if I wanted to switch from using x86 as the backend(the > default) to using SPARC, PTX or my own ISA, what would I have to modify? Is > there a command line parameter (to be applied at build or run time) for > specifying the target ISA? > >>>> > >>>> Since Graal only supports one compiler instance right now you have to > instantiate the right GraalCompiler. Something hacky like this: > >>>> > >>>> diff --git > a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > >>>> --- > a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > >>>> +++ > b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java > >>>> @@ -141,7 +159,21 @@ > >>>> > >>>> HotSpotBackend backend = createBackend(); > >>>> GraalOptions.StackShadowPages = config.stackShadowPages; > >>>> - compiler = new GraalCompiler(getRuntime(), getTarget(), > backend); > >>>> +// compiler = new GraalCompiler(getRuntime(), getTarget(), > backend); > >>>> + // TODO GraalRuntime needs to support multiple compilers > >>>> + { > >>>> + //protected TargetDescription createTarget() { > >>>> + final int wordSize = 8; > >>>> + final int stackFrameAlignment = 16; > >>>> + final int stackBias = 0; > >>>> + final int implicitNullCheckLimit = 4096; > >>>> + TargetDescription target = new TargetDescription(new > PTX(), true, stackFrameAlignment, stackBias, implicitNullCheckLimit, > config.vmPageSize, wordSize, true, true); > >>>> + > >>>> + //protected HotSpotBackend createBackend() { > >>>> + Backend ptxbackend = new PTXBackend(getRuntime(), > target); > >>>> + > >>>> + compiler = new GraalCompiler(getRuntime(), target, > ptxbackend); > >>>> + } > >>>> if (GraalOptions.CacheGraphs) { > >>>> cache = new HotSpotGraphCache(); > >>>> } > >>>> > >>>> -- Chris > >>>> > >>>>> > >>>>> Vasanth > >>>>> > >>>>> -----Original Message----- > >>>>> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > >>>>> Sent: Thursday, February 21, 2013 5:30 PM > >>>>> To: Venkatachalam, Vasanth > >>>>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >>>>> Subject: PTX example > >>>>> > >>>>> Vasanth, > >>>>> > >>>>> I've committed and pushed the basic PTX example. After running > "./mx.sh --vm server build" and "./mx.sh --vm server unittest BasicPTXTest" > you should get the output I pasted in below. The "--vm server" flag means > that you are using Graal in hosted mode running on top of HotSpot's server > compiler. You can also start the unit test from within Eclipse after > generating Eclipse project files with "./mx.sh ideinit". > >>>>> > >>>>> Note that the example is still very basic and we'll need more > restructuring of the compiler backend to nicely work with GPU > architectures. But we have to start with *something* ;). > >>>>> > >>>>> - thomas > >>>>> > >>>>> running tests in com.oracle.graal.compiler.ptx.test > >>>>> JUnit version 4.8 > >>>>> .0: int > >>>>> .entry test1Snippet ( > >>>>> .param .u32 param0 > >>>>> ) { > >>>>> .reg .pred %p; > >>>>> .reg .u32 %r<16>; > >>>>> L87: > >>>>> mov.s32 %r0, %r6; > >>>>> add.s32 %r0, %r0, 1; > >>>>> exit; > >>>>> } > >>>>> > >>>>> result=com.oracle.graal.api.code.CompilationResult at 665df3c6 > >>>>> > >>>>> Time: 0.03 > >>>>> > >>>>> OK (1 test) > >>>>> > >>>> > >>> > >> > > > >