MMTk's API is designed with an assumption that LTO will be enabled for a performant build.
It is essential to allow the Rust compiler to optimize across the crate boundary between the binding crate and mmtk-core.
LTO allows inlining for both directions (from mmtk-core to the binding, and from the binding to mmtk-core),
and allows further optimization such as specializing and constant folding for the
We suggest enabling LTO for the release build in the binding's manifest (
Cargo.toml) by adding a profile for the release build,
so LTO is always enabled for a release build.
[profile.release] lto = true
If your binding project is a Rust binary (e.g. the VM is written in Rust), this should be enough. However, if your binding project is a library, there are some limitations with cargo that you should be aware of.
Cargo only allows LTO for certain crate types. You will need to specify the crate type properly, otherwise cargo may skip LTO without any warning or error.
[lib] ... # be careful - LTO is only allowed for certain crate types crate-type = ["cdylib"]
At the time of writing, cargo has some limitations about LTO with different crate types:
- LTO is only allowed with
bin). Check the code of
can_ltofor your Rust version to clarify.
- If the
crate-typefield includes any type that LTO is not allowed, LTO will be skipped for all the libraries generated (https://github.com/rust-lang/rust/issues/51009). For example, if you have
crate-type = ["cdylib", "rlib"]and cargo cannot do LTO for
rlib, LTO will be skipped for
cdylibas well. So only keep the crate type that you actually need in the