Detecting memory is close to running out at Runtime?

Unity Engine
,
1

I’m occasionally running into an out of memory error in my WebGL Unity app when users load too many models.

Is there any way to catch this? I put a try/catch around the offending line (followed by a Dispose) but not seeing any sign of the exception.

Alternatively, is there any way to get more fine-grained memory usage info? In particular, seeing the ALLOC_GFX stats (used/peak/reserved) would be very helpful.

Could not allocate memory: System out of memory!
Trying to allocate: 3576616B with 32 alignment. MemoryLabel: VertexData
Allocation happened at: Line:261 in 
Memory overview
[ ALLOC_TEMP_TLS ] used: 32768B | peak: 0B | reserved: 4194304B 
[ ALLOC_DEFAULT ] used: 181916731B | peak: 181916731B | reserved: 185270364B 
[ ALLOC_TEMP_JOB_1_FRAME ] used: 0B | peak: 0B | reserved: 262144B 
[ ALLOC_TEMP_JOB_2_FRAMES ] used: 0B | peak: 0B | reserved: 262144B 
[ ALLOC_TEMP_JOB_4_FRAMES (JobTemp) ] used: 0B | peak: 0B | reserved: 1835008B 
[ ALLOC_TEMP_JOB_ASYNC (Background) ] used: 0B | peak: 0B | reserved: 1310720B 
[ ALLOC_GFX ] used: 1799404755B | peak: 1799404755B | reserved: 1799471103B 
[...]
$MemoryManager::Allocate(unsigned long, unsigned long, MemLabelId, AllocateOptions, char const*, int) @ [...]
22:59:17.706 instrument.js:107 Unity error: exception thrown: RuntimeError: table index is out of bounds,RuntimeError: table index is out of bounds
2

You need to enable exception support, and you cannot (realistically) rely on exception handling in release builds for webgl. See: Unity - Manual: Debug and troubleshoot WebGL builds

Knowing the memory usage won‘t help you much either. For one, the app memory may not reflect the actual memory limit due to javascript etc etc also using some of the tab‘s memory. Moreover memory allocations require contiguous blocks of memory available, so even if 100 mb are still available, it may be heavily fragmented and not allow an allocation of a 10mb block of memory.

The only way to deal with memory issues in WebGL is to be extremely conservative with memory management. In your case, allowing the user to load any number (or any type) of model is a flawed design for WebGL. You should limit it to loading just one model, always replace and unload the previously loaded one (or maybe two, three or five - whatever always works) and have a size check of each model (if loaded from file) that simply disallows loading of models that are more than X mb on disk as a (very rough) pre-estimation of its memory usage.