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

[James Zhao]

Here's a comparison of the memory (MB) and the CPU (ms) usage.
Memory Comparison - http://www.flickr.com/photos/92143816@N00/3859425885/
CPU Comparison - http://www.flickr.com/photos/92143816@N00/3860208646/

"new cont - don't force gc"  means a new continuation is created for each
iteration of the microthread.
"keep cont - don't force gc" keeps reusing a single continuation.
"keep cont - force gc -mem" means the above but do a GC.Collect() every
loop.

Can someone explain the discrepancy between the "new cont" and the "keep
cont"'s memory usage?

Thanks.
James



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

>
>
> 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/a40155f9/attachment.html