Mono 5.2.0 Release Notes
These notes are for a current or upcoming PREVIEW RELEASE and might not reflect the final release.
THIS IS A DRAFT/WORK IN PROGRESS PLACEHOLDER OF THE 5.2 RELEASE NOTES
- 188.8.131.52 - First Alpha Release (11 May 2017)
Strong assembly names
Mono will now optionally respect public keys and version numbers when loading strongly signed assemblies. If Mono is invoked with the
--assembly-loader=strict option, then requests (whether via a static assembly reference, or using an assembly name using the reflection API) that include a public key token and version number will only load strong named assemblies with a matching token and name (respecting any bindings in relevant app config files).
To debug the assembly loading process, set the logging environment variables to trace level “info” or lower and trace filter to include “asm”. (See Logging runtime events.)
The current default behavior is the same as in previous Mono versions. It is explicitly available with the
Experimental Default Interface Methods Support
We added experimental support for the current prototype. Check the C# specs
Multiple fixes and new intrinsics added. The library is now considered ready for general usage.
Optimized Array Stores
Added a fast path for storing on array of reference values when the stored value is of the same type of the array element type.
Class Initialization Improvements
Do hold any runtime locks while running the class initializer. This improves startup scalability.
Reduced minor collection pause times
Made the runtime tables used to store reflection information generational, so the GC can avoid scanning them during minor collections. Those tables can become significantly large on workloads like Visual Studio for Mac.
Interpreter passes the majority of the JIT test suite
Major progress was made on the interpreter front. It can now run non-trivial programs.
We continue to publish internal docs for mono, making it more convenient to browse and search the Mono runtime internals and associated documentation.
In order to holistically improve the correctness and stability of Mono, we have been investing effort in custom static analysis tooling, which will be deployed as part of our continuous build to rule out certain classes of bugs. Recently we have made progress on minimizing the amount of manual annotation work required to add new analyses, making it easier for us to verify more properties of our code.
Managed methods can include a dizzying array of attributes beyond the actual method code. The mangler encodes the attributes which are necessary to create a unique name for each method. If two methods mangle to the same string, they are the same method. This can be thought of as a primary key for each method, and extends to methods which are mono wrappers. Internally, mono is using it to build a deduplicating pass to remove binary bloat associated with generics.
The functions g_getenv and g_setenv are neither threadsafe nor reentrant. Subsequent calls to g_getenv can cause previous strings returned from it to point to garbage memory. This was leading to issues with System.Configuration that could be seen with HttpClient. Now we lock around these calls and return duplicated memory. This is a serious API change to g_getenv. The string returned must now always be freed. We don’t expect many embedders to be using the version of eglib that is linked into mono for other functions. Those who do might want to check that this change does not introduce memory leaks.
/placeholder for automatically generated list of fixed bugzilla bugs/
- 580: Type.Load loads strong type despite version mismatch (see Strong assembly names)
- 49721: Assembly binder uses wrong strongly named assembly when same assembly with different version exists in local folder (see Strong assembly names)
/placeholder for automatically generated list of contributors/