Re: Garbage collection

Barry Kelly (CodeGear) wrote:

Allocation policy should ideally be at the allocation site, not
associated with the type. This is a known mistake that the Microsoft
Managed C++ guys made, and fixed (syntactically if not orthogonally) for
C++/CLI: introducing 'gcnew', rather than depending on types annotated
with '__gc'.


+1 !!!

But if " you don't have nothing else to do ;-) " (TM) then perhaps it's a very nice-to-have feature (not really a must-have) to have also an GC attribute on type - to express an exclusion filter - but, imho, definitely do not rely on types _only_ to define the allocation policy. Ie. sometimes is handy to have:

TMyGCStringList = class(TStringList); auto; //<- this is GCed
....<my class definition>
end;

and to disable it when we need it:

var
objMyTSL: TMyGCStringList; explicit; //<- something like this

....but of course, usually we need to mark the objects as GCed not classes, imho.


Non-reference-counted GC typically needs to search the heap for
references in order to be sure it's safe to deallocate, and GC is almost
always invoked by an allocation request (not enough free space to
allocate -> collect and then check again -> still not enough free space,
ask OS for more).


I would see a very interesting option in triggering the GC at an end-of-scope signal, or at least a generation of it - assuming that we speak about a generational engine. This is important when we speak from behavioral POV, ie. what /the user/ does, not what the /program/. Ie. usually a end-of-scope point is usually the end of an action, and many times, at least in the actions from the presentation layer the users stops to see the results of their actions (and hence the program). Here, imho, it's quite interesting to evaluate the possibility of a lower-priority (ie. will start only if the program is (almost) idle) dedicated GC thread(s). Also, I must confess that I don't like the GC therm. What I would like to see in Delphi it's a more advanced memory manager - but, anyway, I want to praise the Pierre's achievements - having a configurable GC (see my other posts) and also, having a memory "defragmenter" to work in a separate thread in the low-activity periods of program (keyboard data entry stages / idle times aso.).

Thus, GC can start on any thread that allocates memory, and it needs to
freeze some parts of the world, or at least mark memory ranges
unmodified and search them and then use write barriers (basically mark
memory range as dirty if it's written to) to detect when they've been
modified (and thus have to be searched again). With multi-core CPUs and
especially NUMA machines, it can be better to parallelize the searching
process, and have multiple (possibly dedicated) threads for GC.

In any case, there's no big benefit to somehow trapping the thread which
made the original allocation (if it's even still alive) and getting it
specifically to do the searching.

And on the other side, since the allocation thread is blocked and can't
continue without the memory it's asking for, there's typically no big
drawback to doing some fraction (1/Total-CPU-core-count) (if not all,
especially when heap is small such as gen0 of a generational heap) of
the collection on the allocating thread, in a non-concurrent GC, since
it also saves a context switch.


Yes, the main point is to have a engine which can mitigate the performance hits by delaying the (de)allocation - and this, imho, implies a separate (dedicated) thread(s). Something like a run-time configurable memory server. Also, such a server can do other things like memory preallocation thing which would be very interesting for a certain range of applications (at least) - for ex. db apps in which it happens to work from a small amount of time.

And did I mention "configurable at runtime"? <g>

-- Barry


Nice discussion, btw.

PS: Do you are aware of

http://www.ravenbrook.com/project/mps/

and

http://www.answers.com/topic/region-inference
?
<region inference is a nice thing but implies a little bit of dedicated programming for it, imho>


hth,

--

m. th. .

Relevant Pages

  • Re: CMemoryState & multi-threaded application
    ... released, and interspersed with smaller allocations, *will* cause fragmentation. ... I've sometimes done this by having a thread that wakes up once a minute and traces memory. ... Manager, Process Viewer, etc., since they are largely clueless about storage allocation ...
    (microsoft.public.vc.mfc)
  • Re: safe scanf( ) or gets
    ... I've been searching for something like this since a few days.. ... > For getstype of things, uses the sfgetrfunction which does memory ... > as necessary to get the entire string. ...
    (comp.lang.c)
  • Re: How to release heap memory that is marked as free
    ... As I said, fragmentation is a very serious problem, and one of the most serious problems ... my allocator was accused of using massive amounts of memory. ... I'm going to have to re-think the memory allocation that I'm ... process's 'working set'. ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... memory they can consume. ... So we need the extra (skb) ... included in the reserve? ... if the allocation had to dip into emergency reserves, ...
    (Linux-Kernel)
  • Re: Memory leak with CAsyncSocket::Create
    ... read my essay on how storage allocators work. ... Create method is consuming system memory that is not released back to ... The memory consumption is either shown as "Mem Usage" on the Task ... many levels of allocation going ...
    (microsoft.public.vc.mfc)