When is memory, allocated by .NET process, released back to Windows -
the setup
.net allocates memory each generation’s heap (0, 1, 2, loh) in segments continuous block of memory, on startup, , when attempts satisfy allocation request, after collection.
this memory allocated each heap level off application “warms up”, except potentially generation 2, , large object heap. during garbage collection, each heap (0, 1, 2) swept , compacted, except large object heap (loh), swept.
i understand ‘sweep’ part of collection mean gc identifies objects no longer rooted , available collection (or finalization) , ‘compact’ means addresses still alive in heap reorganized available remaining heap has more continuous memory available it.
as budget each segment within heap exceeded, .net allocate segment in order fulfill allocations if can.
the question
my question comes down happens memory in each heap, not used application (committed) longer, still reserved .net? when released os?.
i believe scenario process might appear consuming lot of memory (virtual size quite large, private bytes small), when inspecting heaps mostly free space. caveat, total size of heaps may quite small, , not account memory being consumed process.
there no blocked finalizer , looks healthy process - may have been running weeks before triggered monitor alert (e.g.).
trying further clarification of question, if read tess .net memory management - restaurant analogy, if tables heap segments, restaurant ever lose tables (e.g. free heap segments)?
edit
- removed confusing reference working set , chickens
- added reference tess restaurant analogy
my answer - doesn't matter. os gives application (within .net runtime runs) virtual memory. not 'real' memory. os can put each page of virtual memory wherever likes - on processor, in main memory, on disk. so, possible app use more memory amount of ram on system, , os copy bits needed to/from disk ensures app keeps running (modulo addressing & technical limitations).
the os manages virtual memory of processes on system, , ensures 1 program doesn't hog ram on system detriment of other programs. when .net runtime asks memory system use in heaps, doesn't use it, memory (if system low on free ram) moved disk, because isn't being accessed.
clarification via email tess: (emphasis mine)
the segment sizes stay same throughout course of application, there 2 things consider here.
the allocations segment virtual allocation, meaning while reserve virtual memory, commit use, private bytes used segment not same segment size, means after gc, private bytes go down, while virtual bytes stay same.
when segment no longer used, i.e. if happen gc in segment no longer contains .net objects, virtual alloc returned os.
taking on faith, heap segments (restaurant tables) returned os.
Comments
Post a Comment