After running the VS2010 profiler with Object Lifetime Tracking in my app, I have this on a particular class :
Number of Instances----------1?418?276
%Total Instances --------------------- %5.8
Total Bytes Allocated ------- 158?846?912
%Total Bytes -------------------------- %5.94
Gen 0 Instances Collected --------- 5?196
Gen 1 Instances Collected --------54?894
Gen 2 Instances Collected ----747 874
Instances Alive At End --------- 610 312
Gen 0 Bytes Collected ----------- 581 952
Gen 1 Bytes Collected ---------6?148?128
Gen 2 Bytes Collected ---------3?761?888
As you cans see, half of all created instances end up mainly as Gen 2, and the other half is staying alive until the end of the App. [ha, ha, ha, ha, staying alive, staying alive... -> Ok sorry, I could'nt resist...]
What bothers me is that these instances should have a very short lifetime (It's basically a datafield class - that could be a struct, but I preferred to make it a class to "activate" GC on it).
These instances are created by reading very large binary files (each line being a class/ a record) and passed via a small sized queue by delegate/event to workers that basically just read it, put it in queues (which are very regularly dequeued), and then terminate (background workers ending normally). I guess Events are unsubscribed to when workers no more exist.
So, is there a way to identify where are these references hiding ? Because if they are not GC'd they ARE still referenced somewhere, but how to tell for sure ? I'm tired of guessing and trying so many hypothesis SO if somebody has more rational guidelines or a fair checklist and/or tools / precise profiler places to look at, I welcome it.
Complementary Resources to the Answers
Visual GCRoot via DGML - Thanks to Richard Szalay
Also, this video GCRoot Demo from Chris Lovett is very educative on the subject.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…