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

[James Zhao]

Oh and here's the actual data
http://spreadsheets.google.com/pub?key=tYFncjADIjzq3rtmWF6EWdw&output=html

On Wed, Aug 26, 2009 at 4:19 PM, James Zhao <jameszhao00 at gmail.com> wrote:

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