[Mono-dev] Mono preview 2.0 binary and DTrace
andreas.faerber at web.de
Sat Aug 2 12:30:09 EDT 2008
Am 02.08.2008 um 17:25 schrieb Boris Dušek:
> I grabbed the Mono Preview 2.0 installer for OS X and wanted to test
> new DTrace probes mentioned in Release Notes, but it did not work.
Just to be sure, how did you test? As described in mono's man page?
> On the #mono IRC channel, I learned that DTrace probes in mono are not
> enabled in the binary packages provided, since it would incur
> performance penalty even when no tracing is done.
I had inquired about the sentence in the Release Notes myself and have
not yet received an answer. ;)
> However, from the
> DTrace docs, they say especially that "... No instrumented code is
> present for inactive probes, so your system does not experience any
> kind of performance degradation when you are not using DTrace. ... No
> effective difference exists between a system where DTrace is not
> active and one where the DTrace software is not installed." (quote
> from 2nd paragraph of
> http://docs.sun.com/app/docs/doc/817-6223/chp-intro-3?a=view )
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
a) Worries about performance degradation.
b) No one updated the build system.
c) The build machine isn't DTrace-capable.
The main reason for not automatically enabling DTrace support was that
it is somewhat hard to detect correctly. That's why we preferred --
enable-dtrace over --disable-dtrace. So, to get a DTrace-enabled
Mono.framework, the build bots need to specify that argument.
And I thought we had agreed that if someone is really worried about
performance, they should build their own Mono. Inversing this
significantly limits the usefulness of the feature as most Mac users
will just download the available binary.
Not enabling it during the previews is especially bad, since it
reduces the amount of testing this new feature gets. Apart from the
issue of mono.d not yet being installed, I've been considering marking
the provider as stable for better usability.
More information about the Mono-devel-list