* [ARM64] Add g_GCShadowEnd to JIT_WriteBarrier_Table

This change moves address of g_GCShadowEnd to JIT_WriteBarrier_Table like
others variables used in Write Barrier.

This fix simmilar to RISC-V one https://github.com/dotnet/runtime/pull/90036

* [ARM64] Move GCShadow vars to the end of the wbs block

* Update src/coreclr/vm/arm64/asmhelpers.asm

---------
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

The ILLink ProjectReference output shouldn't be copied to consuming projects.

From the docs:
> Private	Optional boolean. Specifies whether the reference should be copied to the output folder. This attribute matches the Copy Local property of the reference that's in the Visual Studio IDE.

* Microsoft.Bcl.Numerics.Tests: fix restore failure when DotNetBuildFromSource.

* Use NetCoreAppCurrent.

* Try fix CI test failures.

Guarantee that we do not hold onto a strong reference of the watcher when processing events (#91301)

Microsoft.Dotnet.Sdk.Internal
 From Version 9.0.100-alpha.1.23429.7 -> To Version 9.0.100-alpha.1.23431.1
Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

We were not generating information about static virtuals on interface types. Information about default interface methods normally goes to the class, but if the T we're dispatching on is an interface, this information wasn't generated. The fix is to put this information into dispatch maps and sealed vtables, same way we do for classes.

The test shows what the problem is - if we change `IBar` to be a class, things would work even before this PR.

When we started generating custom modifiers into metadata format to support new function pointer APIs in #85504, we should have also added it to native layout format. We currently have a mismatch. This is a low risk bugfix to ignore modifiers on the metadata side. We'll want to do a full fix to actually emit and compare this. Tracked in a .NET 9 bug at #91381.

No regression test because I spent too much time being puzzled at why https://github.com/Handlebars-Net/Handlebars.Net/blob/50614fd844e5360eb10e76154aa74da4d7bf12ce/source/Handlebars/Helpers/IHelperDescriptor.cs#L13 is generated as a custom modifier (`[in] !TOptions& modreq([netstandard]System.Runtime.InteropServices.InAttribute) options`) whereas if I do it, I get `[in] !T& 'value'` with a custom attribute. We'll want to write a proper set of tests with ambiguities for the bug I opened anyway.

The precode code was incorrectly using the HOST_ARM64, HOST_ARM, etc. defines instead
of the TARGET_ ones. This means the cross-DAC was using the wrong architectures
*Precode::Type codes.

* Add late binding lookup in VB.NET for COM objects

* Implement IDirectoryContents on PhysicalDirectoryInfo

* Update test

* Avoid code duplication

Adds job to runtime-coreclr crossgen2 that runs the innerloop test group
with hot/cold splitting enabled in Crossgen2.

* Fix offset calculation for nested struct

* Add a test for nested struct with pinvoke

* Move and update test with real c++ implementation

* Exclude newly added test from wasm

* Disable interop tests on android and apple devices

- Add an error message explicitly calling out incompatible architecture when we detect that case
- Propagate the load error when failing to load a PE image
- Show file path if trying to load from a path, assembly display name otherwise

This reverts commit 838b21fc.

The current mechanism has a fundamental flaw which is the idling threads can start running at unpredictable times when they are woken up. This causes all sorts of problems. For example, when a thread gets here in gc_thread_function -

`if (n_heaps <= heap_number)`

if it's true it's supposed to wait. But its execution could be delayed so after it reads n_heaps it can stop for a while since no thread is waiting on this thread anyway... till some time later when a heap count changes happens again and it requires this thread to participating. And now this thread does the comparison and discovers that it needs to wait so it goes idle and all other threads will just be waiting for this thread to join.

Another example is it's not safe to change the heap count for a join from a larger one to a smaller one. It's fine to change from a smaller one to a larger one because all the threads participating will have to run in order for a join to finish. But if no one is waiting on a thread, it could just wake up from the event being set by the last thread joining and not run for a while. Then go back to the respin loop at a point where the color was changed and changed again! So now it thinks it can proceed with a join it does not belong to. And of course that wouldn't work.

The way threads are going idle/waking up is hard to keep track of - not only does it involve the gc_start_event and gc_idle_thread_event, it also uses WaitForGCEvent which is used by SuspendEE/RestartEE which in turn means whenever we want to call these we'd need to care about how that would affect this.

The new mechanism only uses gc_start_event and gc_idle_thread_event, but I changed gc_idle_thread_event to a per heap event. We can easily track which threads are going idling easily - whenever a thread is about to wait on the idle event, we increase the current idle_thread_count. And when we increase the heap count we only set the gc_idle_thread_event for the new heaps that are about to participate so we can deduct that many from idle_thread_count. There's a much simpler code path between "we know we don't need these threads anymore" to "these threads are at a known point" because the next time gc_start_event is set (ie, a GC is requested) we make sure to get these threads to a good known point, ie, we wait till all of them have completed increasing idle_thread_count.

Also fixed a couple of other problems that I hit while testing the new mechanism -

We are setting freeable_uoh_segment and freeable_soh_segment in decommission_heap to DECOMMISSIONED_REGION_P. And this causes us to simply lose the value for them. We should make sure we do push these to the free regions before we start changing the heap count.

We should also call background_delay_delete_uoh_segments before we start changing the heap count so we can get rid of the regions marked with heap_segment_flags_uoh_delete. If we allow these to be rearranged in equalize_promoted_bytes it means the order can change the invariant of the first region never being deleted no longer holds true and we can AV in this method.

I added an new method delay_free_segments to perform both tasks.

The accounting of generation_free_list_space is slightly off for LOH which causes us to hit assert (gen_size >= dd_fragmentation (dd)); in change_heap_count because we were not counting the loh_pad size.
I also disabled assert (free_list_space_decrease <= dd_fragmentation (dd)); for gen2 since I'm seeing this fired while I'm doing stress runs. I have yet to investigate this since I didn't want to add yet more changes to this PR.

* Use live illink

* Include ILLink.Tasks for subsets that depend on it

Also prevent build-native.proj from importing illink.targets.

* Address feedback

- Don't reference ILLink.Tasks from subsets
- Use PackageReference from illink.tasks
- Import props from source directory

  Add extensibility to shipping targets to make this possible.
- Set IsSourceProject false for .proj files

* Fix TFM, Configuration, PrivateAssets

* Address feedback

Avoid needing to reorganize SDK imports

* Fix typo

* Fix configuration in ToolsILLinkDir

* Don't change IsSourceProject

* Update eng/illink.targets
Co-authored-by: NViktor Hofer <viktor.hofer@microsoft.com>

* Fix tools configuration

* Normalize directory separator chars

We agreed on (at least under src/libraries) to use the Windows directory separator char `\` instead of a forward slash. This helps when looking at binlogs as those then correctly display a path.

---------
Co-authored-by: NViktor Hofer <viktor.hofer@microsoft.com>

* Remove experimental wasm arguments from template and add them to features.md

* Fix WBT

* Use lowercase host in runtimeconfig.template.json

* Override runtimeconfig only for wasmconsole

* [wasm] Add blazor startup measurement to browser-bench

New blazor-frame project is slightly modified blazor template.

The browser bench measures the starup time of the blazor-frame app
inside the iframe. It tries to load it from the `blazor-frame/index.html`
relative url. So to enable the blazor measurements, build the blazor-frame
app separately and add a link to (or copy) the published wwwroot
to the browser-bench app bundle. This will be usually handled by our
measurements infrastructure.

Also fixed responses for missing files in the simple server.

* Remove forgotten file

* Feedback

* Remove unused parts

* Fix console version

* Call ReachedManaged from Main

Upgrade our TFM to net9.0

- direct fmov for imm constants on arm64

* Remove DirectoryInfo.ToString() from ref assembly

* Remove partial keyword

Report UnknownCredentials status on Unix/Managed NegotiateAuthenticationPal implementation for NTLM w/ default credentials. (#91160)

This was handled inconsistently between the managed NTLM implementation and the GSSAPI one.
Add test for the behavior.
Add test to ensure SocketsHttpHandler using CredentialCache.DefaultCredentials with NTLM doesn't throw PNSE exception and returns the Unauthorized HTTP response instead.

Trying to get this to work for the short period till the sdk moves to
net9.0 would not be worth the effort. Failure:

```
        [] Executing (Captured Output) - /root/helix/work/workitem/e/dotnet-latest/dotnet run -c Debug -f net8.0 --no-build -  in pwd /root/helix/work/workitem/e/wbt/nonwasm_net8.0_Debug_4utlyi5x_k3s
        [] Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
```

When recording a new AOT profile for .NET MAUI apps running on Android,
we noticed that System.Reflection.Emit work was being done on a
background thread. The call seen in `dotnet-trace` output:

    11.32ms microsoft.extensions.dependencyinjection!Microsoft.Extensions.DependencyInjection.ServiceLookup.ILEmitResolverBuilder.GenerateMethodBody(Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceCallSite,System.Reflection.Emit.ILGenerator)

.NET Android apps are unique in that there is a JIT,
`RuntimeFeature.IsDynamicCodeCompiled` is true, System.Reflection.Emit
is possible -- S.R.E is however, not great for startup performance.

Starting threads on Android during startup can also be slow, as Android
will commonly put all but a single core to sleep for battery saving
purposes. We try to avoid starting threads on startup for "hello world"
applications on Android.

To solve this for now, introduce a new feature flag:

    Microsoft.Extensions.DependencyInjection.DisableDynamicEngine

Which, we will provide a value in either the Android or .NET MAUI
optional workload via an MSBuild property. To test, I put this in my
app's `.csproj` file:

    <RuntimeHostConfigurationOption Include="Microsoft.Extensions.DependencyInjection.DisableDynamicEngine"
                                    Condition="'$(DisableDynamicEngine)' != ''"
                                    Value="$(DisableDynamicEngine)"
                                    Trim="true" />

Customers *could* opt to change this flag, but we don't think it will
particularly useful. An example of services realized by .NET MAUI at
startup, via some logging added:

    08-25 13:21:55.647 16530 16530 I DOTNET  : RealizeService called: System.Collections.Generic.IEnumerable`1[Microsoft.Maui.Hosting.IMauiInitializeService]
    08-25 13:21:55.664 16530 16530 I DOTNET  : RealizeService called: System.Collections.Generic.IEnumerable`1[Microsoft.Maui.Hosting.IMauiInitializeScopedService]
    08-25 13:21:55.665 16530 16530 I DOTNET  : RealizeService called: Microsoft.Maui.Dispatching.IDispatcher
    08-25 13:21:55.668 16530 16530 I DOTNET  : RealizeService called: System.Collections.Generic.IEnumerable`1[Microsoft.Maui.LifecycleEvents.LifecycleEventRegistration]
    08-25 13:21:56.057 16530 16530 I DOTNET  : RealizeService called: System.Collections.Generic.IEnumerable`1[Microsoft.Maui.Hosting.HandlerMauiAppBuilderExtensions+HandlerRegistration]
    08-25 13:21:56.115 16530 16530 I DOTNET  : RealizeService called: Microsoft.Extensions.DependencyInjection.IServiceScopeFactory
    08-25 13:21:56.670 16530 16530 I DOTNET  : RealizeService called: Microsoft.Maui.Controls.HideSoftInputOnTappedChangedManager
    08-25 13:21:56.712 16530 16530 I DOTNET  : RealizeService called: System.Collections.Generic.IEnumerable`1[Microsoft.Maui.Hosting.ImageSourcesMauiAppBuilderExtensions+ImageSourceRegistration]
    08-25 13:21:57.700 16530 16530 I DOTNET  : RealizeService using S.R.E: Microsoft.Maui.Controls.HideSoftInputOnTappedChangedManager

`HideSoftInputOnTappedChangedManager` would be realized once per page,
which would not be a huge payoff to use S.R.E for. So the only way the
S.R.E codepath could be useful on Android would be if the customer is
registering lots of services themselves. They might be better off just
using `new()` in that case?

An example of the startup time Android reports with the new flag on/off:

    DisableDynamicEngine=false
    08-25 14:31:37.462  2090  2330 I ActivityTaskManager: Displayed com.companyname.testmaui/crc643c09abdeec717b83.MainActivity: +733ms
    08-25 14:31:39.394  2090  2330 I ActivityTaskManager: Displayed com.companyname.testmaui/crc643c09abdeec717b83.MainActivity: +737ms
    08-25 14:31:41.326  2090  2330 I ActivityTaskManager: Displayed com.companyname.testmaui/crc643c09abdeec717b83.MainActivity: +730ms
    DisableDynamicEngine=true
    08-25 14:32:20.233  2090  2330 I ActivityTaskManager: Displayed com.companyname.testmaui/crc643c09abdeec717b83.MainActivity: +724ms
    08-25 14:32:22.137  2090  2330 I ActivityTaskManager: Displayed com.companyname.testmaui/crc643c09abdeec717b83.MainActivity: +727ms
    08-25 14:32:24.042  2090  2330 I ActivityTaskManager: Displayed com.companyname.testmaui/crc643c09abdeec717b83.MainActivity: +716ms

This was a `dotnet new maui` project, using dotnet/maui/main on a Pixel
5 device.
Co-authored-by: NEric Erhardt <eric.erhardt@microsoft.com>

It was supposed to be fixed in https://github.com/dotnet/runtime/pull/90068 but we should've used `guint` for the one-bit bitfield.

Currently, we have a PMI collection of the libraries tests. A PMI collection doesn't represent actual code run, so doesn't have PGO data and compilations, OSR compilations, and tends to overemphasize generics since it attempts many instantiations that might not occur in practice.

Similar to #74961, which enabled a collection of a run coreclr tests, this change enables a collection of a run of libraries tests.

We collect two different scenarios: "normal", meaning no configuration switch variables set, and "no_tiered_compilation", meaning we set DOTNET_TieredCompilation=0. Because the amount of data collected is so large, we create each of these scenarios as a separate job, and a separate resulting .mch file. (If done all at once, we end up running out of disk space on the Azure DevOps machines that collect all the per-Helix collections and merge them into the single, large resulting .mch file.)

The changes here are similar to (and sometimes a copy of) the changes in #74961, altered because the process of running the libraries tests is somewhat different in a few ways.

The "control flow" is as follows:

- eng/pipelines/coreclr/superpmi-collect.yml: specifies two additional collection runs, as described above.
- eng/pipelines/libraries/run-test-job.yml: specifies the scenarios to run, the additional job dependencies, and adds the logic to post-process all the per-Helix-machine .mch files
- eng/pipelines/libraries/superpmi-collect-variables.yml: extract out SuperPMI-specific variables from run-test-job.yml
- eng/pipelines/libraries/superpmi-postprocess-step.yml: extract out SuperPMI post-processing steps from run-test-job.yml
- src/libraries/sendtohelix.proj: additional logic to add files needed for collection to the Helix correlation payload. In particular, we need superpmi.py (and dependencies), and superpmi/mcs/superpmi-shim-collector, as well as the JIT dll itself (which is already in the payload, but not in an easily found location). We could probably significantly trim down what we copy, as currently I just copy the entire Core_Root, which is over 1GB, and we only need 4 files.
- src/libraries/sendtohelixhelp.proj: call sendtohelix-superpmi-collect.targets, and define Helix artifacts to download to the AzDO machine.
- src/libraries/sendtohelix-superpmi-collect.targets: extract out SuperPMI specific HelixPreCommand and HelixPostCommand logic from sendtohelixhelp.proj. Define some Helix "pre" and "post" commands. The "pre" commands set up the collection before the tests are run. The "post" commands merge/dedup/thin the collection, preparing it to be uploaded to artifact storage.
- eng/testing/RunnerTemplate.cmd/sh: This is built into every libraries test RunTests.cmd/sh file, and is activated (enabled superpmi collection) by the Helix "pre" commands mentioned above.

The change to CultureInfoCurrentCulture.cs is to fix a problem where the test creates a new clean environment but copies over a few environment variables. It needs to also copy over SuperPMIShim* variables.

The collected data is quite large: about 700,000 methods in the "normal" scenario, and 300,000 in the "no_tiered_compilation" scenario, for a total of about 17GB for both.

* Restore MSVC C4244 warning code against zlib
* Restore clang implicit-int-conversion warning code against zlib

See the individual .patch files for a description of each change.

These could create TYP_ULONG/TYP_UINT indirs/LCL_FLD nodes, which are
illegal.

Fix #91174