Profiler Interest Group - Announcements

I'm making this issue as an informal way to flag other issues and discussions that might be relevant to Building .NET profiling tools. This is similar to the .NET announcements repo, but given that profiling is a small crowd I didn't want to create noise for everyone or be very formal about it. Follow the issue if this is something you care about. Hopefully it works well but if not we can try something else.

Please don't do discussion directly in this issue, just links. Thanks!

Retroactive announcement - Oct 20th - I updated the profiling status page that describes our progress supporting the ICorProfiler APIs
PR: dotnet/coreclr#14644
Latest status: https://github.com/noahfalk/coreclr/blob/master/Documentation/project-docs/profiling-api-status.md

@davmason

Retroactive announcement - Oct 20th - @davmason implemented new ICorProfiler APIs (#14612, dotnet/coreclr#14643) to help profilers deal with the breaking changes that are coming with [tiered jitting] (dotnet/coreclr#12193)

@sywhang

Jan 4th 2018 - @sywhang brought up more profiling tests for ARM and OSX and we believe things are working well
PR: dotnet/coreclr#15659
Issue: #6098
Latest status: https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/profiling-api-status.md

@sywhang

Jan 4th - @sywhang fixed a bug in which the profiler invoked AppDomainCreationFinished multiple times for the same AppDomain
Issue #6804

.NET Core 2.1 bug : (
We had an unintended behavior change in the ReJIT profiling API that has caused some profilers to fail. I've got a fix that restores the original behavior in the daily builds and working on getting it into 2.1 servicing releases. If you have a profiler that uses the RequestReJIT API but does not call ICorProfilerFunctionControl::SetILFunctionBody to set the IL you may have been affected. Check out dotnet/coreclr#18448 for more details and please reach out in that issue discussion if you have any questions or concerns I can help with.

Yes, I had seen that. Fortunately, doesn't impact me. :)

We are adding a startup hook that could potentially be useful for profilers: dotnet/core-setup#4421. The plan is to add a DOTNET_STARTUP_HOOKS environment variable that can be used to inject managed code into the process before Main. If you have comments or suggestions, please leave them in that pull request!

@davmason

.NET Core 2.2 Preview 2 has shipped with Tiered Compilation on by default. We warned this was in progress last year above in this thread:

Retroactive announcement - Oct 20th - @davmason implemented new ICorProfiler APIs (#14612, dotnet/coreclr#14643) to help profilers deal with the breaking changes that are coming with [tiered jitting] (#12193)

If you haven't yet tested with this feature on we hope you will soon : )

Tiered compilation will be disabled by default for .NET Core 2.2 RTM, mainly due to https://github.com/dotnet/coreclr/issues/19752, which we plan to fix soon for 3.0

dotnet/coreclr#22617 allows profilers to edit more types of metadata after module load (specifically adding TypeDef and MethodDef). However, adding virtual methods after module load is still unsupported.

There is a minor breaking change as part of this work. ICorProfilerInfo7::ApplyMetadata now potentially can trigger a GC, so it is now illegal to call it in situations where a GC is forbidden.

Also included in that PR is a document (located at Documentation/Profiling/Profiler Breaking Changes.md) to track breaking changes as they happen.

@davmason

If you have any questions/concerns about @davmason's changes above, as always feel free to reach out to us. Thanks!

the existing COR_PRF_HIGH_BASIC_GC profiling is VERY heavy weight. dotnet/coreclr#22866 added a lightweight GC profiling option that just gives you

GC start callback
GC end callback
update generational bounds

this is something you can use on production machines. you call access this by calling ICorProfilerInfo5::SetEventMask2 and set COR_PRF_HIGH_BASIC_GC in dwEventsHigh.

There are three recent changes to announce.

First, profiler attach/detach is now supported (#24670) leveraging the existing EventPipe work. You can find documentation on how to use it here: https://github.com/dotnet/coreclr/blob/master/Documentation/Profiling/Profiler%20Attach%20on%20CoreCLR.md. This means that the trigger process will use a completely different API, but the advantage is that it works on Linux and Windows.

Second, a new api ICorProfilerInfo10::RequestReJITWithInliners has been added (#24461) to allow profilers to ReJIT after attach. Documentation for ReJIT on attach is here: https://github.com/dotnet/coreclr/blob/master/Documentation/Profiling/ReJIT%20on%20Attach.md.

The last announcement is that ICorProfilerInfo2::DoStackSnapshot is now supported on Linux (#24968). On Linux you can call DoStackSnapshot from the same thread you are running on at any time, if you would like to get a snapshot of other threads there is now ICorProfilerInfo10::SuspendRuntime to stop all managed threads (without performing a GC) and make them safe to snapshot, and then ICorProfilerInfo10::ResumeRuntime to resume the runtime once you are finished collecting snapshots. It is not possible to snapshot an arbitrary thread on Linux. Windows support remains unchanged.

Please feel free to reach out with any questions, comments, or concerns.

Hi Everyone,

PR #1201 means that arrays are no longer special cased on class unload and profilers will be notified (via ClassUnloadStarted) when an array type is unloaded from a collectible context. Up until this point they have been purposefully excluded from ClassUnloadStarted.

I don't expect this to be a breaking change for any profilers, please get in touch if this is not the case.

Currently (ever since CLRv4, including CoreCLR), neither ClassLoad* or ClassUnload* callbacks are called for arrays. Will this change ClassLoad* callbacks too?

As it stands now the class load callbacks are not called. That is because this wasn't an intentional change, but rather a side effect of removing array's TypeDesc.

Is that an issue for your profiler? It would be a fairly small change to have array types reported for class load, or to block them from being reported in class unload and go back to the old behavior.

Hi again everyone,

I would like to give you all a heads up about a potential breaking change.

#32283 introduced a new GC generation for the first time since very early in desktop .net. This means that there are now 5 total generations instead of the previous 4:

Gen 0
Gen 1
Gen 2
Large Object Heap
Pinned Object Heap

There is no specific breaking change to the ICorProfiler APIs, but I suspect that many of you will be broken because of assumptions made about the number of GC generations inside your profilers. We (the .net diagnostics team) are finding many of our tools need updating because of this change. If you are interested in the type of work we need to do, you can find that at dotnet/diagnostics#1408.

Hi everyone,

I just merged a small breaking change with #60999. There was a typo in the name of one method in the released .Net 6 corprof.idl, it does not impact any types or layouts so it will not break at runtime, but if you are building against the .net 6 headers and upgrade to this change it will cause a build break.

Wanted to post this here in case anyone else runs into it.
The changes made in #69121 will cause RequestReJITWithInliners to return CORPROF_E_REJIT_INLINING_DISABLED if a debugger is attached at startup, this only affects .NET 6.

Hi All,

The issue reported in #76016 was found and fixed too late to be in the 7.0 GA release. It is currently scheduled to go in the first servicing update in January, PR is at #77533.

This will only impact 7.0, not previous versions. The symptoms you will see are not getting ModuleLoadFinished callbacks for dynamic modules.

If you have questions or concerns please comment in #76016 or file a new issue to not spam everyone on this thread.

Hi All,

First off some bookkeeping, I just locked the issue to make sure discussion doesn't happen here and this is limited to announcements only. I want to be clear that I welcome any and all discussion, you'll just need to file a new issue or comment on an existing one to have the discussion so this issue can be announcements only.

Next up I want to announce the new NonGC heap and related ICorProfiler APIs. For the history of the runtime all objects have been on a GC heap, but starting in .net 8 preview 5 we now keep some objects that are available at compile time on a NonGC heap. See this issue for more details: dotnet/diagnostics#4156

What this means to ICorProfiler implementations is some objects will not work with the existing GC APIs. We have added new APIs to work with NonGC objects.

interface ICorProfilerInfo14 : ICorProfilerInfo13
{
    HRESULT EnumerateNonGCObjects([out] ICorProfilerObjectEnum** ppEnum);

    HRESULT GetNonGCHeapBounds(
                    [in] ULONG cObjectRanges,
                    [out] ULONG *pcObjectRanges,
                    [out, size_is(cObjectRanges), length_is(*pcObjectRanges)] COR_PRF_NONGC_HEAP_RANGE ranges[]);
}

If you pass a NonGC object to an existing GC API you will see the error CORPROF_E_NOT_GC_OBJECT.

If possible please try out your profilers on preview 5 or later and let us know if you run in to any issues. As mentioned above feel free to reach out any time with a new issue or by commenting on dotnet/diagnostics#4156.

Hi all!

A recent PR for .NET 10 may affect profilers using Enter/Leave/Tailcall hooks.

It has always been the case that calling an ICorProfilerInfo method from within these callbacks that triggered the .NET GC to run may have corrupted memory without warning. As a profiler author the only solution was to learn which methods might do that and avoid calling them. With this PR we have reduced the set of profiler methods that trigger the GC and enabled explicit error checks for the ones that still do. After this PR is submitted calling an ICorProfilerInfo method that might trigger GC returns error code CORPROF_E_UNSUPPORTED_CALL_SEQUENCE when called from Enter/Leave/Tailcall hooks. Its possible that some profilers are currently invoking these APIs and getting lucky in not having the GC run, but now would get the error code always instead. #107152 (comment) has the list of profiler methods that might trigger GC and have this change in behavior.

If you have any questions about this or requests to make other APIs callable from Enter/Leave/Tailcall hooks we're happy to discuss. Best way is to open a new GH issue in this repo and tag @dotnet/dotnet-diag in it (don't use this issue, it is only for announcements). Thanks!

Hello everyone!

This PR for .NET 10 affects profilers that use GetFunctionInfo2 without a COR_PRF_FRAME_INFO frameInfo obtained from a FunctionEnter2 callback.

Originally, GetFunctionInfo2 would return 0 for the ClassID if the exact match could not be determined. As brought up in #107139, there are some scenarios where a "decent" default value (e.g. System.__Canon) would suffice. With the aforementioned change, GetFunctionInfo2 will now return the MethodTable associated with the function as the ClassID rather than returning 0 if it could not be exactly determined.
Profilers should still be cautious that without passing in a COR_PRF_FRAME_INFO obtained from FunctionEnter2, the ClassID and type arguments may not be exact, as documented.

If there are any questions, please use #107139 or open a new GH issue in this repo and tag @dotnet/dotnet-diag in it. Thanks!

Hi all! We have developed a updated version (V6) of the NetTrace file format to better support multi-process tracing and make a variety of other improvements (changes are described here). In .NET 10 the runtime still emits the older version 5 that we have used for years, but the V6 format version is planned to show up in the new dotnet-trace collect-linux scenario under development now. The file is being emitted by the OneCollect library. We don't have any concrete plan to use the V6 format in other scenarios right now but its possible that the .NET 11 runtime or other tools might emit it in the future.

If you have a profiling tool that uses the TraceEvent library to parse the NetTrace format, TraceEvent's parser has already been updated to handle the new version. We recommend you update to the latest TraceEvent release. If you have your own custom implementation of a parser then you'll need to modify it if you want to support the new format. Since dotnet-trace collect-linux isn't ready yet there isn't anything easily available to test with for now but you can keep an eye on dotnet/diagnostics#5570 that has the in-progress implementation.

If you have any questions, please open a GH issue and tag @dotnet/dotnet-diag to make sure we see it. Thanks as always!

Navigation Menu

Repository navigation

Profiler Interest Group - Announcements #9305

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Profiler Interest Group - Announcements #9305

Description

Activity

noahfalk commented on Nov 21, 2017

noahfalk commented on Nov 21, 2017

noahfalk commented on Jan 5, 2018

noahfalk commented on Jan 5, 2018

dotnetjt commented on Jun 15, 2018

noahfalk commented on Jun 16, 2018

dotnetjt commented on Jun 16, 2018

sbomer commented on Aug 15, 2018

noahfalk commented on Sep 14, 2018

kouvel commented on Nov 13, 2018

davmason commented on Feb 16, 2019

noahfalk commented on Feb 16, 2019

Maoni0 commented on Feb 28, 2019

davmason commented on Jun 13, 2019

5 remaining items

davmason commented on Apr 23, 2020

davmason commented on Apr 23, 2020

davmason commented on May 21, 2020

davmason commented on Nov 2, 2021

gamingrobot commented on Jul 25, 2022

davmason commented on Oct 28, 2022

davmason commented on Jun 8, 2023

noahfalk commented on Sep 12, 2024

mdh1418 commented on Sep 20, 2024

noahfalk commented on Oct 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions