This reverts commit dotnet/coreclr@3f4ee3bed52291e592d7ab67da1fc0e39ee8a3b7.


Commit migrated from https://github.com/dotnet/coreclr/commit/81c38cd7272d0cbb70885122b7350fedaf0fd3ba

Merge changes from TFS

Commit migrated from https://github.com/dotnet/coreclr/commit/59da8574383d547a20dcae478b67ff458f6d71e6

* Improve ReaderWriterLockSlim scalability

Subset of dotnet/coreclr#13243, fixes dotnet/coreclr#12780

- Prevented waking more than one waiter when only one of them may acquire the lock
- Limited spinning in some cases where it is very unlikely that spinning would help

The _myLock spin lock runs into some bad scalability issues. For example:
1. Readers can starve writers for an unreasonable amount of time. Typically there would be more readers than writers, and it doesn't take many readers to starve a writer. On my machine with 6 cores (12 logical processors with hyperthreading), 6 to 16 reader threads attempting to acquire the spin lock to acquire or release a read lock can starve one writer thread from acquiring the spin lock for several or many seconds. The issue magnifies with more reader threads.
2. Readers and especially writers that hold the RW lock can be starved from even releasing their lock. Releasing an RW lock requires acquiring the spin lock, so releasers are easliy starved by acquirers. How badly they are starved depends on how many acquirers there are, and it doesn't take many to show a very noticeable scalability issue. Often, these acquirers are those that would not be able to acquire the RW lock until one or more releasers release their lock, so the acquirers effectively starve themselves.

This PR does not solve (1), but solves (2) to a degree that could be considered sufficient. dotnet/coreclr#13243 solves (1) and (2) and for (2) it is still better by order-of-magnitude compared with this PR in several cases that I believe are not extreme, but if the complexity of deprioritization is deemed excessive for the goals then of what I tried so far this is the perhaps simplest and most reasonable way to solve (2).

I believe this PR would also be a reasonably low-risk one to port back to .NET Framework.

Commit migrated from https://github.com/dotnet/coreclr/commit/e000977dc11feb3f7f7920a57f0e53f4749377e0

Alpine Linux has a very small default stack size limit, about 80kB.
This is not enough for running coreclr apps.

This change enables overriding the default stack size using the
COMPlus_DefaultStackSize env variable. For Alpine, it also sets
the default stack size to the same value we use for Windows, which
is 1.5MB.

Commit migrated from https://github.com/dotnet/coreclr/commit/5f2d1ec0e50a3aceddcc75172021cea10677b354

[RyuJIT/arm32] Fix MultiReg flag setter

Commit migrated from https://github.com/dotnet/coreclr/commit/8abfe25cbd02e07361301e0a5cadb6716b3c0cde

The jit will refine the types of temps used to pass arguments to inlinees
when it creates the assignments to these temps.

Unfortunately this is too late to drive devirtualization in the body of
the inlinee, as thes assignments are created after the inlinee body is
imported.

So, add similar refinement logic to the place where the temps are first
created.

Closes dotnet/coreclr#13520.

Commit migrated from https://github.com/dotnet/coreclr/commit/85c59f9aa92092e72618df51879a9338ca9d4307

Commit migrated from https://github.com/dotnet/coreclr/commit/f46134f56e408fc3e4cd14cd8ed43be90765f7fe

[RyuJIT/ARM32] Remove unnecessary genIsValidDoubleReg() assertion

Commit migrated from https://github.com/dotnet/coreclr/commit/6fe0e8685e81099f5e1cf02504ddfe4ff183c750

Add InnerIterationCount to layout benchmarks

Commit migrated from https://github.com/dotnet/coreclr/commit/c8ede5ad70ffa3bc34a522102b7646cae2bdebfd

Bitwise operation fix in `SetRegSpillFlagByIdx()`.

Fix dotnet/coreclr#13423


Commit migrated from https://github.com/dotnet/coreclr/commit/7447d75d3027c4d01171ea46753d371fe7835a61

When I added the base Stream.Read/Write(span) default implementations, I added a special-case check for if the span is empty, in which case it made the operation a nop.  But various streams want to impose behavior even in the 0-byte case, e.g. throwing an ObjectDisposedException if the stream has been closed.  This commit just removes the check and allows Read/Write to delegate for all sized spans.

Commit migrated from https://github.com/dotnet/coreclr/commit/a9c4c6c6f85a26591c72983ea28eccb581eb9eca

Fixed assertion failure in legacy backend

Commit migrated from https://github.com/dotnet/coreclr/commit/463a67316ef0187373a6d4c501aa913026ab6d88

Override Span-based Read/Write on FileStream

