You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?)
The text was updated successfully, but these errors were encountered:
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
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. TheLayout
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, soCapacityOverflow
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
orString
), 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?)The text was updated successfully, but these errors were encountered: