Re:Java 25's new CPU-Time Profiler (1)
by cxr on Saturday September 13, 2025 @03:58PM
(#45234858)
> The JVM is really a fantastic piece of engineering and IMHO represents a whole direction in computing I feel sad that we didn't take. We opted to stay close to the metal with all the security, portability, code reuse, and other headaches that entails, instead of going into managed execution environments
It's worth asking whether even the AOT-compile-to-JVM-bytecode strategy is itself an unnecessary holdover from the past. I'd much rather see a healthy ecosystem where programs in languages designed to be lowered into an efficient form (whether it be C or C#) are nonetheless generally distributed and run from source, and all the machinery to lower it into more compact/fast-to-execute forms is automatic (i.e. on-the-fly) and incidental (e.g. as a consequence of execution), rather than having people manually actually managing compilation and distribution of ELF, Mach-O, etc. binaries.
Don't like the way sed or grep work? Open up the program in your text editor, find and fix whatever it is you don't like, then overwrite the previous ~/bin/sed.src file, and re-run it. No compilation; no steps to set up a development environment beforehand; nothing.
Bonus: since your programs aren't limited to the set of optimizations that were known (and were implemented/shipped in GCC and enabled) at build time, then your system can be continually doing optimization passes, which means you can go to sleep on a Tuesday, wake up on a Wednesday, and find that your program—and several other programs on your computer, and indeed the whole system overall—has literally gotten faster overnight.
It's worth asking whether even the AOT-compile-to-JVM-bytecode strategy is itself an unnecessary holdover from the past. I'd much rather see a healthy ecosystem where programs in languages designed to be lowered into an efficient form (whether it be C or C#) are nonetheless generally distributed and run from source, and all the machinery to lower it into more compact/fast-to-execute forms is automatic (i.e. on-the-fly) and incidental (e.g. as a consequence of execution), rather than having people manually actually managing compilation and distribution of ELF, Mach-O, etc. binaries.
Don't like the way sed or grep work? Open up the program in your text editor, find and fix whatever it is you don't like, then overwrite the previous ~/bin/sed.src file, and re-run it. No compilation; no steps to set up a development environment beforehand; nothing.
Bonus: since your programs aren't limited to the set of optimizations that were known (and were implemented/shipped in GCC and enabled) at build time, then your system can be continually doing optimization passes, which means you can go to sleep on a Tuesday, wake up on a Wednesday, and find that your program—and several other programs on your computer, and indeed the whole system overall—has literally gotten faster overnight.