News for hackers. Stuff that matters.
Re:Notes on debugging HotSpot's JIT compilation by thfuran on Tuesday March 26, 2024 @08:48AM (#39827182)
What exactly do you expect an optimizing compiler to do?
Re:Notes on debugging HotSpot's JIT compilation by hardware2win on Tuesday March 26, 2024 @09:21AM (#39827488)
Leave code without obvious side effects alone (this is different from dead code)
Re:Notes on debugging HotSpot's JIT compilation by thfuran on Tuesday March 26, 2024 @10:36AM (#39828438)
But this is code obviously without side effect.
Re:Notes on debugging HotSpot's JIT compilation by hardware2win on Tuesday March 26, 2024 @11:02AM (#39828806)
There are side effects, but in real world, not abstract
Re:Notes on debugging HotSpot's JIT compilation by dkersten on Tuesday March 26, 2024 @02:50PM (#39831423)
So non-obvious side effects?

You can say that about any code at all, so no optimising would ever be possible. The program running faster is a side effect after all.

Re:Notes on debugging HotSpot's JIT compilation by thfuran on Wednesday March 27, 2024 @02:01PM (#39842495)
No, that code has no side effects. The implementation is free to produce whatever side effects it wants or needs as part of execution, but that is absolutely none of the compiler's business.
Re:Notes on debugging HotSpot's JIT compilation by dzaima on Tuesday March 26, 2024 @08:53PM (#39834592)
What would "leave alone" even be? There's no "default" state of performance of Java code; it would be ridiculously stupid for there to be something saying that, say, "a+b" for int type values has to take at least 1 nanosecond or something. And you can't use big O complexity here either - the int type has a maximum of 2 billion, and thus a loop over it is trivially O(1), just with a potentially-big constant factor. (or, alternatively, the loop was sped up by a constant factor of 2 billion, and optimizing compilers should extremely obviously be allowed to optimize code by a constant factor)