News for hackers. Stuff that matters.

A comment on Notes on debugging HotSpot's JIT compilation. Parent comment

Re:Notes on debugging HotSpot's JIT compilation by mike_hearn on Tuesday March 26, 2024 @05:44AM (#39825866)
Things like that often will be, which is why you generally need to use the JMH harness to do microbenchmarking on the JVM. It uses internal APIs to stop the compiler treating results as dead and eliminating them.

In this case it doesn't happen because to see that the entire operation is dead requires the compiler to inline payload into main, but he says he disabled inlining for that method specifically so it wouldn't happen. Recall that the goal is to see the assembly for a block of code in isolation, not demo what the JVM can do when given free reign.

[ Parent | on HN ]
Re:Notes on debugging HotSpot's JIT compilation by comonoid on Tuesday March 26, 2024 @06:35AM (#39826162)
Well, inlining is not necessary, good old interprocedure analysis would resolve it too.
[ Parent | on HN ]
Re:Notes on debugging HotSpot's JIT compilation by lewurm on Tuesday March 26, 2024 @08:02AM (#39826795)
Sure, but neither javac (the Java to bytecode compiler) or HotSpot are doing that. The former tries to preserve as much as possible, and for the latter interprocedure analysis is too costly at run-time.
[ Parent | on HN ]
Re:Notes on debugging HotSpot's JIT compilation by anonymous-panda on Tuesday March 26, 2024 @12:23PM (#39829666)
Could javac do the analysis and record it in the bytecode for HotSpot to optimize? Or is this kind of hybrid teamwork not done?
[ Parent | on HN ]
Re:Notes on debugging HotSpot's JIT compilation by mike_hearn on Tuesday March 26, 2024 @12:31PM (#39829761)
It is done, but for this case the problem is partial compilation. For this you'd need methods to be tagged as pure, but that assumption needs to propagate and it could be violated by a library being upgraded.
[ Parent | on HN ]