Currently OOM error handler and OOM panic payload gets Layout as the only bit of information. This is too little and too much information at the same time.
Allocators only report an empty AllocError, so they can't report why an allocation failed. The Layout comes from allocator's caller, and users can only guess why the allocation failed. When users actually want to know the details, Layout is not sufficient, and would be better if allocators could report the exact reason directly (e.g. fragmentation, too-large alignment, etc.).
Layout can't contain invalid size or alignment, by design, so CapacityOverflow handling is an entirely separate code path, which OOM-handling hooks can't see. And custom allocators can't report this error themselves. It would be nice if capacity overflow could be folded into rest of the error handling, so that all allocation failures could be handled in one place.
There's a cost to constructing and returning informative errors. Rust programs have a lot of repetitive reallocation code (on almost every modification of a Vec or String), but it may be for nothing if there isn't an OOM hook or catch_unwind that needs this information. Could OOM errors be kept as empty unit structs for performance and code size efficiency, but have some out-of-bounds mechanism for getting details about allocation failures? (e.g. Allocator could take an event listener function and give it detailed info only when it's set?)
Related to discussion here: https://internals.rust-lang.org/t/questioning-usefulness-of-alignment-in-oom-errors-and-handlers/20233/7
Currently OOM error handler and OOM panic payload gets
Layoutas the only bit of information. This is too little and too much information at the same time.Allocators only report an empty
AllocError, so they can't report why an allocation failed. TheLayoutcomes from allocator's caller, and users can only guess why the allocation failed. When users actually want to know the details,Layoutis not sufficient, and would be better if allocators could report the exact reason directly (e.g. fragmentation, too-large alignment, etc.).Layoutcan't contain invalid size or alignment, by design, soCapacityOverflowhandling is an entirely separate code path, which OOM-handling hooks can't see. And custom allocators can't report this error themselves. It would be nice if capacity overflow could be folded into rest of the error handling, so that all allocation failures could be handled in one place.There's a cost to constructing and returning informative errors. Rust programs have a lot of repetitive reallocation code (on almost every modification of a
VecorString), but it may be for nothing if there isn't an OOM hook or catch_unwind that needs this information. Could OOM errors be kept as empty unit structs for performance and code size efficiency, but have some out-of-bounds mechanism for getting details about allocation failures? (e.g. Allocator could take an event listener function and give it detailed info only when it's set?)