Escape Analysis and MH.invoke, MH.invokeExact

[Garcia Gutierrez Miguel Alfredo]

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 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:

>
> 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/