Are there any plans to provide more granular/detailed information when using the memory profiler with dots projects?
#ECS/DOTS memory profiling?
compact zephyr
trail trellis
Hello @compact zephyr
Have you used version 1.1.5 of the [package] (https://docs.unity3d.com/Packages/com.unity.memoryprofiler@latest)? In that version non-temp UnsafeUtility allocations get named by the holding field & type in the All If Memory table and have full on references listed in the references panel, if there's any references to that memory tonne found in live managed objects (thread stack data bytes are not available for the managed data crawler in the package to parse for references, only Heap bytes and the GCHandle & static variables as entry points).
If you have used that, and the Entities Memory Profiler Module already, could you please go a bit more into detail on what kind of added granularity/details you're looking for?
Or better, what kind of problem you are looking to solve.
compact zephyr
Hello @trail trellis I hadn't noticed that there were new versions of the memory profiler package (last version I tried was 1.1.1).
For those allocations that don't show any named references, I assume that they're referenced by native memory only? It would be nice if there was an easy way of classifying them, perhaps with a custom allocator? I'm not trying to solve a specific problem, just figuring out where all my memory usage is going haha
trail trellis
The Memory Profiler package takes the dumped heap bytes, the static field info and the GCHandle a to then crawl the heap. That means it follows each reference type field to the address it points to and tries to read the object header (essentially a pointer, or pointer-pointer, to the type info) and based on the type info, then reads the bytes following the header to see if any of it's reference fields point at more objects.
As of 1.1.5 the crawler also follows pointer fields into native memory. That's how it finds those UnsafeUtility allocations. It does not following pointer fields (or pointer sized fields, which Boehm, conservatively and heuristically as it is, considers as references that will keep any found objects alive) into managed code, because it has no chance to validate these objects and from my tests so far resulted in too many faulty objects being found (i.e. objects overlapping other objects on the heap).
As mentioned, it also doesn't know about any potential roots on the thread local stack. So there might be managed references to the rest of these, the crawler just can't find them for any of the above reasons. So it's that, or a native reference, yes.
trail trellis
Unity's native code usually allocates native allocations outside of Unsafe Utility and using the native roots system, that's also exposed via the native memory manager plugin API. That memory then shows up under the other Native Memory categories in the All Of Memory table. Technically you could write yourself a plugin that would allocate native memory for you with that API and give it an "Area" and "Object" name.
We're also looking into extending the UnsafeUtility API to follow a similar path and allow allocating a root (Area + Object Name combo) for your allocations to get grouped under. The details are still getting hashed out but stay tuned on that. 😊
compact zephyr
Unity's native code usually allocates native allocations outside of Unsafe Utili...
That sounds great, thanks for the info!