…ease/9.0-staging

[automated] Merge branch 'release/9.0' => 'release/9.0-staging'

Backport of dotnet#112282 to release/9.0

We observed several crash reports in dotnet Android coming from
google play store, like this one:

dotnet#109921 (comment)

and it happens at the following callstack:

mono_class_setup_vtable_full at /__w/1/s/src/mono/mono/metadata/class-setup-vtable.c:900
init_io_stream_slots at /__w/1/s/src/mono/mono/metadata/icall.c:3378
ves_icall_System_IO_Stream_HasOverriddenBeginEndRead at /__w/1/s/src/mono/mono/metadata/icall.c:3437
 (inlined by) ves_icall_System_IO_Stream_HasOverriddenBeginEndRead_raw at /__w/1/s/src/mono/mono/metadata/../metadata/icall-def.h:228

Looking a little deeper at that that code path expects call to
mono_class_try_get_stream_class to succeed since it calls
mono_class_setup_vtable on returned class pointer. There are other
places where code expectes mono_class_try_get_[shortname]_class to
always succeed or it will assert. Other locations handles the case
where it returns NULL meaning that the class has been linked out.

After looking into the macro implementation generating the
mono_class_try_get_[shortname]_class functions it appears that it has
a race where one thread could return NULL even if the class successfully
gets loaded by another racing thread. Initially that might have
been intentionally and callers would need to redo the call, but then
there is no way for callers to distinct between hitting the race and
class not available. Adding to the fact that code would also expect that
some critical classes never fail loading, like what
init_io_stream_slots does, this race ended up in race conditions.

In the past, this particular race in init_io_stream_slots was hidden
due to multiple calls to mono_class_try_get_stream_class minimzing the
risk of a race to cause a crash. That implementation was however
changed by dotnet@e74da7c
ending up in just one call to mono_class_try_get_stream_class in the
critical paths.

Since code relies on mono_class_try_get_[shortname]_class to succeed
for some critical classes, code asserts if it returns NULL or crashes.
The fix will use acquire/release semantics on the static variable
guarding the cached type and make sure memory order is preserved
on both read and write. Previous implementation adopted a similar approach
but it took a copy of the static tmp_class into a local variable meaning
that memory order would not be guaranteed, even if it applied memory
barriers and volatile keywords on the static variables.

Fix also adds an assert into init_io_stream_slots since it expects
failures in calls to mono_class_try_get_stream_class as fatal.

