Always send large futures to heap

[mhils]

Motivation

In #4009, task::spawn was changed to send tasks to the heap to prevent stack overflows in debug mode.
The initial proposal was to do this unconditionally in debug mode:

if cfg!(debug_assertions) {

but based on a suggestion from @Darksonn this was then changed to

if cfg!(debug_assertions) && std::mem::size_of::<T>() > BOX_FUTURE_THRESHOLD {

As detailed in #6057, this creates a bit of a footgun where code works great in debug builds but then fails in release mode. This can be surprisingly hard to track down (#6057 (comment)).

Solution

Instead of only doing this for debug builds only, I propose we change the condition to

if std::mem::size_of::<T>() > BOX_FUTURE_THRESHOLD {

only so that debug and release builds work the same way.

@Darksonn mentioned that there may be other - better - ways to fix this in #6057 (comment). I don't know what the alternative would be, but until that is tackled I think this here could be better than the current implementation. :)

[Darksonn]

This would be somewhat unfortunate. Because of inlining, release mode can handle much larger futures than debug mode, and if we can store the future directly in the task allocation without indirection, then that really is for the best performance-wise.

[mhils]

Thanks. When you say "can handle much larger futures", do you have any intuition on how much larger? For context, we tripped over a 65k future. Does it make sense to conceptually do something like this?

    pub(crate) const BOX_FUTURE_THRESHOLD: usize = if cfg!(debug_assertions)  { 2048 } else { 16384 };

16384 is what clippy uses for the (off-by-default clippy::large_futures), but otherwise I'm making up numbers here. Do we have any benchmarks to assess impact?

[Darksonn]

I guess we can take it with a larger size in release mode.

[Darksonn]

Thanks.