You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- The actual resolution, for all edge types, is done by `resolveEdge()`.
716
716
Based on the `ResolveType`, it either inserts the move at the top or bottom
717
-
of the block.
717
+
of the block.
718
718
The algorithm for resolution can be found in [[2]](#[2]), though note
719
719
that there is a typo: in the last 'if' statement, it should be
720
720
"if b != loc(pred(b))" instead of "if b = loc(pred(b))":
@@ -1212,11 +1212,11 @@ term "EH Var" means a `lclVar` marked `lvLiveInOutOfHndlr`):
1212
1212
1213
1213
1. For determining whether an EH var should be a candidate for register allocation,
1214
1214
e.g. if the defs outweight the uses.
1215
-
1215
+
1216
1216
- An initial investigation might only consider an EH var as a register candidate if it has a single use. One complication is that we sometimes generate better code for a non-register-candidate local than one that is always spilled (we don't support `RegOptional` defs).
1217
1217
Thus, it would be better to identify *before* building intervals whether we should consider it a candidate, but the problem with that is that we don't necessarily know at that
1218
1218
time whether there is a single def. A possible approach:
1219
-
1219
+
1220
1220
- Add an `isSingleDef` flag to `Interval`.
1221
1221
- When allocating a use of a `writeThru` interval:
1222
1222
- If it's marked `isSingleDef`, allocate as usual.
Copy file name to clipboardexpand all lines: docs/design/features/DynamicPgo.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ You may already be familiar with the legacy .NET approach to profile feedback, c
18
18
19
19
## General Idea
20
20
21
-
Profile based optimization relies heavily on the principle that past behavior is a good predictor of future behavior. Thus observations about past program behavior can steer optimization decisions in profitable directions, so that future program execution is more efficient.
21
+
Profile based optimization relies heavily on the principle that past behavior is a good predictor of future behavior. Thus observations about past program behavior can steer optimization decisions in profitable directions, so that future program execution is more efficient.
22
22
23
23
These observations may come from the recent past, perhaps even from the current execution of a program, or from the distant past. Observations can be from the same version of the program or from different versions.
24
24
@@ -174,7 +174,7 @@ The classic paper on profile synthesis is [Ball-Larus](#BL93), which presents a
174
174
175
175
Profile synthesis is interesting even if instrumented or sampled profile data is available.
176
176
177
-
First, even in a jitted environment, the JIT may be asked to generate code for methods that have not yet executed, or that have for various reasons bypassed the stage of the system that runs instrumented versions. Profile synthesis can step in and provide provisional profile data.
177
+
First, even in a jitted environment, the JIT may be asked to generate code for methods that have not yet executed, or that have for various reasons bypassed the stage of the system that runs instrumented versions. Profile synthesis can step in and provide provisional profile data.
178
178
179
179
Second, even if profile feedback is available, it may not be as representative as one might like. In particular parts of methods may not have been executed, or may have distorted profiles. Given the linearity of profile data, we can blend together the actual observations with a synthetic profile to produce a hybrid profile, so that our optimizations do not over-react to the actual profile (think of this as a kind of insurance policy: we want to make sure that if program behavior changes and we suddenly veer into un-profiled or thinly profiled areas, we don't fall off some kind of performance cliff). More on this below.
180
180
@@ -601,7 +601,7 @@ We likely need to get through at least item 7 to meet our aspirational goals.
601
601
4. Enable hot/cold splitting (runtime dependence) for jitted code
602
602
5. Implement profile-based block layout (based on "TSP" algorithm above)
603
603
604
-
We likely need to get through at least item 3 to meet our aspirational goals.
604
+
We likely need to get through at least item 3 to meet our aspirational goals.
605
605
606
606
-----
607
607
#### Group 3: Profile Handling by Runtime and JIT
@@ -671,7 +671,7 @@ NET's legacy approach to PGO is called IBC (Instrumented Block Counts). It is av
671
671
672
672
A special instrumentation mode in crossgen/ngen instructs the JIT to add code to collect per-block counts and (for ngen) also instructs the runtime to track which ngen data structures are accessed at runtime, on a per-assembly basis. This information is externalized from the runtime and can be inspected and manipulated by IBCMerge. It is eventually packaged up and added back to the corresponding assembly, where it can be accessed by a subsequent "optimizing" run of crossgen/ngen. This run makes the per-block data available to the JIT and (for ngen) uses the internal runtime counters to rearrange the runtime data structures so they can be accessed more efficiently. Prejitting can also use the data to determine which methods should be prejitted (so called partial ngen).
673
673
674
-
The JIT (when prejitting) uses the IBC data much as we propose to use PGO data to optimize the generated code. It also splits methods into hot and cold portions. The runtime leverages IBC data to
674
+
The JIT (when prejitting) uses the IBC data much as we propose to use PGO data to optimize the generated code. It also splits methods into hot and cold portions. The runtime leverages IBC data to
675
675
676
676
The main aspiration of IBC is to improve startup, by ensuring that the important parts of prejitted code and data are compact and can be fetched efficiently from disk.
Copy file name to clipboardexpand all lines: docs/design/specs/PortablePdb-Metadata.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -556,7 +556,7 @@ The meaning of the _flags_ byte:
556
556
557
557
The remaining bits are reserved for future use and have currently no meaning.
558
558
559
-
> The data can be used to find the reference in a file indexing service such as a symbol server.
559
+
> The data can be used to find the reference in a file indexing service such as a symbol server.
560
560
> For example, the [Simple Symbol Query Protocol](https://github.com/dotnet/symstore/blob/master/docs/specs/Simple_Symbol_Query_Protocol.md) uses a combination of _file-name_, _time-stamp_ and _file-size_ as a [key](https://github.com/dotnet/symstore/blob/master/docs/specs/SSQP_Key_Conventions.md#pe-timestamp-filesize).
561
561
> Other services might use the MVID as it uniquely identifies the module.
Copy file name to clipboardexpand all lines: docs/infra/buildtriage.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
1
## Build Triage Rotation
2
2
3
-
The responsibility of this role is triaging our rolling / official builds, filing issues to track broken tests, submitting changes to dotnet/runtime to work around issues (disabling a test, undoing a PR that broke the build).
3
+
The responsibility of this role is triaging our rolling / official builds, filing issues to track broken tests, submitting changes to dotnet/runtime to work around issues (disabling a test, undoing a PR that broke the build).
4
4
5
5
In some cases this will require working with core-eng team when the issues are in Helix / Azure / Arcade. This person will also attend CI Council with the infra manager to provide updates on our reliability status.
6
6
7
-
This directly impacts developer productivity and the need to promptly fix such breaks can span across time zones. Hence it will be the collective responsibility of the Scout pool to investigate such breaks.
7
+
This directly impacts developer productivity and the need to promptly fix such breaks can span across time zones. Hence it will be the collective responsibility of the Scout pool to investigate such breaks.
8
8
9
9
This role will work on a rotation basis. There are six people in the role and each rotation will last for a calendar month.
10
10
@@ -22,9 +22,9 @@ We have different dashboards for public (Rolling & PR Builds) and internal build
22
22
23
23
In addition to the dashboards, official build failure notifications are sent to the internal runtime infrastructure email alias.
24
24
25
-
For each of these mail notifications, a matching issue should exist (either in the dotnet/runtime repository or in dotnet/core-eng or dotnet/arcade). The person triaging build failures should reply to the email with a link to the issue to let everyone know it is triaged. This guarantees that we are following-up on infrastructure issues immediately. If a build failure's cause isn't trivial to identify, consider looping in dnceng.
25
+
For each of these mail notifications, a matching issue should exist (either in the dotnet/runtime repository or in dotnet/core-eng or dotnet/arcade). The person triaging build failures should reply to the email with a link to the issue to let everyone know it is triaged. This guarantees that we are following-up on infrastructure issues immediately. If a build failure's cause isn't trivial to identify, consider looping in dnceng.
26
26
27
-
Tests are not run during the internal builds. Publishing and signing steps are run only during internal builds. Rolling builds run tests for the full matrix.
27
+
Tests are not run during the internal builds. Publishing and signing steps are run only during internal builds. Rolling builds run tests for the full matrix.
28
28
29
29
For new issues, try to provide a [runfo](https://runfo.azurewebsites.net/) search which will make it easy to isolate repeated instances of that failure.
30
30
@@ -34,7 +34,7 @@ Contact @jaredpar if you are having any trouble with runfo, site or utility.
34
34
35
35
## Ongoing Issues
36
36
37
-
All the issues causing the builds to fail should be marked with [`blocking-clean-ci`](https://github.com/dotnet/runtime/issues?q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-ci) label.
37
+
All the issues causing the builds to fail should be marked with [`blocking-clean-ci`](https://github.com/dotnet/runtime/issues?q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-ci) label.
38
38
Any issues causing build breaks in the official build should be marked with [`blocking-clean-official`](https://github.com/dotnet/runtime/issues?q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-official).
39
39
It helps in tracking issues effectively.
40
40
@@ -50,7 +50,7 @@ The main meta-bug linking to currently tracked issues is [here](https://github.c
Copy file name to clipboardexpand all lines: docs/pr-guide.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -84,7 +84,7 @@ If you have determined the failure is definitely not caused by changes in your P
84
84
* In a follow-up Pull Request, disable the failing test(s) with the corresponding issue link tracking the disable.
85
85
* Update the tracking issue with the label `disabled-test`.
86
86
* For libraries tests add a [`[ActiveIssue(link)]`](https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.XUnitExtensions/src/Attributes/ActiveIssueAttribute.cs) attribute on the test method. You can narrow the disabling down to runtime variant, flavor, and platform. For an example see [File_AppendAllLinesAsync_Encoded](https://github.com/dotnet/runtime/blob/a259ec2e967d502f82163beba6b84da5319c5e08/src/libraries/System.IO.FileSystem/tests/File/AppendAsync.cs#L899)
87
-
* For runtime tests found under `src/tests`, please edit [`issues.targets`](https://github.com/dotnet/runtime/blob/master/src/tests/issues.targets). There are several groups for different types of disable (mono vs. coreclr, different platforms, different scenarios). Add the folder containing the test and issue mimicking any of the samples in the file.
87
+
* For runtime tests found under `src/tests`, please edit [`issues.targets`](https://github.com/dotnet/runtime/blob/master/src/tests/issues.targets). There are several groups for different types of disable (mono vs. coreclr, different platforms, different scenarios). Add the folder containing the test and issue mimicking any of the samples in the file.
88
88
89
89
There are plenty of possible bugs, e.g. race conditions, where a failure might highlight a real problem and it won't manifest again on a retry. Therefore these steps should be followed for every iteration of the PR build, e.g. before retrying/rebuilding.
Copy file name to clipboardexpand all lines: docs/workflow/using-dotnet-cli.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
2
2
# Using your .NET Runtime build with .NET SDK
3
3
4
-
This walkthrough explains how to run your own app against your local build using only the .NET SDK.
4
+
This walkthrough explains how to run your own app against your local build using only the .NET SDK.
5
5
6
6
Testing your local build this way is quite realistic - more like a real user. However it takes longer because you have to build the package. Each build can take 10 minutes altogether.
7
7
@@ -181,9 +181,9 @@ So the steps are:
181
181
182
182
```cmd
183
183
build.cmd clr+libs+host+packs -c release
184
-
```
184
+
```
185
185
186
-
If you only changed libraries, `build.cmd libs+host+packs -c release` is a little faster; if you only changed clr, then `build.cmd clr+host+packs -c release`
186
+
If you only changed libraries, `build.cmd libs+host+packs -c release` is a little faster; if you only changed clr, then `build.cmd clr+host+packs -c release`
Copy file name to clipboardexpand all lines: src/libraries/System.Memory.Data/README.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -2,21 +2,21 @@
2
2
3
3
## Binary Data
4
4
The `BinaryData` type provides a lightweight abstraction for a payload of bytes. It provides convenient helper methods to get out commonly used primitives, such as streams, strings, or bytes. The assumption when converting to and from string is that the encoding is UTF-8.
5
-
5
+
6
6
### Data ownership
7
7
When using the `byte[]` or `ReadOnlyMemory<byte>` constructors or methods, `BinaryData` will wrap the passed in bytes. When using streams, strings, or rich model types that will be serialized as Json, the data is converted into bytes and will be maintained by `BinaryData`. Thus, if you are using bytes to create your instance of `BinaryData`, changes to the underlying data will be reflected in `BinaryData` as it does not copy the bytes.
8
8
9
9
### Usage
10
10
The main value of this type is its ability to easily convert from string to bytes to stream. This can greatly simplify API surface areas by exposing this type as opposed to numerous overloads or properties.
11
-
11
+
12
12
To/From string:
13
13
```C# Snippet:BinaryDataToFromString
14
14
vardata=newBinaryData("some data");
15
15
16
16
// ToString will decode the bytes using UTF-8
17
17
Console.WriteLine(data.ToString()); // prints "some data"
0 commit comments