'Re: Escape Analysis and MH.invoke, MH.invokeExact'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-graal-dev
Subject:    Re: Escape Analysis and MH.invoke, MH.invokeExact
From:       Lukas Stadler <lukas.stadler () jku ! at>
Date:       2013-07-30 5:49:58
Message-ID: 9D980859-076F-4FD2-9380-A6B1EB022D78 () jku ! at
[Download RAW message or body]

Hey,

I'm going to talk to Chris (Thalinger) tomorrow, he's been working on the method \
handle implementation in Graal. I don't think this is so specific to method handles - \
it should apply to other forms of "closures" as well. Vlad also mentioned this at \
ECOOP - a higher order function should probably get a bonus when making an inlining \
decision.

- Lukas

On Jul 29, 2013, at 0:16 , Garcia Gutierrez Miguel Alfredo \
<miguelalfredo.garcia@epfl.ch> wrote:

> Lukas,
> 
> > Are you referring to the fact that the method handle itself is not actually used \
> > within the called code, because it's only used to determine what needs to be \
> > called?
> 
> Yes, that's the case I had in mind. Within that case there appear to be subcases, \
> e.g. (a) the "payload" of the MH is a direct pointer to the target method; or (b) \
> the MH contains in addition bound arguments, or in general composes other MHs. 
> > I'd have to look into how the method handle calls are actually encoded... 
> 
> I haven't looked into that aspect in Graal. Regarding the other HotSpot compilers, \
> the description of MH implementation doesn't mention an interplay with EA: \
> https://wikis.oracle.com/display/HotSpotInternals/Method+handles+and+invokedynamic 
> > do you think that it happens a lot that method handles could be escape analyzed?
> 
> Well, it's only a hunch, but the argument goes as follows:
> (1) a method P receives (via some formal) different MH instances across \
> invocations, (2) if the MH is just invoke'd or invokeExact'd and otherwise doesn't \
> escape P, (3) then P could be inlined.
> Perhaps I'm somewhat biased in that I believe the scenario above co-exists \
> frequently with two additional boosters: (4) the MH is invoked repeatedly inside P \
> (that's often the case for collection operations) (5) in spite of being inlined, no \
> DeoptimizeNode appears to be needed (assuming, or better said *hoping* that the \
> lowerings of invoke() and invokeExact() don't behave like invokevirtual) 
> That's the summary (ie, the "hunch" in words). Perhaps (4) and (5) are additional \
> bonus, which don't degrade performance even if not present. 
> 
> Miguel
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/
> 
> ________________________________________
> From: Lukas Stadler [lukas.stadler@jku.at]
> Sent: Monday, July 29, 2013 6:30 AM
> To: Garcia Gutierrez Miguel Alfredo
> Cc: graal-dev@openjdk.java.net
> Subject: Re: Escape Analysis and MH.invoke, MH.invokeExact
> 
> I'm not that familiar with the MethodHandle code, I have to admit.
> Are you referring to the fact that the method handle itself is not actually used \
> within the called code, because it's only used to determine what needs to be \
> called? I'd have to look into how the method handle calls are actually encoded... \
> do you think that it happens a lot that method handles could be escape analyzed? 
> - Lukas
> 
> On Jul 27, 2013, at 3:42 , Garcia Gutierrez Miguel Alfredo \
> <miguelalfredo.garcia@epfl.ch> wrote: 
> > Lukas,
> > 
> > Thanks for the link, that overview is quite helpful. For the moment I'm just \
> > wading through the info deluge of PEA and its interplay with inlining. 
> > I was wondering whether it could pay off to make (Partial) EA handle specially \
> > the "escaping behavior" of a MethodHandle instance wrt invoke (resp. \
> > invokeExact). From what I've seen, the receiver of an instance-method invocation \
> > is deemed method-escaping. However it appears that (conceptually) the EA analysis \
> > could special-case MH.invoke() and MH.invokeExact() callsites, by not concluding \
> > "receiver escapes" for them. Perhaps this heuristic could enable other \
> > optimizations. 
> > All of the above of course with the big disclaimer that I'm not that familiar \
> > with EA, and without knowing for sure whether an implementation of MH.invoke, \
> > MH.invokeExact could (somehow) let "this" escape. 
> > 
> > Miguel
> > --
> > Miguel Garcia
> > Swiss Federal Institute of Technology
> > EPFL - IC - LAMP1 - INR 328 - Station 14
> > CH-1015 Lausanne - Switzerland
> > http://lamp.epfl.ch/~magarcia/
> > 
> > ________________________________________
> > From: Lukas Stadler [lukas.stadler@jku.at]
> > Sent: Friday, July 26, 2013 8:24 PM
> > To: Garcia Gutierrez Miguel Alfredo
> > Cc: graal-dev@openjdk.java.net
> > Subject: Re: escapa analysis, packed objects
> > 
> > Hi Miguel,
> > 
> > unfortunately there's no documentation on Graal's partial escape analysis yet.
> > A short intro is available here: \
> > https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis I'm \
> > currently working on a publication on this topic, I'd be happy to send you a \
> > version of it as soon as it's complete enough to make sense :-) I also could give \
> > you an introduction over skype. 
> > Concerning the "structs" proposals:
> > The IBM proposal seems to be mostly about how to interact with the C world, like \
> > a convenient wrapper around sun.misc.Unsafe. I think that John Rose's proposal is \
> > more interesting, especially since the locking mechanism allows partial escape \
> > analysis to work much more efficiently. (We actually already do a similar trick \
> > for boxing operations, so we could take advantage of this mechanism pretty \
> > quickly) 
> > Much of this can be handled by the compiler, but of course it's only part of the \
> > picture. Allowing structs as return values means that this needs to be handled \
> > correctly by the interpreter, by deoptimization, by stack walking, in the debug \
> > interface, in jni code, etc. I think it's too big a task (and too many VM \
> > changes) for us to do, but once this proposal gets picked up by the hotspot team, \
> > we can quickly provide efficient support for it. 
> > - Lukas
> > 
> > On Jul 25, 2013, at 13:32 , Garcia Gutierrez Miguel Alfredo \
> > <miguelalfredo.garcia@epfl.ch> wrote: 
> > > 
> > > Hi,
> > > 
> > > Escape analysis in Graal looks interesting. Are there any publications \
> > > describing it? What I've heard about is: 
> > > (1) Jong-Deok Shoi et al. \
> > > https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis 
> > > (2) EA in the client compiler, \
> > > http://ssw.jku.at/General/Staff/TK/Research/Publications/ 
> > > 
> > > 
> > > Another question, this time looking into the future. Approaches have been put \
> > > forward to support "structs in the JVM", things like: 
> > > packed objects, \
> > > http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 
> > > http://openjdk.java.net/jeps/169
> > > 
> > > What about Graal? For example, the use case "method returns a struct", would \
> > > HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a \
> > > slippery topic, but comments are welcome! :) 
> > > 
> > > Miguel
> > > 
> > > --
> > > Miguel Garcia
> > > Swiss Federal Institute of Technology
> > > EPFL - IC - LAMP1 - INR 328 - Station 14
> > > CH-1015 Lausanne - Switzerland
> > > http://lamp.epfl.ch/~magarcia/
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic