[Mono-dev] Image mempool grows with use of mono_runtime_invoke on value types

Zoltan Varga vargaz at gmail.com
Tue Nov 4 07:04:19 EST 2008


  This is now fixed in SVN. In the meantime, you can try using the
mono_method_get_unmanaged_thunk () functionality to avoid this problem:



On Tue, Nov 4, 2008 at 2:19 AM, Ewen Cheslack-Postava
<ewencp at cs.stanford.edu> wrote:
> Hi all,
> I'm embedding mono in my application.  We happen to call methods from
> unmanaged code on value types pretty regularly and we noticed memory
> usage getting out of hand after a few days running continuously.  I've
> tracked the problem down to the image's mempool which is growing
> continuously.  The offending function is
> mono_marshal_get_runtime_invoke, specifically the call to
> signature_dup_add_this around line 4707 of marshal.c.   The
> MonoMethodSignature is duplicated and the memory is allocated from the
> image's memory pool.  The cache lookup that is happening after that is
> succeeding and the allocated signature just sits around until the
> program ends.
> So I've tracked the problem down but I'm not sure what to do about it.
>  This condition seems to be true for any non-static method invocations
> on value types.  Is there some way to get a MonoMethod* which doesn't
> have hasthis set so I can avoid this case?  Even if not, is the memory
> pool the right place to allocate this from?  It isn't cleaned up until
> the image is closed but the signature is immediately discarded.  Even
> if I call the same method over and over, a new signature is generated
> each time even though it appears they should be identical.  Should
> there be a cache for these duplicated signatures as well so the
> mempool doesn't have potentially unbounded growth?
> Thanks,
> -Ewen
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list