MemoryProfiler: Jagged array may not be collected in memory captures

[pw_prg_yinchao]

Hi there, I found jagged array (T[ ][ ]) may not be collected in memory captures.

Test codes are something like:

public class TestComponent : MonoBehaviour
{
    ...
    private TestClass[] array1 =
    {
        new TestClass(),
    };
    private TestClass[][] array2 =
    {
        new [] {new TestClass(), null},
        null,
    };
    ...
}

Then managed object array2 and managed type TestClass[ ][ ] not found in captured snapshot (using Unity 2019.4.5f1 + com.unity.memoryprofiler@0.2.9-preview.1).

[pw_prg_yinchao]

And, managed object of type TestClass[ ] inside array2 also not found.

[Peter77]

FYI, same issue in Heap Explorer:

Jagged array may not be collected in memory captures

[pw_prg_yinchao]

Alright, I found it has been fixed in 2019.4.10:

Profiler: Fixed an issue with multi-dimensional arrays of reference types not having their metadata type being reported (1273416)

Unity 2019.4.10

[MartinTilo]

Yes, the package can’t fix everything as the editor and runtime also have quite some backend code to report the data, so updating to the latest Editor patch version and latest package version should usually be the first thing to try when hitting any bugs with it, as we are basically unaware of any bugs with it at the moment.

[pw_prg_yinchao]

@MartinTilo

Yes, the package can’t fix everything as the editor and runtime also have quite some backend code to report the data, so updating to the latest Editor patch version and latest package version should usually be the first thing to try when hitting any bugs with it, as we are basically unaware of any bugs with it at the moment.

Thank you for the reply!

But I found another question: it seems that interned strings, including literals and strings passed to string.Intern(), neither be collected. Is this expected? Or a known issue?
For me, it is unexpected. Because these strings should be on the heap, and contribute to the total size of managed heap, right?

[MartinTilo]

@pw_prg_yinchao

But I found another question: it seems that interned strings, including literals and strings passed to
string.Intern()
, neither be collected. Is this expected? Or a known issue?

That’s how Interned strings work in C#, also see the Microsoft Docs on this:

Performance Considerations
If you are trying to reduce the total amount of memory your application allocates, keep in mind that interning a string has two unwanted side effects. First, the memory allocated for interned String objects is not likely to be released until the common language runtime (CLR) terminates. The reason is that the CLR’s reference to the interned String object can persist after your application, or even your application domain, terminates. Second, to intern a string, you must first create the string. The memory used by the String object must still be allocated, even though the memory will eventually be garbage collected.

[pw_prg_yinchao]

@MartinTilo

That’s how Interned strings work in C#, also see the Microsoft Docs on this:

Oh, that is to say, the interned string instances will not be created until I try to access them by literals or string.Intern()?

[MartinTilo]

No. As I understand this, literals will be part of the intern pool from whenever the code they live in gets JIT compiled or I guess statically initialized? Those that you intern explicitly will be added to the intern pool if they didn’t already live there, but would have been created by you before being added there. Once interned or retrieved from there, you’ll only have references to the same instance.

If you recreate the string and get it from the interned pool, the recreated one will be a separate instance that will get collected by the GC

[pw_prg_yinchao]

Thank you for the explanation! And I agree with you mostly.
But I am confused with where is the pool that contains the interned strings. Is it on the heap?
If it is, I am wondering why they not be collected by snapshot. Otherwise, it doesn’t matter anymore

[MartinTilo]

@pw_prg_yinchao

But I am confused with where is the pool that contains the interned strings. Is it on the heap?
If it is, I am wondering why they not be collected by snapshot.

afaik, they are stored together with Type Metadata and Generics in the VM Domain Heaps, which are separate from the VM GC-Managed Heaps shown in the Memory Profiler tables. Memory Map does show Domain Heaps for Mono builds, but not their content, and not yet visually distinct from empty GC Heaps as it is missing the info to distinguish between the two (2021.2 already has that info and it’ll get backported but there is no version of the Memory Profiler yet available that would highlight that difference yet either).

Good point though. We’ve taken a note that it might be interesting to list these out too.

[pw_prg_yinchao]

@MartinTilo

afaik, they are stored together with Type Metadata and Generics in the VM Domain Heaps, which are separate from the VM GC-Managed Heaps shown in the Memory Profiler tables. Memory Map does show Domain Heaps for Mono builds, but not their content, and not yet visually distinct from empty GC Heaps as it is missing the info to distinguish between the two (2021.2 already has that info and it’ll get backported but there is no version of the Memory Profiler yet available that would highlight that difference yet either).

Thank you very much for the explanation in detail!

@MartinTilo

Good point though. We’ve taken a note that it might be interesting to list these out too.

So glad to hear that! Afaik, interned strings often take considerable memories and there is no good way to profile them now. So this is important information for us.