diff options
Diffstat (limited to 'Documentation/project-docs')
6 files changed, 70 insertions, 18 deletions
diff --git a/Documentation/project-docs/ci-trigger-phrases.md b/Documentation/project-docs/ci-trigger-phrases.md index dd0e981ead..f57be03262 100644 --- a/Documentation/project-docs/ci-trigger-phrases.md +++ b/Documentation/project-docs/ci-trigger-phrases.md @@ -11,7 +11,10 @@ To trigger a job, post a comment on your PR with "@dotnet-bot {trigger-phrase}". - **Windows_NT x64 Release Priority 1 Build & Test:** "test Windows_NT pri1" - **Windows_NT x64 Release IL RoundTrip Build & Test:** "test Windows_NT ilrt" -- **Windows_NT x64 Release Long-Running GC Build & Test:**: "test Windows_NT x64 Release longgc" +- **Windows_NT x64 Release Long-Running GC Build & Test:**: "test Windows_NT Release longgc" +- **Windows_NT x64 Release GC Simulator:**: "test Windows_NT Release gcsimulator" +- **Windows_NT x64 Release Standalone GC:**: "test Windows_NT Release standalone_gc" +- **Windows_NT x64 Release GC Reliability Framework:**: "test Windows_NT Release gc_reliability_framework" - **Windows_NT x64 Release Ready-To-Run Priority 0 Build & Test:** "test Windows_NT Release r2r" - **Windows_NT x64 Checked Ready-To-Run Priority 0 Build & Test:** "test Windows_NT Checked r2r" - **Windows_NT x64 Release Ready-To-Run Priority 1 Build & Test:** "test Windows_NT Release pri1r2r" @@ -69,6 +72,8 @@ To trigger a job, post a comment on your PR with "@dotnet-bot {trigger-phrase}". - **Windows_NT x64 Checked GCStress=0xc JitStress=2 Build & Test:** "test Windows_NT gcstress0xc_jitstress2" - **Windows_NT x64 Checked GCStress=0xc MinOpts Heap Verify 1 Build & Test:** "test Windows_NT gcstress0xc_minopts_heapverify1" - **Windows_NT x64 Checked Long-Running GC Build & Test:**: "test Windows_NT x64 Checked longgc" +- **Windows_NT x64 Checked Standalone GC:**: "test Windows_NT Checked standalone_gc" +- **Windows_NT x64 Checked GC Reliability Framework:**: "test Windows_NT Checked gc_reliability_framework" - **Windows_NT x64 Formatting:**: "test Windows_NT formatting" - **Windows_NT x64 Checked CoreFX Baseline Build & Test:** "test Windows_NT corefx_baseline" - **Windows_NT x64 Checked CoreFX MinOpts Build & Test:** "test Windows_NT corefx_minopts" @@ -166,6 +171,11 @@ To trigger a job, post a comment on your PR with "@dotnet-bot {trigger-phrase}". - **Ubuntu x64 Release Priority 1 Build & Test:** "test Ubuntu pri1" - **Ubuntu x64 Release IL RoundTrip Build & Test:** "test Ubuntu ilrt" - **Ubuntu x64 Release Long-Running GC Build & Test:**: "test Ubuntu Release longgc" +- **Ubuntu x64 Release GC Simulator:**: "test Ubuntu Release gcsimulator" +- **Ubuntu x64 Release Standalone GC:**: "test Ubuntu Release standalone_gc" +- **Ubuntu x64 Checked Standalone GC:**: "test Ubuntu Checked standalone_gc" +- **Ubuntu x64 Release GC Reliability Framework:**: "test Ubuntu Release gc_reliability_framework" +- **Ubuntu x64 Checked GC Reliability Framework:**: "test Ubuntu Checked gc_reliability_framework" - **Ubuntu x64 Release Ready-To-Run Priority 0 Build & Test:** "test Ubuntu Release r2r" - **Ubuntu x64 Checked Ready-To-Run Priority 0 Build & Test:** "test Ubuntu Checked r2r" - **Ubuntu x64 Release Ready-To-Run Priority 1 Build & Test:** "test Ubuntu Release pri1r2r" @@ -248,6 +258,11 @@ To trigger a job, post a comment on your PR with "@dotnet-bot {trigger-phrase}". - **OSX x64 Release Priority 1 Build & Test:** "test OSX pri1" - **OSX x64 Release IL RoundTrip Build & Test:** "test OSX ilrt" - **OSX x64 Release Long-Running GC Build & Test:**: "test OSX Release longgc" +- **OSX x64 Release GC Simulator:**: "test OSX10.12 Release gcsimulator" +- **OSX x64 Release Standalone GC:**: "test OSX10.12 Release standalone_gc" +- **OSX x64 Checked Standalone GC:**: "test OSX10.12 Checked standalone_gc" +- **OSX x64 Release GC Reliability Framework:**: "test OSX10.12 Release gc_reliability_framework" +- **OSX x64 Checked GC Reliability Framework:**: "test OSX10.12 Checked gc_reliability_framework" - **OSX x64 Release Ready-To-Run Priority 0 Build & Test:** "test OSX Release r2r" - **OSX x64 Checked Ready-To-Run Priority 0 Build & Test:** "test OSX Checked r2r" - **OSX x64 Release Ready-To-Run Priority 1 Build & Test:** "test OSX Release pri1r2r" diff --git a/Documentation/project-docs/clr-configuration-knobs.md b/Documentation/project-docs/clr-configuration-knobs.md index 63f094b8ee..3787666174 100644 --- a/Documentation/project-docs/clr-configuration-knobs.md +++ b/Documentation/project-docs/clr-configuration-knobs.md @@ -303,9 +303,6 @@ Name | Description | Type | Class | Default Value | Flags `StackSamplingNumMethods` | Number of evolving methods to track as hot and JIT them in the background at a given point of execution. | DWORD | UNSUPPORTED | 32 | `AltJitNgen` | Enables AltJit for NGEN and selectively limits it to the specified methods. | STRING | INTERNAL | | REGUTIL_default `JitNoCMOV` | | DWORD | INTERNAL | 0 | REGUTIL_default -`UseRyuJIT` | Set to 1 by .NET 4.6 installer to indicate RyuJIT should be used, not JIT64. | DWORD | INTERNAL | 0 | IgnoreEnv / IgnoreHKCU / IgnoreConfigFiles -`useLegacyJit` | Set to 1 to do all JITing with compatjit.dll. Only applicable to x64. | DWORD | EXTERNAL | 0 | -`DisableNativeImageLoadList` | Refuse to load native images corresponding to one of the assemblies on this semicolon-delimited list of assembly names. | STRING | EXTERNAL | | REGUTIL_default `JitValNumCSE` | Enables ValNum CSE for the specified methods | STRING | INTERNAL | | REGUTIL_default `JitLexicalCSE` | Enables Lexical CSE for the specified methods | STRING | INTERNAL | | REGUTIL_default `JitNoCSE` | | DWORD | INTERNAL | 0 | REGUTIL_default diff --git a/Documentation/project-docs/contributing-workflow.md b/Documentation/project-docs/contributing-workflow.md index ff21143d7a..3634802a10 100644 --- a/Documentation/project-docs/contributing-workflow.md +++ b/Documentation/project-docs/contributing-workflow.md @@ -83,24 +83,24 @@ Suggested Workflow We use and recommend the following workflow: 1. Create an issue for your work. - - You can skip this step for trivial changes. - - Reuse an existing issue on the topic, if there is one. - - Use [CODE_OWNERS.TXT](https://github.com/dotnet/coreclr/blob/master/CODE_OWNERS.TXT) to find relevant maintainers and @ mention them to ask for feedback on your issue. - - Get agreement from the team and the community that your proposed change is a good one. - - If your change adds a new API, follow the [API Review Process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md). - - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. + - You can skip this step for trivial changes. + - Reuse an existing issue on the topic, if there is one. + - Use [CODE_OWNERS.TXT](https://github.com/dotnet/coreclr/blob/master/CODE_OWNERS.TXT) to find relevant maintainers and @ mention them to ask for feedback on your issue. + - Get agreement from the team and the community that your proposed change is a good one. + - If your change adds a new API, follow the [API Review Process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md). + - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. 2. Create a personal fork of the repository on GitHub (if you don't already have one). 3. Create a branch off of master (`git checkout -b mybranch`). - - Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue. - - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. + - Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue. + - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. 4. Make and commit your changes. - - Please follow our [Commit Messages](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#commit-messages) guidance. + - Please follow our [Commit Messages](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#commit-messages) guidance. 5. Add new tests corresponding to your change, if applicable. 6. Build the repository with your changes. - - Make sure that the builds are clean. - - Make sure that the tests are all passing, including your new tests. + - Make sure that the builds are clean. + - Make sure that the tests are all passing, including your new tests. 7. Create a pull request (PR) against the upstream repository's **master** branch. - - Push your changes to your fork on GitHub (if you haven't already). + - Push your changes to your fork on GitHub (if you haven't already). Note: It is OK for your PR to include a large number of commits. Once your change is accepted, you will be asked to squash your commits into one or some appropriately small number of commits before your PR is merged. diff --git a/Documentation/project-docs/dotnet-standards.md b/Documentation/project-docs/dotnet-standards.md index 452c703f0a..d7268369d7 100644 --- a/Documentation/project-docs/dotnet-standards.md +++ b/Documentation/project-docs/dotnet-standards.md @@ -49,7 +49,7 @@ ECMA 372 - C++/CLI The C++/CLI language was standardized as [ECMA 372](http://www.ecma-international.org/publications/standards/Ecma-372.htm) in 2005. -EMCA 372 is supported by the .NET Framework, but not .NET Core. +ECMA 372 is supported by the .NET Framework, but not .NET Core. **ECMA 372 Resources** diff --git a/Documentation/project-docs/garbage-collector-guidelines.md b/Documentation/project-docs/garbage-collector-guidelines.md index 66d4c69b9f..1981c8ab6f 100644 --- a/Documentation/project-docs/garbage-collector-guidelines.md +++ b/Documentation/project-docs/garbage-collector-guidelines.md @@ -26,12 +26,43 @@ Required Testing: Validation of the behavior of the affected APIs. ## Stress Testing ## Stress testing must run for at least **48 hours** against a debug build. -Instructions for running stress are located in the repo at tests\src\GC\Stress\stress_run_readme.txt. +Stress testing for checked and release builds can be done on pull requests with The .NET CI infrastructure. +A stress run can be requested using the trigger phrase: + +``` +@dotnet_bot test <platform> <flavor> gc_reliability_framework +``` + +This will run the stress framework for the default amount of time (15 hours) on the given platform and build flavor. ## Functional Testing ## A functional test run executes the same code as a stress run, but only runs for 30 minutes. Instructions for running stress are located in the repo at tests\src\GC\Stress\stress_run_readme.txt. +It is recommended that you run at least some of the below PR-triggered CI jobs: + +``` +@dotnet_bot test Windows_NT Checked longgc +@dotnet_bot test OSX10.12 Checked longgc +@dotnet_bot test Ubuntu Checked longgc +@dotnet_bot test Windows_NT Checked standalone_gc +@dotnet_bot test OSX10.12 Checked standalone_gc +@dotnet_bot test Ubuntu Checked standalone_gc +``` + +The "Long GC" tests are a series of GC tests whose running time is too long or memory usage is too high to run with +the rest of the Priority 0 unit tests. The "Standalone GC" build mode builds and runs the GC in a semi-standalone manner +(see https://github.com/dotnet/coreclr/projects/3). + +You may also wish to run the GC Simulator tests. They may take up to 24 hours to complete and are known to sometimes fail on Ubuntu +due to poor interactions with the Linux OOM killer. However, they have proven to be quite useful in finding bugs in the past: + +``` +@dotnet_bot test Windows_NT Release gcsimulator +@dotnet_bot test Ubuntu Release gcsimulator +@dotnet_bot test OSX10.12 Release gcsimulator +``` + ## Performance Testing ## Coming soon. diff --git a/Documentation/project-docs/performance-guidelines.md b/Documentation/project-docs/performance-guidelines.md index f9c5e17c91..a2e15d5e01 100644 --- a/Documentation/project-docs/performance-guidelines.md +++ b/Documentation/project-docs/performance-guidelines.md @@ -50,5 +50,14 @@ Capturing a trace using PerfView will allow you to: PerfView is available at the [Microsoft Download Center](http://www.microsoft.com/en-us/download/details.aspx?id=28567 "Microsoft Download Center"). The help documentation is quite substantial and can help you get started. Clicking the blue links throughout PerfView's UI will also take you to the appropriate help topic. It is also recommended that you watch the [PerfView Tutorial Videos](http://channel9.msdn.com/Series/PerfView-Tutorial). +# Running the CoreCLR Performance Tests on Windows # +1. The first step to running the performance tests locally is to do a release build of CoreCLR and all of the performance tests. You can do this with the command `build.cmd x64 Release`, this will of course build the x64 runtime, and you should use x86 if you want to test x86. + +2. After building the runtime you will need to generate a core root that contains all of the binaries we just built along with the required dependencies. This can be done with the command `tests\runtest.cmd Release x64 GenerateLayoutOnly`, with the same caveat that x86 should be used if that is the platform that you are testing. + +3. Now we need to actually run the performance tests. You can do that with the following command that should be run from the root of your repo `tests\scripts\run-xunit-perf.cmd -arch x64 -configuration Release -testBinLoc bin\tests\Windows_NT.x64.Release\Jit\Performance\CodeQuality`. This will run all of the tests in the JIT CodeQuality directory as the script will walk all sub-directories and look for tests to run. If you want to just run a single test, pass the path of the single test that you want to run. + +4. Navigate to the `sandbox` directory in the root of your repo. Inside that directory you will find a bunch of files that follow the name Perf-*.md. These will contain the results, formatted as Markdown files, for each test that was run. + # Additional Help # If you have questions, run into any issues, or would like help with any performance related topics, please feel free to post a question. Someone from the .NET performance team will be happy to help. |