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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=81663 --- shadow/81663 2007-07-20 12:54:08.000000000 -0400 +++ shadow/81663.tmp.29065 2007-08-01 08:11:58.000000000 -0400 @@ -269,6 +269,16 @@ ------- Additional Comments From [EMAIL PROTECTED] 2007-07-20 12:54 ------- This look ok. You can avoid guessing how much space to reserve by allocating code using g_malloc, emitting the code, then allocating from the code manager when the length of the emitted code is known. + +------- Additional Comments From [EMAIL PROTECTED] 2007-08-01 08:11 ------- +For this cases we should delegate caching to the arch-specific code. +In most cases, for eligible signatures, the exact type doesn't matter, +only the number of params does. With this in place we could allocate +a lot less memory and we could do it in a not appdomain specific way. +For x86 not taking into account struct returns we could have a simple +array as the cache lookup, with the number of arguments as the index +into the cache. The code memory would be allocated with +mono_global_codeman_reserve(). _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
