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

Rodrigo Kumpera kumpera at gmail.com
Fri Nov 27 08:29:35 EST 2009

I agree with Zoltan, we better figure out how to extend the profilling
interface to support such tool than
to increase the complexity of the runtime.

On Thu, Nov 26, 2009 at 10:22 PM, Zoltan Varga <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>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
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> _______________________________________________
> Mono-devel-list mailing list
> 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/20091127/811741b5/attachment.html 

More information about the Mono-devel-list mailing list