[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