Skip to content

Avoid writing jitdump code for block data #122274

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.

Sign up for GitHub

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

Open
tommcdon wants to merge 5 commits into
base: main
Choose a base branch
from
+16 −14
Open

Avoid writing jitdump code for block data #122274

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0846b49
Avoid writing jitdump code for block data
tommcdon Dec 7, 2025
571b734
Address PR feedback
tommcdon Feb 5, 2026
f0df6e6
Merge branch 'main' into dev/tommcdon/jitmap_blockdata_fix
tommcdon Feb 11, 2026
bc2db43
Address PR feedback
tommcdon Feb 11, 2026
d2af966
Merge branch 'main' into dev/tommcdon/jitmap_blockdata_fix
tommcdon Feb 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/coreclr/pal/inc/pal.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -360,7 +360,7 @@ PALIMPORT
int
PALAPI
// Log a method to the jitdump file.
PAL_PerfJitDump_LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo);
PAL_PerfJitDump_LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo, bool reportCodeBlock);

PALIMPORT
int
Expand Down
17 changes: 8 additions & 9 deletions src/coreclr/pal/src/misc/perfjitdump.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -247,7 +247,7 @@ struct PerfJitDumpState
return 0;
}

int LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo)
int LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo, bool reportCodeBlock)
{
int result = 0;

Expand All @@ -257,7 +257,9 @@ struct PerfJitDumpState

JitCodeLoadRecord record;

size_t bytesRemaining = sizeof(JitCodeLoadRecord) + symbolLen + 1 + codeSize;
size_t reportedCodeSize = reportCodeBlock ? codeSize : 0;

size_t bytesRemaining = sizeof(JitCodeLoadRecord) + symbolLen + 1 + reportedCodeSize;

record.header.timestamp = GetTimeStampNS();
record.vma = (uint64_t) pCode;
Expand All @@ -269,15 +271,12 @@ struct PerfJitDumpState
// ToDo insert debugInfo and unwindInfo record items immediately before the JitCodeLoadRecord.
{ &record, sizeof(JitCodeLoadRecord) },
{ (void *)symbol, symbolLen + 1 },
{ pCode, codeSize },
{ pCode, reportedCodeSize },
};
size_t itemsCount = sizeof(items) / sizeof(items[0]);

size_t itemsWritten = 0;

if (result != 0)
return FatalError();

if (!enabled)
goto exit;

Expand Down Expand Up @@ -390,9 +389,9 @@ PAL_PerfJitDump_IsStarted()

int
PALAPI
PAL_PerfJitDump_LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo)
PAL_PerfJitDump_LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo, bool reportCodeBlock)
{
return GetState().LogMethod(pCode, codeSize, symbol, debugInfo, unwindInfo);
return GetState().LogMethod(pCode, codeSize, symbol, debugInfo, unwindInfo, reportCodeBlock);
}

int
Expand Down Expand Up @@ -420,7 +419,7 @@ PAL_PerfJitDump_IsStarted()

int
PALAPI
PAL_PerfJitDump_LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo)
PAL_PerfJitDump_LogMethod(void* pCode, size_t codeSize, const char* symbol, void* debugInfo, void* unwindInfo, bool reportCodeBlock)
{
return 0;
}
Expand Down
11 changes: 7 additions & 4 deletions src/coreclr/vm/perfmap.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -339,7 +339,7 @@ void PerfMap::LogJITCompiledMethod(MethodDesc * pMethod, PCODE pCode, size_t cod
s_Current->WriteLine(line);
}

PAL_PerfJitDump_LogMethod((void*)pCode, codeSize, name.GetUTF8(), nullptr, nullptr);
PAL_PerfJitDump_LogMethod((void*)pCode, codeSize, name.GetUTF8(), nullptr, nullptr, /*reportCodeBlock*/true);
}
}
EX_CATCH{} EX_END_CATCH
Expand Down Expand Up @@ -380,7 +380,7 @@ void PerfMap::LogPreCompiledMethod(MethodDesc * pMethod, PCODE pCode)
if (methodRegionInfo.hotSize > 0)
{
CrstHolder ch(&(s_csPerfMap));
PAL_PerfJitDump_LogMethod((void*)methodRegionInfo.hotStartAddress, methodRegionInfo.hotSize, name.GetUTF8(), nullptr, nullptr);
PAL_PerfJitDump_LogMethod((void*)methodRegionInfo.hotStartAddress, methodRegionInfo.hotSize, name.GetUTF8(), nullptr, nullptr, /*reportCodeBlock*/true);
}

if (methodRegionInfo.coldSize > 0)
Expand All @@ -393,7 +393,7 @@ void PerfMap::LogPreCompiledMethod(MethodDesc * pMethod, PCODE pCode)
name.Append(W("[PreJit-cold]"));
}

