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

[Zoltan Varga]

On Wed, Aug 26, 2009 at 3:11 AM, James Zhao <jameszhao00 at gmail.com> wrote:

> 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?
>

Nothing of production quality right now.

         Zoltan


>
> 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/20090826/85ea07e4/attachment.html