Memory fragmentation

[zqlpaopao]

my code

 fn main()  {
    std::thread::sleep(std::time::Duration::from_secs(10));
    loop {
        test();
        std::thread::sleep(std::time::Duration::from_secs(3));
    }
}


struct MyVec {
    vec: Vec<i32>,
}

impl Drop for MyVec {
    fn drop(&mut self) {
        println!("MyVec is being dropped, memory is being released.");
    }
}

fn test() {
    let mut my_vec = MyVec { vec: Vec::with_capacity(101) };

    for i in 0..101 {
        my_vec.vec.push(i);
    }
    println!("{:?}", my_vec.vec.len());
}

Memory at startup

Run output

101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101
MyVec is being dropped, memory is being released.
101

long

Are these caused by dynamic memory allocation? If so, how should we deal with this situation? We can't let the memory grow indefinitely, can we? Or, the OS has its own recycling strategy, and when it reaches a certain size, it will be recycled. Can we set this value ourselves? Otherwise, we can't control the size of the program. Will there be memory leakage problems if the running time is long

[bjorn3]

This behavior depends entirely on the memory allocator used by the libc on your system and is the same as for programs written in C. Some allocators are more eager to release memory to the OS than others. Some release memory in a background thread every X seconds. Some allocators have ways to control their behavior (eg make them more or less eager to free memory or request it to immediately release all memory that can be released) while others don't. You should look in the documentation of the libc implementation you are using on your system. This is probably glibc on Linux, but can also be musl.

[saethlin]

I'm closing this because the relevant behavior here is not part of Rust. It's possible to change the #[global_allocator] so that you can choose the allocator implementation that fits your use case.