PAL_PerfJitDump_LogMethod((void*)methodRegionInfo.coldStartAddress, methodRegionInfo.coldSize, name.GetUTF8(), nullptr, nullptr);
PAL_PerfJitDump_LogMethod((void*)methodRegionInfo.coldStartAddress, methodRegionInfo.coldSize, name.GetUTF8(), nullptr, nullptr, /*reportCodeBlock*/true);
}
}
EX_CATCH{} EX_END_CATCH
Expand Down Expand Up @@ -450,7 +450,10 @@ void PerfMap::LogStubs(const char* stubType, const char* stubOwner, PCODE pCode,
s_Current->WriteLine(line);
}

PAL_PerfJitDump_LogMethod((void*)pCode, codeSize, name.GetUTF8(), nullptr, nullptr);
// For block-level stub allocations, the memory may be reserved but not yet committed.
// Emitting code bytes in that case can cause jitdump logging to fail, and the bytes
// are optional in the jitdump specification.
Copy link
Member

@noahfalk noahfalk Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels unfortunate that we would sacrifice our code bytes. I imagine one of the major reasons someone would choose the jitdump format rather than the perfmap format is to get those code bytes.

I'm wondering...

  • If we think folks want JitDumps without code bytes maybe we should have a config that eliminates the code bytes everywhere by design. That would give them a much smaller jitdump file than they have today.
  • If we moved where we call ReportStubBlock() from the point where memory is reserved to the point where the memory is committed I'm guessing that is a neglible change in the total number of stubs reported in the file. At most it would be one record per page when we already report other jitted code/stubs at densities of >100 per page.

Copy link
Member Author

@tommcdon tommcdon Feb 12, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels unfortunate that we would sacrifice our code bytes.

I believe the intent of #113943 was to add configuration knobs to control the volume of stub data reported to the perf tool. I have noticed that perf inject is much faster after that change, mostly it reduces the symbolic output the perf tool needs to process. Adding @davidwrighton who might have more to add.

Count of jitted*.so files for each DOTNET_PerfMapStubGranularity using the repro from #120419:

  • 0 - groups both reporting of stub types as well as allocations (default) - 750 jitted-*.so files after running perf inject. 12 are aggregated functions and therefore do not have code.
  • 1 - groups both reporting of stub types but report each block allocation - 753 jitted-*.so files after running perf inject, 12 are aggregated functions and therefore do not have code.
  • 2 - report allocations of grouped stub types - 3774 jitted-*.so files after running perf inject
  • 3 - enables 1 and 2 - each unique stub type allocation is reported - 3774 jitted-*.so files after running perf inject

For cases 0 and 1, we report groups of stubs as a 'virtual group of stubs'. In that case, I felt that reporting the code bytes for these aggregated functions that we are reporting didn't seem to add value. Perf inject creates a "so" file that represents a function with code inside of it. The so's that represent block data will contain a pointer to a large block of data containing code for multiple stubs (by design with 0 and 1 configurations). While the intent is not to be sacrificing code bytes, we are sacrificing reporting of unique stub data, which in turn means that we do not have unique code data that represents the aggregated symbol. In terms of missing code data overall, a relatively small percentage will be missing code. In the test case, ~1.6% is missing code (out of ~750 jitted-*.so files created, 12 were aggregated functions). I would expect for larger apps, the percentage to decrease.

In cases 2 and 3, the code data will be present.

If we think folks want JitDumps without code bytes maybe we should have a config that eliminates the code bytes everywhere by design. That would give them a much smaller jitdump file than they have today.

My expectation is that if customers do not wish to have code bytes might use perfmaps and not jitdumps. With that said, I would be happy to add another config switch to disable code bytes for jitdumps. Thoughts?

If we moved where we call ReportStubBlock() from the point where memory is reserved to the point where the memory is committed, I'm guessing that is a negligible change in the total number of stubs reported in the file. At most it would be one record per page when we already report other jitted code/stubs at densities of >100 per page.

I will give this try.

Copy link
Member

@noahfalk noahfalk Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With that said, I would be happy to add another config switch to disable code bytes for jitdumps. Thoughts?

I'm not actively encouraging us to do it, I just wanted to leave the door open in case you or others were aware of customer interest in jitdump without code bytes. I'm not aware of it.

I believe the intent of #113943 was to add configuration knobs to control the volume of stub data reported to the perf tool.

I had the same perception - I don't think 113943 was trying to remove code bytes. It seemed like it was an unintended bug. This PR, as-is, would elevate the missing code from bug to by-design which I'm hoping we can avoid.

I will give this try.

Thanks!

PAL_PerfJitDump_LogMethod((void*)pCode, codeSize, name.GetUTF8(), nullptr, nullptr, /*reportCodeBlock*/ stubAllocationType != PerfMapStubType::Block);
}
}
EX_CATCH{} EX_END_CATCH
Expand Down
Loading