[Mono-list] Mono preview 2.0 binary and DTrace

Andreas Färber andreas.faerber at web.de
Sun Aug 3 10:08:03 EDT 2008


Hi,

Are you talking of the once announced binary snapshots of trunk  
Mono.framework, so that you would make some Novell-internal setting to  
configure with --enable-dtrace?

Or do you suggest me to change trunk's configure.in to enable DTrace  
when specifically Mac OS X v10.5+ is detected and no --disable-dtrace  
was passed? Changes other than that I am skeptical about.

Btw Universal Binaries shouldn't be a problem, since iirc you use lipo  
to combine two separate builds and the mono.d file would be platform- 
independent so no special handling necessary.

Andreas

Am 02.08.2008 um 20:14 schrieb Geoff Norton:

> Zoltan,
>
>  I'm fine with this on trunk, but I still think barring any compelling
> reason we should leave the branch as is.
>
> -g
>
> On Sat, 2008-08-02 at 19:20 +0200, Zoltan Varga wrote:
>> Hi,
>>
>>  Looking at dtrace.h, all the current probes seem to be in
>> non-critical code-paths, so they
>> are unlikely to have a perf impact. We could make --enable- 
>> dtrace=true
>> the default in HEAD,
>> so it gets some testing.
>>
>>                          Zoltan
>>
>> On Sat, Aug 2, 2008 at 7:16 PM, Geoff Norton <gnorton at novell.com>  
>> wrote:
>>> On Sat, 2008-08-02 at 18:30 +0200, Andreas Färber wrote:
>>>
>>>> Not fully true, there is of course a minimal degradation (~5 nop
>>>> instructions on Solaris), but it should be hardly noticeable. I  
>>>> have
>>>> taken care to only call helper functions when the probe is active.
>>>>
>>>> Was the answer on IRC in any way official? I could think of three
>>>> possible reasons:
>>>>
>>>> a) Worries about performance degradation.
>>>
>>> Yes
>>>
>>>> b) No one updated the build system.
>>>
>>> True but minor
>>>
>>>> c) The build machine isn't DTrace-capable.
>>>
>>> d) We havn't tested it fully in our QA process, nor has it been
>>> available long enough for us to feel comfortable turning it on at  
>>> this
>>> stage.  We also would need to invesgate how to do it in our  
>>> universal
>>> binaries, etc.  Its a lot of testing and it unfortunately will not  
>>> make
>>> 2.0 unless there is a compelling argument against this and support  
>>> from
>>> the runtime team and from the QA team.
>>>
>>> -g
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>



More information about the Mono-list mailing list