Merge dotnet/main into feature/fcalls-cleanups

Author: am11

.config/dotnet-tools.json

@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "10.0.0-prerelease.24568.1",
+      "version": "10.0.0-prerelease.24575.1",
       "commands": [
         "xharness"
       ]

.github/workflows/jit-format.yml

@@ -28,21 +28,10 @@ jobs:
     container: ${{ matrix.os.container }}
     name: Format jit codebase ${{ matrix.os.name }}
     steps:
-      - name: Checkout jitutils
-        uses: actions/checkout@v4
-        with:
-          path: jitutils
-          repository: dotnet/jitutils
-          ref: main
-          token: ${{ secrets.GITHUB_TOKEN }}
       - name: Install .NET
         uses: actions/setup-dotnet@v4
         with:
           dotnet-version: '8.0.x'
-      - name: Build jitutils
-        run: |
-          ./bootstrap${{ matrix.os.extension }}
-        working-directory: jitutils
       - name: Checkout runtime
         uses: actions/checkout@v4
         with:
@@ -52,7 +41,7 @@ jobs:
 
       - name: Run jitformat.py
         run: |
-          python3 runtime/src/coreclr/scripts/jitformat.py --jitutils jitutils -r runtime -o ${{ matrix.os.name }} -a x64 ${{ matrix.os.cross }}
+          python3 runtime/src/coreclr/scripts/jitformat.py -r runtime -o ${{ matrix.os.name }} -a x64 ${{ matrix.os.cross }}
         env:
           ROOTFS_DIR: ${{ matrix.os.rootfs }}
 
@@ -61,4 +50,4 @@ jobs:
         with:
           path: runtime/format.patch
           name: format.${{matrix.os.name}}.patch
-        if: failure()
+        if: failure()

docs/design/coreclr/botr/ilc-architecture.md

@@ -129,7 +129,7 @@ Note that while "constructed" and "unconstructed" type nodes are modelled separa
 
 Related compiler switches: `--dgmllog` serializes the dependency graph into an XML file. The XML file captures all the nodes in the graph, but only captures the first edge leading to the node (knowing the first edge is enough for most purposes). `--fulllog` generates an even bigger XML file that captures all the edges.
 
-Related tools: [Dependency analysis viewer](../how-to-debug-compiler-dependency-analysis.md) is a tool that listens to ETW events generated by all the ILC compiler processes on the machine and lets you interactively explore the graph.
+Related tools: [Dependency analysis viewer](../../../../src/coreclr/tools/aot/DependencyGraphViewer/README.md) is a tool that listens to ETW events generated by all the ILC compiler processes on the machine and lets you interactively explore the graph.
 
 ## Object writing
 The final phase of compilation is writing out the outputs. The output of the compilation depends on the target environment but will typically be some sort of object file. An object file typically consists of blobs of code or data with links (or relocations) between them, and symbols: named locations within a blob. The relocations point to symbols, either defined within the same object file, or in a different module.

docs/design/coreclr/botr/profilability.md

@@ -31,22 +31,23 @@ ICorProfilerCallback
 
 This interface comprises the callbacks made by the CLR into the profiler to notify the profiler of interesting events.  Each callback is wrapped in a thin method in the EE that handles locating the profiler's implementation of ICorProfilerCallback(2), and calling its corresponding method.
 
-Profilers subscribe to events by specifying the corresponding flag in a call to ICorProfilerInfo::SetEventMask().  The profiling API stores these choices and exposes them to the CLR through specialized inline functions (CORProfiler\*) that mask against the bit corresponding to the flag.   Then, sprinkled throughout the CLR, you'll see code that calls the ICorProfilerCallback wrapper to notify the profiler of events as they happen, but this call is conditional on the flag being set (determined by calling the specialized inline function):
+Profilers subscribe to events by specifying the corresponding flag in a call to ICorProfilerInfo::SetEventMask()/ICorProfilerInfo::SetEventMask2().  The profiling API stores these choices and exposes them to the CLR through specialized inline functions (CORProfiler\*) that mask against the bit corresponding to the flag.   Then, sprinkled throughout the CLR, you'll see code that calls the ICorProfilerCallback wrapper to notify the profiler of events as they happen, but this call is conditional on the flag being set (determined by calling the specialized inline function):
 
     {
-        //check if profiler set flag, pin profiler
-        BEGIN_PIN_PROFILER(CORProfilerTrackModuleLoads());
+        // check if profiler set flag
+        BEGIN_PROFILER_CALLBACK(CORProfilerTrackModuleLoads());
 
-        //call the wrapper around the profiler's callback implementation
-        g_profControlBlock.pProfInterface->ModuleLoadStarted((ModuleID) this);
+        // call the ProfControlBlock wrapper around the profiler's callback implementation
+        // which pins the profiler in DoOneProfilerIteration via EvacuationCounterHolder
+        (&g_profControlBlock)->ModuleLoadStarted((ModuleID) this);
+        // unpins the profiler after completing the callback
 
-        //unpin profiler
-        END_PIN_PROFILER();
+        END_PROFILER_CALLBACK();
     }
 
 To be clear, the code above is what you'll see sprinkled throughout the code base.  The function it calls (in this case ModuleLoadStarted()) is our wrapper around the profiler's callback implementation (in this case ICorProfilerCallback::ModuleLoadStarted()).  All of our wrappers appear in a single file (vm\EEToProfInterfaceImpl.cpp), and the guidance provided in the sections below relate to those wrappers; not to the above sample code that calls the wrappers.
 
-The macro BEGIN\_PIN\_PROFILER evaluates the expression passed as its argument.  If the expression is TRUE, then the profiler is pinned into memory (meaning the profiler will not be able to detach from the process) and the code between the BEGIN\_PIN\_PROFILER and END\_PIN\_PROFILER macros is executed.  If the expression is FALSE, all code between the BEGIN\_PIN\_PROFILER and END\_PIN\_PROFILER macros is skipped.  For more information about the BEGIN\_PIN\_PROFILER and END\_PIN\_PROFILER macros, find their definition in the code base and read the comments there.
+The macro BEGIN_PROFILER_CALLBACK evaluates the expression passed as its argument.  If the expression is TRUE, the code between the BEGIN_PROFILER_CALLBACK and END_PROFILER_CALLBACK macros is executed, and the profiler is pinned into memory (meaning the profiler will not be able to detach from the process) through the ProfControlBlock wrapper.  If the expression is FALSE, all code between the BEGIN_PROFILER_CALLBACK and END_PROFILER_CALLBACK macros is skipped.  For more information about the BEGIN_PROFILER_CALLBACK and END_PROFILER_CALLBACK macros, find their definition in the code base and read the comments there.
 
 Contracts
 ---------