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

[Marek Habersack]

On 11/28/2009 07:12 AM, Miguel de Icaza wrote:
> Hello Marek,
Hey Miguel,

>
> I think the idea is very useful, but I would like to see this
> implemented as a loadable profiler.
We discussed that with Rodrigo and Zoltan, and while doing it is easy 
the conclusion was that at this time it's not practical because we don't 
support multiple profilers right now and it would conflict with, e.g., 
the soft debugger (it is possible to use the allocation profiling 
callback while another profiler is active, but since we support only one 
callback per category, it may override the original handler). Zoltan 
suggested that the code is committed as-is right now, and modified to 
use the profiler interface when we have multiple profiler support ready 
(the change to do that in my code would be really minimal).

> We could make an alias to load other modules like --module that would
> just be an alias to this feature if you think that the profiler
> association is too negative.
I think it doesn't reflect the purpose of the code and, as Zoltan said, 
it is more a tooling interface than a profiling one. Also, what do you 
think about implementing the support in the similar fashion as the soft 
debugger - i.e. it wouldn't be a separate .so, but would live in the 
runtime, otherwise behaving like a shared module? That would let us keep 
the code together with the I/O portability layer.

marek

>
> On Nov 26, 2009, at 7:08 PM, Marek Habersack 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
>> <iomap-report.diff>_______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>