Java Local annotations and Graal Inlining

[Juan Fumero]

Hi Doug, 
   You are right. I got confused with some of the tooling in
Manchester. We will go for parsing with the ASM library.

Regards,
Juan

On Mon, 2018-05-28 at 17:40 +0200, Doug Simon wrote:
> Hi Juan,
> 
> I'm a little lost. I don't recall ResolvedJavaMethod ever having a
> getLocalAnnotations method. Standard Java reflection doesn't provide
> this either. I think you can only get at these by parsing the class
> files.
> 
> -Doug
> 
> > On 28 May 2018, at 10:14, Juan Fumero <juan.fumero at manchester.ac.uk
> > > wrote:
> > 
> > Hi all, 
> > 
> > I have a question concerning local Java annotations and the
> > inlining
> > phase in Graal. 
> > 
> > I want to get Java annotations associated with local variables
> > (runtime
> > annotations). The way we currently do is through the
> > ResolvedJavaMethod
> > and the getLocalAnnotations method (we based on Graal-0.22). I
> > wanted
> > to reproduce this example using the last Graal but this method does
> > not
> > exist anymore. 
> > 
> > Currently, we can see local annotations when we directly compile
> > the
> > method that contains the annotations. However, when the method
> > contains
> > a methodInvoke, after inlining we do not see any local annotations
> > any
> > more. Is this due to an error during inlining? 
> > 
> > To clarify, here I show you a snippet of what we are trying to do. 
> > Our goal is to associate a Graal-IR node with a Java annotation. In
> > this case, a PhiNode (i var).
> > 
> > <code>
> > @Target({ ElementType.LOCAL_VARIABLE, ElementType.TYPE})
> > @Retention(RetentionPolicy.RUNTIME)
> > public @interface Local {
> > }
> > 
> > 
> > public void foo(...) {
> >    bar(...)
> > }
> > 
> > public void bar(...) {
> >    for (@Local int i = 0, i ... ) {
> > 
> >    }
> > }
> > </code>
> > 
> > If I build the Graal-IR for the method `bar`, I see @Local for the
> > PhiNode(i var). However, when I compile the method `foo`, I can the
> > inlined loop in `foo` after inlining but I do not see @Local
> > anymore. 
> > The real code is more complicated, `foo` is from an abstract class
> > and
> > bar is directly the user code. Our compiler has to start compiling
> > from
> > method `foo`. 
> > 
> > 
> > Any pointers, suggestions or work around will be appreciated. 
> > 
> > 
> > Thanks,
> > Juan
> > 
> 
>