On Sun, 16 Feb 2025 15:41:52 GMT, Chen Liang <li...@openjdk.org> wrote:
>> src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1237: >> >>> 1235: return res; >>> 1236: } >>> 1237: >> >> Centralizing the allocation into a helper on its own Looks unseful (for >> resource Management, debugging/profiling and to pick the optimal >> implementation). >> >> but it’s a shame that 2 dimensional allocations are sub-optimal, shouldnt >> that be addressed in the jvm (or c2?) > > Indeed, it's better if hotspot can recognize and optimize the bytecode > sequence generated by javac, or javac should generate bytecode like these > methods to speed up allocation in general. > > Is splitting the allocation into a dedicated method a factor? I know this may > affect JIT compilation heuristics. It is almost always a mistake to try to generate optimized code in javac behind the user's back. The VM does a better job when javac stays out of the optimization business and just provides a concise bytecode representation of the desired computation. The VM always has more information than javac, and so all optimization descisions are best deferred until VM runtime, when all classes are loaded. In addition, increasing classfile sizes to improve peak performance is likely to harm startup performance, and (of course) static application footprint. Also, even if javac gets an optimization perfectly correct for current platforms (and the footprint costs are negigible), in a few years platforms will change and the VM will want to optimize the bytecodes a different way. But the "optimization" in the classfile, will be obsolete, and the now-suboptimal code will stick around forever in release JARs; the VM's problem will then be to reverse-engineer the "optimized not-optimized" code and reorganize it, which is an unfair ask of the VM. In summary, there's nothing javac can do for optimization that is not better done by the VM, later on. Classfiles are semantic specifications, not performance engines. https://bugs.openjdk.org/browse/JDK-8308105#comment-14755577 In that line of thinking, I recommend replacing the multianewarray instruction, in javac's current translation strategy, with an invokedynamic, which can spin code that is as optimal as we need, now and in the foreseeable future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23642#discussion_r1966296640
