Escape Analysis and MH.invoke, MH.invokeExact
Garcia Gutierrez Miguel Alfredo
miguelalfredo.garcia at epfl.ch
Mon Jul 29 00:16:38 PDT 2013
> 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:
> 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.
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
From: Lukas Stadler [lukas.stadler at jku.at]
Sent: Monday, July 29, 2013 6:30 AM
To: Garcia Gutierrez Miguel Alfredo
Cc: graal-dev at 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?
On Jul 27, 2013, at 3:42 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:
> 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 Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> From: Lukas Stadler [lukas.stadler at jku.at]
> Sent: Friday, July 26, 2013 8:24 PM
> To: Garcia Gutierrez Miguel Alfredo
> Cc: graal-dev at 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 at epfl.ch> wrote:
>> 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
>> 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 Garcia
>> Swiss Federal Institute of Technology
>> EPFL - IC - LAMP1 - INR 328 - Station 14
>> CH-1015 Lausanne - Switzerland
More information about the graal-dev