Keys occupy double memory size after updating

[zhu-he]

Running the following code will use 2GB of memory.

let cache = moka::future::Cache::new(10);
cache.insert(vec![1u8; 1 << 30], ()).await;
cache.insert(vec![1u8; 1 << 30], ()).await;

Testable:

let cache = moka::future::Cache::new(10);
let key = std::sync::Arc::new(());
cache.insert(key.clone(), ()).await;
cache.insert(key.clone(), ()).await;
assert_eq!(std::sync::Arc::strong_count(&key), 2);

[cfeitong]

The updated key is not dropped immediately; instead, its drop is deferred until a later point in time. This behavior is expected in concurrent data structures. To achieve optimal performance, such data structures often rely on some form of garbage collection. In the case of moka, it uses crossbeam-epoch as the underlying garbage collection mechanism.

To address your test case, you can perform additional random operations on the cache. This allows crossbeam-epoch to advance its internal epoch, which will then reclaim unused garbage, including the updated key.

Here is an updated version of your test:

    let key = std::sync::Arc::new(1);
    let cache = moka::future::Cache::new(10);
    cache.insert(key.clone(), ()).await;
    cache.insert(key.clone(), ()).await;

    // Perform some random operations to advance the epoch.
    for i in 0..100 {
        let key_i = std::sync::Arc::new(i);
        cache.insert(key_i.clone(), ()).await;
    }

    // Verify that the strong count is as expected.
    assert_eq!(std::sync::Arc::strong_count(&key), 2);