webrev that allows the compilation target runtime to be queried

[Thomas Wuerthinger]

I'll nominate you as an author on the Graal project. This will give you an OpenJDK account. - thomas

On Sep 3, 2013, at 5:27 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> Thomas,
> 
> I need an account to be able to upload the webrev. Did you guys ever get that sorted out? If so, can you send me the details?
> 
> Vasanth
> 
> -----Original Message-----
> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] 
> Sent: Monday, September 02, 2013 8:05 AM
> To: Venkatachalam, Vasanth
> Cc: graal-dev at openjdk.java.net
> Subject: Re: webrev that allows the compilation target runtime to be queried
> 
> Vasanth,
> 
> Can you please upload the webrev/patch and send a link to it (the mailing list drops attachments)?
> 
> Regarding the thread register: It is not a strict requirement that the current thread must always be in a certain register. One could also change Graal to load the current thread from some address on the stack whenever needed.
> 
> - thomas
> 
> On Aug 30, 2013, at 12:17 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
> 
>> Hi,
>> 
>> Graal contains some logic that calls the host runtime (x86 or Sparc) for information that is specific to the runtime that it is generating code for.
>> An example is the method HotSpotRuntimeUtils.threadRegister(), which retrieves the thread register of the host runtime.
>> This logic works when where the host runtime is the same as the runtime  that it is generating code for, but can break in cases where the two runtimes are different, such as when the JVM is running on x86 but generating code for HSAIL.
>> 
>> The attached patch provides an initial workaround that we'd like to get feedback on. This isn't the final solution but is intended to set up for a better solution later, whether that comes from us or the community. Christian, can you upload a webrev for this to the review site?
>> 
>> In detail, the patch adds some routines to a central location (we chose HotSpotGraalRuntime). These routines can be used to set the target ISA runtime at startup or to query it. If the target ISA runtime isn't set, then it defaults to the host runtime. Currently we've commented out the code (in HSAILCompilationResult) which sets the target ISA runtime, so that the default behavior of using the host runtime is preserved. However, to help people see how this is meant to work, we've modified HotSpotReplacementUtils.threadRegister( ) to query the target ISA runtime for the thread register, which again defaults to the host runtime so that there's no change in behavior.
>> 
>> We're calling this a workaround because the problem of how to handle the thread register for HSAIL requires more investigation. In HSAIL, register values don't persist across function calls. Rather, every function gets its own "localized" view of the entire register set. So there's currently no way of fixing a single register as the "thread register" and having it persist across all calls. We would have to instead inject some code for each function call that sets up the thread register for that call. The details need to be worked out.
>> 
>> With this patch (which includes some supporting changes to designate a "thread register for HSAIL), we were able to get past some Unit test failures where Graal was querying the host runtime for the thread register when we were compiling for HSAIL.
>> 
>> We'd welcome feedback and suggestions about alternative solutions.
>> 
>> Vasanth
>> 
> 
> 
>