| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* Add design document for the unloadability
|
|
|
|
|
|
* Update linux/OSX build instructions
* Update based on feedback
* Address PR feedback
* Update to address feedback
|
|
Patch vtable slots and similar when tiering is enabled
For a method eligible for code versioning and vtable slot backpatch:
- It does not have a precode (`HasPrecode()` returns false)
- It does not have a stable entry point (`HasStableEntryPoint()` returns false)
- A call to the method may be:
- An indirect call through the `MethodTable`'s backpatchable vtable slot
- A direct call to a backpatchable `FuncPtrStub`, perhaps through a `JumpStub`
- For interface methods, an indirect call through the virtual stub dispatch (VSD) indirection cell to a backpatchable `DispatchStub` or a `ResolveStub` that refers to a backpatchable `ResolveCacheEntry`
- The purpose is that typical calls to the method have no additional overhead when code versioning is enabled
Recording and backpatching slots:
- In order for all vtable slots for the method to be backpatchable:
- A vtable slot initially points to the `MethodDesc`'s temporary entry point, even when the method is inherited by a derived type (the slot's value is not copied from the parent)
- The temporary entry point always points to the prestub and is never backpatched, in order to be able to discover new vtable slots through which the method may be called
- The prestub, as part of `DoBackpatch()`, records any slots that are transitioned from the temporary entry point to the method's at-the-time current, non-prestub entry point
- Any further changes to the method's entry point cause recorded slots to be backpatched in `BackpatchEntryPointSlots()`
- In order for the `FuncPtrStub` to be backpatchable:
- After the `FuncPtrStub` is created and exposed, it is patched to point to the method's at-the-time current entry point if necessary
- Any further changes to the method's entry point cause the `FuncPtrStub` to be backpatched in `BackpatchEntryPointSlots()`
- In order for VSD entities to be backpatchable:
- A `DispatchStub`'s entry point target is aligned and recorded for backpatching in `BackpatchEntryPointSlots()`
- The `DispatchStub` was modified on x86 and x64 such that the entry point target is aligned to a pointer to make it backpatchable
- A `ResolveCacheEntry`'s entry point target is recorded for backpatching in `BackpatchEntryPointSlots()`
Slot lifetime and management of recorded slots:
- A slot is recorded in the `LoaderAllocator` in which the slot is allocated, see `RecordAndBackpatchEntryPointSlot()`
- An inherited slot that has a shorter lifetime than the `MethodDesc`, when recorded, needs to be accessible by the `MethodDesc` for backpatching, so the dependent `LoaderAllocator` with the slot to backpatch is also recorded in the `MethodDesc`'s `LoaderAllocator`, see `MethodDescBackpatchInfo::AddDependentLoaderAllocator_Locked()`
- At the end of a `LoaderAllocator`'s lifetime, the `LoaderAllocator` is unregistered from dependency `LoaderAllocators`, see `MethodDescBackpatchInfoTracker::ClearDependencyMethodDescEntryPointSlots()`
- When a `MethodDesc`'s entry point changes, backpatching also includes iterating over recorded dependent `LoaderAllocators` to backpatch the relevant slots recorded there, see `BackpatchEntryPointSlots()`
Synchronization between entry point changes and backpatching slots
- A global lock is used to ensure that all recorded backpatchable slots corresponding to a `MethodDesc` point to the same entry point, see `DoBackpatch()` and `BackpatchEntryPointSlots()` for examples
Due to startup time perf issues:
- `IsEligibleForTieredCompilation()` is called more frequently with this change and in hotter paths. I chose to use a `MethodDesc` flag to store that information for fast retreival. The flag is initialized by `DetermineAndSetIsEligibleForTieredCompilation()`.
- Initially, I experimented with allowing a method versionable with vtable slot backpatch to have a precode, and allocated a new precode that would also be the stable entry point when a direct call is necessary. That also allows recording a new slot to be optional - in the event of an OOM, the slot may just point to the stable entry point. There are a large number of such methods and the allocations were slowing down startup perf. So, I had to eliminate precodes for methods versionable with vtable slot backpatch and that in turn means that recording slots is necessary for versionability.
|
|
Add a note to clarify debugging w/ dotnet is fine
|
|
* Updated "Viewing JIT Dumps" for .NET Core 3.0
plus some minor wording change
* Incorporated changes from https://github.com/dotnet/coreclr/pull/21859
|
|
The license name already has 'license' in the end, the second one is unnecessary.
|
|
|
|
Lay the groundwork for guarded devirtualization of virtual and interface
calls in the jit.
Introduce the notion of a guarded devirtualization candidate and identify
these if regular devirtualization fails. Use simple heuristics to produce
a class to guess for. Require that the method that would be invoked if the class
guess is correct be a plausible inline candidate.
Generalize the calli transformer to become an indirect call transformer.
This runs after importation because it needs to introduce control flow and
runs before inlining so that the new direct calls it introduces can be inlined.
Implement the transformation to duplicate the call site, devirtualize on the side
where the class is now known exactly, and turn the resulting direct call into an
inline candidate.
Add a motivation and design document.
|
|
arguments for Linux/arm cross build (Part 2) (#21034)
* Stop building and publishing Hostx86/arm crossgen on Linux/arm
* Remove -crosscomponent argument and stop using CAC_ROOTFS_DIR environment variable in build.sh
* Simplify the related logic in build.sh
* Don't need to specify crosscomponent in tests/scripts/run-pmi-diffs.py
* Don't set CAC_ROOTFS_DIR in buildpipeline, Jenkins files and in tests/scripts/run-pmi-diffs.py
* Adjust documentation
|
|
|
|
|
|
* Update changing-corelib.md
@jkotas
* Update changing-corelib.md
|
|
|
|
|
|
Update to reflect changes in the repo, and fix various formatting issues.
|
|
(#20836)
* Don't use crosscomponent|-crosscomponent command line args in build.sh
* Don't use CROSSCOMPONENT environment variable in build.sh src/pal/tools/gen-buildsys-clang.sh
* Remove mentioning -crosscomponent from usage() in build-test.sh
* Don't use -crosscomponent in buildpipeline
* Don't use -crosscomponent in Groovy files
* Remove mentioning crosscomponent in Documentation/building/linux-instructions.md
* Stop building Hostx86/armel crossgen in build.sh
* Disable CrossGen-ing of System.Private.CoreLib on Linux/armel
|
|
* Corrected some typos and grammar as per English language guidelines.
* Reverted some of the changes
* Reverted back some changes Phase 2
|
|
precomppiled -> precompiled
|
|
Visual Studio Code is also broadly known as VSCode. But since this document already contained a typo
and Visual Studio Code is not referred as VSCode elsewhere in the CoreCLR documentation I figured it could
be nice to _clean_ this documentation page.
|
|
ref https://github.com/dotnet/coreclr/issues/12705#issuecomment-314102508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Remove old reference to Rotor in documentation.
All remaining references relate to rotor's role in CoreCLR history.
* Remove rotor comment from enummem.cpp.
I can find no evidence that the presence of g_pStressLog is conditional
on FEATURE_PAL being defined.
* Remove old todo, DbgDllMain looks for thread detach.
* Update nativepipeline.h comment refernce to rotor.
All unix-like systems except android have FEATURE_DBGIPC_TRANSPORT_DI
defined, hence "most unix-like platforms".
* Update some comments to not refer to Rotor.
* Remove some more references to Rotor from comments.
* Remove old comment.
Though maybe this macro should be removed and everywhere use the & operator.
It appears there are only two places that use this macro.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Correct pdf link
|
|
|
|
(#19773)
* Add short guide for using tiered compilation and how to provide feedback
* Suggested changes
* Update to say that it's enabled by default
* Add info about target framework/runtime
|
|
|
|
|
|
* testsing -> testing
* reclaming -> reclaiming
* oppurtunity -> opportunity
* implemenation -> implementation
* indicaates -> indicates
* enregisterd -> enregistered
* compuations -> computations
* convinient -> convenient
* intution -> intuition
* Communicaton -> Communication
|
|
Change build-test.sh to always build the xunit wrappers. Before it would drop a token and check the existence of the token.
Unify x64 linux/OSX/Windows excludes into one file, issues.targets. Includes different locations in the file which show where to put excludes.
Remove all target specific aspects of issues.targets, all tests are excluded now via wildcard, this allows expanding to .cmd and .sh based on the built platform.
Unify path separators to forward slash(/) in issues.targets to support both platforms
Clean up issues.targets by removing long standing exclude tests, specifically tests that have been excluded due to missing features like rva_statics.
Add DisableProjectBuild to tests which have been removed from issues.targets
Conditionally add DisableProjectBuild to tests which have been marked as unsupported on unix. This is mostly a port of the unsupportedOnUnix.txt list. Instead of excluding the tests, unix will simply not build them. If tests are built on windows, they will be run but they will return pass, the test wrapper will check return instantly.
All exclusions ported to issues.targets for linux targets.
Expand runtest.py, this includes simple issues that made it past the original CR. In addition it adds more optional features to help with inner loop dev work such as: creating a repro folder under bin/repro/.. which sets up the env and calls the failing test. In addition a launch.json will now be created under bin/repro/.. which can be used to easily debug using vscode. More logging, such as printing failures, longest running tests ect.
Initial excludes ported for arm64 windows
Arm64 linux, armhf unix excludes and enables running runtest.sh for these targets.
arm64 windows and arm32 windows excludes and enables running runtest.cmd on arm64 targets
init-tools.sh changes to pull armhf and aarch64 dotnetcli
init-tools.cmd changes to pull x86 packages for dotnetcli for arm64 windows
runtest.cmd for almost all scenarios will call runtest.py
runtest.sh for almsot all scenarios will call runtest.py
Removes all logic for running tests using runtest.sh
|
|
|
|
|
|
Enable Tiered Compilation by default
1) Changes the default state of the tiered compilation feature check to be ON BY DEFAULT
2) Removed comments about the source about this being a work in progress. Although it will surely continue to evolve and improve, remaining issues would be better tracked in our issue tracking system with the same default presumption as other runtime features - assume it works unless noted otherwise.
3) Adjusts a number of tests and automated scripts that made assumptions that the default setting of this feature is off.
4) Stop accepting the deprecated env var COMPLUS_EXPERIMENTAL_TieredCompilation. I'm not aware it has any remaining usage but if so we're going to find out.
5) Adjust config names for JitBench
|
|
|
|
|
|
|
|
|
