compiling code that has never been interpreted

[Doug Simon]

On Sep 3, 2013, at 11:12 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Can you explain briefly how a non-eager compilation is supposed to look and behave at runtime?
> For example, if the target method calls something in a class that has not yet been loaded.

Instead of a compiled call, you should see a deopt at the unresolved call site (i.e., the position of the invoke bytecode). The method will then execute in the interpreter and if it becomes (or remains) hot, it will be recompiled. This time around, the call will most likely be compiled (assuming the first deopt reflected a meaning phase change in the application).

> In our non-eager hsail compilations there was no indication that anything might be missing, but
> it's possible we weren't handling all the nodes correctly.
> 
> -- Tom
> 
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Tuesday, September 03, 2013 10:29 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: compiling code that has never been interpreted
> 
> On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Doug --
>> 
>> Thanks, yet this works.
>> What is the reason that someone would want eagerResolving turned off?
> 
> Two reasons (that I can think of):
> 
> 1. Prevent non-executed code paths causing extra class loading during compilation.
> 2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses.
> 
> -Doug
> 
>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com] 
>> Sent: Tuesday, September 03, 2013 10:00 AM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: compiling code that has never been interpreted
>> 
>> Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work.
>> 
>> On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> 
>>> For the HSAIL-based junit tests, we have the following general structure:
>>> 
>>> 1.       run a method in normal java mode
>>> 
>>> 2.       compile same method into HSAIL and dispatch
>>> 
>>> 3.       compare results
>>> 
>>> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc.  (We are compiling with the flag -G:+InlineEverything).  We are running --vm server.
>>> 
>>> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted?  Or is this not supported?
>>> 
>>> I can try to get igv graphs if needed.
>>> 
>>> -- Tom
>>> 
>> 
>> 
>> 
> 
> 
>