Commit migrated from https://github.com/dotnet/coreclr/commit/fa79179baa11923cba48e2cdd9c9bd723486a136

Commit migrated from https://github.com/dotnet/coreclr/commit/a88ac369ee776acafcaf1a39aeee93520b07b5f0

Modify gtNewTempAssign to more generally map self-assignment of temps
into nops.

We already were doing something similar over in `impAssignStruct`, and
now we catch non-struct cases too.

Commit migrated from https://github.com/dotnet/coreclr/commit/637bfeffb0fd0378ff6d04d7bb845938b77bdade

[tfs-changeset: 1671421]


Commit migrated from https://github.com/dotnet/coreclr/commit/fd9dce46c1d441883bb38ca24554ce3f8224276e

[tfs-changeset: 1671419]


Commit migrated from https://github.com/dotnet/coreclr/commit/5f0700214606bb9d922e686d9cca0c489379202d

Remove macro definition checks that aren't useful and cause unnecessary build breaks (dotnet/coreclr#13523)



Commit migrated from https://github.com/dotnet/coreclr/commit/1eea080a7b3a13110975b92034a22e4fc473df46

Commit migrated from https://github.com/dotnet/coreclr/commit/8b7dcb5900392f9e30a8aaabe11c89d470178322

These tests were too short-running to measure effectively.  Add an inner
iteration count that makes the running time around 1 second (measured
locally).


Commit migrated from https://github.com/dotnet/coreclr/commit/ad75eead4d663427381c103246c27c2e20587420

* Introduce COMPlus_GDBJitEmitDebugFrame

* Use a proper #ifdef macro


Commit migrated from https://github.com/dotnet/coreclr/commit/aed0665893b812eadd8be6362116285f59e27288

Adds overrides for the new Span-based Read/Write methods on FileStream.

A few notes:
- As with {Unmanaged}MemoryStream, FileStream isn't sealed, which means a derived type could have overridden all of the existing abstract/virtual methods, including Read(byte[],int,int).  If a consumer then switched to using that stream with Read(Span), because we now override Read(Span), the consumer should get the same behavior intended by the stream developer. As such, since we have no good/efficient way to check whether Read(byte[],int,int) is overridden, we check whether the current stream is a concrete FileStream (rather than a derived type), and if it isn't we use the default base behavior, which will call the Read(byte[],int,int) method.
- FileStream is odd in that it has a dual nature around whether it was initialized for sync vs async, a setting that on Windows ends up configuring the native handle to operate in async mode.  Sync operations on an async-configured FileStream end up delegating to the async methods and blocking, and async operations on a sync-configured FileStream end up using the synchronous behavior asynchronously.  There were some inconsistencies around how this was handled between Windows and Unix, in particular around the ReadByte method, and as part of adding these overloads, I changed that as well, as doing so made the code simpler with the new Span-based support.  Technically this is a breaking change on Unix, but it would be very niche, including calling ReadByte on an async stream while other async operations were in progress... in that case, the desktop and Windows core behavior was to allow direct access to any cached data in the buffer, whereas on Unix we would serialize the ReadByte call with other async operations in flight.


Commit migrated from https://github.com/dotnet/coreclr/commit/1cb3580858f3224f0e0981965a2da1fd61ba9e08

Commit migrated from https://github.com/dotnet/coreclr/commit/f0e86604cbc2e30889ec354423bb4478924ece29

Commit migrated from https://github.com/dotnet/coreclr/commit/d5136b04cd19f35280949d078b5df19b99f0eb26

Fix warnings when building SOS.NETCore.csproj

Commit migrated from https://github.com/dotnet/coreclr/commit/246789d44abf75e6b945e4508ed25b9561d79adc

* [Local GC] Build the GC using system headers

* Disable features to get the GC to build

* Get rid of the separate 'GC PAL' build

* Remove unused stuff

* Don't build gcenv.os.cpp when linking in a standalone gc

* Stub out CPUGroupInfo and NumaNodeInfo

* Stub out IsGCThread and friends

* Build the GC as a shared library 🎉

* Build, link, and run! 🎉

* Fix standalone GC build break

* Fixes where the GC's MethodTable and VM's MethodTable classes disagree

* Integrate a standalone GC into the CoreCLR build system (so it gets copied to the output folder). Re-enable some ifdef-ed out includes that are required for a non-standalone build of the GC.

* Bring changes to Unix and fix the Unix build. Implement some compiler intrinsic wrappers and alignment functions expected by the GC.

* Fix the Windows build

* 1. Code review feedback: use standard types for BitScanForward and
   BitScanForward64
2. Delete FEATURE_COM stuff from the build system, not needed for this
PR
3. Fix the Unix build

