[Mono-bugs] [Bug 69204][Wis] New - Lazy load MonoMethod, MonoMethodSignature and MonoMethodHeader

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by bmaurer@users.sf.net.

http://bugzilla.ximian.com/show_bug.cgi?id=69204

--- shadow/69204	2004-11-07 12:45:30.000000000 -0500
+++ shadow/69204.tmp.1079	2004-11-07 12:45:30.000000000 -0500
@@ -0,0 +1,84 @@
+Bug#: 69204
+Product: Mono: Runtime
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: bmaurer@users.sf.net               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Lazy load MonoMethod, MonoMethodSignature and MonoMethodHeader
+
+When compiling a simple HelloWorld, the bulk of the runtime footprint comes
+from parsing MonoMethod's:
+
+==10440== 279620 bytes in 6355 blocks are still reachable in loss record
+862 of 862
+==10440==    at 0x3414AC25: calloc (vg_replace_malloc.c:176)
+==10440==    by 0x70E5AE: g_malloc0 (in /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x80BCA32: mono_get_method_from_token (loader.c:821)
+==10440==    by 0x80BCEA0: mono_get_method_full (loader.c:953)
+==10440==    by 0x80BCE3C: mono_get_method (loader.c:935)
+==10440==    by 0x80B642C: mono_class_init (class.c:1495)
+
+==10440== 140432 bytes in 6598 blocks are still reachable in loss record
+861 of 862
+==10440==    at 0x3414AC25: calloc (vg_replace_malloc.c:176)
+==10440==    by 0x70E5AE: g_malloc0 (in /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x80ADB9A: mono_metadata_signature_alloc (metadata.c:1379)
+==10440==    by 0x80ADC6D: mono_metadata_parse_method_signature_full
+(metadata.c:1447)
+==10440==    by 0x80BCAF5: mono_get_method_from_token (loader.c:846)
+==10440==    by 0x80BCEA0: mono_get_method_full (loader.c:953)
+
+==10440== 120776 bytes in 4122 blocks are still reachable in loss record
+860 of 862
+==10440==    at 0x3414AC25: calloc (vg_replace_malloc.c:176)
+==10440==    by 0x70E5AE: g_malloc0 (in /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x80AE7F3: mono_metadata_parse_mh_full (metadata.c:1948)
+==10440==    by 0x80BCC26: mono_get_method_from_token (loader.c:923)
+==10440==    by 0x80BCEA0: mono_get_method_full (loader.c:953)
+==10440==    by 0x80BCE3C: mono_get_method (loader.c:935)
+
+In addition, these trigger other allocations, examples:
+
+==10440== 70656 bytes in 69 blocks are still reachable in loss record 857
+of 862
+==10440==    at 0x3414A2A8: malloc (vg_replace_malloc.c:131)
+==10440==    by 0x70E526: g_malloc (in /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x70F6D3: g_mem_chunk_alloc (in
+/usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x6FE8C9: (within /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x6FDD41: g_hash_table_insert (in
+/usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x80BCEC5: mono_get_method_full (loader.c:956)
+
+==10440== 69728 bytes in 8716 blocks are still reachable in loss record 856
+of 862
+==10440==    at 0x3414A2A8: malloc (vg_replace_malloc.c:131)
+==10440==    by 0x70E526: g_malloc (in /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x71D25D: g_memdup (in /usr/lib/libglib-2.0.so.0.400.0)
+==10440==    by 0x80AD95B: mono_metadata_parse_type_full (metadata.c:1326)
+==10440==    by 0x80ADD8F: mono_metadata_parse_method_signature_full
+(metadata.c:1481)
+==10440==    by 0x80BCAF5: mono_get_method_from_token (loader.c:846)
+
+In all, the MonoMethod's account for a fair amount of the 1.5 MB of data
+that the runtime keeps around for the HelloWorld.
+
+Most of these MonoMethod's never get used, so we should delay allocating
+them. Also, even if a MonoMethod is created, it's signature and header may
+never be used (eg, if you use s.ref to reflect on a method, chances are you
+  never need its header).
+
+When possible though, we could try to avoid creating the MonoMethod at all.
+We would need to figure out a way to lay out the vtable though (we could
+read directly from the metadata). Another option is to make MonoMethod
+much, much lighter and allocate the heavy information on demand.