[WIP] Fast codegen-free generic object instantiation + improve Activator.CreateInstance perf

.config/dotnet-tools.json

@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.20559.2",
+      "version": "1.0.0-prerelease.20575.2",
       "commands": [
         "xharness"
       ]

Directory.Build.props

@@ -57,7 +57,7 @@
     <WasmAppBuilderDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'WasmAppBuilder', 'Debug', '$(NetCoreAppCurrent)', 'publish'))</WasmAppBuilderDir>
     <WasmBuildTasksDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'WasmBuildTasks', 'Debug', '$(NetCoreAppCurrent)', 'publish'))</WasmBuildTasksDir>
     <MonoAOTCompilerDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'MonoAOTCompiler', 'Debug', '$(NetCoreAppCurrent)'))</MonoAOTCompilerDir>
-  
+
     <AppleAppBuilderTasksAssemblyPath>$([MSBuild]::NormalizePath('$(AppleAppBuilderDir)', 'AppleAppBuilder.dll'))</AppleAppBuilderTasksAssemblyPath>
     <AndroidAppBuilderTasksAssemblyPath>$([MSBuild]::NormalizePath('$(AndroidAppBuilderDir)', 'AndroidAppBuilder.dll'))</AndroidAppBuilderTasksAssemblyPath>
     <WasmAppBuilderTasksAssemblyPath>$([MSBuild]::NormalizePath('$(WasmAppBuilderDir)', 'WasmAppBuilder.dll'))</WasmAppBuilderTasksAssemblyPath>
@@ -105,8 +105,6 @@
   </PropertyGroup>
 
   <PropertyGroup>
-    <!-- Default to portable build if not explicitly set -->
-    <PortableBuild Condition="'$(PortableBuild)' == ''">true</PortableBuild>
     <!-- Default to discarding symbols if not explicitly set -->
     <KeepNativeSymbols Condition="'$(KeepNativeSymbols)' == ''">false</KeepNativeSymbols>
     <!-- Used for launchSettings.json and runtime config files. -->

docs/coding-guidelines/api-guidelines/nullability.md

@@ -1,20 +1,20 @@
 # Nullability annotations
 
-C# 8 provides an opt-in feature that allows for the compiler to  track reference type nullability in order to catch potential null dereferences.  We are adopting that feature across .NET's libraries, working up from the bottom of the stack.  We're doing this for three primary reasons, in order of importance:
+As of C# 8 and improved in C# 9, the C# language provides an opt-in feature that allows the compiler to track reference type nullability in order to catch potential null dereferences.  We have adopted that feature set across .NET's libraries, working up from the bottom of the stack.  We've done this (and continue to do so for all new library development) for three primary reasons, in order of importance:
 
-- **To annotate the .NET surface area with appropriate nullability annotations.**  While this could be done solely in the reference assemblies, we're doing it first in the implementation to help validate the selected annotations.
-- **To help validate the nullability feature itself.**  With millions of lines of C# code, we have a very large and robust codebase with which to try out the feature and find areas in which it shines and areas in which we can improve it.  The work to annotate System.Private.CoreLib in .NET Core 3.0 helped to improve the feature as shipped in C# 8, and annotating the rest of the libraries will continue to be helpful in this regard.
-- **To find null-related bugs in .NET Runtime itself.** We expect to find relatively few meaningful bugs, due to how relatively well-tested the codebases are and how long they've been around.
+- **To annotate the .NET surface area with appropriate nullability annotations.**  While this could be done solely in the reference assemblies, we do it in the implementation to help validate the selected annotations.
+- **To help validate the nullability feature itself.**  With millions of lines of C# code, we have a very large and robust codebase with which to try out features and find areas in which it shines and areas in which we can improve it.  The work to annotate System.Private.CoreLib in .NET Core 3.0 helped to improve the feature as shipped in C# 8, and the rest of the core libraries being annotated in .NET 5 helped to further flesh out the design for C# 9.
+- **To find null-related bugs in .NET Runtime itself.** We have found few meaningful bugs, due to how relatively well-tested the codebases are and how long they've been around.  However, for new code, the annotations do help to highlight places where null values may be erroneously dereferenced, helping to avoid NullReferenceExceptions in places testing may not yet be adequate.
 
 ## Breaking Change Guidance
 
