| Age | Commit message (Collapse) | Author |
|---|
|
algorithm. When infinite recursions are detected, we consider that two types are not assignable (same behavior as Desktop/CoreCLR), and throw the exception.
[tfs-changeset: 1708703]
|
|
I'm looking at size regressions between .NET Native 1.7 and the current mainline branch. A thing that stood out is universally bigger EETypes. A contributor to this was getting rid of GenericInstanceDescs between 1.7 and 2.0 and replacing them by direct references to generic composition details from the EEType. Size-wise, this was mostly a wash, but we can actually do better - these new fields are not critical to be pointer-sized.
This change turns them into relative pointers. This saves 33 kB on a hello world app. I expect around 100 kB savings on the UWP People app based on my back-of-the-envelope calculation.
Project N baggage:
1. Update pntestcl build configuration to compile it with a C# compiler that is not 8 years old
2. Disable metadata validation transform on class libraries. This is hitting what appears to be a CCI metadata validator bug (Validator.cs:796) where it thinks a modified type should have the same interned key as the unmodified version of it. The act of resolving a modified type strips off the modifier. This ticks off the validator.
3. Fix a Reducer bug where it wasn't marking non-interface constraints as necessary. The C# unmanaged constraint is expressed as [modreq UnmanagedType] ValueType. We were not marking UnmanagedType as necessary.
4. Update checked in binder because this is a file format change
[tfs-changeset: 1708263]
|
|
|
|
|
|
AppDomains.
[tfs-changeset: 1687664]
|
|
faster on all platforms.
[tfs-changeset: 1687628]
|
|
longer a nested type in EH.
[tfs-changeset: 1687171]
|
|
Fixes #1194
|
|
|
|
|
|
|
|
[tfs-changeset: 1683373]
|
|
|
|
This is a very mild reliability and perf boost.
The issue described in https://github.com/dotnet/roslyn/issues/4388 has been fixed and we no longer need to check every typed handler and compare it to MRT's System.Object EEType when looking for a handler.
[tfs-changeset: 1683270]
|
|
* Fix issues building the runtime, corelib and type loader for WebAssembly
* Fix test infrastructure to allow running with the wasm flavor
|
|
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]
|
|
- thunk addresses can be wider than type Int,
but valid in C pointers terms.
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
|
|
Port of https://github.com/dotnet/coreclr/pull/14228
[tfs-changeset: 1677267]
|
|
|
|
This adds a unit test for `ILCompiler.Compiler` so that we can no longer
use this as an excuse not to write unit tests for this assembly.
The first test is a generalized framework to write tests for dependency
graph. The test runs ILScanner on a method from the test assembly, and
validates various invariants that the method declares. This will let us
e.g. write targeted unit tests that check that the various size on disk
features within the compiler do the right thing (e.g. make sure we don't
unnecessarily expand variant interfaces, GVMs, etc.).
|
|
|
|
|
|
|
|
FirstChanceException. We're supposed to pass in an AppDomain as sender, but completing that will require a CoreFX change to pass in an AppDomain we can use.
[tfs-changeset: 1666024]
|
|
|
|
ExceptionIDs represents contract between runtime and CoreLib. It does not make sense to have ExceptionIDs.ThreadAbort in it since it is never used in this contract. It was just used as a convenient internal implementation detail that can be done differently.
|
|
[tfs-changeset: 1664997]
|
|
- Primary improvement is to the performance of failed interface casting (the is case where null is returned).
- Change checking ICastable flag from needing access to the RareFlags to being examinable directly from EEType
- Remove unused existing RuntimeAllocated flag and move ICastable flag to be directly on EEType
- Secondary improvement
- Micro-optimize use of assignability cache by removing an if statement from the assignability cache lookup function and force inline it into its caller. Removal of the extra function prolog/epilog/removal of the if statement is worth about 300ms.
- This will improve performance of all interface cast checks by a small but measurable amount.
[tfs-changeset: 1664305]
|
|
IsByRefLikeAttribute is the shipping version of the StackOnlyAttribute
[tfs-changeset: 1664170]
|
|
- Pick up latest .NET Core 2.0 CLI and buildtools
- Remove all project.json references and convert everything to msbuild projects
- Stick to vanilla .NET CLI project shape as much as possible. Minimize dependencies on buildtools special behaviors
|
|
Changes include:
1. Introduces a razzle environment variable _pureNative to dictate the pure native compilation of MRT
2. Additional source code in MRT code base to support the managed startup code
3. Tweak in the native startup code to not include classlibFunctions
4, Build script changes to the managed and native part of MRT100_app and MRT150
[tfs-changeset: 1662741]
|
|
VS is trying to "upgrate" the full framework projects without ToolsVersion
[tfs-changeset: 1662259]
|
|
The latest project templates do not have it, and it is only good for generating warnings like the following in the detailed build log:
Project file contains ToolsVersion="4.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="14.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
[tfs-changeset: 1662024]
|
|
CR: JKotas, FadiM, DavidWr
At some moment the CallConverterThunk code took dependency on the blittable check missing in GCHandle.set_Target (change 1566458), so we had to place that check under "#if CORERT" (https://github.com/dotnet/corert/pull/1393). This change enables the check and introduces the UnsafeGCHandle structure to use in the CallConverterThunk code.
UnsafeGCHandle is a faster version of the GCHandle structure with the following differences:
* The constructor assumes the handle type is valid; no range check is performed.
* The pinned flag is not stored in the _handle field.
* The Target getter and setter assume the UnsafeGCHandle has been allocated.
* No blittable check is performed when allocating a pinned UnsafeGCHandle or setting its target.
* The GetRawTargetAddress method returns the raw address of the target (the pointer to its m_pEEType field).
* The Free method is not thread-safe and does not throw if the UnsafeGCHandle has not been allocated or has been already freed.
Also avoid the native runtime call in release builds in the RuntimeImports.RhHandleGet method and Runtime.Base's version of the UnsafeGCHandle.get_Target method (in debug builds the runtime performs additional checks).
[tfs-changeset: 1661633]
|
|
Building against the lightweight version of S.P.CoreLib has bitrotted
over the past year. The classlib is handy for codegen and architecture
bringups and we might want to use it when getting rid of ready to run
helpers.
|
|
* Add PreInitFieldInfo that extracts preinitialized data information from fields that have [PreInitialized] and [InitDataBlob] pointing to RVA field
* Added FrozenArrayNode for frozen arrays with data extracted from preinit RVA data field
* Added GCStaticsPreInitDataNode (CoreRT only) to hold GC pointers for GC static fields. Pre-init data fields points to frozen data, while other data initialized to null.
* Changed GCStaticsNode to emit a pointer reloc to GCStaticspreInitDataNode and mask 0x2 for the GC static EEType.
* Changed InitializedStatics in StartupCodeHelper to check for 0x2 and memcpy the GC field data as needed
* Fixed a bug in bad GCStaticsEETypeNode size calculation - it's off-by-1 as static GC static field layout in CoreRT includes EEType already.
|
|
- Instead of performing lazy lookups at individual use sites, perform a single lazy lookup to get a dictionary, and then use normal canonical lookups from there
- Shares logic with USG dictionary acquisition, and with normal canonical codegen
- Add LazyGenericPolicy nob to CoreRT environment to control policy
Universal Shared Generics Changes
- Fixup EETypeNode generation for USG types
- Consider TemplateTypeLayout necessary for all universal generic canon types
- Use RhAllocLocal2 which returns a byref to the first field of the "local" object instead of the start of the object.
- Tweak USG field invoke map generation to not stop compilation. Still needs to be implemented.
[tfs-changeset: 1658670]
|
|
Three parts:
1. Update casting logic to allow casting SzArray to rank 1 MdArray (but
not the other way around)
2. Update MdArray rank 1 methods to be able to operate on SzArrays
3. Update array creation path to emulate the behavior where allocating
rank 1 MdArray with 0 lower bounds actually gives you an SzArray
Third bullet point makes this the most annoying, because we can't
reliably support `newobj instance void int32[0...]::.ctor(int32)`
without hitting the type loader. I was also considering adding an
optional field on Rank 1 MdArrays that lets you get to the SzArray's
EEType from it. It might be better.
Fixes #3331.
|
|
Merge nmirror to master
|
|
- Make it work for all TypeManagerHandle based environments
- Including non INPLACE_RUNTIME based cases
- Uses classlib functions architecture
[tfs-changeset: 1657913]
|
|
Merge nmirror to master
|
|
Some of the unused code was likely not getting optimized away.
|
|
Remove RelocatedTypeAttribute that is no longer necessary
[tfs-changeset: 1657461]
|
|
The way we were setting common defines (such as `AMD64`, `BIT64`, `ARM`)
was extremely fragile and invited partial fixes such as #3414 and #3424.
This really needs to be centralized.
|
|
Today our ProjectN images are not CFG-enabled, but CFG will kick in for applications that have CFG enabled, in particular, WWAHost (for JavaScript apps). Today with those apps and dynamic interop enabled we would trigger a CFG check as those thunks are never registered under CFG.
There are a couple of ways to achieve this. 1) You could take advantage of the CFG table which OS loader understands and would remap in MapViewOfFile. In order to make those thunks show up in CFG, you need to give them symbolic names. According to my testing, it only seem to work if we map the full mrt100_app.dll, which isn't ideal. 2) Use SetProcessValidCallTargets and supply the thunks. I went with SetProcessValidCallTargets, which works, but has its own set of challenges (if we discover that OS matrix we need to support with CFG becomes unsustainable with this approach we can revisit):
1. Our ARM test environment is on 8.1, while SetProcessValidCallTargets is Win10+.
Normally you would fix this by either 1) LoadLibrary/GetProcAddress or 2) delay loading. Unfortunately none of these work today because LoadLibrary is not part of WACK (and has a non-trivial cost to support) and 2) SetProcessValidCallTargets is on kernel32 and not delay loadable.
Fortunately there is a API set available load api-ms-win-core-memory-l1-1-3.dll which will has this API. It is effectively forwarded to kernelbase.dll but for the purpose of delay loading it works perfectly. When the API is not found, we would redirect the API to a predefined failure stub that simply returns true.
It is worth noting that if we opt to use LoadLibrary/GetProcAddress (which you can't do under UWP), calling SetProcessValidCallTarget would trigger CFG check as it is declared __declspec(guard(nocf)) for security reasons. Fortunately delay loading works fine.
2. Calling SetProcessValidCallTargets would fail on non-CFG-enabled processes. This can be fixed by calling GetProcessMitigationPolicy to determine whether the process is CFG-enabled.
3. SetProcessValidCallTargets require our thunks to be 0x10 aligned. x64/ARM is already 0x10 aligned but x86 is only aligned on 0x4. This means we'll need to waste 0xc for each thunk on x86. This a bit unfortunate but I doubt anyone would care. If this ends up wasting too much space we can revisit and optimize as needed.
4. SetProcessValidCallTargets is not allowed in WACK today. Fortunately it is already on pre-approved WACK list for RS2. It does mean that you won't be able to submit apps with mrt100_app.dll today but that's probably fine - our plan for the new toolchain is RS3+.
5. Our toolsets in razzle enlistment only has 8.1 the latest. For now I've work arounded by manually declaring the imports and copy the latest mincore.lib to rh/public/minwin folder. This has a unfortunate side effect that it also 'upgrades' RaiseFailFastException to a new API set that is not available down-level 8.1. I've made RaiseFailFastException also delay loading so that we wouldn't immediately fail to load under ARM + Win 8.1. I doubt any one cares about how N failfast under 8.1.
6. Similarly, ToF also has a copy of Win8 toolset in its own ExternalAPI (not the razzle one) and it doesn't support creating a CFG-aware binary. One possiblity is to use JavaScript app like in the bug, but you also need a reliable way to construct thunks and send it over to javaScript as v-table so that JavaScript can call it. This is basically dyanmic interop feature so the best way to cover this today without CFG-aware toolset is in dyanmic interop testing with full dyanmic interop mode on (everything dynamic). Once we have a CFG-aware toolset (I suspect this would only happen when we move out of ToF), we can have the main C++ app call reverse p/invoke thunks.
I've introduced a new API PalMarkThunksAsValidCallTargets to do the heavylifting - to allocate the correct data structure ro register the thunks and call SetProcessValidCallTargets. Rest of the stuff are less interesting.
After this change, I've verified the Yahoo app with dynamic interop turned on can proceed further (but still eventually timed out). I've also done a few more testing:
* ARM 8.1 private interop run,
* x86 private interop run,
* thunkpool tests
* x86chk precheckin
* verified ARM phone does have SetProcessValidCallTargets API.
* Build and ran all CoreRT tests
[tfs-changeset: 1655595]
|
|
Merge nmirror to master
|
|
The one in `RhNewArray` would have saved me around 45 minutes of
investigation so I think this is worth it.
|
|
Delegates
|
|
value comparison.
[tfs-changeset: 1654211]
|
