SimpleStreamableAssetManager: Memory Bloat/Leak in AssetIndexToBounds4Index

Overview:

A report has been received regarding a memory leak that eventually leads to OOM crashes when s.StreamableAssets.UseSimpleStreamableAssetManager=1 is enabled. In projects that utilize this manager, repeated level transitions cause memory allocated by AssetIndexToBounds4Index to grow indefinitely, ultimately exhausting available system memory.

One customer has encountered OOM crashes due to this issue in a memory-constrained environment.

Technical Detail:

The root cause lies in how FSimpleStreamableAssetManager::RemoveRenderAssetElements handles the deregistration of object elements. The function currently calls TSimpleSparseArray::Reset(Index), which invalidates the entry but intentionally retains the allocated memory to enable efficient reuse.

While this behavior is by design, a critical issue emerges when assets (e.g., Textures) remain registered with the manager—because UnregisterAsset() is not invoked under certain conditions, such as during level transitions—while the assets are still resident in the memory cache but are no longer referenced by any objects in the active level.

In this state, the inner TSimpleSparseArray associated with a given AssetIndex preserves its peak capacity from previous level transitions and never releases it.

Impact on Large-Scale Projects:

In large-scale titles featuring numerous unique biomes and assets across multiple levels (e.g., Level A → B → C), AssetIndexToBounds4Index continues to expand as new assets are encountered. Because the inner buffers for obsolete asset indices are never emptied, the overall memory footprint grows linearly with the total number of unique assets loaded during a single play session.

Workaround:
The customer confirmed that explicitly calling Empty() when the element count reaches zero successfully prevents further memory bloat:

void FSimpleStreamableAssetManager::RemoveRenderAssetElements(int32 ObjectRegistrationIndex)
{
    for (const FAssetRecord& Asset : ObjectAssets)
    {
        const int32& AssetIndex = Asset.AssetRegistrationIndex;
        const int32& AssetElementIndex = Asset.AssetElementIndex;
        check(AssetIndex != INDEX_NONE);
        check(AssetElementIndex != INDEX_NONE);
        AssetIndexToBounds4Index[AssetIndex].Reset(AssetElementIndex);
        
+       // Fix Start
+       // Force free the memory buffer if empty to prevent memory leaks.
+       if (AssetIndexToBounds4Index[AssetIndex].Num() == 0)
+       {
+           AssetIndexToBounds4Index[AssetIndex].Empty();
+       }
+       // Fix End
    }
}

Due to the nature of this leak, it is best observed using a debugger rather than through a simple visual inspection.

1. Create a project based on Lyra.
2. Add s.StreamableAssets.UseSimpleStreamableAssetManager=1 to the [SystemSettings] section in Config/DefaultEngine.ini.
3. Launch PIE and start a game session via a warp gate.
4. Exit back to the menu and select a different game/map to trigger a level transition.
5. Set a breakpoint in FSimpleStreamableAssetManager::UpdateTask_Async() and inspect the AssetIndexToBounds4Index array.
6. Repeat 4-5

Actual Result: Inspecting the elements of AssetIndexToBounds4Index reveals multiple TSimpleSparseArray instances where Num() is 0, yet GetAllocatedSize() reports a non-zero value.

Expected Result: Memory associated with TSimpleSparseArray instances in AssetIndexToBounds4Index, corresponding to unused UStreamableRenderAsset, should be released appropriately.

Notes:

In small-scale projects like Lyra, where map and asset variety is limited, each element of AssetIndexToBounds4Index is eventually reused. As a result, this behavior may appear intentional or efficient rather than indicative of memory bloat or a leak.

However, the issue becomes most prominent in high-end, large-scale games where unique biomes are separated into individual levels and progression relies on frequent level transitions.