-We are striving to get annotations correct the "first time" and are doing due-diligence in an attempt to do so.  However, we acknowledge that we are likely to need to augment and change some annotations in the future:
+We strive to get annotations correct the "first time" and do due-diligence in an attempt to do so.  However, we acknowledge that we are likely to need to augment and change some annotations in the future:
 
 - **Mistakes.** Given the sheer number of APIs being reviewed and annotated, we are likely to make some errors, and we'd like to be able to fix them so that long-term customers get the greatest benefit.
-- **Breadth.** Annotation takes time, so annotations will roll out over time rather than being released all at once.
+- **Breadth.** Annotation takes time, so annotations have rolled out and will continue to roll out over time rather than all at once for the whole stack.
 - **Feedback.** We may need to revisit some "gray area" decisions as to whether a parameter or return type should be nullable or non-nullable (more details later).
 
-Any such additions or changes to annotations can impact the warnings consuming code receives if that code has opted in to nullability analysis and warnings. Even so, for at least the foreseeable future we may still do so.  We will be very thoughtful about when and how we do.
+Any such additions or changes to annotations can impact the warnings consuming code receives if that code has opted-in to nullability analysis and warnings. Even so, for at least the foreseeable future we may still do so, and we will be very thoughtful about when and how we do.
 
 ## Annotation Guidance
 
@@ -23,7 +23,7 @@ Nullability annotations are considered to represent intent: they represent the n
 - **DO** annotate all new APIs with the desired contract.
 - **CONSIDER** changing that contract if overwhelming use suggests a different de facto contract. This is particularly relevant to virtual/abstract/interface methods defined in a library where all implementations may not be under your control, and derived implementations may not have adhered to the original intent.
 - **DO** respect documented behaviors.  Nullability annotations are about codifying a contract, and documentation is a description of that contract.  If, for example, a base abstract or virtual method says that it may throw an exception if `null` is passed in, that dictates that the argument should be non-nullable.
-- **DO** continue to validate all arguments as you would have prior to nullability warnings.  In particular, if you would have checked an argument for `null` and thrown an `ArgumentNullException` if it was `null`, continue to do so, even if the parameter is defined as non-nullable.  Many consumers will not have nullability checked enabled, either because they're using a language other than C#, they're using an older version of C#, they simply haven't opted-in to nullability analysis, or the compiler isn't able to detect the misuse.
+- **DO** continue to validate all arguments as you would have prior to nullability warnings.  In particular, if you would have checked an argument for `null` and thrown an `ArgumentNullException` if it was `null`, continue to do so, even if the parameter is defined as non-nullable.  Many consumers will not have nullability checked enabled, either because they're using a language other than C#, they're using an older version of C#, they simply haven't opted-in to nullability analysis, they've explicitly suppressed warnings, or the compiler isn't able to detect the misuse.
 - **DO NOT** remove existing argument validation when annotating existing public/protected APIs.  If through the course of annotating it becomes clear that internal/private surface area is unnecessarily checking for nulls when nulls aren't possible (i.e. you found dead code), such use can be removed or replaced by asserts.
 - **AVOID** making any changes while annotating that substantively impact the generated IL for an implementation (e.g. `some.Method()` to `some?.Method()`).  Any such changes should be thoroughly analyzed and reviewed as a bug fix.  In some cases, such changes may be warranted, but they're a red flag that should be scrutinized heavily.
 

docs/design/coreclr/jit/lsra-detail.md

@@ -387,7 +387,7 @@ well as supporting components) in more depth.
 -   `LinearScan::identifyCandidates`
 
     -   This mostly duplicates what is done in
