On Tue, Jan 30, 2024 at 8:30 AM Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> wrote: > > > It will only do that in some select few cases. > > Agreed, I phrased the original statement incorrectly. I was meant to say > that > it's not going to pointlessly inline code, i.e. it will only inline code > that is known > to be not inlinable by earlier JDK's.
This is also not how it works. It has some heuristics about when it thinks inlining might at least not hurt and is safe to do, but this is pretty much not connected theoretically to any existing JDK implementation. You have seen the diff. 90% of all the optimizer improvements is trivial pruning of useless basic blocks and trying to remove redundant STORE/LOAD pairs. Then there's a tiny bit of extra inlining which only works for trivial methods (like the onPull from above). There seem to be few places where it works for the intended purpose of optimizing HOF for collection usage (sometimes the HOF is inlined but not the closure). In other cases where HOF are inlined, these trivial cases lead to massive code blow-up which will rather have a negative impact on JIT code parsing with the result of the exact same code being generated (because these cases are so trivial). In almost every case the inliner makes trivial changes that would better be done by the JIT. It's far from clear whether enabling the inliner will create overall better code or if it will even put a hit on JIT compilation because of the increased code size. It's definitely not a free guaranteed win. > > See https://github.com/apache/incubator-pekko-http/pull/456 for an > example of the correctness issue. > Afaik none of the many projects enable the inliner for development. > > By correctness I was referring to the inliner producing incorrect code on a > clean > compile. I guess our major disagreement is about priorities. I highly prioritize my time as a (for this project mostly unpaid) developer. A 2x-3x hit on compilation times is huge in such a big project that often accidentally triggers major recompilation. If you think about it in general, it's far more important for this project to remove hurdles for potential contributors than to squeeze out the last bits of performance (which is unclear anyway). --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
