RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

[Claes Redestad]

On 2019-11-13 21:04, John Rose wrote:
> On Nov 13, 2019, at 11:24 AM, Claes Redestad <claes.redestad at oracle.com 
> <mailto:claes.redestad at oracle.com>> wrote:
>>
>>> Thanks for suggesting that Vladimir.  That indeed is how the existing 
>>> code is organized.
>>
>> Yes, not very startup friendly... ;-)
> 
> No, but it’s maintainer friendly.  We can walk and chew gum at the same 
> time >
> Is it time to think about a jlink plugin which inlines simple method calls?
> Perhaps we need to wait until we understand (semi-)closed-world packaging.
> 
> Long, long ago, a very early version of javac did inlining of simple 
> method calls.
> That functionality was removed when we realized that this was placing 
> “getfield”
> instructions in classes which didn’t have access to the referenced 
> private fields,
> causing code to break.  It also messed up the binary compatibility story 
> required
> to make sense of independently recompiled class files.  How innocent we were
> back then.  We won’t make those same mistakes again, but we could try the
> same trick again, more carefully, in jlink or some other static 
> packaging workflow.

As a startup optimization, inlining small (private?) methods at link-
time seems like a promising candidate, yes.

Similar to other promising candidates like constant folding I think it
opens up some more general questions about observability. For example:
do we retain the original bytecode and mappings everything back to it
so that a debugger would be none the wiser about any inlining that may
have happened? Do we "simply" deoptimize and redefine everything back to
the stashed original when someone hooks in a debugger..? (Do we go so
far as to allow opting out of debuggers entirely?)

/Claes