Gerenciamento de memória GC

Introdução (que deve ser lida depois).

http://www.hpl.hp.com/personal/Hans_Boehm/gc/
http://www.hpl.hp.com/personal/Hans_Boehm/gc/04tutorial.pdf

Quem monitora a lista comp.lang.c++ deve ter visto o tópico sobre o
garbage Collector

[http://groups.google.com/group/comp.lang.c++/browse_thread/thread/8100fa1e738da5a4?hl=en]

lendo o pdf descobri isto (slide 64)

Bora lá.

************************************************************

Other experiences • Generally works quite well for small (<>
clients or on 64-bit machines. • Sometimes needs a bit pointer location information for frequently occurring heap objects. Usually GC_MALLOC_ATOMIC is sufficient for C code. • Some successful uses with much larger heaps. • Some problems with 500MB heaps on 32-bit machines. • Large arrays (> about 1MB) sometimes problematic. • Fragmentation cost (for heaps > a few MB) is typically less than a factor of 2. • Fragmentation essentially never an issue for small objects. • Whole block coalescing is important. • I haven't seen much of a problem with long running apps. (Vesta, Xerox printers). • Stationary objects allow one word object headers in gcj.

***************************************************
tem também os becnhmarks




C expl. free é o malloc que nós costumamos usar BDW GC é o Garbage Collection.

pra completar vai as dicas que recebi no grupo cppbrasil [google groups]

***************************************************************

Arrays grandes não costumam ser um problema pro Boehm GC desde que
você não fique alocando/desalocando eles com freqüência. Eles causam o mesmo
problema de fragmentação que com malloc.

Quanto a performance. Bom, para ter uma performance razoavel é necessário usar alocação
tipada e, principalmente, trabalhar sem interior pointers. Se for possível ter essas duas restrições
no teu projeto, o BoehmGC com o coletor incremental ou paralelo é aceitavel.

Porém GC em uma linguagem como C++, que não tem um sistema de tipos forte e a pilha não é tipada
é bem complicado mesmo. Não tem milagre. Vai ser mais lento e vai usar mais memória.

Porém a não ser que você esteja trabalhando com programas extremamente sensíveis a performance,
o GC vai ser o menor dos teus problemas. Normalmente não irá ocupar mais que 10% do total de cpu
usado.

Quanto ao problema de fragmentação, ele existe e é real com heaps grandes em sistemas 32 bits. Não espere
conseguir usar heaps de 1.5 - 2 Gb num sistema 32bits.

*****************************************************************

Conclusão
deixa de ser preguiçoso use o GC só como detector de memory leak ele faz muito bem isso
e a Mozilla usa ele para isso, um makefile com a opção --with-debug resolveria isso. Creio que tb deva fazer um comparativo malloc vs new para arrays e objetos.

espero que as informações tenhão sido uteis
ps: 10% da cpu é um preço muito caro, quando eu mexer no Makefile faço alguns benchmarks devia aprender a usar a Boost pra isso també né.