There's no way to get the managed object size in memory

[danmoseley]

Public API to detect the size of the managed object.

As mentioned in this article, we don't have such API to get the size in the runtime.

So far, if we want to do so, we have a choice to use some tools or techniques (not at the runtime), such as:

• using dotMemory.
• using WinDBG and calculate the object fields one by one.
• measuring the GC before and after ccreating the objects.

On of the very good example of that need, in the case we build customized cache and we want to keep the maximum size limit under control.

The developers around the world still asking and requesting such API.

How we can implement such thing

The good news that we already have this mechanism already implemented internally by SizedReference Type.

internal class SizedReference : IDisposable
{	
	//some code here

	public SizedReference(Object target) { ... }
	
	public Object Target { get {...} }

	public Int64 ApproximateSize { get { ... } }
	
	public void Dispose() {}
}

What we gonna do is just to expose it as Public API

Proposed API

I suggest to add some class under System.Runtime to as a wrapper to SizedReference

or just as extension to the object.

/// <summary>
/// Get the approximate size allocated for this object in the memory in bytes
/// </summary>
/// <param name="obj">the object that you want to know its size</param>
/// <returns>size in bytes</returns>
public static long GetSize(this object obj)
{
	//using SizedReference Type to get the approximate size
}

---

---

@alden-menzalgy commented on Sun Nov 05 2017

Hi,

There is no way to get the actual (or even an approximate) size of the cached object in the memory.

The case is, we have +100 customized cache for different purposes to accelerate our platform, for each cache we have

• Cache MaxSize
• Cache ConsumedSize
• Cache RemainingSize

Whenever we insert some object to be cached, we should detect its size to re-calculate aforementioned cache properties.

I know that's a complex issue and depends on many factors, so far we have some workarounds but non of them is official and we afraid to be changed in any minor or major release.

Should you add any API to get the object size in the memory ? or at least Type size and then we can add the object-specific data length.

Related Topics

Workaround 1
What Microsoft says about this issue

---

@JanEggers commented on Sat Nov 11 2017

you can use structs for your cache items and Marshal.Sizeof

---

@alden-menzalgy commented on Mon Nov 13 2017

It requires changing the structure that we've built the application with.
It may consider a workaround but not permanent solution

[danmoseley]

https://github.com/dotnet/coreclr/issues/14561

[danmoseley]

There is an internal mechanism SizedReference in Desktop and the linked issue is proposing porting this to .NET Core and making it public, which seems like it's what you need assuming you want the transitive size (which is what I assume it returned)

[joperezr]

@alden-menzalgy would you be interested in writing up a form api proposal for this?

[almez]

@joperezr yup, I'm interested.
Is there any procedure should be done before starting with the proposal ?

[almez]

@danmosemsft you're right, that's exactly what I'm talking about.

[joperezr]

Yes, here is a very good example of how an Api proposal should look: https://github.com/dotnet/corefx/issues/271. You can also find more info about our review process in general here https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md in case you need.

[almez]

Public API to detect the size of the managed object.

As mentioned in this article, we don't have such API to get the size in the runtime.

So far, if we want to do so, we have a choice to use some tools or techniques (not at the runtime), such as:

• using dotMemory.
• using WinDBG and calculate the object fields one by one.
• measuring the GC before and after ccreating the objects.

On of the very good example of that need, in the case we build customized cache and we want to keep the maximum size limit under control.

The developers around the world still asking and requesting such API.

How we can implement such thing

The good news that we already have this mechanism already implemented internally by SizedReference Type.

internal class SizedReference : IDisposable
{	
	//some code here

	public SizedReference(Object target) { ... }
	
	public Object Target { get {...} }

	public Int64 ApproximateSize { get { ... } }
	
	public void Dispose() {}
}

What we gonna do is just to expose it as Public API

Proposed API

I suggest to add some class under System.Runtime to as a wrapper to SizedReference

or just as extension to the object.

/// <summary>
/// Get the approximate size allocated for this object in the memory in bytes
/// </summary>
/// <param name="obj">the object that you want to know its size</param>
/// <returns>size in bytes</returns>
public static long GetSize(this object obj)
{
	//using SizedReference Type to get the approximate size
}

[almez]

@joperezr thanks you for your help, please find above proposal.

[jkotas]

The current internal SizedReference API has the following characteristics:

• The size is accurate only after Gen2 GC.
• These handles are expensive. Basically, the GC has to traverse the whole object graph for each to compute the size.

Are you happy with these performance characteristics?

I suggest to add some class under System.Runtime to as a wrapper to SizedReference

This wrapper cannot be built using the current SizedReference . The current SizedReference design requires you to create the handle first, then you have to wait for Gen2 GC to happen, and then you can see the approximate size at the time of the last Gen2 GC.

[jkotas]

cc @Maoni0 @swgillespie

[danmoseley]

@KKhurin cc

[Maoni0]

We only update the size for sized ref handles in gen2 GC because gen2 GCs already need to traverse these object graphs anyway which means it adds no overhead aside from having to write the size into the data associated with these handles; in Server GC there is a caveat because Server GC has multiple GC threads and since these handles were supposed to get the inclusive size, ie, as long as something is in the object graph for the handle it's counted, even if it's referred to by other sources like the stack (so we have all threads finish with the sized ref handle traversing before we start with other sources).

Things to think about for the usage scenario for this -

• do you want inclusive size or exclusive size? asp.net folks originally wanted inclusive size; now we are discussing using the exclusive size instead based on their usage scenario.

• does this need to be accurate? right now we do this in gen2 because it's cheap (gen2 already needs to do this anyway). also if you want to get this size in gen0/1 GCs there's also complications of an object being alive because an older generation object is holding onto it. and if you want to get the size while the user threads are running the graph can be modified as you are getting the size.

there are ways to not have GC do this - you could do this via debugging APIs (ICorDebugProcess5::GetTypeLayout and related), profiling APIs (similar to debugging ones) or reflection (you could get the fields of an object and calculate the size of each). not to say these are easy to do or don't have their own set of problems - for example, if you use the debugging/profiling APIs you can't attach another live debugger/profiler to the same process.

[stephentoub]

There hasn't been any progress on this issue for a couple of years, including no follow-up to the questions posed about whether the significant implications of the proposal still make it useful. As such, I'm going to close this. Thanks.