4 ms·

IMHO, it will be a nightmare for debuggers.

mnem 6y ago
Generally trying to debug optimised code is a nightmare anyway. Most debugging is performed on non-optimised builds, which wouldn’t be affected by the proposed optimisation.
- thu2111 6y ago
  There's actually a compiler that does all these things and allows debugging of optimised code whilst seeing the unoptimised form - Sulong. Sulong is an LLVM JIT-compiling engine that runs on GraalVM. So it uses the same infrastructure of the JVM, but without JVM bytecode getting into the picture. Instead the JVM runs LLVM bitcode directly. But it does so in the standard way which gives many benefits: • Splitting of hot/cold paths, as in this work. • Cross-function optimisation and inlining regardless of visibility, as requested above. • Ability to debug an optimised program, because the JVM can 'deoptimize' the parts being inspected or debugged. • Run the Linux version of the bitcode cross-platform. • In "Managed Sulong" (which is an enhanced payware version), all allocations are garbage collected and bounds checked. Yes even for C/C++ programs, just needing a recompile. It's just about possible to do this within the rules of well defined C/C++, as long as the program doesn't try to do non-portable or non-defined things like pass stack pointers between threads. Managed Sulong can also sandbox LLVM code modules, and redirect IO back into the JVM for mapping via the pluggable socket/filesystem layers. • Cross-language interop, including recent experimental support for e.g. casting Java or Ruby or Python objects to C++ objects and calling methods on them. • All the same compiler optimisations as LLVM does still apply. It's a pretty amazing and under-appreciated project. On the other hand the code being run inherits the limits of the JVM, e.g. you shouldn't try and fork the process (of course, lots of runtimes don't like being forked and on Windows you can't do it at all).
  - brian_herman 6y ago
    Yeah, sulong looks pretty cool! https://llvm.org/devmtg/2019-04/slides/TechTalk-Schatz-Sulong_an_experience_report.pdf https://llvm.org/devmtg/2019-04/slides/TechTalk-Schatz-Sulon...
jcranmer 6y ago
Inlining and outlining are per se probably some of the least destructive optimizations for debugging: they don't affect the order or existence of instructions, compared to the naïve translation model, merely where it is located within the executable. (Admittedly, generating the debugging records to be able to refer to variables in the non-outlined portion of the function from the outlined function is probably not done, although it's probably doable with the current DWARF expression syntax. This is much like how most of the <optimized out> variables you see in gdb could be specified with DWARF information but aren't because the compiler doesn't maintain the information.)

mnem 6y ago

Generally trying to debug optimised code is a nightmare anyway. Most debugging is performed on non-optimised builds, which wouldn’t be affected by the proposed optimisation.

thu2111 6y ago
There's actually a compiler that does all these things and allows debugging of optimised code whilst seeing the unoptimised form - Sulong. Sulong is an LLVM JIT-compiling engine that runs on GraalVM. So it uses the same infrastructure of the JVM, but without JVM bytecode getting into the picture. Instead the JVM runs LLVM bitcode directly. But it does so in the standard way which gives many benefits: • Splitting of hot/cold paths, as in this work. • Cross-function optimisation and inlining regardless of visibility, as requested above. • Ability to debug an optimised program, because the JVM can 'deoptimize' the parts being inspected or debugged. • Run the Linux version of the bitcode cross-platform. • In "Managed Sulong" (which is an enhanced payware version), all allocations are garbage collected and bounds checked. Yes even for C/C++ programs, just needing a recompile. It's just about possible to do this within the rules of well defined C/C++, as long as the program doesn't try to do non-portable or non-defined things like pass stack pointers between threads. Managed Sulong can also sandbox LLVM code modules, and redirect IO back into the JVM for mapping via the pluggable socket/filesystem layers. • Cross-language interop, including recent experimental support for e.g. casting Java or Ruby or Python objects to C++ objects and calling methods on them. • All the same compiler optimisations as LLVM does still apply. It's a pretty amazing and under-appreciated project. On the other hand the code being run inherits the limits of the JVM, e.g. you shouldn't try and fork the process (of course, lots of runtimes don't like being forked and on Windows you can't do it at all).
- brian_herman 6y ago
  Yeah, sulong looks pretty cool! https://llvm.org/devmtg/2019-04/slides/TechTalk-Schatz-Sulong_an_experience_report.pdf https://llvm.org/devmtg/2019-04/slides/TechTalk-Schatz-Sulon...

jcranmer 6y ago

Inlining and outlining are per se probably some of the least destructive optimizations for debugging: they don't affect the order or existence of instructions, compared to the naïve translation model, merely where it is located within the executable. (Admittedly, generating the debugging records to be able to refer to variables in the non-outlined portion of the function from the outlined function is probably not done, although it's probably doable with the current DWARF expression syntax. This is much like how most of the <optimized out> variables you see in gdb could be specified with DWARF information but aren't because the compiler doesn't maintain the information.)