[Mono-dev] [PATCH] MONO_IOMAP reporting option - string allocation locations
Marek Habersack
grendel at twistedcode.net
Fri Nov 27 10:40:29 EST 2009
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
>
>
More information about the Mono-devel-list
mailing list