On Aug 29, 2014, at 5:27 PM, Martin Buchholz <marti...@google.com> wrote:
> I agree that the benefit is very small, but I am coming at this from source > code consistency and bytecode size (not jitted code performance), and I think > bytecode size is at least one of the problems with assert. We agree about JDK-6445664. See my JDK-6316156, which I just linked to your bug. Unfortunately the current inlining heuristics create a performance linkage (an accidental one) to the size of a method's bytecode instructions. (BTW, there is no such linkage to the overall class file size, lest anyone go a quest to shrink class files. For example, you won't get penalized for using a CONSTANT_Long instead of a CONSTANT_Integer of the same value.) I am not against individual ad hoc reductions in bytecode size, or regularization of code, but I am resolutely against any proposition that a steady stream of such suggestions is worth the expense of anyone's professional attention. To be positive... :-) New useful APIs (streams), or real algorithmic changes to old libraries (TimSort), make me smile a lot. More than that, bugs like JDK-6445664, which connect desirable code styles to required JIT optimizations, excite my interest, because they show opportunities that we can exploit if we coordinate our efforts. (Streams are also in the latter category, since they are likely to require new JIT optimizations.) In that spirit, I'll try some rabble-rousing on the JIT team about this... — John
