summaryrefslogtreecommitdiff
path: root/src/vm/virtualcallstub.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-01-22Do not throw from TraceResolver (#22126)Michal Strehovsk√Ĺ1-3/+5
Fixes #22059.
2019-01-12Patch vtable slots and similar when tiering is enabled (#21292)Koundinya Veluri1-4/+41
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-29Delete code related to LoaderOptimization and SharedDomain (#21031)Jan Kotas1-22/+0
2018-11-15Allow supressing exceptions in diamond inheritance cases (#20458)Michal Strehovsk√Ĺ1-13/+22
2018-11-13Optimize vtable calls (#20696)Fadi Hanna1-7/+123
* 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-11-10Delete dead/unreachable code related to remoting (#20880)Jan Kotas1-10/+2
2018-08-28fix build break when STUB_LOGGING is defined (#19707)Andy Ayers1-1/+1
2018-05-27Typo (#18141)John Doe1-1/+1
* Ajusted -> Adjusted * alot -> a lot * Ambigous -> Ambiguous * amoun -> amount * amoung -> among * Amperstand -> Ampersand * Anbody -> Anybody * anddoens't -> and doesn't * anme -> name * annoations -> annotations * annother -> another * anothr -> another * ansynchronous -> asynchronous * anticpation -> anticipation * anway -> anyway * aother -> another * Apparant -> Apparent * appartment -> apartment * appdmomain -> appdomain * Appdomian -> Appdomain * appdomin -> appdomain * approproiate -> appropriate * approprate -> appropriate * approp -> appropriate * appened -> appended * appropiately -> appropriately * appropraitely -> appropriately * Apperantly -> Apparently * approp. -> appropriate * Approriate -> Appropriate
2018-05-25Typo (#18122)John Doe1-1/+1
* acquringing -> acquiring * Activ -> Active * activley -> actively * acutal -> actual * bIncomingIPAdddefed -> bIncomingIPAddRefed * adddr -> addr * readding -> reading * Addfunction -> AddFunction * additionnal -> additional * Additonal -> Additional * Additonally -> Additionally * Addresss -> Address * addtion -> addition * aded -> added * aditional -> additional * adjustements -> adjustments * Adress -> Address * afer -> after * aformentioned -> aforementioned * afte -> after * agains -> against * agaisnt -> against * aggresively -> aggressively * aggreates -> aggregates * aggregious -> egregious * aginst -> against * agregates -> aggregates * Agressive -> Aggressive * ahve -> have * ajdust -> adjust * ajust -> adjust * alement -> element * algoritm -> algorithm * alighnment -> alignment * alignmant -> alignment * constraits -> constraints * Allcator -> Allocator * alllocate -> allocate * alloacted -> allocated * allocatate -> allocate * allocatoror -> allocator * alloctaed -> allocated * alloction -> allocation * alloted -> allotted * allt he -> all the * alltogether -> altogether * alocate -> allocate * alocated -> allocated * Alocates -> Allocates * alogrithm -> algorithm * aloocate -> allocate * alot -> a lot * alwasy -> always * alwyas -> always * alwys -> always
2017-09-19Disable VSD Stub Kind Prediction on H/W Exception (#14051)Jonghyun Park1-4/+4
* Disable VSD Stub Kind Prediction on H/W Exception * Add a comment on a false argument * Use BOOL (instead of bool) for consistency * Replace remaining bool/true/false with BOOL/TRUE/FALSE
2017-07-25PerfMap instrument stubs (#12437)Steve MacLean1-0/+20
* PerfMap instrument stubs * Perfmap fix segfault
2017-06-12[Arm64/Unix] Add 64K page support (#10981)Steve MacLean1-27/+27
* [Arm64/Unix] Support 64K pages * GC move GCToOSInterface::Initialize() into InitializeGarbageCollector()
2017-05-18[x86/Linux] Fix undefined references on SOS (#11701)Jonghyun Park1-7/+7
2017-02-28[x86/linux] Implement BackPatchWorkerAsmStub (#9690)Yongseop Kim1-0/+7
* [x86/linux] Implement BackPatchWorkerAsmStub This implementation is ported from BackPatchWorkerAsmStub in vm/i386/virtualcallstubcpu.hpp
2017-02-15Remove never defined FEATURE_REMOTINGdanmosemsft1-207/+0
2016-09-29Set THUMB bit for RUNTIME_FIXUP_HELPER functions (#7373)Jonghyun Park1-1/+1
* Appends THUMB bit for RUNTIME_FIXUP_HELPER address * Revise GetEEFuncEntryPoint (for ARM) and use it to set thumb bit * Uses GetEEFuncEntryPoint instead of GFN_TADDR
2016-05-19Fix x86 only ICastable feature bug.Yi Zhang1-5/+4
When we call ICastable.IsInstanceOfInterface, we treat RuntimeTypeHandle as a OBJECTREF, which is incorrect as-per x86 calling convention since RuntimeTypehandle is a struct that contains a RuntimeType ref field and needs to be passed in stack. Our VM simple call helpers CALL_MANAGED_METHOD doesn't handle this correctly (it does the simple thing that always assume all the arguments are passed in register first). I'm fixing this by using a static method that takes RuntimeType instead of RuntimeTypeHandle, then convert it to RuntimeTypehandle. Also switch to use PREPARE_NONVIRTUAL_CALLSITE(METHODID) as per Jan's suggestion. ICastable test is now enabled in x86 for both JITs.
2016-01-27Update license headersdotnet-bot1-4/+3
2015-12-12Port of all JIT changes for .NET Framework 4.6.1 changesBrian Sullivan1-0/+4
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-09-08Fix missing uses of the INSTALL_MANAGED_EXCEPTION_DISPATCHERJan Vorlicek1-0/+2
This fixes issues stemming from my recent changes in managed exception dispatching where I have missed few places where we need to perform managed exception dispatching or unhandled exception reporting.
2015-09-08Fix managed exception dispatchingJan Vorlicek1-0/+4
The managed exception dispatching is initiated from the UNINSTALL_MANAGED_EXCEPTION_DISPATCHER macro and it should be used only at the border between managed and native code, when managed code calls native one. This macro is part of the UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE macro. However, it turns out that the UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE (or the UNINSTALL_UNWIND_AND_CONTINUE_HANDLER that uses it) is also used at places where there is no managed / native border. In that case, the managed dispatching results incorrectly in skipping native frames that would otherwise handle the exception. The fix removes the INSTALL_MANAGED_EXCEPTION_DISPATCHER / UNINSTALL_MANAGED_EXCEPTION_DISPATCHER from the INSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE / UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE and puts them to specific places where INSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE / UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE and INSTALL_UNWIND_AND_CONTINUE_HANDLER / UNINSTALL_UNWIND_AND_CONTINUE_HANDLER are used at the border between managed and native code.
2015-03-18Implement runtime support for ICastable interfaceEugene Zemtsov1-41/+91
The goal of this change is to facilitate an alternative (MCG based) way of doing COM interop, we're going to use it on Unix platforms. New ICastable interface allows objects to pretend at runtime that they support an interface and to provide an alternative type that is used to resolve actual calls to interface methods. BE VERY CAREFUL: This is a very dangerous feature, and at this stage it can easily lead to memory corruption without any native code involved. Reviewers: Yi Zhang, Noah Falk, Jan Kotas. DDR clean. [tfs-changeset: 1435198]
2015-01-30Initial commit to populate CoreCLR repo dotnet-bot1-0/+4198
[tfs-changeset: 1407945]