ansaurus

Question

How to determine why an object is pinned

Answer 1

A:

In my experience it is rarely useful to look at Object[] as it is the underlying type of a lot of types, which means that you'll end up with lots of these on the heap making it harder to identify the correct one. Additionally internal structures such as the interned string table is also stored as an Object[].

If you are trying to figure out why the application uses a lot of memory, try to identify other types that may or may not encapsulate Object[] and find out what roots these.

If you provide more information on what you're trying to accomplish I may be able to provide more specific advice.

EDIT: Fragmentation isn't necessarily as bad as it may sound and 100 MB free doesn't strike me as an alarming high number. Have you identified if the free blocks are in the generational heap on on the large object heap?

What is the output of !eeheap -gc?

Brian Rasmussen 2009-10-13 19:54:36

I am looking at possible memory fragmentation for OOM issues I am having. Using http://www.zhaun.net/post/Debugging-NET-virtual-memory-fragmentation-with-WinDbg.aspx as a starting point. I am seeing very different !gcroot output in the memory dump I have there are 48093 Free objects consuming 112MB the dump file is 1.2GB. Running a !gcroot takes about 30 minutes so I can only sample random objects. I don't think the type of the object is that important, just that something has it pinned.This is only one thing we are looking at for OOM problems. Already got a 300MB event leak over 10hours

Darryl Braaten 2009-10-13 21:01:57

In the grand scheme of things 100MB is not that large, but it could be cluttering up things. I believe the object I was looking at are in gen2, it is a desktop application so most things end up in gen2. The LOH as 60MB free

Darryl Braaten 2009-10-15 17:41:43

Your heap usage is 800 MB and the eeheap shows that the majority is on gen 2 heap while only a bit is on LOH. If you want to identify free blocks you can do a !dumpheap -type Free

Brian Rasmussen 2009-10-15 18:43:45

Am I correct in my understanding that !dumpheap -type Free returns space that has no objects, and is unusable? The pinned object in my question is an the next object after one of the free items. I just picked a couple at random from the list of 48,0093 I am thinking that this is a dead end.

Darryl Braaten 2009-10-15 23:04:13

Yes, the free spots are free space on the heap. If they are located next to pinned objects they will not be made available during compaction. However, those objects should not be pinned forever, so eventually compaction should be able to get rid of the free chunks.

Brian Rasmussen 2009-10-16 05:36:25

Unless I am leaking pinned objects.

Darryl Braaten 2009-10-16 20:27:12

Answer 2

A:

GCRoot will not generally tell you why something is pinned. A lot of the object arrays that you find in CLR are used for internal things. Instead, reading your comment on the other answer, could I suggest that you first start with something different to track down your memory leak?

Start with "!dumpheap -stat" and look at the biggest memory users there. However, ignore the basic CLR types such as object[], string, etc. Find which of your objects (defined as "not something in mscorlib or system.dll) that are there, and find out what roots those. It's usually easier to track down a leak from that direction, even if it turns out that you are leaking a primitive types in your application.

This is usually how I track down managed leaks in CLR, and it works fairly well for most leaks.

Lee Culver 2009-10-13 22:37:45

Yes, which is why I am asking how to determine why an object is pinned. gcroot just tells me that an object is pinned.

Darryl Braaten 2009-10-13 23:10:32

There isn't a way to determine why an object is pinned as far as I know. Again, going back to this specific example, a pin to an object array is how we store static variables in CLR. So, you may be looking at where we house static variables, but I can't be sure. Some pinned handles you can tell why they are pinned by the type (RefCnt handles, for example, are only used in com-interop). In general though, you cannot determine why an object is being pinned without access to CLR sources and symbols.

Lee Culver 2009-10-14 17:26:59

Answer 3

+2 A:

The !findroots command in .NET 4's SOS (or !refs in SOSEX) waits until the next GC (you can specify which generation) and will then tell you what roots the object has.

Richard Szalay 2010-03-01 21:43:02

ansaurus

tags:

views:

answers:

How to determine why an object is pinned

related questions