On 2019-11-13 21:04, John Rose wrote:
On Nov 13, 2019, at 11:24 AM, Claes Redestad <claes.redes...@oracle.com
<mailto:claes.redes...@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
