Stop keeping metadata in memory before writing it to disk #96358
Labels
A-metadata
Area: Crate metadata
E-help-wanted
Call for participation: Help is requested to fix this issue.
E-medium
Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
rustc_metadata
encodes all the crate information into an in-memory buffer inEncodedMetadata
. This in-memory buffer is then passed around to be written to disk, as anrmeta
file inrustc_interface::encode_and_write_metadata
and/or in anrlib
/dylib
by codegen. Codegen wraps metadata into an object file using theobject
crate to be nice to linkers that will manipulate therlib
/dylib
.Keeping
metadata
in-memory increases the amount of memory used by rustc significantly. We want to investigate saving this memory by writing metadata to disk early, reading it back if required.Instructions:
rustc_codegen_ssa::back::link::emit_metadata
andrustc_codegen_ssa::METADATA_FILENAME
to new modulerustc_metadata::fs
.rustc_interface::passes::encode_and_write_metadata
andrustc_metadata::util::non_durable_rename
torustc_metadata::fs
.encode_and_write_metadata
even if!need_metadata_file
.rustc_serialize::opaque::FileEncoder
inrustc_metadata::rmeta::encoder
instead of anopaque::Encoder
, it should encode directly to the temporary file, and re-read this temporary file to build theEncodedMetadata
.EncodedMetadata
to hold aMmap
of the on-disk metadata instead of aVec
. ThisMmap
can be of the temporary file, or of the proper renamed output file. In the former case,EncodedMetadata
should carry theMaybeTempDir
to avoid deleting the temporary directory while accessing theMmap
.Extra: the current implementations of
create_rmeta_file
andcreate_compressed_metadata_file
inrustc_codegen_ssa::back::metadata
buffer everything to a vector before writing it all at once. This could be refactored to write directly to the file using aBufWriter
.Please reach out on Zulip if you have any questions. Preferably on a public stream so experts on codegen can weigh in when necessary.
The text was updated successfully, but these errors were encountered: