On 2019-11-13 21:49, John Rose wrote:
On Nov 13, 2019, at 12:39 PM, Claes Redestad<claes.redes...@oracle.com> wrote:
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?)
Yep. These questions are why link-time optimization is not a slam dunk.
If it were, I suppose we’d have it already.
Debugging is especially hard. We don’t want to give it up, but any
program transformation is going to make debugging harder to implement.
You should see what the JITs do to support deopt; like exact GC, it’s
something that makes them different animals from the usual llvm/gcc
compilers.
That said, a bytecode-to-bytecode “deoptimization” is easier to specify
and think about than a machine-code-to-bytecode deopt, which is what
the JITs support. Juicy problems everywhere!
Yes, not trivial, but likely much easier.
Also I wonder if stashing classifies for debugging only will motivate a partial
resurrection of pack200, for storing said things “cold” on disk.
AFAIU, pack200 comes with a maintenance burden that we'd like to
permanently get rid of. For a stashed-away class file archive only used
when debugging then plain old zip at a high compression level might be
sufficient.
/Claes