…id. (dotnet#112373)

Backport of dotnet#112358 to release/9.0

On Android we have seen ANR issues, like the one described in
dotnet#111485. After investigating
several different dumps including all threads it turns out that we
could end up in a deadlock when init a monitor since that code path
didn't use a coop mutex and owner of lock could end up in GC code
while holding that lock, leading to deadlock if another thread was
about to lock the same monitor init lock. In several dumps we see
the following two threads:

Thread 1:

syscall+28
__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+14
NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+384
sgen_gc_lock+105
mono_gc_wait_for_bridge_processing_internal+70
sgen_gchandle_get_target+288
alloc_mon+358
ves_icall_System_Threading_Monitor_Monitor_wait+452
ves_icall_System_Threading_Monitor_Monitor_wait_raw+583

Thread 2:

syscall+28
__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+144
NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+652
alloc_mon+105
ves_icall_System_Threading_Monitor_Monitor_wait+452
ves_icall_System_Threading_Monitor_Monitor_wait_raw+583

So in this scenario Thread 1 holds monitor_mutex that is not a coop
mutex and end up trying to take GC lock, since it calls,
mono_gc_wait_for_bridge_processing_internal, but since a GC is already
started (waiting on STW to complete), Thread 1 will block holding
monitor_mutex.

Thread 2 will try to lock monitor_mutex as well, and since its not a
coop mutex it will block on OS __futex_wait_ex without changing
Mono thread state to blocking, preventing the STW from processing.

Fix is to switch to coop aware implementation of monitor_mutex.

Normally this should have been resolved on Android since we run
hybrid suspend meaning we should be able to run a signal handler on the
blocking thread that would suspend it meaning that STW would continue,
but for some reason the signal can't have been executed in this case putting the app under coop suspend limitations.

This fix will take care of the deadlock, but if there are issues running
Signals on Android, then threads not attached to runtime using
coop attach methods could end up in similar situations
blocking STW.

Co-authored-by: lateralusX <lateralusx.github@gmail.com>

…s on iOS to return -1 (dotnet#112012)

* Fix IndexOf on empty strings on iOS to return -1
* disable new test for hybrid glob on browser

…ails on WinSrv 2025 (dotnet#112473)

…um member names (dotnet#112057)

* Fix case-insensitive deserialization of default enum values

* renaming

* Update comment

---------

Co-authored-by: Pranav Senthilnathan <pranas@microsoft.com>

…rgets to inner build (dotnet#112487)

* Move generation of SuggestedBindingRedirects.targets to inner build

These targets depend on the AssemblyVersion of the library which is
specific to the inner-build of the library.  Generate them in the inner-build.

* Update src/libraries/System.Resources.Extensions/src/System.Resources.Extensions.csproj

---------

Co-authored-by: Eric StJohn <ericstj@microsoft.com>

The IL link file was getting included as unnecessary content in transitive dependent projects which caused confusion.

Fixes dotnet#112110

Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>

…tnet#112714)

When the Take amount is larger than the number of elements in the source `Iterator<T>`, Last ends up throwing an exception and LastOrDefault ends up returning the default value, rather than returning the last value in the taken region.

As part of fixing this, I sured up the tests to try to cover more such sequences of operations. In doing so, the tests got a lot slower, so I tracked down and fixed places where we were doing a lot of unnecessary work.

…ilure (dotnet#112005)

method_make_alwaysthrow_typeloadfailure replaces the entire method code with a throw of type load exception. This behaviour not only seem dubious, if it is triggered from inlining a method, that might never even get called, but it also does changes to the set of basic blocks that can lead to crashes later on during compilation.

Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

…ter (dotnet#111700)

The wrapper was relatively recently changed to icall into mono_get_addr_compiled_method in order to obtain a native function pointer to call using calli. This is incorrect on interpreter where we expect an `InterpMethod*`. This commit adds a new opcode instead, that on jit it goes through the same icall path, while on interpeter in similarly computes the appropiate method to call.

On a separate track, it might be useful to investigate whether the necessary delegate invoke wrapper should have been present in the aot image and not be executed with the interpreter in the first place.

Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>
Co-authored-by: Steve Pfister <steveisok@users.noreply.github.com>

Previously this would only include the PDB for the primary output which
missed any other additions to TfmRuntimeSpecificPackageFile - such as
those from references or packages.

Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…ificateDirectory (dotnet#112531)

* Add support for LDAPTLS_CACERTDIR \ TrustedCertificateDirectory (dotnet#111877)

* Add CompatibilitySuppressions.xml

* Remove unwanted test changes that were ported from v10

…rce that is an assembly ref (dotnet#112893)

When getting a resource where `ResourceResolve` handler returns an assembly with a manifest resource that is an assembly ref, we incorrectly resolved the reference on the original assembly instead of the assembly returned by the handler and then also looked for the resource on the original assembly again instead of using the referenced assembly.

This change includes a test for this case using IL. The manifest resource file (as opposed to assembly ref) case is already covered in libraries tests.

… local comparisons (dotnet#112539)

* JIT: fix local assertion prop error for partial local comparisons

If a JTRUE comparison only involves part of a local value we cannot make assertions
about the local as a whole.

Fixes dotnet#111352.

* restrict to TYP_LONG locals

---------

Co-authored-by: Andy Ayers <andya@microsoft.com>

…12791)

- On Windows, checking CPU utilization seems to involve a small amount of overhead, which can become noticeable or even significant in some scenarios. This change makes the intervals of time over which CPU utilization is computed configurable. Increasing the interval increases the period at which CPU utilization is updated. The same config var can also be used to disable CPU utilization checks and have features that use it behave as though CPU utilization is low.
- CPU utilization is used by the starvation heuristic and hill climbing. When CPU utilization is very high, the starvation heuristic reduces the rate of thread injection in starved cases. When CPU utilization is high, hill climbing avoids settling on higher thread count control values.
- CPU utilization is currently updated when the gate thread performs periodic activities, which happens typically every 500 ms when a worker thread is active. There is one gate thread per .NET process.
- In scenarios where there are many .NET processes running, and where many of them frequently but lightly use the thread pool, overall CPU usage may be relatively low, but the overhead from CPU utilization checks can bubble up to a noticeable portion of overall CPU usage. In a scenario involving 100s of .NET processes, it was seen that CPU utilization checks amount to 0.5-1% of overall CPU usage on the machine, which was considered significant.

…leases" (dotnet#113026)

…tegers (dotnet#113094)

…e generator (dotnet#113081) (dotnet#113150)

A balancing group can result in TransferCapture being emitted with a negative "capnum". If the compiler is running under a culture that uses something other than '-' as the negative sign, the resulting generated code will fail to compile.

…ng registers for TLS (dotnet#112549)

* Do not overwrite gcrefs masks present in reg1/reg2 fields

* Temporary use debian 10

* Revert "Temporary use debian 10"

This reverts commit 269225f.

---------

Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>
Co-authored-by: Jeff Schwartz <jeffschw@microsoft.com>

…ws (dotnet#112794)

* Stop counting work items from ThreadPoolTypedWorkItemQueue for ThreadPool.CompletedWorkItemCount (dotnet#106854)

* Stop counting work items from ThreadPoolTypedWorkItemQueue as completed work items

---------

Co-authored-by: Eduardo Manuel Velarde Polar <evelardepola@microsoft.com>
Co-authored-by: Koundinya Veluri <kouvel@users.noreply.github.com>

* Make counting of IO completion work items more precise on Windows

- Follow-up to dotnet#106854. Issue: dotnet#104284.
- Before the change, the modified test case often yields 5 or 6 completed work items, due to queue-processing work items that happen to not process any user work items. After the change, it always yields 4.
- Looks like it doesn't hurt to have more-precise counting, and there was a request to backport a fix to .NET 8, where it's more necessary to fix the issue

---------

Co-authored-by: Eduardo Velarde <32459232+eduardo-vp@users.noreply.github.com>
Co-authored-by: Eduardo Manuel Velarde Polar <evelardepola@microsoft.com>

Backport of dotnet#113280

Co-authored-by: ManickaP <mapichov@microsoft.com>

Co-authored-by: vseanreesermsft <78103370+vseanreesermsft@users.noreply.github.com>

…uild 20250223.3 (dotnet#112836)

Microsoft.CodeAnalysis.Analyzers , Microsoft.CodeAnalysis.NetAnalyzers
 From Version 3.11.0-beta1.25076.3 -> To Version 3.11.0-beta1.25123.3

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…112835)

* Update dependencies from https://github.com/dotnet/roslyn build 20250223.1

Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset
 From Version 4.12.0-3.25105.5 -> To Version 4.12.0-3.25123.1

* Update dependencies from https://github.com/dotnet/roslyn build 20250224.2

Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset
 From Version 4.12.0-3.25105.5 -> To Version 4.12.0-3.25124.2

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>

…50213.3 (dotnet#112627)

Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit
 From Version 9.0.0-prerelease.25103.3 -> To Version 9.0.0-prerelease.25113.3

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>

…ld 20250213.2 (dotnet#112552)

Microsoft.DotNet.CilStrip.Sources , System.ComponentModel.TypeConverter.TestData , System.Data.Common.TestData , System.Drawing.Common.TestData , System.Formats.Tar.TestData , System.IO.Compression.TestData , System.IO.Packaging.TestData , System.Net.TestData , System.Private.Runtime.UnicodeData , System.Runtime.Numerics.TestData , System.Runtime.TimeZoneData , System.Security.Cryptography.X509Certificates.TestData , System.Text.RegularExpressions.TestData , System.Windows.Extensions.TestData
 From Version 9.0.0-beta.25071.2 -> To Version 9.0.0-beta.25113.2

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…12.2 (dotnet#112515)

Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil
 From Version 0.11.5-alpha.25102.5 -> To Version 0.11.5-alpha.25112.2

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…112468)

* Update dependencies from https://github.com/dotnet/arcade build 20250211.5

Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XliffTasks , Microsoft.DotNet.XUnitAssert , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions
 From Version 9.0.0-beta.25077.4 -> To Version 9.0.0-beta.25111.5

* Make the workload sdk follow the sdk flow

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Larry Ewing <lewing@microsoft.com>

…ashTable; improve ginst hash function (dotnet#113316)

Backport of dotnet#113287

This change will revert to the hashtable container used for the generic instance cache in .NET 8.0 to address a performance regression introduced by changing to a different container in 9. Also improves the hash function used for the cache (the existing one was suboptimal.)

Co-authored-by: Katelyn Gadd <kg@luminance.org>

….36 (dotnet#112628)

Microsoft.SourceBuild.Intermediate.sdk , Microsoft.DotNet.ApiCompat.Task
 From Version 9.0.103-servicing.25065.25 -> To Version 9.0.104-servicing.25111.36

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>

…aging