[Mono-dev] Mono Continuations - Memory keeps increasing after store()

[James Zhao]

Hi,

Thank you for that info. So that means if current stack > last stack, the
stack pointer is C freed and malloced. If that's the case, then the behavior
I've been experiencing is even more bizarre.

Also, you mentioned the built-in gc. What other GCs are available?

Thanks,
James


On Tue, Aug 25, 2009 at 8:58 PM, Zoltan Varga <vargaz at gmail.com> wrote:

> Hi,
>
>   mono_gc_free_fixed () is a no-op when using mono's built in GC, since
> mono_gc_alloc_fixed () is implemented as a call to GC_malloc ().
>
>                      Zoltan
>
> On Wed, Aug 26, 2009 at 2:55 AM, James Zhao <jameszhao00 at gmail.com> wrote:
>
>> Hi,
>> Here's Mono Continuations' continuation_store (...). From looking at the
>> code below, it appears as though store() follows these two branches:
>>
>>  1. cont->saved_stack && num_bytes <= cont->stack_alloc_size - use the
>> memory directly
>>
>>  2. else - gc free the used memory, and create some new memory.
>> However, the weird thing is if I repeatedly use continuation_store(), the
>> memory usage increases until at a later step a huge and laggy GC operation
>> is done. Can anyone explain why this happens?
>> If I alloc/free a continuation for roughly each time I call store , the
>> continuation appears to be GC'ed immediately.
>>
>>  Thanks
>> James
>>  static int continuation_store (MonoContinuation *cont, int state,
>> MonoException **e) { MonoLMF *lmf = mono_get_lmf (); gsize num_bytes; if
>> (!cont->domain) *e = mono_get_exception_argument ("cont", "Continuation not
>> initialized"); if (cont->domain != mono_domain_get () || cont->thread_id !=
>> GetCurrentThreadId ()) *e = mono_get_exception_argument ("cont",
>> "Continuation from another thread or domain"); cont->lmf = lmf;
>> cont->return_ip = __builtin_return_address (0); cont->return_sp =
>> __builtin_frame_address (0); num_bytes = (char*)cont->top_sp -
>> (char*)cont->return_sp; /*g_print ("store: %d bytes, sp: %p, ip: %p, lmf:
>> %p\n", num_bytes, cont->return_sp, cont->return_ip, lmf);*/ if
>> (cont->saved_stack && num_bytes <= cont->stack_alloc_size) { /* clear to
>> avoid GC retention */ if (num_bytes < cont->stack_used_size) memset
>> ((char*)cont->saved_stack + num_bytes, 0, cont->stack_used_size -
>> num_bytes); } else { tasklets_lock (); internal_init (); if
>> (cont->saved_stack) { mono_g_hash_table_remove (keepalive_stacks,
>> cont->saved_stack); mono_gc_free_fixed (cont->saved_stack); }
>> cont->stack_used_size = num_bytes; cont->stack_alloc_size = num_bytes * 1.1;
>> cont->saved_stack = mono_gc_alloc_fixed (cont->stack_alloc_size, NULL);
>> mono_g_hash_table_insert (keepalive_stacks, cont->saved_stack,
>> cont->saved_stack); tasklets_unlock (); } memcpy (cont->saved_stack,
>> cont->return_sp, num_bytes); return state; }
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090825/c4810235/attachment.html