We have no availability based heuristics, nor does anyone else AFAIK, for dynamically enabling/disabling/tuning code gen to fit into smaller code cache pools or react to low space indications. Running out of code cache space is pretty rare and you can have a bigger cache if you like.Zing and OpenJDK as well as other compilers make aggressive and optimistic optimizations which minimize code size such as implicit null checks, brach/exception elimination, constant folding, Class Hierarchy Analysis to name a few. The general way these work is by the compiler either proving some code is redundant or not generating some unlikely code path optimistically (with a de-optimization fallback).As you point out, some optimizations bloat the code (unrolling etc), or result in code duplication (inlining). The compilers have different heuristics for how much to inline with a lot of seemingly arbitrary weights for different parameters. I leave it to people more involved in determining these heuristics to answer how much they worry about code size. I recommend looking at the GA sample in JMH for an interesting approach to exploring the parameter space for inlining.
-- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