-        `Compiler::lvaMarkLocalVars(). There are differences in what
+        `Compiler::lvaMarkLocalVars()`. There are differences in what
         constitutes a register candidate vs. what is tracked, but we
         should probably handle them in `Compiler::lvaMarkLocalVars()`
         when it is called after `Lowering`.
@@ -445,7 +445,7 @@ node, which builds `RefPositions` according to the liveness model described abov
 
 -   First, we create `RefPosition`s to define any internal registers that are required.
     As we create new `Interval`s for these, we add the definition `RefPosition` to an array,
-    `InternalDefs`. This allows us to create the corresponding uses of these internal
+    `internalDefs`. This allows us to create the corresponding uses of these internal
     registers later.
 
 -   Then we create `RefPosition`s for each use in the instruction.
@@ -474,7 +474,7 @@ node, which builds `RefPositions` according to the liveness model described abov
          we need to ensure that the other source isn't given the same register as the
          target. For this, we annotate the use `RefPosition` with `delayRegFree`.
 
--   Next we create the uses of the internal registers, using the `InternalDefs` array.
+-   Next we create the uses of the internal registers, using the `internalDefs` array.
     This is cleared before the next instruction is handled.
 
 -   Next, any registers in the kill set for the instruction are killed. This is performed
@@ -652,7 +652,7 @@ LinearScanAllocation(List<RefPosition> refPositions)
         -   When `COMPlus_EnableEHWriteThru == 0`, any variable that's
             live in to an exception region is always referenced on the stack.
 
-        -   See [Enable EHWriteThru by default](#enable-EHWriteThru-by-default).
+        -   See [Enable EHWriteThru by default](#enable-ehwritethru-by-default).
 
 -   Code generation (genGenerateCode)
 

docs/workflow/requirements/linux-requirements.md

@@ -50,7 +50,7 @@ Install the following packages for the toolchain:
 - libkrb5-dev
 - libnuma-dev (optional, enables numa support)
 - zlib1g-dev
-- ninja (optional, enables building native code with ninja instead of make)
+- ninja-build (optional, enables building native code with ninja instead of make)
 
 The following dependencies are needed if Mono Runtime is enabled (default behavior):
 
@@ -62,7 +62,7 @@ The following dependencies are needed if Mono Runtime is enabled (default behavi
 sudo apt-get install -y cmake llvm-9 clang-9 autoconf automake \
 libtool build-essential python curl git lldb-6.0 liblldb-6.0-dev \
 libunwind8 libunwind8-dev gettext libicu-dev liblttng-ust-dev \
-libssl-dev libnuma-dev libkrb5-dev zlib1g-dev ninja
+libssl-dev libnuma-dev libkrb5-dev zlib1g-dev ninja-build
 ```
 
 You now have all the required components.

docs/workflow/testing/mono/testing.md

@@ -1,54 +1,108 @@
-# Running Tests using Mono Runtime
+# Running test suites using Mono
 
-## Running Runtime Tests
-We currently only support running tests against coreclr.  There are additional mono runtime tests in mono/mono, but they
-have not been moved over yet. Simply run the following command:
+Before running tests, [build Mono](../../building/mono/README.md) using the desired configuration.
 
+## Runtime Tests
+### Desktop Mono:
+
+To build the runtime tests for Mono JIT or interpreter, execute the following command from `$(REPO_ROOT)/src/tests`
+```
+./build.sh excludemonofailures <release|debug>
+```
+
+Run individual test:
+```
+cd ../mono/netcore
+make run-tests-coreclr CoreClrTest="bash ../../artifacts/tests/coreclr/OSX.x64.Release/JIT/opt/InstructionCombining/DivToMul/DivToMul.sh"
+```
+
+Run all tests:
+```
+cd ../mono/netcore
+make run-tests-coreclr-all
+```
+
+### WebAssembly:
+Build the runtime tests for WebAssembly
+```
+$(REPO_ROOT)/src/tests/build.sh -skipstressdependencies -excludemonofailures os Browser wasm <Release/Debug>
+```
+
+The last few lines of the build log should contain something like this:
 ```
-dotnet build /t:RunCoreClrTests $(REPO_ROOT)/src/mono/mono.proj
+--------------------------------------------------
+ Example run.sh command
+
+ src/tests/run.sh --coreOverlayDir=<repo_root>artifacts/tests/coreclr/Browser.wasm.Release/Tests/Core_Root --testNativeBinDir=<repo_root>/artifacts/obj/coreclr/Browser.wasm.Release/tests --testRootDir=<repo_root>/artifacts/tests/coreclr/Browser.wasm.Release --copyNativeTestBin Release
+--------------------------------------------------
 ```
 
-If you want to run individual tests, execute this command:
+To run all tests, execute that command, adding `wasm` to the end.
 
+### Android:
+Build the runtime tests for Android x64
+```
+$(REPO_ROOT)/src/tests/build.sh -skipstressdependencies -excludemonofailures os Android x64 <Release/Debug>
 ```
-dotnet build /t:RunCoreClrTest /p:CoreClrTest="<TestName>" $(REPO_ROOT)/src/mono/mono.proj
+
+The last few lines of the build log should contain something like this:
 ```
+--------------------------------------------------
+ Example run.sh command
 
-## Running Library Tests
-Running library tests against Mono is straightforward regardless of configuration.  Simply run the following commands:
+ src/tests/run.sh --coreOverlayDir=<repo_root>artifacts/tests/coreclr/Android.x64.Release/Tests/Core_Root --testNativeBinDir=<repo_root>/artifacts/obj/coreclr/Android.x64.Release/tests --testRootDir=<repo_root>/artifacts/tests/coreclr/Android.x64.Release --copyNativeTestBin Release
+--------------------------------------------------
+```
+To run all tests, execute that command, adding `Android` at the end.
 
-1. Build and set the RuntimeFlavor
+### Additional Documents
+For more details about internals of the runtime tests, please refer to the [CoreCLR testing documents](../coreclr)
 
-```bash
-./build.sh /p:RuntimeFlavor=mono
+## Libraries tests
+### Desktop Mono
+Build and run library tests against Mono JIT or interpreter
+```
+$(REPO_ROOT)/dotnet.sh build /t:Test /p:RuntimeFlavor=mono /p:Configuration=<Release/Debug> $(REPO_ROOT)/src/libraries/<library>/tests
 ```
-or on Windows
-```bat
-build.cmd /p:RuntimeFlavor=mono
+Alternatively, you could execute the following command from `$(REPO_ROOT)/src/mono/netcore`
 ```
+make run-tests-corefx-<library>
+```
+For example, the following command is for running System.Runtime tests:
+```
+make run-tests-corefx-System.Runtime
+```
+### Mobile targets and WebAssembly
+Build and run library tests against Webassembly, Android or iOS. See instructions located in [Library testing document folder](../libraries/)
 
-2. cd into the test library of your choice (`cd src/libraries/<library>/tests`)
+# Running the Mono samples
+There are a few convenient samples located in `$(REPO_ROOT)/src/mono/netcore/sample`, which could help you test your program easily with different flavors of Mono or do a sanity check on the build. The samples are set up to work with a specific configuration; please refer to the relevant Makefile for specifics. If you would like to work with a different configuration, you can edit the Makefile.
 
-3. Run the tests
+## Desktop Mono
+To run the desktop Mono sample, cd to `HelloWorld` and execute:
 
 ```
-dotnet build /t:Test /p:RuntimeFlavor=mono
+make run
 ```
+Note that the default configuration of this sample is LLVM JIT.
 
-# Patching Local dotnet (.dotnet-mono)
-Another way to test mono out is by 'patching' a local dotnet with our runtime bits.  This is a good way to write simple
-test programs and get a glimpse of how mono will work with the dotnet tooling.
+## WebAssembly
+To run the WebAssembly sample, cd to `wasm`.  There are two sub-folders `browser` and `console`. One is set up to run the progam in browser, the other is set up to run the program in console. Enter the desirable sub-folder and execute
+
+```
+make build && make run
+```
 
-To generate a local .dotnet-mono, execute this command:
+## Android
+To run the Android sample, cd to `Android` and execute
 
 ```
-dotnet build /t:PatchLocalMonoDotnet $(REPO_ROOT)/src/mono/mono.proj
+make run
 ```
 
-You can then, for example, run our HelloWorld sample via:
+## iOS
+To run the iOS sample, cd to `iOS` and execute
 
 ```
-dotnet build -c Release $(REPO_ROOT)/src/mono/netcore/sample/HelloWorld
-MONO_ENV_OPTIONS="" COMPlus_DebugWriteToStdErr=1 \
-$(REPO_ROOT)/.dotnet-mono/dotnet $(REPO_ROOT)/src/mono/netcore/sample/HelloWorld/bin/HelloWorld.dll
+make run
 ```