webrev for switch statement support in HSAIL backend

[Doug Simon]

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