| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* Update RyuJIT
This picks up:
* JitInterface changes
* dotnet/coreclr#15475
When Cbrt/Asinh/Acosh/Atanh is added, we'll want to uncomment the intrinsic recognition.
* Update framework to latest
* Fix ReadOnlySpan
* Implement Environment.ProcessorCount with PalGetProcessCpuCount
|
|
|
|
* Fix issues building the runtime, corelib and type loader for WebAssembly
* Fix test infrastructure to allow running with the wasm flavor
|
|
Some flavors depend on InitializeModules
[tfs-changeset: 1681285]
|
|
As part of my work on .NET Native optional component bring-up I have refactored internal framework management of app modules to be independent on MRT. This is needed so that the app and optional component only know about "their own" modules (while MRT stores all their modules). I basically somewhat unified ProjectN and CoreRT behavior in the sense that I switched ProjectN over to use the module lists in StartupCodeHelpers used by CoreRT, making them slightly more flexible to support dynamic accumulation of the module list during ProjectN startup. In incremental build mode, I have reused the already existing "assembly rooting" technique to make sure all the component assemblies are properly registered in the module list. The change passes basic testing in single-file, shared and incremental build modes on x86 and amd64, I'm running a full ToF run and I plan to run an AppCompat run after I stabilize the change by addressing CR feedback.
In 2nd iteration I slightly refactored the change based on JanK's and Michal's feedback: I created a secondary version of StartupCodeHelpers specific to .NET Native called StartupCodeHelpers.ProjectN.cs. It only contains the logic regarding the "GetLoadedModules" list which is newly built up using the StartupCodeTrigger calls to StartupCodeHelpers.RegisterModule. The two versions of the module expose the same signatures of the two methods "GetLoadedModules" and "GetLoadedOSModules" that are subsequently called from RuntimeAugments. RhGetLoadedOSModules is still in place as it's needed to produce the dump header. Based on JanK's suggestion I have refactored StackTraceGenerator.Windows to stop calling the method.
In 3rd iteration I addressed additional Michal's and Jan's feedback and I tried to answer some questions.
In 4th iteration I addressed additional JanK's feedback.
Thanks
Tomas
[tfs-changeset: 1681241]
|
|
|
|
CoreRT is component of ProjectN (aka .NET Native for UWP), but our current defines do not reflect it because of CORERT is not defined in ProjectN builds. This creates confusion for folks outside the core runtime team, and conflicts with our documentation. For example, https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md says "CoreRT is the .NET Core runtime that is optimized for AOT scenarios, which .NET Native targets". It does not say "CoreRT is the .NET Core runtime optimized for AOT scenarios that uses RyuJIT backend" or anything like that.
- Before this change:
PROJECTN: defined in closed source ProjectN builds
CORERT: defined in open source CoreRT builds
CORECLR: defined in CoreCLR builds
- After this change:
PROJECTN: defined in closed source ProjectN builds (same)
CORERT: defined in both open source CoreRT builds and closed source ProjectN builds (different)
CORECLR: defined in CoreCLR builds (same)
[tfs-changeset: 1680901]
|
|
The new GetOsModuleHandle API is used by the StackTraceMetadata code in both ProjectN and ProjectX.
[tfs-changeset: 1680143]
|
|
|
|
instantiating unboxing stubs.
The implementation uses a general purpose infrastructure that can associate custom data to methods with unwind info, given the fact that unwind info lookups are very fast.
Similar to GC info and EH info, this implementation now provides a way to associate any custom data to methods, by adding a flag and a reloc to the data in the method's unwind info.
The custom data that can be attached to methods begin with a flag (indicating what data follows), followed by data.
Right now, the only custom data we have for methods are unboxing stub target pointers.
The dependency analysis models this custom data using a new node type: MethodAssociatedDataNode.
The custom data (when it exists) can be be retrieved using a new API on ICodeManager.
The changes also include all the necessary plumbing to link custom data nodes symbols for PX (given that it's UTC that emits the unwind info)
[tfs-changeset: 1673664]
|
|
enable the RhGetCodeTarget API:
1) Stubs are still grouped, but by section now. Linker will merge/fold/sort the unboxing stubs by section name.
2) All unboxing stubs are delimited by __unbox_a and __unbox_z symbols
3) __unbox_a and __unbox_z works on all platforms (tested on ProjectN (no regressions verification), ProjectX single and multi-file, Windows CoreRT, Unbuntu CoreRT, and OSX CoreRT)
4) Implementation uses a registration mechanism for unboxing stubs regions, and is multi-file ready for CoreRT (uses a linked list of stub regions)
5) Deleting the R2R section of unboxing stubs since it doesn't work on non-windows. Using extern "C" variables instead.
6) Removing the module enumeration API exposed by the TypeLoaderCallbacks (no longer needed)
[tfs-changeset: 1672333]
|
|
[tfs-changeset: 1671610]
|
|
1) Enable field access for USG cases (Rooting reflectable fields in the graph, filling TODOs in the FieldAccessMap and StaticsInfoHashtable structures)
2) Implementation of TLS fields reflection support for ProjectX (CoreRT is still TODO)
3) Refactoring/simplification of TLS access (deleting the ThreadStaticFieldOffsets struct from the native runtime, and simplifying TLS access code)
4) Adding more tests to the PX DynamicGenerics unit test.
[tfs-changeset: 1669403]
|
|
generated by the ZapImage::ConvertToLargeUnboxingStub function in the binder
[tfs-changeset: 1665237]
|
|
- Change eetype node name to end with ::`vftable' to improve debuggability in windbg
- Change node name of statics nodes to be composed from mangled type name + a suffix. This makes it possible to find these statics blocks through msdia api surface. Will need work with debugger symbol generation to provide individual static field lookup
- Send debugger events on module load for TypeManager based modules
[tfs-changeset: 1656557]
|
|
|
|
Contributes to https://github.com/dotnet/corefx/issues/16799
[tfs-changeset: 1652035]
|
|
Implement Thread for Unix:
* Use a callback from PalDetachThread to signal the thread as stopped.
* In BasicThreading test account that SafeHandle postpones disposing until the next garbage collection.
* Move reusable code from RuntimeThread.Windows.cs to RuntimeThread.cs.
* Rename *Core functions to *Internal to be close to CoreCLR implementation.
* Priority is ignored for now.
Fixes for Windows:
* Merge HasFinishedExecution and JoinInternal.
* Handle race condition between JoinInternal and SafeWaitHandle finalizer: SafeWaitHandle.DangerousAddRef may throw an ObjectDisposedException.
* Handle Interop.mincore.CreateThread returning the NULL handle.
|
|
between C++ and Managed
- Results in mishandling the parameters to the RhpGetModuleSection api
- Fix is to force a pointer to be passed, which has equivalent handling in both C++ and the existing managed calling convention on the windows x86 builds
[tfs-changeset: 1648927]
|
|
- Move from using an IntPtr which may represent a TypeManager* or a OS module pointer to using a struct TypeManagerHandle consistently
- Except for RuntimeSignature, which has a third possible meaning of its IntPtr. That work will be done in a seperate change, and wil result in removal of nearly all of the new TypeManagerHandle calls in this delta.
- This struct contains a bit which indicates which form of pointer is being worked with, as well as routines for performing RVA access as appropriate
- Added new api to redhawk to get the OS module list (Used in crash dump generation)
- Added new api to get the OS module of of a pointer. These are not yet enabled for TypeManager based scenarios, but that will be done in a followon change. Eventually these will exclusively be use for instruction pointers, and will tie into diagnostic scenarios around stack traces, etc. Currently, it is also used in a few reflection scenarios. Those code patterns will be removed soon.
- Similarly distinguished between getting the OS module for an EEType, and getting the module for an EEType. This is used in error message scenarios.
- Update RhFindBlob to work with both types of module pointers
[tfs-changeset: 1647831]
|
|
Fixed issues and concerns from mirroring to Github
[tfs-changeset: 1647030]
|
|
[tfs-changeset: 1646943]
|
|
[tfs-changeset: 1645382]
|
|
[tfs-changeset: 1636196]
|
|
|
|
1) Removing the ThunkPool APIs from the System.Private.Corelib layer and moving it to mrt100_app.dll. Reasons:
a) A more correct layering
b) Thunks are also used by mrt100_app, and today it has to call into the S.P.Corelib layer to get thunks
c) The binder (which today takes care of laying out the thunks section) is going away with the ProjectX work, so the refactoring is needed
2) Addition of a new API: CreateThunksHeap. Thunks are allocated and deallocated from heaps, and each caller can create and managed their own heaps (TODO: heap deallocation feature)
Note: The use of a simple heap removes the need for a the hashtable that we previously had in the old implementation, and simplifies the implementation a bit.
4) Optimization (use of simple thunks linked list with better perf characteristics)
5) Added ThunkPool APIs into the internal RuntimeAugments assembly, to enable writing of tests that directly target the thunks APIs
6) Tests for the feature (including a multithreaded test).
Tested on all 3 architectures.
[tfs-changeset: 1634032]
|
|
resolution from a metadata token
- Instead of an interface/slot pair
- Cell information is now consolidated into a structure instead of being passed around as a tuple of interface/slot
- Encoding is more complex to avoid bloating the data format
- In addition to interface dispatch, the logic is also able to perform vtable dispatch
- Add support for the concept of dynamic modules
- A dynamic module provides a set of callbacks that are special around the behavior of interface dispatch
- ModuleList associates a DynamicModule with normal module. At some point we will consolidate the DynamicModule with the ModuleManager
Miscellaneous changes
- New variant of LockFreeReaderHashtable to be used with native pointers.
- Support for a cloned type to be cloned based on a direct pointer instead of an indirection
[tfs-changeset: 1630711]
|
|
- Port EnsureSufficientExecutionStack to Unix by switching it to the same implementation as what we use for CoreCLR. It is piggy backing on stackbounds that the runtime keeps track of.
- Add TryEnsureSufficientExecutionStack since it was added as public method for CoreCLR (see https://github.com/dotnet/coreclr/pull/7077/)
[tfs-changeset: 1626388]
|
|
and the runtime.
Overview - here's what generic instance descs were used for and how this functionality is provided now:
- They were needed to support generic unification. For the release scenario, this is no longer necessary because global analysis places generics.
For the F5 scenario, we will again have generic unification, but it will be done differently and is not in this code review yet.
- They were used for GC reporting of statics on generic types. Statics on statically built generic types are now merged into the static GC desc
of their containing module. Statics on dynamic types are reported via two new lists on the RuntimeInstance class, one for regular GC statics,
the other one for thread statics.
- They were also used to hold statics information for dynamically loaded types. This information is now attached to the EEType instead.
- Similarly, generic instance descs held information about the open generic type, the instantiation parameter, and the parameter variance information.
This information is now also attached to the EEType.
Detail notes:
- EEType.Constants.cs, EEType.cs, eetype.h, eetype.inl: Provide for attaching generic and static information to eetypes. The latter is only used for dynamic types.
- MiscHelpers.cpp, module.cpp, module.h, RuntimeInstance.cpp/.h: Remove GenericInstanceDesc logic, provide equivalent functionality.
- rhbinder.h, ZapHeaders.cpp: Bump version number, remove GenericInstanceDesc related fields from module header.
- EETypeCreator.cs: logic to set rareFlags appropriately for attached statics.
- TypeLoaderEnvironment.StaticsLookup.cs: the logic turned out to be wrong for the TLS index - the binder encoded always zero for the index, which cannot work
at runtime. So I changed the binder (see comment below), and I also changed the runtime logic to apply an indirection. For consistency, I did the same
for the thread static offset - this isn't necessary now but may become necessary for the F5 scenario.
- common.h: Add separateCompilation flag to g_BindOptions as prep work for F5 scenario.
- CompactLayoutReader.cpp: for release scenario, merge generic statics and their GC descs early rather than relying on generic instance descs.
- MethodTable.h, MakePdb.cpp, MdilModule.cpp/.h: attach "InstantiatedTypeZapNodes" data structure to method table rather than finding it via
a hash table lookup. This is just a cleanup change.
- MdilModule.cpp/.h: Remove generic instance desc logic, add logic to generate the "GenericComposition" data structure instead, attach that and
the generic definition to eetypes, add a rare flag for eetypes with sealed virtuals, add indirection cells where we used to indirect through generic
instance descs, remove unused "GetReadonlyBlobNode" method, change encoding of native layout info for thread statics (see comments above
for TypeLoaderEnvironment.StaticsLookup.cs).
- ZapImage.cpp/.h: remove generic instance desc sections.
- various copies of rhbind.exe and rhbindui.dll: these are used to build mrt100_app.dll. The change updates rhbind.exe to put the new version number
into the module header of mrt100_app.dll.
[tfs-changeset: 1622930]
|
|
This is to fix bug 241854, where interop generated a spin loop around a call to RhYield and, via a few levels of inlining, the compiler emitted a tight loop around a call to RhYield without loop hijacking in the loop codegen. This is because the compiler assumes all “normal” calls (such as this one) will allow hijacking. Unfortunately, this isn’t the case for this method, which is a RuntimeImport from System.Private.CoreLib to some runtime unmanaged code, which is not hijackable. The fix, in this case, is to pinvoke to RhYield instead of using RuntimeImport.
[tfs-changeset: 1619386]
|
|
- Expand Debug.DebugBreak as IL intrinsic
- Implement RhDebugBreak JIT helper for IL break instruction
- Switch assembly code to use RhDebugBreak to avoid C++ name mangling goo
- Change PalDebugBreak to be inline to avoid extra frames under debugger
- Cleanup some left-over cruft in Unix PAL
|
|
EEType is now a binary contract with a shared EEType.cs reader implementation.
The various EEType probing runtime exports have been superseded by the common EEType.cs -> remove the usage of the exports and delete them.
I will do RhGetCorElementType and RhGetEETypeClassification in a separate changeset because those introduce enum types that have widespread usage and should be deleted in favor of the common ones. This change is big enough as is.
Testing: standard precheckin + NUTC 1k test suite (to test pntestcl)
[tfs-changeset: 1615277]
|
|
[tfs-changeset: 1609436]
|
|
[tfs-changeset: 1608916]
|
|
- Reduce amount of assembly code in PInvoke helpers by moving all slow paths to C++
- Share code between the slow paths of assembly and portable helpers
- Improve performance of the portable helpers by making the access to current thread and the trap thread statics inlineable (e.g. the portable RhpReversePInvoke2 helper has only two extra instructions compared to what the hand-optimized assembly helper would have)
[tfs-changeset: 1605153]
|
|
This checkin is an adaptation of a cache used in the type loader. It is applied to our type casting APIs and brings a significant performance improvement to any type-cast-heavy workload.
The cache has an initial tuning that looks reasonable, but should still be considered provisional as we gather more data on its behavior across various workloads.
[tfs-changeset: 1600411]
|
|
- Replace asm wrappers for GC helpers with regular PInvoke for better portability. There is an extra GC mode switch now but it should not matter because of these helpers are either expensive or rarely used.
- Remove asm code for RhpBulkWriteBarrier by switching to C++ implementation unconditionally (remove CORERT ifdef)
- Move error handling for RhHandleAlloc* to System.Private.CoreLib (remove CORERT ifdef)
- Add missing error handling for RhReRegisterForFinalize
- A few other minor fixes and cleanup
[tfs-changeset: 1596653]
|
|
Recently while experimenting with interop performance micro-benchmarks, I observed that Reverse PInvoke code path in ProjectN is 8-10x slower
than Desktop CLR. Morgan also noticed the slow down and extra memory allocation on this code path while doing the Unity app investigation.
This change aims to improve this code path to achieve parity with Desktop CLR.
This change improve Reverse PInvoke performance by:
1. Remove the dictionary in McgModuleManager which maps between thunk address and delegate. Instead store a weak GCHandle of the delegate in the thunk data section.
2. Optimize open static delegate by storing the static function pointer directly in the thunk data. And later on reverse pinvoke code path directly do a CallI on the function pointer. Modified MCG to generate special function to handle open static delegates.
3. While storing the function pointer, store jump stub code target address. Added a runtime helper to get the jump stub target.
4. Reorder some instructions in RhpReversePInvoke and InteropNative_CommonStub functions so that the hot path get better instruction cache use.
Results:
X86
33% slower than Desktop CLR (75 vs 92 instruction)
5.5x faster than latest ProjectN
AMD64
9% faster than Desktop CLR (54 vs 67 instructions)
7.5x faster than latest ProjectN
[tfs-changeset: 1596255]
|
|
Merge nmirror to master
|
|
Fixing TODOs about collisions with the system assert.h header
[tfs-changeset: 1589045]
|
|
* Add code to generate a metadata blob containing type definition
metadata for all types that had an EEType generated in the current
compilation.
* Hook up Reflection.Execution by rooting the static constructor on
ReflectionExecution (this constructor is eager - just rooting it makes
it run).
* Add mock implementation of RhFindBlob that lets us find blob 13 -
metadata blob
This should be enough to support `Type.GetType("SomeType,
SomeAssembly")`. It's not enough to support things like
`foo.GetType().GetTypeInfo().FullName` - we need mapping table
generation for that.
|
|
- Change module header to use ReadyToRunHeader structure
- Rename ModuleHeaderSection ReadyToRunSectionType
- Rename ModuleHeaderNode to ModulesSectionNode
- Rename ModuleIndirectionCell to ModuleManagerIndirectionNode
- Move modulesSection from runtime to bootstrap native code
|
|
|
|
Add a new command-line switch to ILC: /multifile. When specified, only
the assemblies passed as input will have methods compiled. Referenced
types / methods from other assemblies are not compiled into the output
object file. This switch is most likely temporary as we hone our
compilation story and implementation.
Each managed module adds pointers to the start and end of a module
global data header to a custom section of the object file, .modules$I.
These entries are merged (on Windows, OSX / Linux needs a tweak to CLI
first) at link time producing a list of module headers.
In StartupCodeHelpers.cs, initialize global tables from each module
using the list of pointers that was written to .modules$I. This data is
discovered through two exports (__modules_a and __modules_z) which
through linker section merging, are placed either side of the module
header pointers in the final binary.
Alter interface dispatch to store its dispatch map table as an
ArrayOfEmbeddedDataNode and place it in the module header list. This
allows each module's EETypes to continue using index-based lookup of
dispatch maps.
Add a new field to EETypes which points at a ModuleManager* through an
indirection cell. This indirection cell is filled in at runtime
initialization and allows a type to find its dispatch map table.
ModuleHeaderSection.cs|h files define the section headers currently
supported. ModuleHeaderSection's enumerands are in line with the plan for
ReadyToRun.
Moved the module info lookup out of the bootstrapping code and into the
runtime
Place compilation module group logic to a dedicated set of classes,
CompilationModuleGroup, MultiFileCompilationModuleGroup, and
SingleFileCompilationModuleGroup which together abstract the logic for
decisions about which types / methods should be included in compilation
in single vs multi file.
Extract an interface from Compilation for the methods that root methods
/ types / Main so CompilationModuleGroup can root things without having
to know about the Compilation class.
|
|
The loop hijack worker routine is not honoring the contract that it should be. Namely, the runtime is not allowed to trash any registers in our worker (except r12 on ARM). The two big oversights were scratch FP registers and the flags registers.
I have also added a per-module map from loop index to target address (thus requiring all the shash.h includes). This primarily helps gcstress throughput because the loop indirection cell address calculation ends up being surprisingly lengthy. I considered the other obvious approach of "back-patching" the loop indirection cell in the gcstress case (normal loop hijacking does this, but under gcstress, we do not). However, I ended up preferring this because it could help GC suspension latency in normal operation.
[tfs-changeset: 1573401]
|
|
We have been keeping obsoleted code in the runtime for compatibility with older versions. The runtime version just got bumped up - it allows us to delete the obsolete code before the next compatibility band starts.
[tfs-changeset: 1572810]
|
|
|
|
- Move force-inline GC-safe memory helpers to .inl files to fix link errors for some build flavors.
- Fix a bug in RhUnbox - it was not using GC-safe zero memory.
|
|
[tfs-changeset: 1558883]
|
