Runtime: Create a Mechanism to Get All Thread Managed Stacks

[brianrob]

Useful for getting a snapshot of thread count and what threads are doing. This would used in the performance profiling controller: https://github.com/dotnet/designs/pull/26

[davidfowl]

@brianrob I was literally just filing this bug, how do we get this moved from future to some real milestone? Java has the equivalent and it's https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getAllStackTraces()

Basically a Dictionary<Thread, StackFrame[]>

[brianrob]

@noahfalk is probably the person to talk to about this.

[noahfalk]

Just to clarify/confirm, you are looking for a managed API, implemented in the in-box framework libraries, that returns some enumeration of stack traces via a managed object model? The straightforward way to do this would be to leverage EE suspension and stack walking mechanisms which have a few implications:

a) all stacks will collected at GC safe points. If you are trying to do CPU performance investigations this introduces a small amount of skew as only some assembly instructions are legal GC safe points.

b) No native code will be visible on the stacks

c) Inlined frames will be absent from the results

Depending on the Object model we choose other frames may also be absent such as LCG and ILStubs.

For Brian's scenario I'd anticipate all these limitations are acceptable for now at least. David could you let me know what your scenario is so we get a better idea if that kind of behavior is acceptable?

[davidfowl]

For Brian's scenario I'd anticipate all these limitations are acceptable for now at least. David could you let me know what your scenario is so we get a better idea if that kind of behavior is acceptable?

Yes, I was purely looking at this for diagnostic scenarios (trying to roughly figure out what unit tests was blocking thread pool threads) see https://github.com/aspnet/AspNetCore/pull/6144/commits/0ed10b27124c5eac12b56549d17001b99e2b199c#diff-ff0265dca129a48a78a382851825e82eR101.

[mjsabby]

If we do decide to do this, it’d be useful to fire an event that this API was called. I’d hate for the misuse of such an API go undetected. JFYI OracleJDK 8 recommends using a different mechanism although admittedly for what @davidfowl wants it should in proc and easy to use.

Maybe we could also put this is in an assembly that would be easy to audit so that application hosts can identify an assembly wanting to use such an API.

[jkotas]

This API would naturally belong to the existing System.Diagnostics.StackTrace contract. I expect that we would just add it there. This API is about as prone to misuse as the existing StackTrace type.

[davidfowl]

Should we move to a formal API proposal then? Something on StackTrace?

[noahfalk]

Should we move to a formal API proposal then? Something on StackTrace?

Yeah - https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md

[mjsabby]

Forgot we had the System.Diagnostics.StackTrace contract.

It's a bit more concerning because it'll be easy to misuse with greater damage, you can now do it from a nuget library, etc. Of course that also makes it powerful, etc. for developers.

All in all I want this too but have a little bit of anxiety, not enough to not want it :)

[wsq003]

Any update? This would be very useful for online performance analysis.