| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* Remove concept of AppDomains from the GC
- Leave constructs allowing for multiple handle tables, as scenarios for that have been proposed
- Remove FEATURE_APPDOMAIN_RESOURCE_MONITORING
|
|
Fix COMPlus_DbgMiniDumpType values
|
|
Add ability to override stack size on all platforms
* Add DEFAULT_STACK_SIZE property
* Make environment variable affect all platforms
|
|
|
|
Change MyGet to the custom feeds. I found that for dotnet new console to restore, I needed an ASP.NET feed as well.
|
|
Add the DiagnosticProtocolHelper class to deserialize and dispatch
the new GenerateCoreDump command.
Refactor the PAL createdump launch on unhandled exception code to
used by a new PAL_GenerateCoreDump method that doesn't depend on
the complus dump environment variables.
Changed the "full" createdump not to include the uncommitted pages and
removed the "add module metadata" workaround for SOS clrstack !UNKNOWN
problem now that is fixed in SOS (crashinfo.cpp).
|
|
default (#24252)
When QuickJit is enabled, disable it for methods that contain loops by default
Fixes https://github.com/dotnet/coreclr/issues/19751 by default when QuickJit is enabled
- Added config variable TC_QuickJitForLoops. When disabled (the default), the JIT identifies loops and explicit tail calls and switches to tier 1 JIT.
- This would prevent the possibility of spending too long in QuickJit code, but may decrease startup time a bit when QuickJit is enabled
- Removed TC_StartupTier_OptimizeCode, as now that there is TC_QuickJit, I didn't see a good use for it
- Removed references to "StartupTier" in config variables because we had previously decided not to call it that.
- When QuickJit is disabled, avoid creating native code slots for methods in non-R2R'ed modules, as tiering would be disabled for those anyway
- Marked TC_QuickJit config var as external
|
|
|
|
|
|
* Update ContextualReflection doc
* PR Feedback
|
|
|
|
|
|
These files don't render correctly on github due to broken new lines - fixing it. Only new line characters replaced, nothing else touched.
|
|
|
|
The instructions for CMake failed to list 3.14.1 when using Visual Studio 2019.
|
|
Clarifying that profiler attach/detach are a known gap
|
|
Allow the runtime to load types with incomplete interface implementations. With this change, we allow (in pseudo-C#):
```csharp
interface IFoo { void Frob() { } }
interface IBar : IFoo { abstract void IFoo.Frob() }
class Fooer : IBar { }
```
Calling IFoo.Frob on an instance of `Fooer` will result in new exception being thrown because the default implementation of `IFoo.Frob` was re-abstracted by `IBar`.
|
|
|
|
* Defining VariableLiveRange class
* Adding some typedefs to avoid rewriting
* Defining VariableLiveDescriptor class
* Initializing VariableLiveRange structures before BasicBlock code is being generated
* Getting a siVarLoc for variable homes from a given LclVarDsc and stack level
* Defining VariableLiveKeeper class
* Reporting VariableLiveRanges on changes of variable livenesss or variable homes
* Adding USING_VARIABLE_LIVE_RANGE flag to enable disable VariableLiveRange
* Send VariableLiveRanges to debugger
* Reporting variable homes on prolog
* Wrong argument
* Miss to change variable homes count before sending them to debugger
* Adding dumper of VariableLiveRanges for each blocks and end of code generation
* Close all open VaribleLiveRanges on last BasicBlock
* Changing order of properties initialization on VariableLiveRange constructor
* Type error on assignation
* Rephrasing comments, moving dumps and fixing typos
* Changing const VARSET_TP* for VARSET_VALARG_TP on args
* Variable home was variable location in VariableLiveRange context
* Rephrase and rename of VariableLiveKeeper properties
* Missing some renames
* Adding const where BasicBlock should not be modified
* siBeginBlock and siInit have support for debug code for VariableLiveRange and siScope info
* Adding USING_VARIABLE_LIVE_RANGE flags on methods definition.
* Variable home -> variable location
* Renaming and rephrasing names and uses of VariableLiveRange
* Moving LiveRangeDumper ctor to class declation
* Removing destructors
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Removing blank spaces and reordering functions inside class definition
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Miss to increment the index after refactoring
* Logic for keeping the last BasicBlock end IL offset is shared between siScope and VariableLiverange for debug code
* Missing to print on debug the last block VariableLiveRanges
* Avoid updating VariableLiveRange when unspilling and dying at the same assembly instruction
* Rephrasing #ifs and #ifdefs
* Calling VariableLiveKeeper in one line
* Avoid copying siVarLoc on genSetScopeInfo
* Removing unused args from eeSetLVinfo
* Changing VariableLiveKeeper ctor
* Typo
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Updating VariableLiveDescriptor ctor
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Error on first argument
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Changing reference for pointer
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Renaming assembly offset -> native offset
* removing unnecesary comments and asserts
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Update VariableLiveRange dump message
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Moving VariableLiveRanges classes inside VariableLiveKeeper
* Wrong flag name
* Adding documentation about how we track variables for debug info
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Adding opened issues to doc file
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Changing dump tittle
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Renaming VariableLiveKeeper property
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Update documentation
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Updating comments on flags
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
* Setting Scope Info as default way of tracking variables for debug info
Signed-off-by: Brian Bohe <brianbohe@gmail.com>
|
|
* Update DllMap doc
Update DllMap design doc:
* To note the NativeLibrary APIs that can be used to implement DllMap
* To point to a sample implementation of DllMap.
|
|
|
|
(#23202)
* Add ApplyMetadata changes back
This reverts commit f9c10f995fe65c0e7c30aa1734f7bb22c519983d.
* Fix race condition in loading available class hash for R2R with old R2R images or profiler modified R2R images
|
|
|
|
.Net -> .NET
|
|
|
|
so that it uses run-xunit-perf.py command. run-xunit-perf.cmd is no longer there.
|
|
|
|
|
|
* Update EventCounter spec
* some wording fix
* some wording fix
* fix payload example
* Add DisplayRateTimeScale
|
|
The ref count update traversal in the optimizer is not doing anything,
so remove it. This was overlooked when we changed away from incremental
updates in #19345.
Also: fix up comments and documentation to reflect the current approach
to local var ref counts.
|
|
|
|
|
|
* Use arcade dotnet
* Add cmake_msbuild.cmd
Move msbuild.cmd to cmake_msbuild.bat
Document intent that this file is only used to resolve
Windows cmake dependency on desktop msbuild.exe
Remove one instance of msbuild.cmd
* Fix inittools.cmd
* Remove spurious setup_vs_tools.cmd calls
|
|
This reverts commit ee755e322dabc2fc280e2561b0fbaf6e90aedf54.
|
|
* Update EventCounter spec
We made a flurry of decisions in our meeting last wednesday.
Partly this fills in areas of the design we didn't adequately decide on and
partly this suggests a few changes after having had time to think on it.
1) My suggestion to use IntervalSec as an identifier for a series doesn't
work. I proposed a new field 'Series' that is used for that same purpose.
2) I am proposing we no longer standardize on the five-tuple of stats.
Although it made sense to me at the time, decisions we made later in the
meeting invalidated the basis for that choice IMO.
3) Aggregating seems like an overly generic name that all counters do, so
I propose 'Incrementing' as a more specific term.
4) I am proposing we stop accepting fractional time intervals because
probably nobody would have used them anyways and now we don't have to worry
about floating point rounding and canonicalization issues when determining
if two clients share the same time series or in round tripping the identifier
back to them.
5) I defined specific fields for 'DisplayName' and 'CounterType' in our
wire protocol. Although not opposed to a generic metadata field for other
purposes, it seemed unnecessary for our current purposes.
6) I switched Incrementing coutner to float, because it it
would be a shame if we had to make a whole new counter in the future
that did exactly the same thing just with floating point values. For example
'GC Seconds Paused'
|
|
|
|
|
|
|
|
(#22363)
|
|
* Enable arm64 linux musl builds
Note that -clang5.0 is required to be passed.
* Fix syntax error
* Pass clang arg to build-test.sh
|
|
* Support building with VS2019 Preview
* Fixing gen-buildsys-win to only set the architecture for the VS generator
* Refactoring Dev11/147911/fpcw.cpp so that it compiles under VS2019
* Removing the remaining traces of VS2015 build support
|
|
|
|
* 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
|
