Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NativeAOT] GC events don't get logged on Linux #87445

Closed
elinor-fung opened this issue Jun 13, 2023 · 2 comments · Fixed by #88282
Closed

[NativeAOT] GC events don't get logged on Linux #87445

elinor-fung opened this issue Jun 13, 2023 · 2 comments · Fixed by #88282
Assignees
Milestone

Comments

@elinor-fung
Copy link
Member

The event firing in Native AOT is under a mix of FEATURE_EVENT_TRACE and FEATURE_ETW.

Some things don't even attempt to fire:

#ifdef FEATURE_ETW
ETW::GCLog::ETW_GC_INFO gcStartInfo;
gcStartInfo.GCStart.Count = count;
gcStartInfo.GCStart.Depth = depth;
gcStartInfo.GCStart.Reason = static_cast<ETW::GCLog::ETW_GC_INFO::GC_REASON>(reason);
gcStartInfo.GCStart.Type = static_cast<ETW::GCLog::ETW_GC_INFO::GC_TYPE>(type);
ETW::GCLog::FireGcStart(&gcStartInfo);
#endif // FEATURE_ETW

Implementation of ETW::GCLog is in eventtrace.cpp, which is only included on Windows:

list(APPEND COMMON_RUNTIME_SOURCES
windows/PalRedhawkCommon.cpp
windows/PalRedhawkMinWin.cpp
${GC_DIR}/windows/gcenv.windows.cpp
eventtrace.cpp
rheventtrace.cpp

(There's a bunch of stuff in there, so it's not quite as simple as including it on non-Windows)

Related (but more involved than): #87325

cc @LakshanF

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Jun 13, 2023
@ghost
Copy link

ghost commented Jun 13, 2023

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The event firing in Native AOT is under a mix of FEATURE_EVENT_TRACE and FEATURE_ETW.

Some things don't even attempt to fire:

#ifdef FEATURE_ETW
ETW::GCLog::ETW_GC_INFO gcStartInfo;
gcStartInfo.GCStart.Count = count;
gcStartInfo.GCStart.Depth = depth;
gcStartInfo.GCStart.Reason = static_cast<ETW::GCLog::ETW_GC_INFO::GC_REASON>(reason);
gcStartInfo.GCStart.Type = static_cast<ETW::GCLog::ETW_GC_INFO::GC_TYPE>(type);
ETW::GCLog::FireGcStart(&gcStartInfo);
#endif // FEATURE_ETW

Implementation of ETW::GCLog is in eventtrace.cpp, which is only included on Windows:

list(APPEND COMMON_RUNTIME_SOURCES
windows/PalRedhawkCommon.cpp
windows/PalRedhawkMinWin.cpp
${GC_DIR}/windows/gcenv.windows.cpp
eventtrace.cpp
rheventtrace.cpp

(There's a bunch of stuff in there, so it's not quite as simple as including it on non-Windows)

Related (but more involved than): #87325

cc @LakshanF

Author: elinor-fung
Assignees: -
Labels:

area-NativeAOT-coreclr

Milestone: -

@elinor-fung
Copy link
Member Author

(There's a bunch of stuff in there, so it's not quite as simple as including it on non-Windows)

More details - the tracking of whether the runtime provider is enabled for ETW vs event pipe is happening/stored in different places.

Event pipe is tracked in MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_DOTNET_Context

DOTNET_TRACE_CONTEXT MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_DOTNET_Context;

And updated in EtwCallbackCommon (called by EventPipeEtwCallbackDotNETRuntime, isn't registered as an ETW callback):
ctxToUpdate->EventPipeProvider.Level = Level;
ctxToUpdate->EventPipeProvider.EnabledKeywordsBitmask = MatchAnyKeyword;
ctxToUpdate->EventPipeProvider.IsEnabled = ControlCode;

ETW is tracked in MICROSOFT_WINDOWS_NATIVEAOT_GC_PUBLIC_PROVIDER_Context:

#ifdef FEATURE_ETW
MICROSOFT_WINDOWS_NATIVEAOT_GC_PRIVATE_PROVIDER_Context.IsEnabled = FALSE;
MICROSOFT_WINDOWS_NATIVEAOT_GC_PUBLIC_PROVIDER_Context.IsEnabled = FALSE;
// Register the Redhawk event provider with the system.
RH_ETW_REGISTER_Microsoft_Windows_Redhawk_GC_Private();
RH_ETW_REGISTER_Microsoft_Windows_Redhawk_GC_Public();
MICROSOFT_WINDOWS_NATIVEAOT_GC_PRIVATE_PROVIDER_Context.RegistrationHandle = Microsoft_Windows_Redhawk_GC_PrivateHandle;
MICROSOFT_WINDOWS_NATIVEAOT_GC_PUBLIC_PROVIDER_Context.RegistrationHandle = Microsoft_Windows_Redhawk_GC_PublicHandle;
#endif // FEATURE_ETW

And updated in RhEtwControlCallback:
RhEtwControlCallback(GUID * /*SourceId*/, uint32_t IsEnabled, uint8_t Level, uint64_t MatchAnyKeyword, uint64_t MatchAllKeyword, EVENT_FILTER_DESCRIPTOR * FilterData, void * CallbackContext)
{
RH_ETW_CONTEXT * Ctx = (RH_ETW_CONTEXT*)CallbackContext;
if (Ctx == NULL)
return;
Ctx->Level = Level;
Ctx->MatchAnyKeyword = MatchAnyKeyword;
Ctx->MatchAllKeyword = MatchAllKeyword;
Ctx->FilterData = FilterData;
Ctx->IsEnabled = IsEnabled;
EtwCallback(IsEnabled, (RH_ETW_CONTEXT*)CallbackContext);
}

The ETW::GCLog implementations use macros that are ETW-specific:

// Map the CLR private provider to our version so we can avoid inserting more #ifdef's in the code.
#define MICROSOFT_WINDOWS_DOTNETRUNTIME_PRIVATE_PROVIDER_Context MICROSOFT_WINDOWS_NATIVEAOT_GC_PRIVATE_PROVIDER_Context
#define MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_Context MICROSOFT_WINDOWS_NATIVEAOT_GC_PUBLIC_PROVIDER_Context
#define Microsoft_Windows_DotNETRuntimeHandle Microsoft_Windows_Redhawk_GC_PublicHandle

#define ETW_TRACING_CATEGORY_ENABLED(Context, Level, Keyword) \
(ETW_TRACING_INITIALIZED(Context.RegistrationHandle) && ETW_CATEGORY_ENABLED(Context, Level, Keyword))

Implementation of GCLog::FireGcStart also checks EventPipeAdapter_Enabled() - but the other defines still only exist under FEATURE_ETW right now. The event pipe enabled check does also mean that it is doing the added work as long as event pipe is enabled, regardless of whether the actual provider and keyword are enabled.

if (EventPipeAdapter_Enabled() || ETW_TRACING_CATEGORY_ENABLED(
MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_Context,
TRACE_LEVEL_INFORMATION,
CLR_GC_KEYWORD))

@agocke agocke added this to the 8.0.0 milestone Jun 13, 2023
@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Jun 13, 2023
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jul 1, 2023
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jul 10, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Aug 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants