Skip to content

[pull] main from dotnet:main#100

Merged
pull[bot] merged 9 commits intoabpedroni:mainfrom
dotnet:main
Aug 9, 2022
Merged

[pull] main from dotnet:main#100
pull[bot] merged 9 commits intoabpedroni:mainfrom
dotnet:main

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Aug 9, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

ilonatommy and others added 9 commits August 9, 2022 08:20
…ties (#73230)

* Fix of VHO for most test cases.

* Cleanup.

* New testcases with auto-props.

* Adjusted ProtectionLvlTest to new changes.
* Replace MissingInteropDataException with NotSupportedException
* Replace MissingRuntimeArtifactException with MissingMetadataException (it was already used as a MME in some spots anyway). I'll try to get rid of MME later.
* Change the messages to refer to static analysis as the fix, not RD.XML.
* Avoid additional Pipes invocation and clean-up project

* Update System.IO.Pipes.AccessControl.csproj
This introduces a lookup table for regions where we can find the current generation, the planned generation and a couple flags efficiently, i.e. by simple indexing into table.

The table has byte-sized elements where the low 2 bits represent the current generation and the high 2 bits represent the planned generation. The 4 bits in between are available for flags, 2 are used so far, one to show that a region was swept in the plan phase, and one to show that a region was demoted.

The table is used in the mark phase, in the mark_through_cards_helper (which is also called in the relocate_phase), and in the write barriers (for now only the most frequently used ones, Array.Copy has its own way of setting cards that I haven't fixed).

I have changed the write barrier to only set single bits for the case where a pointer to younger generation is stored into an object in an older generation. This costs an interlocked operation in the case the bit is not already set. In the test cases we looked at this is more than compensated by lower cost in card marking. For cases where the cost of the interlocked instruction is too high, an escape hatch has been provided the form of the COMPLUS_GCWriteBarrier setting which can be used to select another flavor of write barrier - either a more precise write barrier for regions, or an imprecise write barrier. Both set whole bytes and thus need no interlocked operations.

The write barrier uses a global ephemeral range to decide quickly whether a stored pointer can be in an ephemeral generation at all. For now, this global ephemeral range is simply set to the address range of the whole heap, to avoid having to update the write barrier on the fly. A slightly more sophisticated approach that takes into account low gen 2 regions is present in the code, but disabled for now.
* Set up HttpClient for ClientWebSocket.ConnectAsync

* more tests

* Update src/libraries/System.Net.WebSockets.Client/src/System/Net/WebSockets/WebSocketHandle.Managed.cs

Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com>

* Apply suggestions from code review

Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com>

* Refactoring websockets test inheritance

Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com>
* [wasm-ep] remove in-JS VFS tracing support

use the websocket diagnostic server support instead

* remove browser-mt-eventpipe sample

use the browser-threading sample for working with threading
use the browser-eventpipe sample for working with tracing

* remove the EventPipeSessionOptions, too
We were only handling uses of promoted locals when varTypeIsStruct(lcl)
was true. For TYP_LONG promoted locals on x86 it is not.

Fix #73559
@pull-request-quantifier-deprecated
Copy link
Copy Markdown

This PR has 2168 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +1593 -575
Percentile : 100%

Total files changed: 62

Change summary by file extension:
.cpp : +560 -63
.h : +69 -7
.hpp : +2 -2
.cs : +271 -148
.csproj : +21 -49
.resx : +4 -4
.asm : +332 -0
.S : +319 -20
.proj : +0 -1
.js : +1 -70
.html : +0 -18
.ts : +14 -186
src/mono/sample/wasm/browser-mt-eventpipe/Makefile : +0 -7

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@pull pull bot added ⤵️ pull and removed Extra Large labels Aug 9, 2022
@pull pull bot merged commit acc4f23 into abpedroni:main Aug 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants