Construct a Box[[[i32; 32]; 32]; 32]> without hitting stack

[zeroexcuses]

Is there a way to construct a Box< [[[i32; 32]; 32]; 32] > without it ever hitting the stack ? (since it's 128MB in size).

[H2CO3]

It's just 128 kB, but <Box<_> as Default>::default() seems to do the trick.

[scottmcm]

@zeroexcuses

without it ever hitting the stack

The general answer here is via https://doc.rust-lang.org/std/boxed/struct.Box.html#method.new_zeroed or https://doc.rust-lang.org/std/boxed/struct.Box.html#method.new_uninit, as that gives you memory from calloc or malloc (well, not literally, but the rust equivalents) without actually initializing the underlying T. Then it's up to you to use unsafe code to initialize it properly before turning it into a normal Box<T>.

[zeroexcuses]

I'm moving over the solution tag as this seems to be the more general / less magical solution.

[gkcjones]

If you need a general solution that doesn’t require unstable features, isn’t subject to the current element count limits of stable Default, and doesn’t have to be pretty, this should work:

pub fn make_big_box() -> Box<[[[i32; 64]; 64]; 64]> {
    // Alloc on heap.
    let data = vec![0; 64 * 64 * 64];

    // Throw away redundant capacity value.
    let data = data.into_boxed_slice();

    // Extract raw pointer, losing Box.
    let data = Box::into_raw(data);

    // Cast from slice to 3-D array.
    let data = data as *mut [[[_; 64]; 64]; 64];

    // Recreate box taking ownership.
    // Safety: Ensure allocation sized correctly above.
    unsafe { Box::from_raw(data) }
}

[Yandros]

@zeroexcuses

the more general solution

While that will be the case once that nightly feature is stabilized, I wouldn't say that a nightly-only API really counts as a general solution.

In the interim, that API is polyfilled within the ::uninit crate:

BoxUninit in uninit::extension_traits - Rust

Optimized in-place heap initialization

The Box::uninit().init(...) delayed-initialization pattern is suprisingly effective in helping the optimizer inline the creation of the value directly into the heap.

• For those wondering why Box::new(...) could not be made as efficient, the answer lies in temporaries: the ... temporary when calling Box::new() is created before attempting the allocation, and given that this allocation can fail / have side-effects, the optimizer is not allowed to reorder the creation of the temporary after the allocation, since it can change the semantics of the code for these corner (but not unreachable) cases. It is hence illegal for the optimizer to inline the creation of ... directly into the heap.Whereas Box::uninit().init(...) only creates the temporary after the allocation attempted in uninit() has succeeded, at which point it should be trivial for the optimizer to inline its creation directly into the heap.
• Note, however, that this property cannot be guaranteed from a library perspective; for instance, the heap-inlined initialization does not seem to happen when the optimization level ( opt-level ) is less than 2 . Inversely, the author has observed that the heap-inlined initialization does seem to kick in when compiling with -C opt-level=2 (or 3 ), e.g. , when running on --release .

Example

use ::uninit::prelude::*;

let ft: Box<u8> = Box::uninit().init(42);
assert_eq!(*ft, 42);

This optimization can even allow creating arrays too big to fit in the stack.

• For instance, the following implementation panics:

ⓘ

fn alloc_big_boxed_array () -> Box<[u64; 10_000_000]>
{
    // This can panic because of the `[0; 10_000_000]` stack
    // temporary overflowing the stack.
    Box::new([0; 10_000_000])
}

• Whereas the following one does not (doc-tested with RUSTDOCFLAGS=-Copt-level=2 ):

fn alloc_big_boxed_array () -> Box<[u64; 10_000_000]>
{
    // But this works fine, since there is no stack temporary!
    Box::uninit().init([0; 10_000_000])
}

FWIW, it's also important to note that .uninit()-followed-by-init(…) only elides the stack temporary if using opt-level ≥ 2, e.g., when compiling on --release. So that's another important caveat to keep in mind.

• Using unsafe code might be needed to write guaranteed-in-place initialization in that case, although given a legitimate I could update that crate with new APIs, should those be deemed useful.

Finally, for the very case of 0-init array, I think that @H2CO3's suggestion is both simple and effective. And for non-0-init array, by starting off a 0-init one, we don't need unsafe anymore. So

[H2CO3]

Also, one doesn't even need default if they are worried about hitting the array size limit for which Default is implemented. vec![…].into_boxed_slice().try_into().unwrap() works just fine.

[gkcjones]

@H2CO3

vec![…].into_boxed_slice().try_into().unwrap()

Thanks! I’m glad to learn a simpler (safe) way to do that. No idea why try_into() never occurred to me.