Gets the memory regions, which are segments of the heap, that make up the various garbage collection generations.
HRESULT GetGenerationBounds( [in] ULONG cObjectRanges, [out] ULONG *pcObjectRanges, [out, size_is(cObjectRanges), length_is(*pcObjectRanges)] COR_PRF_GC_GENERATION_RANGE ranges);
[in] The number of elements allocated by the caller for the
[out] A pointer to an integer that specifies the total number of ranges, some or all of which will be returned in the
[out] An array of COR_PRF_GC_GENERATION_RANGE structures, each of which describes a range (that is, block) of memory within the generation that is undergoing garbage collection.
GetGenerationBounds method can be called from any profiler callback, provided that garbage collection is not in progress.
Most shifting of generations takes place during garbage collections. Generations might grow between collections but generally do not move around. Therefore, the most interesting places to call
GetGenerationBounds are in
During program startup, some objects are allocated by the common language runtime (CLR) itself, generally in generations 3 and 0. Thus, by the time managed code starts executing, these generations will already contain objects. Generations 1 and 2 will normally be empty, except for dummy objects that are generated by the garbage collector. (The size of dummy objects is 12 bytes in 32-bit implementations of the CLR; the size is larger in 64-bit implementations.) You might also see generation 2 ranges that are inside modules produced by the Native Image Generator (NGen.exe). In this case, the objects in generation 2 are frozen objects, which are allocated when NGen.exe runs rather than by the garbage collector.
This function uses caller-allocated buffers.
Platforms: See System Requirements.
Header: CorProf.idl, CorProf.h
.NET Framework Versions: Available since 2.0
Submit and view feedback for