[Mono-dev] [PATCH] MONO_IOMAP reporting option - string allocation locations

[Marek Habersack]

On 11/27/2009 02:29 PM, Rodrigo Kumpera wrote:
> I agree with Zoltan, we better figure out how to extend the profilling
> interface to support such tool than
it would defy the purpose of the tool, but it seems I can remove the 
code from mono_string_new_utf16 without harming functionality - would 
that be ok?

marek
> to increase the complexity of the runtime.
>
>
> On Thu, Nov 26, 2009 at 10:22 PM, Zoltan Varga <vargaz at gmail.com
> <mailto:vargaz at gmail.com>> wrote:
>
>     Hi,
>
>        This patch adds code to the string allocation functions which
>     need to be as fast as
>     possible. I think it might be better to implement this as a profiler
>     module, a profiler can already receive notifications when an object
>     is allocated.
>
>                              Zoltan
>
>     On Fri, Nov 27, 2009 at 1:08 AM, Marek Habersack
>     <grendel at twistedcode.net <mailto:grendel at twistedcode.net>> wrote:
>
>         Hello everybody,
>
>                 Attached is an update to the original code I posted last
>         week. The update adds support for reporting string allocation
>         locations. It is useful with large code base where strings may
>         be created in one location but used in many others. The code
>         adds a new internal function which does the job of backtrace (3)
>         but supports mono JIT. It's basically a lighter version of
>         mono_jit_walk_stack which was too heavy for this purpose. The
>         code needs to record stack location for each and every string
>         allocated in the application and the runtime only to store it
>         for later use when IOMAP kicks in. Doing that with
>         mono_stack_walk rendered Mono many times slower and made
>         debugging the application virtually impossible. The patch makes
>         execution just slightly slower than usual. The reporting code
>         uses simple heuristics to select the possible string allocation
>         location - it attempts to ignore all methods from assemblies
>         installed in GAC, from corlib and, should the two checks fail,
>         from a list of assemblies and classes to ignore. This is done
>         based on the premise that the Mono runtime and class libraries
>         are case-sensitive and don't have the problem some applications
>         might have (there's actually an instance where that assumption
>         is incorrect - in System.Web we check for existence of
>         web.config, Web.config and Web.Config - but it's intended :)).
>         The results of the selection algorithm might not always be
>         accurate, but they should be close enough to aid the developer
>         to spot the location where string was allocated.
>                 Please review and let me know if I can commit.
>
>         marek
>
>         _______________________________________________
>         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
>
>
>
>     _______________________________________________
>     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
>
>