BT

Mono Adopts .NET Source Code

| by Jonathan Allen Follow 578 Followers on Apr 08, 2015. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT