A draft of the release notes for Mono 4.0 have been posted. Among other changes, they have started to adopt code from Microsoft’s CoreCLR project.
To be more precise, Microsoft is actually releasing their MIT licensed source code in three sets.
- ReferenceSource
- CoreFX
- CoreCLR
Since CoreCLR itself is still in flux, the Mono team is focusing on the ReferenceSource drop at this time. Their short-term goal is to replace buggy and incomplete Mono components with their .NET equivalents. You can track the progress of the effort on Trello.
In addition to the Decimal class, the following namespaces have been replaced with code from ReferenceSource:
- System.Collections
- System.Collections.Concurrent
- System.Collections.Generic
- System.Collections.Specialized
- System.ComponentModel
- System.ComponentModel.Design
- System.Diagnostic.Contracts
- System.Linq
- System.Linq.Parallel
- System.Text.RegularExpressions
- System.Runtime.CompilerServices
- System.Threading.Tasks
Assorted classes from other namespaces have also been incorporated into Mono.
Dropped Support
Mono will no longer be capable of generating assemblies that target .NET 4.0 or earlier. Only .NET 4.5 and mobile-based profiles are supported as of this version. This change has raised some concerns among those using Unity, which is currently based on an old Mono implementation of .NET 3.5.
EntityFramework is no longer being shipped “in the box”, as most users are relying on the version of EF that ships via NuGet anyways. Likewise, they are no longer shipping their own version of the Npgsql driver.
Performance Optimizations
Historically Mono defaulted to maximum precision for floating point operations. While it is safe to use 64-bit math for 32-bit floating-point operations, it can have a negative impact on performance. So there is now an option for enabling 32-bit math.
Method inlining has been improved. “We now inline copies of structures up to eight machine words, up from the previous five. Values larger than that still call memcpy to complete the operation.”
Changes have been made to the way atomic operations work as well.
All atomic methods in the framework are now recognized by the JIT as intrinsics and are inlined as specialized code on platforms that support it. This includes all methods on Interlocked and Volatile, as well as the MemoryBarrier, VolatileRead, and VolatileWrite methods on Thread.
On x86-64, Thread.MemoryBarrier is now implemented with mfence instead of lock add rsp, 0. Also, Interlocked.Exchange is now implemented with xchg [dst], val instead of the overly expensive lock cmpxchg [dst], val loop we previously emitted.
For atomic methods with acquire/release semantics, we now emit memory barriers with those semantics instead of the overly strong sequentially consistent kind.