method handle cracking API

Remi Forax forax at univ-mlv.fr
Thu Apr 25 14:40:31 PDT 2013


On 04/25/2013 05:18 AM, John Rose wrote:
> On Apr 24, 2013, at 7:45 PM, Mark Roos <mroos at roos.com 
> <mailto:mroos at roos.com>> wrote:
>
>> Any chance that one could walk the GWT chain from a call site in 
>> order to build
>> a different look up structure or maybe even some specialized code? 
>> Currently I
>> keep this in the call site but it seems redundant.
>
> Sorry, not in this go-around. We are aiming at cracking 
> CONSTANT_MethodHandle constants.
>
> Cracking transforms like GWT is a harder problem, which we need to 
> think about more.
>
> Simple example: Suppose you have a tree of GWTs that a clever 
> implementation compiles into a big hunk of bytecode. How do you 
> recover the original GWT chain from the bytecode? Answer is, you 
> can't, not unambiguously. And a testable public API requires 
> reproducible results. So now implementations will have to keep extra 
> information about the genesis of each MH, in case someone cracks it. 
> That will be a large and mostly-useless expense.

Note that if you compile it after having created a tree of method 
handles, you already have the information you need
(minor the fact that bound values/objects are often transformed from the 
Java realm to the VM realm) in the method handle tree. Otherwise, it 
means that the implementation is smart enough to generate bytecodes when 
you create method handles, so your implementation have to generate 
bytecodes in a backward fashion which is a tremendous achievement by 
itself. Jerome (the guy that work to port jsr292 on android) and I have 
discussed several times about something along that line and it's far 
from obvious.

>
> — John

Rémi



More information about the mlvm-dev mailing list