Free memory after task is complete

[kokil01]

I am very new to tokio and trying to understand it by writing small programs. In this program I want to see how much memory is allocated for very small tasks and if its reclaimed after the tasks are complete. In this program

async fn process_one(i: i32) {
    let delay_in_seconds = Duration::new(5, 0);
    tokio::time::delay_for(delay_in_seconds).await;
    println!("{}", i);
}

#[tokio::main]
async fn main() {
    for i in 0..1_000_000 {
        task::spawn(async move {
            process_one(i).await;
        });
    }
    let mut buffer = String::new();
    io::stdin().read_to_string(&mut buffer).expect("Ahhhh");
}

In this program I spawn a million tasks where each task waits for 5 seconds, prints a number and then exits. This program works but I observe 2 things -

1. The total memory of the program goes from 0 to 342MB quickly, CPU utilization is near zero.
2. I see number 0 to 1_000_000 printed in random order and after all of them are printed the memory still stays at 342MB!

This is puzzling to me. Shouldn't the memory be freed after all the tasks are complete? Thanks!

[Darksonn]

This is probably not a memory leak in Tokio, but Rust's memory allocator not releasing the memory back to the OS. If I run the loop several times with a sleep in between, the memory remains constant after the first run.

[Noah-Kennedy]

To add to this, this isn't something to be worried about, allocators tend to cache old allocations under the assumption that something may soon ask for another allocation with the same layout, rather than return the memory to the OS.

[adityasupugade]

For how long will allocators cache old allocations, When can we expect that memory to be freed?

[Darksonn]

I don't think the default allocator has a timeout after which it will free it. But I don't know the details. It's a complicated topic and there are lots of different allocators out there with different behavior.

[jxs]

as @Darksonn states, this is Rust's memory allocator, you can confirm that using a tool like Heaptrack.
taking your example:

use std::time::Duration;
use tokio::task;
use std::io;

async fn process_one(i: i32) {
    let delay_in_seconds = Duration::new(5, 0);
    tokio::time::delay_for(delay_in_seconds).await;
    println!("{}", i);
}

#[tokio::main]
async fn main() {
    for i in 0..1_000_000 {
        task::spawn(async move {
            process_one(i).await;
        });
    }
    let mut buffer = String::new();
    io::stdin().read_line(&mut buffer).expect("Ahhhh");
}

and analyzing with heaptrack --analyze you confirm those ~300mb are released back:

[oronsh]

Hey, sorry for waking this discussion up but I could also use some explanation please :)
I'm using the example above with jemalloc configured to aggressively returning memory to the OS like this:
JEMALLOC_SYS_WITH_MALLOC_CONF=background_thread:true,narenas:1,tcache:false,dirty_decay_ms:0,muzzy_decay_ms:0,abort_conf:true

when I'm spawning 1 million tasks the memory goes back to 18.9MB compared to 808Kb when spawning 1000 tasks.
Why is there such a difference? I would expect 2 scenarios to end up with the same memory after finishing executing the tasks.
I'm asking because I can see similar behavior with an application that I'm working on, when spawning more tasks the memory is stuck and never returning to the start point, even when not sending anymore requests (a tonic application).
This discussion made me ask if this could be just something with tokio itself, I did some tests with a simple hyper server and ended up with the same conclusions.

@Darksonn @jxs

Thanks a lot!

[audacioustux]

[Darksonn]

If you have a new question, post a new question instead of posting an answer to this one.

[audacioustux]

done #4678