webrev for switch statement support in HSAIL backend

[Doug Simon]

Object pointers in compiled code is a complex issue. HotSpot (especially the GCs) treat oops in nmethods very specially. Since HSAIL kernels are only “fake” nmethods (as far as I can tell), we’ll need another mechanism for supporting oops in GPU kernels. However, for now, just stay with the current solution.

-Doug

On Nov 21, 2013, at 5:36 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Doug --
> 
> We were thinking about this as well after your questions.
> 
> Stepping back, the problem that we were trying to solve was to be able to generate code which could contain "constant" references embedded in the code but which would not need to be updated if the underlying object moved.  Using a level of indirection thru a JNI Global reference seemed like one solution.
> 
> This does not seem like an HSAIL-specific problem so maybe the best solution would be to have some support in graal itself to support this.  This support would include releasing handles if the code that uses them gets discarded.
> 
> What do you think?
> 
> -- Tom
> 
> 
> 
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon
> Sent: Thursday, November 21, 2013 10:26 AM
> To: Venkatachalam, Vasanth
> Cc: graal-dev at openjdk.java.net
> Subject: Re: webrev for switch statement support in HSAIL backend
> 
> 
> On Nov 20, 2013, at 8:08 PM, Venkatachalam, Vasanth <Vasanth.Venkatachalam at amd.com> wrote:
> 
>> Doug,
>> 
>> Answers inlined below.
>> 
>> If there are no other changes required please commit the webrev, citing Vasanth Venkatachalam as the author, with the commit message: "Adds support to the HSAIL backend for handling Java switch constructs .
>> 
>> Vasanth
>> 
>> -----Original Message-----
>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon
>> Sent: Tuesday, November 19, 2013 6:23 PM
>> To: graal-dev at openjdk.java.net
>> Subject: Re: webrev for switch statement support in HSAIL backend
>> 
>> graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java:
>> 
>> +            // Get a JNI reference handle to the object.
>> +            long refHandle = OkraUtil.getRefHandle(obj);
>> 
>> How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed.
>> 
>>> [Vasanth] OkraUtil never creates more than one JNI ref for any given object. 
>> This change isn't introducing anything new. This code has been in the assembler all along, we just extended it to remove the restriction that the Object passed as parameter to mov(Register reg, Object obj) must be an instance of Class.
> 
> Even if it has been there all along, my question/concerns still remain. This is a memory leak if the global JNI refs are not managed to reflect the object lifetimes. Worse, if the objects are Class values, it will also probably prevent class unloading.
> 
> -Doug
>