Point taken, however in practice this point is quite high to not matter that much. At least in these benchmarks zeroing out is typically responsible for less th

Point taken, however in practice this point is quite high to not matter that much. At least in these benchmarks zeroing out is typically responsible for less than 10% of total time overhead, and this including the fact the benchmarked VMs didn't do any zeroing-out elision: http://www.cs.utexas.edu/users/mckinley/papers/zero-oopsla-2011.pdf http://www.cs.utexas.edu/users/mckinley/papers/zero-oopsla-2... I was mostly talking about general variable initialization, not just huge arrays - and for any case "hard" like yours (but actually not impossible to elide; state-machines and inductive proofs are not a rocket surgery) - you've got several trivial cases like I posted above which can be solved by simple local data-flow analysis. This is the same like with NP-hard problems. Some people get scared by NP-hard, but it only matters if you need an exact solution, and is not a problem in practice if you're ok with a result at 0.95 of the optimum. It is also sometimes more time-effective to reuse huge arrays to work around obligatory variable initialization done by the runtime for rare cases where it would be a performance problem, than to fight UBs in 10s of other places where performance doesn't matter.