* Fix the Windows x86 build - the _BitScanForward64 intrinsic is not available when targeting 32-bit platforms

* Remove a number of things from gcenv.base.h that are not used

* Remove a linker workaround now that we are not linking a standalone GC into the runtime

* Remove dead code, make the lack of GC_PROFILING for standalone gc not break profiling on the non-standalone build

* Code review feedback - use add_library_clr and other cmake-related fixes

* Fix include indentation

* Remove some extraneous parameters to cmake functions (cmake is remarkably lenient...)


Commit migrated from https://github.com/dotnet/coreclr/commit/8acf6c9f7e33b1bfe77205cd2e61f2c60e8c00ce

Update JitOptimizerTodoAssessment.md

Commit migrated from https://github.com/dotnet/coreclr/commit/2766385624a9c5b73d32bed85519c044447701ff

* Add variables to pipeline to enable enforcepgo for Release

* Address review


Commit migrated from https://github.com/dotnet/coreclr/commit/ce54898a65f89b95537a943a48bae1c60cd249ed

Fix incorrect switch temp lcl type

Commit migrated from https://github.com/dotnet/coreclr/commit/10c89f401b3b7cf4cc095649455ce4d2efd33b18

* Delete some dead PAL code

GetComputerName and GetUserName are not used.

* HAVE_GETPWUID_R can now be deleted


Commit migrated from https://github.com/dotnet/coreclr/commit/dfd90b728c3bc26c4e038a3dbd6075ce3f257d2b

* Remove empty try's

* Remove some dead comments

* more


Commit migrated from https://github.com/dotnet/coreclr/commit/469940932199d4f281896184c8fd49daffdd1a5d

Remove some `goto`s that were added to work around dotnet/coreclr#9692 (poor code
layout for loop exit paths) -- the JIT's layout decisions were improved
in dotnet/coreclr#13314, and these particular `goto`s are no longer needed; crossgen
of System.Private.CoreLib now produces the same machine code with or
without this change.

Part of dotnet/coreclr#13466.

Commit migrated from https://github.com/dotnet/coreclr/commit/f4bf9209719b4c356416cdeaf3aa57eba54c9206

Cap ThreadPool thread requests minimalistically

- Only request an additional thread on dequeue if enqueue request was suppressed, and if there are any work items left in the queues
- ThreadPool pad hot cache line
- Add ideas from dotnet/coreclr#13408

Commit migrated from https://github.com/dotnet/coreclr/commit/99db31c41d5057e08cc4701c79f11246b9191a9b

fix JitConfig initialize and destoy.

Commit migrated from https://github.com/dotnet/coreclr/commit/8020aa727020c5a02e2c27ec4b07ee3ffbaf057d

Avoid unnecessary intermediate Version allocation

Commit migrated from https://github.com/dotnet/coreclr/commit/8b802826b89b0cbd0a037255bb13a86f95bc4447

Fixing wcsstr function to account for cases where search string is longer than remaining target string. (dotnet/coreclr#13504)



Commit migrated from https://github.com/dotnet/coreclr/commit/358826b58e1863857d110b30abb32257171d1009

* Use CreateFile2FromApp if available

This is needed for F5 UAP brokering scenarios.

Remove check for handle type. Overzealous, doesn't apply to UAP scenarios.

* Address feedback

- Use CreateFile2 if Win8 or higher
- Always use CreateFile2FromApp if Appx
- Make DisableMediaInsertionPrompt a struct
- Push CreateFile2FromApp down to avoid JIT

* More feedback

Always use FromApp for WinRT.

* Conditionalize IsWindows8OrAbove check

* Always use FromApp if in AppX

* Address more feedback

- Fix Unix build by moving LoadString to shared
- Break out CREATEFILE2 struct
- Condition CreateFile2FromApp usage

* Move include


Commit migrated from https://github.com/dotnet/coreclr/commit/41a2b788cb77668d397e372df40c5215bf61bfa7

* Remove bogus assembly warnings in VS

* Fix warnings about sharing files within the project tree

* Remove bogus lines

* Remove lines showing up as bogus source files

* Remove overridden target

* feedback


Commit migrated from https://github.com/dotnet/coreclr/commit/151002c8814c2f9fdbc0979c6737f6a3e1878fba

Fixed misconception between FP register allocator and RyuJIT's CSE phase

Commit migrated from https://github.com/dotnet/coreclr/commit/d99751c0dac420a2e9b0c52ea50d5d766e538d3b

Add span-based Version methods

Commit migrated from https://github.com/dotnet/coreclr/commit/e8993ecdc48e98b6e8ec4ee8d21d28f11e9e5f65