summaryrefslogtreecommitdiff
path: root/src/vm/arm64/virtualcallstubcpu.hpp
AgeCommit message (Collapse)AuthorFilesLines
2019-01-11Patch vtable slots and similar when tiering is enabled (#21292)Koundinya Veluri1-1/+17
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.
2018-11-13Optimize vtable calls (#20696)Fadi Hanna1-0/+158
* Implementation of R2R vtable call thunks. These thunks will fetch the target code pointer from the vtable of the input thisPtr, and jump to that address. This is especially helpful with generics, since we can avoid a generic dictionary lookup cost for a simple vtable call. Overall, these thunks cause the CPU to have less branch mispredictions, and give a small performance boost to vtable calls. These stubs are under VirtualCallStubManager so that the managed debugger can handle stepping through them.
2018-05-24[Arm64] debugging work (#17993)David Wrighton1-1/+0
* Fix missing implementation of FuncEvalFrame::UpdateRegDisplay for ARM64 - Implementation is missing. Build new one based ARM implementation * Enable just my code on arm64 * Fix logging of addresses for DispatchPatchOrSingleStep * arm64 does not leave the PC at the start of the breakpoint * Enable interop debugging * Tweaks for windows arm64 mixed mode debugging support
2017-07-24[Arm64] Fix ResolveStub tokenHash lookupSteve MacLean1-2/+2
2016-06-21Arm64:return buffer arg should be passed in x8Rahul Kumar1-12/+12
2016-01-27Update license headersdotnet-bot1-4/+3
2015-12-11Port of all JIT changes for .NET Framework 4.6.1 changesBrian Sullivan1-46/+31
http://blogs.msdn.com/b/dotnet/archive/2015/11/30/net-framework-4-6-1-is-now-available.aspx .NET Framework list of changes in 4.6.1 https://github.com/Microsoft/dotnet/blob/master/releases/net461/dotnet461-changes.md Additional changes including - Working ARM64 JIT compiler - Additional JIT Optimizations o Tail call recursion optimization o Array length tracking optimization o CSE for widening casts o Smaller encoding for RIP relative and absolute addresses in addressing modes o Tracked Local Variable increased to 512 o Improved handling of Intrinsics System.GetType() o Improved handling of Math intrinsics - Work for the X86 Ryu-JIT compiler [tfs-changeset: 1557101]
2015-07-27[aarch64] Initial aarch64/linux bring upGeoff Norton1-3/+3
2015-01-30Initial commit to populate CoreCLR repo dotnet-bot1-0/+473
[tfs-changeset: 1407945]