| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Implement the remaining AVX2 intrinsic
|
|
* Remove old reference to Rotor in documentation.
All remaining references relate to rotor's role in CoreCLR history.
* Remove rotor comment from enummem.cpp.
I can find no evidence that the presence of g_pStressLog is conditional
on FEATURE_PAL being defined.
* Remove old todo, DbgDllMain looks for thread detach.
* Update nativepipeline.h comment refernce to rotor.
All unix-like systems except android have FEATURE_DBGIPC_TRANSPORT_DI
defined, hence "most unix-like platforms".
* Update some comments to not refer to Rotor.
* Remove some more references to Rotor from comments.
* Remove old comment.
Though maybe this macro should be removed and everywhere use the & operator.
It appears there are only two places that use this macro.
|
|
* Obejct -> Object
* Oberserver -> Observer
* objetcs -> objects
* observeable -> observable
* obsolated -> obsoleted
* occour -> occur
* occurance -> occurrence
* occures -> occurs
* occuring -> occurring
* occurrance -> occurrence
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
Add MethodImplOptions.AggressiveOptimization and use it for tiering
Part of fix for https://github.com/dotnet/corefx/issues/32235
Workaround for https://github.com/dotnet/coreclr/issues/19751
- Added and set CORJIT_FLAG_AGGRESSIVE_OPT to indicate that a method is flagged with AggressiveOptimization
- For a method flagged with AggressiveOptimization, tiering uses a foreground tier 1 JIT on first call to the method, skipping the tier 0 JIT and call counting
- When tiering is disabled, a method flagged with AggressiveOptimization does not use r2r-pregenerated code
- R2r crossgen does not generate code for a method flagged with AggressiveOptimization
|
|
Add pointer overloads for Avx2.BroadcastScalarToVector256
|
|
* Improve Guid parsing performance
Significantly improves the performance of parsing all Guid number styles, primarily by avoiding using the StringToInt core helper that was used previously to parse each of the consistuent components, as well as avoiding some unnecessary searches of the strings in order to determine which format is employed.
I kept strong compatibility with the existing implementation, down to what exceptions are thrown when (even when they’re a bit strange). However, there are a few cases where the error messages in those exceptions differ from what they previously were, due to ambiguities, and IMO it not being worth making the implementation slower to try to maintain the exact same choice. For example, the string “{0xdddddddd, 0xdddd 0xdddd,{0xdd,0xdd,0xdd,0xdd,0xdd,0xdd,0xdd,0xdd}}” isn’t parsable, because it’s missing a comma between the second and third components, and with whitespace removed the parser will try to parse “0xdddd0xdddd” and fail to do so. Previously that would result in an error message “Additional non-parsable characters are at the end of the string”, and now it’ll result in an error message “Guid string should only contain hexadecimal characters.” Similarly, “(-ddddddd-dddd-dddd-dddd-dddddddddddd)” would previously fail with “Unrecognized Guid format”, and now it’ll also fail with “Guid string should only contain hexadecimal characters.”
* Undo int->uint / short->ushort field changes
* Address PR feedback
|
|
|
|
|
|
Now that IAsyncStateMachineBox is an IThreadPoolWorkItem, we can queue it directly in Task.Yield's awaiter. This makes `await Task.Yield();` allocation-free when the default scheduler is used.
|
|
|
|
* Enable delegate marshalling for collectible types
This change is trivial - it just removes checks preventing the delegate
marshalling for collectible types. The unmanaged to managed thunks are
allocated from a global LoaderAllocator and they are released when the
corresponding managed delegates are collected. So for unloadability, we
don't need to change this behavior in any way.
* Disable CoreFX tests outdated by the change
|
|
being returned (#20109)
|
|
|
|
In .NET Core 2.1, I added a bunch of optimizations to async methods that are based on reusing the async state machine object itself for other purposes in order to avoid related allocations. One of those optimizations was using the boxed state machine itself as the continuation object that could be queued onto a Task, and in the common case where the continuation could be executed synchronously, there would then not be any further allocations. However, if the continuation needed to be run asynchronously (e.g. because the Task required it via RunContinuationsAsynchronously), the code would allocate a new work item object and queue that to the thread pool to execute. This then also forced the state machine object to lazily allocate the Action delegate for its MoveNext method. This PR extends the system slightly to also cover that asynchronous execution case, by making the state machine box itself being queueable to the thread pool. In doing so, it avoids that AwaitTaskContinuation allocation and also avoids forcing the delegate into existence. (As is the case for other optimizations, this one is only employed when ETW logging isn't enabled; if it is enabled, we need to flow more information, and enabling that would penalize the non-logging case.)
|
|
CancellationTokenRegistration.Dispose is guaranteed to only return when the associated callback has already finished running or has been successfully removed such that it'll never run. This is to ensure that code following Dispose can be guaranteed that the callback isn't currently running and won't after that point, as if it did, it could potentially depend on mutable shared state or itself mutate shared state in a non-thread-safe manner.
However, significant optimizations introduced in .NET Core 2.1 impacted a specific case of this guarantee. It still behaves correctly if cancellation hasn't already been requested, if cancellation has already processed the associated callback, and even if cancellation is currently executing the associated callback. However, if cancellation is currently processing other callbacks and hasn't yet gotten around to processing the associated one, Dispose() may incorrectly return immediately, such that the callback may still end up getting invoked after Dispose() returns, which can violate assumptions of consuming code in very impactful ways.
This commit modifies how the callbacks are removed from the registration list in order to fix the issue. Previously, all of the callbacks were swapped out at once, which then left the list empty, which is what caused subsequent disposals to think the callback had already been processed or unregistered. With this change, we instead just remove each registration as it's being processed, such that a concurrent disposal can still successfully find the registration in the callback list if it's not yet been processed.
This change does have a small perf impact, but only on the case where cancellation is actually invoked, which is the less common case; most usage of CTS doesn't actually result in cancellation, and optimization is focused on registration and unregistration perf. Rather than taking and releasing the lock once when cancellation is requested, we now take and release the lock per callback when cancellation is requested.
|
|
|
|
|
|
Since a 0-length buffer is technically possible (though not very usable), have sizeOfEachElement==0 -> ByteLength == 0.
|
|
|
|
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
* Porting NumberToDouble to managed code.
* Deleting bcltype/number.cpp and bcltype/number.h
* Fixing NumberToDouble to call Int64BitsToDouble, rather than DoubleToInt64Bits
* Some minor code cleanup in NumberToDouble for better readability.
* Some additional code cleanup in the Number.NumberToDouble.cs code
|
|
TrimStart/End and avoiding unnecessary Slice. (#19959)
* Mark TrimStart and TrimEnd as Aggressively Inline to improve perf
* Remove inlining attribute and streamline Trim
|
|
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
flow (#20072)
|
|
* Move RegistryKey to shared CoreLib partition
- Cut down RegistryKey to just what CoreLib needs. I went back and forth on whether to share the corefx implementation with ifdefs or not. I have choosen to duplicate it at the end. The ifdefs were either too complex or there was too much cruft left behind that the IL linker was not able to remove.
- Move the internal CoreLib implementation of Registry to Internal.Win32 namespace to ensure that it is not confused with the public standlone one
Fixes #10741 and #17899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Ensure that the registry keys are always disposed
- Use smaller subset of registry APIs
- Reduce diffs with CoreCLR/CoreFX
- Contributes to #11009 and #17899
|
|
|
|
https://github.com/dotnet/coreclr/pull/17096 completely, which only showed modest size improvement
* Removing the _version increment from Clear() entirely to bring it in line with the behavior in Remove() and to keep size gains
[tfs-changeset: 1714543]
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
For consistency with https://github.com/dotnet/coreclr/pull/20005
|
|
|
|
Reduces diffs with CoreRT
|
|
|
|
Fix inconsistent Intel hardware intrinsic APIs
|
