Share via

Want to peek inside Common Language Runtime? [Ravi Krishnaswamy]

  • Article

Today CLR reveals certain key gc, threadpool events via ETW but nothing interesting besides that.

If we were to design a larger scale instrumentation,

- What kind of information/events you would like to see?

- What kind of higher level bucketing (for ex., Loader, JIT, GC) would be interesting?

- What level of granularity you would need?

- Would you like CLR tracing to go to the same place as other Fx instrumentation and your own instrumentation? In other words, do you see value in integrating CLR tracing with System.Diagnostics tracing such that you get it all in one place?

Comments

  • Anonymous
    April 19, 2006
    re: ETW: A class that provided access to it from the BCL would be nice.

    Fusion: (assembly searching/loading)
     Details about fusion-related activities; load contexts and which assemblies are in which context, binding redirects, bindings, etc.

    Interop:
     A lot more information about interop is needed to help diagnose problems. COM and interop with .NET is still a black art.


    Trace output:
    Should be configurable and capable of filtering. The output bindings, level of tracing and filtering should be runtime adjustable so that as problems occur we can dial-up/dial-down the level of trace output.

    There's lots more but this is a start.

  • Anonymous
    April 19, 2006
    David,

    Thanks for the comments. We've had the same thoughts about exposing ETW through the BCL, so that's definitely one for us to consider.

    I wanted to let you know that a blog specifically on the future of tracing is upcoming and, in fact, covers a lot of the same issues you've addressed here. We're very configurable and capable of filtering today (between switches, filters, and the ability to customize them) but the idea of runtime adjustable settings is a great one. It would require a pretty big shift in our current tracing story, but I agree with you that it's something we must consider.

    Anyhow, thanks again for the input.
  • Anonymous
    April 19, 2006
    Posted for Zach Kramer

    Couple of quick thoughts that might help troubleshoot perf issues:



    One trace that I think would be cool is a log of all exceptions that are thrown even if handled.  We frequently see performance problems where the customers have a ton of exceptions and currently you have to attach debugger and start troubleshooting them. If you could get a list and callstacks in a log that would be a great start.  Then you know what types they are and can focus your efforts.



    Another one would be a log of objects getting finalized so you know what types.



    What about a log whenever an object is pinned and then unpinned. Then the GC could also log whenever it could not compact and what pinned object prevented that compaction?  That way you could correlate the three data points.

  • Anonymous
    April 20, 2006
    Mike,

    re: tracing...

    My philosophy is that apps should be fully instrumented but by default the normal amount of information actually traced should be a trickle (for perf). As problems arise the flow should be adjustable at runtime so that restarts are not necessary. The trace stack itself should also be runtime configurable so that filters, switches, etc. can be added/removed as needed without requiring a restart.

    Also, tracing a simple string is a good start but what is really needed is a trace event, not a trace string, so that an entire structure of data can be associated with the trace event; it should also be extensible for custom data.

    I sent a doc to some members of the BCL team about a tracing system I've implemented that talks about these and other issues; it may still be floating around there somewhere.

    Anyway, I look forward to the trace blog. Thanks.
  • Anonymous
    April 20, 2006
    Thanks for your comments David.  I forwarded the doc on to Mike and Ravi.
  • Anonymous
    April 26, 2006
    David,

    Fusion logic is already detailed in the fusion binding log. We already integrated with the CLR ETW, but it is disabled by default (read: conditionally compiled). What is missing is the loader part of it.

    Also I think you misunderstood Ravi's question. Ravi's question isn't about a tracing system implemented in BCL (for that, Mike already replied that BCL will expose ETW in BCL, which I personally believe has all the features you requested.). Instead, it is about exposing CLR internal logics in ETW events so that people can understand the CLR logic better.

    Today CLR is a big blackbox. When a problem occurs it is a huge pain to understand what is going on. Anything makes the diagnosibility better is very welcomed.