Hacker News Reader

Comment by pjmlp | Hacker News Reader

> Those other language implementation strategies do not offer LTO-like features (that I know of), so I have ignored them here.

JVM implementations (and ART), alongside CLR do such optimizations.

Furthermore, nowadays PGO is part of the process as well, so the information can be carried over across runs, used as means for the JIT to quickly achieve the optimal execution point, and carry over from there instead of starting over from scratch every time.

View on HN

On tuesday .NET 8 will be released which has this aswell.

https://devblogs.microsoft.com/dotnet/performance-improvemen...

Yeah, this was a very strange statement to read.

In fact, it's even more wrong than that. The ability for managed runtimes to perform LTO across dynamic code loading means you're even able to get LTO across code your compiler has never witnessed - e.g. plugins written by 3rd parties.

I think it's just usually rolled up into optimizations with other names, like "speculative inlining".

Ah hmm, I guess part of the problem is I am less familiar with JVM, CLR, etc. features in this space.

Does anyone know of articles that go into a bit more on precisely the kinds of LTO they offer? I'll update the guide once I understand the situation a bit better.

Some examples are divirtualization across dynamic libraries, or code inlining, which is quite basic stuff for those implementations.

Here is a 2015 paper for OpenJDK,

https://cr.openjdk.org/~vlivanov/talks/2015_JIT_Overview.pdf

Modern ART has a bit of everything, Assembly written interpreter for fast startup, followed by a JIT stage with PGO capabilities, followed by an AOT compiler that AOT compiles (with LTO) when the device is idle, and uploading PGO data into the Play Store, so that incrementally the same devices collaborate to the optimal PGO data set.

https://source.android.com/docs/core/runtime/jit-compiler

IBM and Azul JVMs have similar approaches with their cloud based JIT infrastructure.

https://developer.ibm.com/articles/jitserver-optimize-your-j...

https://www.azul.com/products/intelligence-cloud/cloud-nativ...

Thanks, this looks great. I'll read through these and add this info in my next update. :)

I'm not sure i would agree that the JVM and its ilk do LTO. They compile code to machine code at runtime, after loading the code it calls, and often after spending some time interpreting it. That means they can do interprocedural optimisations of the kind LTO can do (and then some). But they don't have the separate stages of compilation and linking that many ahead-of-time compiled languages do, which means they don't do linking, which surely means they can't do link-time optimisation!

This is incorrect. The JVM has an explicitly separate link phase [0]. The difference with AOT compilers is that linking is deferred until runtime. Rather than saying there's no link phase, you should think of it like as if your favorite AOT compiled language could support LTO on dlopen.

0) https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.ht...

The linking mentioned there has nothing to do with the linking in LTO. It happens before JITting, and is neither a barrier to nor an opportunity for optimisation.

Reply on news.ycombinator.com