AW: [Mono-devel-list] GC/Memory allocation performance

[Jörg Rosenkranz]

Hi Zoltan,

I think the garbage collector should be working in all cases.
So a special version isn't the right direction? 

Maybe this performance difference depends more on the garbage
collector implementation? As I understand it (very basic understanding ;-))
in MS's implementation memory allocation is as simple as incrementing 
the pointer to the next free memory block by the amount of allocated 
memory. During collection all used blocks are shifted to avoid memory 
fragmentation. This may speed up allocation but pointers doesn't stay 
constant during runtime.

How's Boehm's GC working? Maybe the fragmentation slows down memory 
allocation?

Bye,
Joerg

> -----Ursprüngliche Nachricht-----
> Von: Varga Zoltan [mailto:vargaz at freemail.hu] 
> Gesendet: Freitag, 30. Mai 2003 15:08
> An: Jörg Rosenkranz
> Cc: mono-devel-list at lists.ximian.com
> Betreff: Re: [Mono-devel-list] GC/Memory allocation performance
> 
> 
> 
>                                                 Hi,
> 
>    The current allocation path is not very optimized under 
> mono. It involves the following:
> - A call to the icall wrapper for mono_object_new_specific.
> - A call to mono_object_new_specific
> - A call to mono_object_new_alloc_specific
> - A call to GC_MALLOC
> - A call to mono_profiler_allocation
> + a few comparisons etc.
> 
> It would be easy to create an optimized version for the 
> common case (no profiler, no remoting etc.). I could do this 
> if there is interest.
> 
>                                        bye
> 
>                                           Zoltan
> 
>