Re: Memory again

[Carsten Mattner <carstenmattner@googlemail.com>]

On Sat, Nov 26, 2011 at 6:54 PM, Dmitry Antipov <antipov@mvista.com> wrote:
> On 11/26/2011 06:58 PM, Carsten Mattner wrote:
>
>> Allow me to be naive and ask this: what about compaction?
>
> Compaction implies the moving of live objects, which means that you
> should be able to find _all_ pointers to such objects and update them.
> Emacs GC has no such features, but it's technically possible
> to enhance mark/sweep GC to do some heap compaction.

The GC I deal with most is Erlang's and it's using a copying gc
algo where the heaps are usually plenty and small enough
to make GC in 999 out of 1000 times to be unnoticeable that
if it's noticeable you found an inefficient piece of your own code.

I don't have as much real life experience with Sun's JVM
or other popular vms' GCs.

>> Would the allocator in use fragment the overall system memory
>> space if it frees more aggressively?
>
> If you want to ask 'if we will run GC more often, will it reduce
> heap fragmentation', the answer is most probably 'no'. You can try
> to play with 'gc-cons-threshold' and 'gc-cons-percentage' and see
> what happens. But, in general, heap fragmentation issues can't be
> solved this way.
>
> Other possible meanings of 'more aggressively' makes no sense for
> simple (non-generational, non-incremental) mark/sweep GC since it
> _always _ marks all live data and _always_ sweeps the whole
> Lisp data regions of the heap.

My question was about doing many tiny alloc/free calls and
fragmenting the kernel vm. Do applications like Emacs have to
consider that and do large as in 2x as required-but-not-available
"just-in-case-I-need-more" allocations?

> If you're looking for good introduction to GC stuff, I would
> recommend ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps.

Thanks.