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