Hi Robert,
I am trying to get documentation how how this lazyloading happens when you are dealing with dtrace probes being added to user applications. In particular if it somehow avoids the overhead of registering dtrace probes when they aren't needed, how does it know if they are needed, etc...
Unfortuntely, lazy loading isn't documented (FWIW, there is an open bug for this - 6818262: Need to document the '-xlazyload' option). By specifying lazy loading with the the '-xlazyload' option we no longer load any helper DOF when the executable starts up. This means that any USDT based probes available for the process in question won't be visible with a 'dtrace -l' as they normally would be. However, if you go and explicitly try and enable USDT probes that are contained in the executable, we will then load them into the kernel and create them on-demand. An example of this is the plockstat provider which sits in libc. We certainly don't want to register the plockstat provider and create probes for every single process that starts up! Only when you explictly reference the plockstat provider for a running process will we create the specified probes. The upside of this is, as you say, we don't suffer any run time overhead that is caused by registering USDT probes when the process starts up. This is not normally an issue for processes that stay around for a while. However, if you have a process that contains USDT probes which may be exec'd frequently then you really need to be lazy loading to avoid potential scalability issues on process startup and exit. Let me know if you have any questions. Jon. _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
