[Mono-dev] Leaky JIT while running MonoDevelop
Rodrigo Kumpera
kumpera at gmail.com
Thu Aug 14 19:13:54 EDT 2008
Hi Casey,
I have an idea on what might be the cause of the leak, and it only happens
under amd64 and aot.
Under amd64 mono_analyze_liveness2 is called from mono_analyze_liveness if
aot is enabled.
This will set MonoMethodVar::interval for a bunch of vars.
In mono_linear_scan, if ->internal is set it calls mono_linear_scan2 and
return. Notice that
mono_linear_scan release the supplied lists, "vars" and "regs", while
mono_linear_scan2 doesn't.
I don't have an amd64 setup here, but could you test if the following change
fix your issue:
Index: mono/mini/linear-scan.c
===================================================================
--- mono/mini/linear-scan.c (revision 110530)
+++ mono/mini/linear-scan.c (working copy)
@@ -509,4 +510,6 @@
g_list_free (active);
g_list_free (inactive);
+ g_list_free (vars);
+ g_list_free (regs);
}
Thanks,
Rodrigo
On Thu, Aug 14, 2008 at 7:12 PM, Casey Marshall
<casey.s.marshall at gmail.com>wrote:
> Oh, but: oof. I'm actually pretty sure this isn't in the JIT, but it's just
> getting blamed on the JIT because it's allocating things via glib -- those
> allocations are cached, and probably whatever is really leaking is just
> reusing the GList memory originally allocated by the JIT.
>
>
> Rodrigo Kumpera wrote:
>
>> Hi Casey,
>>
>> We did a lot of work fixing many kinds of memory leaks under the runtime
>> and JIT.
>> There are a few know issues, but none that would show in valgrind like
>> this. And none
>> that would leak that much.
>>
>> I'll take a look at this issue in the comming days to see if I can narrow
>> it down.
>>
>> In the mean time, do you mind sending the whole valgrind report?
>>
>> Thanks,
>> Rodrigo
>>
>> On Thu, Aug 14, 2008 at 3:07 PM, Casey Marshall <
>> casey.s.marshall at gmail.com <mailto:casey.s.marshall at gmail.com>> wrote:
>>
>> I've been seeing a memory leak -- or, maybe instead, "unbounded memory
>> growth" -- while running MonoDevelop (SVN code of MD, mono-2-0 SVN of
>> Mono). I've been running it under valgrind, and after running it
>> overnight, I find traces like this in the output:
>>
>> > ==7947== 862,223,392 bytes in 1,737,838 blocks are still
>> reachable in loss record 238 of 238
>> > ==7947== at 0x4C21F8F: memalign (vg_replace_malloc.c:460)
>> > ==7947== by 0x4C22028: posix_memalign (vg_replace_malloc.c:569)
>> > ==7947== by 0x507D299: (within /usr/lib/libglib-2.0.so.0.1600.4)
>> > ==7947== by 0x507E0F0: g_slice_alloc (in
>> /usr/lib/libglib-2.0.so.0.1600.4)
>> > ==7947== by 0x506035D: g_list_prepend (in
>> /usr/lib/libglib-2.0.so.0.1600.4)
>> > ==7947== by 0x432953: mono_arch_get_allocatable_int_vars
>> (mini-amd64.c:910)
>> > ==7947== by 0x5579A9: mini_method_compile (mini.c:12490)
>> > ==7947== by 0x558CF8: mono_jit_compile_method (mini.c:12819)
>> > ==7947== by 0x42C5A2: mono_magic_trampoline
>> (mini-trampolines.c:249)
>> > ==7947== by 0x415B164: ???
>> > ==7947== by 0x8FCA917: ???
>> > ==7947== by 0x85E7E9F: ???
>>
>> (there are many other traces, but they're all two orders of magnitude
>> smaller, in terms of memory size)
>>
>> I ran the same test again, this time with --optimize=-linears (which is
>> where at least the above trace came from) and without --debug, and
>> memory still grew, but not quite as quickly. I got another valgrind
>> trace out of that run:
>>
>> > ==5807== 794,797,632 bytes in 1,601,948 blocks are still
>> reachable in loss record 238 of 238
>> > ==5807== at 0x4C21F8F: memalign (vg_replace_malloc.c:460)
>> > ==5807== by 0x4C22028: posix_memalign (vg_replace_malloc.c:569)
>> > ==5807== by 0x507D299: (within /usr/lib/libglib-2.0.so.0.1600.4)
>> > ==5807== by 0x507E0F0: g_slice_alloc (in
>> /usr/lib/libglib-2.0.so.0.1600.4)
>> > ==5807== by 0x506035D: g_list_prepend (in
>> /usr/lib/libglib-2.0.so.0.1600.4)
>> > ==5807== by 0x52AF25: mono_allocate_stack_slots_full
>> (mini.c:9812)
>> > ==5807== by 0x432320: mono_arch_allocate_vars (mini-amd64.c:1137)
>> > ==5807== by 0x558127: mini_method_compile (mini.c:12525)
>> > ==5807== by 0x559419: mono_jit_compile_method (mini.c:12836)
>> > ==5807== by 0x42C5E2: mono_magic_trampoline
>> (mini-trampolines.c:249)
>> > ==5807== by 0x415B164: ???
>> > ==5807== by 0x8BA4AAB: ???
>>
>> I think valgrind just didn't capture this one the first time, but it
>> was
>> a factor in the memory growth.
>>
>> I suppose that because MonoDevelop uses a fair amount of dynamic code,
>> it uses the JIT a lot, which seems to be provoking this. I personally
>> can't figure out why this memory is still reachable -- these are all
>> GLists, and it looks like they are passed to g_list_free at the end. I
>> suppose either some nodes are being lost after sorting, or something
>> more subtle is going on.
>>
>> This is glib version 2.16.4-0ubuntu2, on Ubuntu 8.04, amd64.
>>
>> Thanks.
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> <mailto: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/20080814/7f8161d7/attachment.html
More information about the Mono-devel-list
mailing list