Description

Gil's new loading path may already walk away from this issue.

But here's some thing I tested locally if we want to fix this.
A simple way to fix is to simply add
BulkDataAsync.Deallocate();
ResetAsyncData();
in FUntypedBulkData::FlushAsyncLoading.

But from the interface design aspect, I think we should treat BulkDataAsync to be handled as same to BulkData. We may:
1. While FlushAsyncLoading, don't need any Dest, just BulkData = MoveTemp(BulkDataAsync);
2. While LoadDataIntoMemory, ensure to Flush and check BulkData first and can safely remove codes that check for SerializeFuture.IsValid() while trying to LoadData.
3. When we want to copy data, we can always just LoadDataIntoMemory and then use Memcpy or BulkData.ReleaseWithoutDeallocating() on demand whether we need to keep a copy in BulkData.

A test on a demo Android project saved me about 100MB from BulkDataAsync.Deallocate.

Steps to Reproduce

While launch engine, quite a bit content with BulkData may using Async loading path but the BulkDataAsync never released.

Have Comments or More Details?

There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-37815 in the post.

0
Login to Vote

Fixed
ComponentUE - Foundation - Core
Target Fix4.15
Fix Commit3273235
Main Commit3389599
Release Commit3273235
CreatedOct 26, 2016
ResolvedJan 26, 2017
UpdatedSep 16, 2019
View Jira Issue