On Tue, 30 Jan 2024, 21:27 Johannes Rudolph, <johannes.rudo...@gmail.com> wrote:
> 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. > It's unfortunate I don't have access to my desktop where I looked at it mote comprehensively as at the time I didn't notice any regression and I twayed it with jvm flags that report when the JVM does or doesn't inline. > > > 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). > I admitted earlier that the current default is not ideal and have zero qualms in changing it. --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > >
