garbage collection - How does the .NET CLR distinguish between Managed from Unmanaged Pointers? -
everything jited native machine code, ultimately, have native stack in .net gc needs scan object pointers whenever garbage collection.
now, question is: how .net garbage collector figure out if pointer object inside gc heap managed pointer or random integer happens have value corresponds valid address?
obviously, if can't distinguish two, there can memory leaks, i'm wondering how works. or -- dare -- .net have potential leak memory? :o
as others have pointed out, gc knows precisely fields of every block on stack , heap managed references, because gc , jitter know type of everything.
however, point well-taken. imagine entirely hypothetical world in there 2 kinds of memory management going on in same process. example, suppose have entirely hypothetical program called "intermothra chro-nagava-sploranator" written in c++ uses traditional com-style reference-counted memory management pointer process memory, , objects released invoking release method correct number of times. suppose sploranator hypothetically has scripting language, jabbascript, maintains garbage-collected pool of objects.
trouble arises when jabbascript object has reference non-managed sploranator object, , same sploranator object has reference right back. that's circular reference cannot broken jabbascript garbage collector, because doesn't know memory layout of sploranator object. there potential here memory leaks.
one way solve problem rewrite sploranator memory manager allocates objects out of managed gc pool.
another way use heuristic; gc can dedicate thread of processor scan all of memory looking integers happen pointers objects. sounds lot, can omit pages uncommitted, pages in own managed heap, pages known contain code, , on. gc can make guess if thinks object might dead, , cannot find pointer object in memory outside of control, object dead.
the down side of heuristic of course can wrong. might have integer accidentally matches pointer (though less in 64 bit land). extend lifetime of object. cares? already in situation circular references can extend lifetimes of objects. we're trying make situation better, , heuristic so. not perfect irrelevant; it's better nothing.
the other way can wrong sploranator have encoded pointer, by, say, flipping of bits when storing value , flipping right before call. if sploranator actively hostile gc heuristic strategy doesn't work.
resemblance between garbage collection strategy outlined here , actual gc strategy of product entirely coincidental. eric's musings implementation details of garbage collectors of hypothetical non-existing products entertainment purposes only.
Comments
Post a Comment