[Mono-dev] Mono dtrace provider?

[Andreas Färber]

Hi,

I've revisited the idea of a DTrace provider for Mono and managed to  
get it working on OpenSolaris 2008.05 (dtrace 1.6) and Mac OS X v10.5  
(dtrace 1.2.2).

On OSX, all that is required is the C header file generated by `dtrace  
-h`.

Weird hacks around libtool are only necessary on (Open)Solaris. The  
problem with my previous attempt was that `dtrace -G` not only needs  
read access to the object files but also modifies them! When updating  
libmono-static.a via `ar r` after `drace -G`, everything is fine and I  
finally see my test probe!
The problem with this approach still is that it's a hack, because the  
location of the .a file and of the .o files is at the discretion of  
libtool and thus not very portable. But since it appears to be limited  
to Solaris, we could limit such questionable build steps to that  
platform and an explicit configuration option.

Attached is my diff, with Solaris stuff disabled. Also attached is the  
header generated on OSX and OpenSolaris.
Note that in mono-dtrace.nv.h the #if _DTRACE_VERSION should be  
replaced with something more sensible via regex (to avoid my  
workaround in mini.c), same for #include <unistd.h> which I believe  
hearing was not portable for Windows.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtrace-hack3.diff
Type: application/octet-stream
Size: 2968 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080525/086d25e9/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono-dtrace.osx.h
Type: application/octet-stream
Size: 666 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080525/086d25e9/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono-dtrace.nv.h
Type: application/octet-stream
Size: 487 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080525/086d25e9/attachment-0002.obj 
-------------- next part --------------


Am 13.01.2008 um 19:12 schrieb Miguel de Icaza:

>
>> I thought data/ would be an obvious choice for the .d file, and chose
>> mono/utils for the generated header and object file but the object
>> file seems to depend on all object files with the probes, here mini.o
>
> Hand written information can go into the data directory;   Source code
> generated by a tool should be generated at compile time.

The issue with that approach is the use-case of the generated header:  
The Solaris version thereof (dtrace 1.5+?) defines convenience macros  
for use in the source code, guarded by an #if. I.e., it defines  
PROVIDERNAME_PROBENAME() and PROVIDERNAME_PROBENAME_ENABLED() as no-op  
macros for non-DTrace builds. In e.g. mini.c I then #include <mono/ 
utils/mono-dtrace.h> and insert the probe as MONO_TEST ();. For this  
to compile, the header is needed on non-DTrace-aware platforms, so  
we'd need some version of the generated file in SVN but could  
overwrite it on platforms with dtrace available. Or we'd need either a  
manual header file as wrapper, sync'ed with the generated one, or our  
own guards added around each macro invocation.

The general idea would be to have a new switch --enable-dtrace which  
defaults to "no" on all platforms. If enabled, this would check for  
the dtrace tool and set up some arch flags and an automake/C define.  
Then, initially, I'd suggest some simple probes for performance  
evaluation such as ves-init-begin, ves-init-end, gc-begin and gc-end.  
Does this sound reasonable?

Compare: http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html

In addition to those static probes, Sun Java on Solaris also has the  
ability to generate providers and probes dynamically from Java code. I  
haven't looked into that yet but it might turn out highly platform- 
specific, and if we want to add such a thing, this too should depend  
on the suggested configure switch, to have it disabled by default.

Andreas