locked
Memory Profiling - Consuming Memory Details by Class RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    I need to take the details of objects that are currently in the CLR's memory of a .Net process. I used ObjectAllocated(..) call back in the profiler to store each and every objects being created in CLR. 

    I was getting too much of overhead upto 1 minute. Then i came accross ObjectReferences(..) call back which gives me the live objects after each Garbage collection event conpletes. On replacing with this call back , the overhead was minimal upto 10 seconds. 

    Firstly i need to be clear if ObjectReference gets called when a GC is in progress.

    And Since ObjectReferences(..) gave me minimal overhead and i was able to get the object details , can i go with this callback itself? Or is there any negative impact or any improper values i would get from ObjectReferences(..) call back?
    Tuesday, May 16, 2017 12:58 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    I haven't verified any of this, but I strongly suspect that you will only get this callback for objects in the generation being collected and are found to be referenced. An object in Gen1 won't be reported for a Gen0 collection, while an object that gets collected in Gen0 would not be reported at all.

    Objects will only be reported during collection and not when allocated, so a short lived process might not report any objects if in does not live long enough to trigger a collection.

    Tuesday, May 16, 2017 9:59 PM