[samus]

It's certainly better than in Java where LTO is simply not possible due to reflection. The more interesting question is which code effectively gets compiled so you know what has to be audited. That is, without disassembling the binary. Maybe debug information can help?

[pjmlp]

Not only it is possible, it has been available for decades on commercial AOT compilers like Aonix, Excelsior JET, PTC, Aicas.

It is also done on the cousin Android, and available as free beer on GraalVM and OpenJ9.

[hedora]

Those all break compatibility to achieve that.

[pjmlp]

No they don't, PTC, Aicas, GraalVM and OpenJ9 support reflection.

The others no longer matter, out of business.

[saagarjha]

You can't LTO code under the presence of reflection. You can AOT but there will always be a "cold path" where you have to interpret whatever is left.

[pjmlp]

Yet it works, thanks to additional metadata, either in dynamic compiler which effectly does it in memory, throwing away execution paths with traps to redo when required, and with PGO like metadata for AOT compilation.

And since we are always wrong unless proven otherwise,

https://www.graalvm.org/jdk21/reference-manual/native-image/...

https://www.graalvm.org/latest/reference-manual/native-image...

[saagarjha]

You do understand that the topic at hand is not shipping around all that code needed to support a trap, right?

[0x696C6961]

In Go, the symbol table contains enough information to figure this out. This is how https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck is able to limit vulnerabilities to those that are actually reachable in your code.

[saagarjha]

The symbol table might contain reflection metadata, but it surely can't identify what part of it will be used.

[mike_hearn]

It's possible and in recent years the ecosystem has been evolving to support it much better via native-image metadata. Lots of libraries have metadata now that indicates what's accessed via reflection and the static DCE optimization keeps getting better. It can do things like propagate constants to detect more code as dead. Even large server frameworks like Micronaut or Spring Native support it now.

The other nice thing is that bytecode is easy to modify, so if you have a library that has some features you know you don't want, you can just knock it out and bank the savings.

[metaltyphoon]

Doesn’t Java offer some sort of trimming like C#? I know he won’t remove everything but at least they can trim down a lot of things.

[pjmlp]

Yes, jlink, code guard, R8/D8 on Android, if you want to stay at the bytecode level, plus all the commercial AOT compilers and the free beer ones, offer similar capabilities at the binary level.