Re: [Mono-dev] Mono preview 2.0 binary and DTrace
On Sun, 2008-08-03 at 21:57 +0200, Andreas Färber wrote: What I will be looking into next is method-enter/method-exit probes for tracing managed function flow, but it seems more complicated (the JIT would need to always emit a call to a helper function, supplying it the data to conditionally pass out - otherwise the dynamic part of DTrace wouldn't work) and thus cannot be on by default for performance reasons, just like in Java. IMO, the correct way of doing this would be to implement it in a profiler module, and it's amazingly easy doing so. But actually the logging profiler does just that if you invoke it with the c option: it logs all method enter and exit events. It uses per-thread buffers (periodically flushed) to minimize overhead and locking, each event takes between 2 and 5 bytes in the log file (including the full timestamp!), and even this way the overhead is really high. I doubt dtrace could be any faster... but if it is I'd like to know how it does it :-) What the profiler misses, in this case, is a GUI that is oriented towards browsing the log, maybe with a timeline, showing the threads in parallel, and with a filter and fast search functions... The data is all in the log, the problem is those log files can take several hundreds of Mb on disk (with the events compacted that way), so IMO keeping all the data in RAM in the GUI would be the wrong approach (because each event would take much more than 5 bytes!). This is the main reason why this kind of tool has not yet been written: doing it well for the general case (a typical program run during more than ten minutes) is not trivial. But if you need only one line in a text file for each method enter-exit, take the Mono.Profiler code, put a couple of WriteLine inside MethodEnter and MethodExit in the EventProcessor, be sure to print also stack.Depth, and you have your trace :-) As a bonus, if you want to be able to distinguish threads, also print stack.ThreadId. It is worse than mono --trace because you don't have the method arguments, but it is much more efficient during execution so there are more cases when this is actually doable. I *know* this is not dtrace, it does not profile the whole system but only Mono... but this works also on Linux. Ciao, Massi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
Ciao Massi, Am 05.08.2008 um 08:23 schrieb Massimiliano Mantione: On Sun, 2008-08-03 at 21:57 +0200, Andreas Färber wrote: What I will be looking into next is method-enter/method-exit probes for tracing managed function flow, but it seems more complicated (the JIT would need to always emit a call to a helper function, supplying it the data to conditionally pass out - otherwise the dynamic part of DTrace wouldn't work) and thus cannot be on by default for performance reasons, just like in Java. IMO, the correct way of doing this would be to implement it in a profiler module, and it's amazingly easy doing so. Although not really familiar with it, I am aware of the existing cross- platform tracing and profiling mechanisms in Mono. (The JIT profiling DTrace probes mostly match Mono's own hooks except that I reported some profiler hooks were missing for generic sharing and when some optimizations were not run - I got no reply to that, maybe you want to check on that.) DTrace is a different paradigm... But actually the logging profiler does just that if you invoke it with the c option: it logs all method enter and exit events. It uses per-thread buffers (periodically flushed) to minimize overhead and locking, each event takes between 2 and 5 bytes in the log file (including the full timestamp!), and even this way the overhead is really high. I doubt dtrace could be any faster... but if it is I'd like to know how it does it :-) ...currently, having to start mono with the DTrace tool as documented is an intermediate step - the final goal is to deploy a runtime with DTrace compiled in, no probes activated at startup. Then when something goes wrong, e.g. while running ASP.NET with mod_mono, you connect to the mono pid (or to all running mono instances) and see what's going on. What DTrace is doing afaik is it pre-compiles the D script to bytecode and it has per-CPU buffers. Unless I activate a certain probe, no data gets collected for it. Even if activated (i.e., called and data passed into), the script can use predicates to minimize the data collected to that of interest (e.g., only profile compilation of method starting with A), and built-in aggregation functions can further reduce the amount of data actually kept (e.g., a histogram). So this means that the actual if (enabled) needs to be different, and I wouldn't want to mess with the semantics of the cross-platform mechanism. Personally, I have used DTrace for my thesis on H.264 SVC streaming, and being under great time pressure DTrace has allowed me to get the statistics I wanted with a minimum of work - for absolute numbers I got histograms directly in GNUplot format, for a cumulative distribution function I postprocessed the output with an existing Mono tool of mine (probably there's an easier way too but I'm no expert). http://www.informatik.uni-mannheim.de/pi4/publications/Faerber2008a (pp. 14ff) Anyway, believing that DTrace will be slightly faster, I have taken care to place the DTrace probes enclosed by Mono's hooks (e.g., start profiler hook, start DTrace probe, whatever, end DTrace probe, end profiler hook) and would ask that we stick with this order. It should not have any influence when DTrace is not compiled in (e.g., Linux) as my macros become no-op then. I don't wish to replace or belittle your profiler work. I think the two have different scopes and different use cases and can live side by side, even benefitting from increased review. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
On Tue, 2008-08-05 at 12:26 +0200, Andreas Färber wrote: IMO, the correct way of doing this would be to implement it in a profiler module, and it's amazingly easy doing so. [...] I don't wish to replace or belittle your profiler work. I think the two have different scopes and different use cases and can live side by side, even benefitting from increased review. Don't worry, I did not take your post that way. I *know* dtrace is a different thing, even if I have never used it. I was trying to say the following: [1] If you want dtrace hooks for every enter-exit method, the easiest way to implement them is inside a profiler module that uses the existing enter-exit profiling hooks. This has its downsides: you must start the runtime enabling this dtrace profiler module, and at this point the overhead is not zero. However it seems so easy to do that it could be useful anyway if you need the feature now instead of in a few weeks or months. [2] Anyway, if you want to extend the JIT to insert enter and exit empty dtrace hooks to every method, it's very likely that you should reuse (and extend) the existing prologue-epilogue instrumentation code instead of trying to reinvent it. [3] As nice as dtrace can be, we don't have it on Linux, and our main focus is Linux. Here, the easiest way you have to log all enter-exit events efficiently is the c option of the logging profiler, so I explained how to use it for that purpose in case somebody needed it now. Of course the logging profiler is not dtrace :-) And of course there's place for both in the world... My points [1] and [2] are suggestions on how to get those dtrace hooks into Mono, point [3] is about how to get something similar without using dtrace. Anyway, I get your point that dtrace hooks are conditional, and the conditions can be given dynamically as D scripts. This is something we miss in Mono-land, and can cut the event bandwidth significantly. So, to answer my question, maybe dtrace would be slower than the logging profiler in logging individual enter-exit events, but typically when using dtrace you will never ask the system to log *all* of them, you will select them with a D script, so the resulting event bandwidth will be much slower and the performance acceptable. Did I get it right? Thanks! Massi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
Hi, On mono HEAD, dtrace is now enabled under solaris and macosx if the dtrace utility is detected by configure. Zoltan On Sun, Aug 3, 2008 at 4:08 PM, Andreas Färber [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
Hi, Am 03.08.2008 um 16:52 schrieb Zoltan Varga: On mono HEAD, dtrace is now enabled under solaris and macosx if the dtrace utility is detected by configure. Looks okay to me. In this form it would even allow to build with DTrace enabled on pre-10 Solaris once the tool becomes available there. Let's just hope my Solaris build script doesn't break too soon... Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
Hi Andreas,
On Sat, Aug 2, 2008 at 6:30 PM, Andreas Färber [EMAIL PROTECTED] wrote:
I grabbed the Mono Preview 2.0 installer for OS X and wanted to test
new DTrace probes mentioned in Release Notes[1], but it did not work.
Just to be sure, how did you test? As described in mono's man page?
With the same command that worked with mono that I compiled myself.
(with one difference - I used '/path/to/mono' for customly compiled
mono since my install prefix binary dir was not in $PATH):
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$ sudo dtrace -P
mono'$target' -l -c mono
ID PROVIDERMODULE FUNCTION NAME
dtrace: failed to match mono3618 No probe matches description
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$ sudo dtrace -P
mono'$target' -l -c ./mono
ID PROVIDERMODULE FUNCTION NAME
20188 mono3620 mono mono_gc_collect gc-begin
20189 mono3620 mono mono_gc_collect gc-end
21858 mono3620 mono mini_method_compile
method-compile-begin
21859 mono3620 mono mini_method_compile
method-compile-end
21860 mono3620 mono mini_init
ves-init-begin
21861 mono3620 mono mini_init
ves-init-end
btw. while we are at it, is it already possible now or do you plan to
add jstack support (so that the names of .NET functions appear
instead of addresses of frames for the part inside mono runtime?)
right now, with this Hello World program:
class Test {
public static void Main(string[] args) {
System.Console.WriteLine(Hello from C#);
}
}
and this tracing script (tracing usermode stack at every write syscall):
syscall::write:entry
/pid == $target/
{
trace(arg0);
jstack();
}
I get this output which makes me believe it's either not implemented
or I am doing something wrong (both writes are to fd 1 = stderr):
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$
DYLD_LIBRARY_PATH=`pwd`/../lib sudo dtrace -s tracemono.d -c './mono
/Users/boris/Test.exe'
dtrace: script 'tracemono.d' matched 1 probe
Hello from C#
dtrace: pid 1528 has exited
CPU IDFUNCTION:NAME
1 17600 write:entry 1
libSystem.B.dylib`write$UNIX2003+0xa
mono`ves_icall_System_IO_MonoIO_Write+0x66
0x7d6084
0x7d5d60
0x7d5bae
0x7d5ae6
0x7cc8cd
0x7d4ed8
0x7d4e6e
0x7d4df8
0x7d4db6
0x7ca289
0x7ca24b
0x7ca1ce
mono`mono_runtime_exec_main+0xfe
mono`mono_runtime_run_main+0x153
mono`mono_main+0x1360
mono`start+0x36
0x2
1 17600 write:entry 1
libSystem.B.dylib`write$UNIX2003+0xa
mono`ves_icall_System_IO_MonoIO_Write+0x66
0x7d6084
0x7d5d60
0x7d5bae
0x7d5ae6
0x7cc8cd
0x7d63bf
0x7d61bd
0x7d614e
0x7d6128
0x7d4e0a
0x7d4db6
0x7ca289
0x7ca24b
0x7ca1ce
mono`mono_runtime_exec_main+0xfe
mono`mono_runtime_run_main+0x153
mono`mono_main+0x1360
mono`start+0x36
0x2
Tracing Java in this way yields empty trace, so probably it's me doing
something stupid.
Thanks,
Boris
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
Hi Boris,
Am 03.08.2008 um 17:32 schrieb Boris Dušek:
On Sat, Aug 2, 2008 at 6:30 PM, Andreas Färber
[EMAIL PROTECTED] wrote:
I grabbed the Mono Preview 2.0 installer for OS X and wanted to test
new DTrace probes mentioned in Release Notes[1], but it did not
work.
Just to be sure, how did you test? As described in mono's man page?
With the same command that worked with mono that I compiled myself.
(with one difference - I used '/path/to/mono' for customly compiled
mono since my install prefix binary dir was not in $PATH):
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$ sudo dtrace -P
mono'$target' -l -c mono
ID PROVIDERMODULE FUNCTION
NAME
dtrace: failed to match mono3618 No probe matches description
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$ sudo dtrace -P
mono'$target' -l -c ./mono
ID PROVIDERMODULE FUNCTION
NAME
20188 mono3620 mono mono_gc_collect
gc-begin
20189 mono3620 mono mono_gc_collect
gc-end
21858 mono3620 mono mini_method_compile
method-compile-begin
21859 mono3620 mono mini_method_compile
method-compile-end
21860 mono3620 mono mini_init
ves-init-begin
21861 mono3620 mono mini_init
ves-init-end
Looks right.
btw. while we are at it, is it already possible now or do you plan to
add jstack support (so that the names of .NET functions appear
instead of addresses of frames for the part inside mono runtime?)
right now, with this Hello World program:
class Test {
public static void Main(string[] args) {
System.Console.WriteLine(Hello from C#);
}
}
and this tracing script (tracing usermode stack at every write
syscall):
syscall::write:entry
/pid == $target/
{
trace(arg0);
jstack();
}
I get this output which makes me believe it's either not implemented
or I am doing something wrong (both writes are to fd 1 = stderr):
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$
DYLD_LIBRARY_PATH=`pwd`/../lib sudo dtrace -s tracemono.d -c './mono
/Users/boris/Test.exe'
dtrace: script 'tracemono.d' matched 1 probe
Hello from C#
dtrace: pid 1528 has exited
CPU IDFUNCTION:NAME
1 17600 write:entry 1
libSystem.B.dylib`write$UNIX2003+0xa
mono`ves_icall_System_IO_MonoIO_Write+0x66
0x7d6084
0x7d5d60
0x7d5bae
0x7d5ae6
0x7cc8cd
0x7d4ed8
0x7d4e6e
0x7d4df8
0x7d4db6
0x7ca289
0x7ca24b
0x7ca1ce
mono`mono_runtime_exec_main+0xfe
mono`mono_runtime_run_main+0x153
mono`mono_main+0x1360
mono`start+0x36
0x2
1 17600 write:entry 1
libSystem.B.dylib`write$UNIX2003+0xa
mono`ves_icall_System_IO_MonoIO_Write+0x66
0x7d6084
0x7d5d60
0x7d5bae
0x7d5ae6
0x7cc8cd
0x7d63bf
0x7d61bd
0x7d614e
0x7d6128
0x7d4e0a
0x7d4db6
0x7ca289
0x7ca24b
0x7ca1ce
mono`mono_runtime_exec_main+0xfe
mono`mono_runtime_run_main+0x153
mono`mono_main+0x1360
mono`start+0x36
0x2
Tracing Java in this way yields empty trace, so probably it's me doing
something stupid.
DTrace support has been a recurrently requested feature for about two
years now. I'm happy that I got it working so far! :)
All current DTrace features are documented in mono's man page, that is
the six probes. I don't pretend that this is in any way conclusive,
there are many more probes and features imaginable, some listed as a
roadmap in the to-be Wiki documentation, see attached. Suggestions and
contributions always welcome. The current probes are meant to allow a
little profiling of the runtime, and were a convenient way for me to
trace what the runtime would be doing if my ppc64 port were working...
I haven't used jstack() yet and would need to look it up in the
documentation. It sounds non-trivial to implement compared to probes.
What I will be looking into next is method-enter/method-exit probes
for tracing managed function flow, but it seems more complicated (the
JIT would need to always emit a call to a helper function, supplying
it the data to conditionally pass out - otherwise the dynamic part of
DTrace wouldn't work) and thus cannot be on by default for performance
reasons, just like in Java.
Andreas
==Using DTrace with Mono==
Mono 2.0 includes DTrace probes when configured with
code--enable-dtrace/code. This
[Mono-dev] Mono preview 2.0 binary and DTrace
Hi, I grabbed the Mono Preview 2.0 installer for OS X and wanted to test new DTrace probes mentioned in Release Notes[1], but it did not work. 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. 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 ) I will understand not having DTrace-enabled Mono binary package for OS X if there is a performance penalty, however in situation when the DTrace documentation states the contrary, and Perl, Python, Ruby and Java SE 6 shipped[1] with OS X Leopard are DTrace-enabled, I really want to know if disabling of DTrace probes in Mono is correctly reasoned. I think with the release notes wording In MacOS and Solaris Mono supports DTrace probes. To use this feature, you must configure mono with --enable-dtrace., many people will think like me that the configure with --enable-dtrace holds only for compiling from source, and that the Mono binary package offered for download has this enabled just like Java, Python etc. in OS X. I have to note that I am no DTrace usage expert (not to speak about implementation), and started learning DTrace just this Monday, so I am just curious about the situation. Anyway, thanks for making the DTrace probes, compiling Mono from source with --enable-dtrace configure flag, as specified in Release Notes, does the trick. Boris Dušek [1]: yes, I know it says it must be enabled with configure --enable-dtrace flag, but I thought that holds for compiling from source only and that the binary packages provided for OS X do have this enabled [2]: OK, Java SE 6 was shipped after Leopard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
Hi, 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[1], 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 possible reasons: 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. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono preview 2.0 binary and DTrace
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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
