Patchable JProfiler thread pool infrastructure - #24598
Draft
r30shah wants to merge 10 commits into
Draft
Conversation
Changes in this commit adds TR_JProfBlockFrequencyCounterSites for Patching BlockFrequencyInfo is patching of JProfiling is enabled. Counters emitted for the block frequency info in low opt compilations through JProfiling would need to be patched to turn-off data collection and potentially turn-on. TR_JProfBlockFrequencyCounterSites to facilitate back and forth patching. Signed-off-by: Rahil Shah <rahil@ca.ibm.com>
…Block instructions in Codegenerator
This commit adds JProfValueSites that contains the information about the instruction and location pair that controls execution of the Value Profiling using JProfiling. This assumption can be used to turn-off or turn-on profiling. Signed-off-by: Rahil Shah <rahil@ca.ibm.com>
Adds three static JIT options to J9Options that control the behaviour
of the patchable JProfiler:
_patchableJProfilingRecompilationFreq (default: 2000)
Maximum raw block-frequency count at which a method is considered
a candidate for warm recompilation rather than patching.
_patchableJProfilingPatchingAgeCutOff (default: 50000000)
Minimum elapsed time (in milliseconds) that must pass since a
method began collecting profiling data before it is eligible to
have its profiling instrumentation patched out.
_numOfMethodsToTriggerPatching (default: 10000)
Number of methods that must accumulate in the patch-pending list
before the dispatcher signals worker threads to begin a patching
phase.
Each option is declared as a static member in J9Options.hpp,
initialised to its default in J9Options.cpp, and exposed as a
command-line-settable option via the _feOptions table:
-Xjit:patchableJProfilingRecompilationFreq=<n>
-Xjit:patchableJProfilingPatchingAgeCutOff=<n>
-Xjit:numOfMethodsToTriggerPatching=<n>
Signed-off-by: Rahil Shah <rahil@ca.ibm.com>
A work-unit class that contains the list of compiled methods that needs their profiling code patches and performs patching. Depending number of worker threads created for Patchable JProfiler, functionality provided by this task allows infrastructure to differentiate analaysis and code patching execution. Signed-off-by: Rahil Shah <rahil@ca.ibm.com>
A work-unit that analyzes the frequency information of various methods and based on the information takes one of the following decision for the method. 1. If it is executed a lot (can be decided based on high max-raw count) by the application, recompile it at warm 2. If it is not executed a lot and application has already spend good amount of CPU Time since the method is compiled, patch the method to disable the profiling data collection as at this point, recompilation is not needed. 3. If application has not executed enough since the method started profiling data collection, let it profile and check other methods. Signed-off-by: Rahil Shah <rahil@ca.ibm.com>
Central coordinator for the JProfiler thread pool which manages set of native JVM threads which collectively performs following two distinct jobs. 1. Analysis - Main thread designed to perform analyze the profiling data and decide if it requires recompilation or patched to enable or disable the data collection. 2. Patching - Worker threads desinged to carry out mechanical work of patching the methods. Signed-off-by: Rahil Shah <rahil@ca.ibm.com>
r30shah
force-pushed
the
JProfilerThreadPoolPR
branch
from
August 20, 2026 14:43
ee12d64 to
9a9fbdd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduces the infrastructure for a patchable JProfiler: a thread-pool-based
design that separates profiling analysis from the mechanical work of patching
compiled method bodies to disable/enable data collection.
The core of the change is three cooperating components — a patching work-unit,
an analysis work-unit, and a thread-pool dispatcher — along with the JIT options
needed to tune their behavior at runtime. Together they allow the JProfiler to
offload patching to dedicated worker threads while keeping analysis on a single
coordinator thread.