Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[safepoint] Use LLVM pass to insert safepoint #11789

Merged
merged 13 commits into from Mar 6, 2019

Conversation

luhenry
Copy link
Contributor

@luhenry luhenry commented Nov 26, 2018

Depends on mono/llvm#35

mono/mini/mini-llvm.c Outdated Show resolved Hide resolved
mono/mini/mini.c Outdated Show resolved Hide resolved
This is to avoid safepoints to stop optimizations from happening.
mono/mini/mini.c Outdated Show resolved Hide resolved
This is to avoid safepoints to stop optimizations from happening.
@lewurm
Copy link
Contributor

lewurm commented Nov 29, 2018

To continue the example from @EgorBo from #11729:

using System;

public class Hello {
        public static void Main (string []args)
        {
                System.Console.WriteLine ("sum: " + SumUp());
        }

        public static int SumUp ()
        {
                int sum = 0;
                for (int i = 0; i < 5; i++)
                        sum += i;
                return sum;
        }
}

Before:

_Hello_SumUp:
     960:   53  pushq   %rbx
     961:   48 8b 1d 68 09 00 00    movq    2408(%rip), %rbx
     968:   48 83 3b 00     cmpq    $0, (%rbx)
     96c:   74 05   je  5 <_Hello_SumUp+0x13>
     96e:   e8 dd 00 00 00  callq   221 <plt__jit_icall_mono_threads_state_poll>
     973:   48 83 3b 00     cmpq    $0, (%rbx)
     977:   74 05   je  5 <_Hello_SumUp+0x1e>
     979:   e8 d2 00 00 00  callq   210 <plt__jit_icall_mono_threads_state_poll>
     97e:   48 83 3b 00     cmpq    $0, (%rbx)
     982:   74 05   je  5 <_Hello_SumUp+0x29>
     984:   e8 c7 00 00 00  callq   199 <plt__jit_icall_mono_threads_state_poll>
     989:   48 83 3b 00     cmpq    $0, (%rbx)
     98d:   74 05   je  5 <_Hello_SumUp+0x34>
     98f:   e8 bc 00 00 00  callq   188 <plt__jit_icall_mono_threads_state_poll>
     994:   48 83 3b 00     cmpq    $0, (%rbx)
     998:   74 05   je  5 <_Hello_SumUp+0x3f>
     99a:   e8 b1 00 00 00  callq   177 <plt__jit_icall_mono_threads_state_poll>
     99f:   48 83 3b 00     cmpq    $0, (%rbx)
     9a3:   74 05   je  5 <_Hello_SumUp+0x4a>
     9a5:   e8 a6 00 00 00  callq   166 <plt__jit_icall_mono_threads_state_poll>
     9aa:   b8 0a 00 00 00  movl    $10, %eax
     9af:   5b  popq    %rbx
     9b0:   c3  retq

LLVM unrolls the loop and can do constant folding, but doesn't understand the semantics of our safepoints and thus can't squash them together.

With this PR:

_Hello_SumUp:
     9c0:   48 83 3d 08 09 00 00 00     cmpq    $0, 2312(%rip)
     9c8:   74 0b   je  11 <_Hello_SumUp+0x15>
     9ca:   50  pushq   %rax
     9cb:   ff 15 07 09 00 00   callq   *2311(%rip)
     9d1:   48 83 c4 08     addq    $8, %rsp
     9d5:   b8 0a 00 00 00  movl    $10, %eax
     9da:   c3  retq

LLVM can be awesome. Nice work @luhenry 👍

@EgorBo
Copy link
Member

EgorBo commented Dec 10, 2018

public static unsafe int GetValue(int* n)
{
    return *n;
}

mono-luhenry generates the following IR:

define hidden monocc i32 @P_GetValue_int_(i64* nocapture readonly %arg_n) #3 gc "mono" {
BB0:
  %0 = bitcast i64* %arg_n to i32*
  %t20 = load i32, i32* %0, align 4
  %1 = load i64, i64* bitcast (i64** getelementptr inbounds ([27 x i64*], [27 x i64*]* @mono_aot_Program_llvm_got, i64 0, i64 24) to i64*), align 16
  %2 = icmp eq i64 %1, 0
  br i1 %2, label %gc.safepoint_poll.exit, label %gc.safepoint_poll.poll.i

gc.safepoint_poll.poll.i:                         ; preds = %BB0
  %3 = load void ()*, void ()** bitcast (i64** getelementptr inbounds ([27 x i64*], [27 x i64*]* @mono_aot_Program_llvm_got, i64 0, i64 25) to void ()**), align 8
  call void %3() #8
  br label %gc.safepoint_poll.exit

gc.safepoint_poll.exit:                           ; preds = %BB0, %gc.safepoint_poll.poll.i
  ret i32 %t20
}

^ temp.opt.bc (mono --aot=llvm,llvmopts="-S -O0" Program.cs)

while mono-master generates (thanks to #11554):

; Function Attrs: norecurse nounwind readonly uwtable
define hidden monocc i32 @P_GetValue_int_(i64* nocapture readonly %arg_n) #2 {
BB0:
  %0 = bitcast i64* %arg_n to i32*
  %t20 = load i32, i32* %0, align 4
  ret i32 %t20
}

Ideally it could be just:

define hidden monocc i32 @P_GetValue_int_(i32* nocapture readonly %arg_n) #3 gc "mono" {
  %0 = load i32, i32* %arg_n, align 4
  ret i32 %0
}

(i32* instead of i64*+bitcast for my int* n)

@luhenry
Copy link
Contributor Author

luhenry commented Dec 12, 2018

@EgorBo that's because the LLVM backend bypasses the optimisation we have in insert_safepoints where we discard the leaf methods.

@lewurm any guidance on where we should do it?

@EgorBo
Copy link
Member

EgorBo commented Dec 12, 2018

@luhenry I guess we can still use that optimization and just don't mark this kind of simple methods with gc "mono" - (LLVMSetGC (method, "mono")) so LLVM won't insert safepoints (if I understand it correctly)

@lambdageek
Copy link
Member

Do we still want this in its current form, @luhenry ? Looks like there's some merge conflict to resolve

@luhenry
Copy link
Contributor Author

luhenry commented Jan 22, 2019

@lambdageek if you want to take it over, that would be most useful. The latest issue is with finding the right linking strategy for gc.safepoint_poll to work for fullAOT.

@lambdageek lambdageek self-assigned this Jan 22, 2019
@lambdageek
Copy link
Member

The latest issue is with finding the right linking strategy for gc.safepoint_poll to work for fullAOT.

@luhenry you mean we have to decide which AOT image gets the safepoint function?

wouldn't we want it to have internal (static) linkage and an inline hint so that every AOT image has its own copy that is inlined at the call sites?

@alexanderkyte
Copy link
Contributor

so the crash happens because we jump to an offset in the GOT that is null.

https://gist.github.com/alexanderkyte/634c9f1f25b7eb252e4d5fb4ea3c2fcf

@vargaz
Copy link
Contributor

vargaz commented Feb 14, 2019

Not sure why that happens, I'd suggest adding it to
preinited_jit_icalls in aot-compiler.c so its initialized on startup.

@alexanderkyte
Copy link
Contributor

Thanks @vargaz, trying that now.

@alexanderkyte
Copy link
Contributor

ibrary -out:../../class/lib/net_4_x-linux/System.Web.Http.WebHost.dll  @./../../build/deps/linux_net_4_x__System.Web.Http.WebHost.dll.response
Read in 33 resources from '/mnt/jenkins/workspace/test-mono-pull-request-i386/external/aspnetwebstack/src/System.Web.Http.SelfHost/Properties/SRResources.resx'
Writing resource file...  Done.
MONO_PATH="./../../class/lib/build:$MONO_PATH" CSC_SDK_PATH_DISABLED= /mnt/jenkins/workspace/test-mono-pull-request-i386/runtime/mono-wrapper  --aot-path=/mnt/jenkins/workspace/test-mono-pull-request-i386/mcs/class/lib/build --gc-params=nursery-size=64m /mnt/jenkins/workspace/test-mono-pull-request-i386/external/roslyn-binaries/Microsoft.Net.Compilers/Microsoft.Net.Compilers.2.8.2/tools/csc.exe  /codepage:65001 /nologo /noconfig /deterministic   -d:NET_4_0 -d:NET_4_5 -d:NET_4_6 -d:MONO -d:WIN_PLATFORM -nowarn:1699 -nostdlib /debug:portable -optimize /features:peverify-compat /langversion:latest  -d:ASPNETMVC -keyfile:../winfx.pub -delaysign -r:./../../class/lib/net_4_x-linux/System.Core.dll -r:./../../class/lib/net_4_x-linux/System.dll -r:./../../class/lib/net_4_x-linux/System.Xml.dll -r:./../../class/lib/net_4_x-linux/System.Configuration.dll -r:./../../class/lib/net_4_x-linux/System.Net.Http.dll -r:./../../class/lib/net_4_x-linux/System.Runtime.Serialization.dll -r:./../../class/lib/net_4_x-linux/System.ServiceModel.dll -r:./../../class/lib/net_4_x-linux/System.IdentityModel.dll -r:./../../class/lib/net_4_x-linux/System.Web.Http.dll -r:./../../class/lib/net_4_x-linux/System.Net.Http.Formatting.dll -r:./../../class/lib/net_4_x-linux/mscorlib.dll  -sourcelink:./../../build/common/sourcelink.json  -resource:System.Web.Http.SelfHost.Properties.CommonWebApiResources.resources -resource:System.Web.Http.SelfHost.Properties.SRResources.resources -target:library -out:../../class/lib/net_4_x-linux/System.Web.Http.SelfHost.dll  @./../../build/deps/linux_net_4_x__System.Web.Http.SelfHost.dll.response

Unhandled Exception:
StackOverflowException
[ERROR] FATAL UNHANDLED EXCEPTION: System.StackOverflowException: The requested operation caused a stack overflow.
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_threads_state_poll()
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_thread_interruption_checkpoint()

Will fix

@alexanderkyte
Copy link
Contributor

@lambdageek seems a bit weird to be seeing this on the OSX desktop lane. It seems like it's definitely related to the area of the runtime that this changes though.

mono/mini/mini.c Outdated Show resolved Hide resolved
@alexanderkyte
Copy link
Contributor

Seeing some failures on MonoTests.runtime.bug-60862.exe, which generates a stacktrace. We mis-report it as being a stacktrace in unmanaged. That seems like it would happen if we do a stacktrace while we are at the top of the stack.

Cannot reproduce on OSX at all. Will attempt at home on linux machine.

@lambdageek would a safepoint triggering on an overflowing stack be correctly identified? I'm not sure what of the many types of fixes for that would be the least disruptive.

@lambdageek
Copy link
Member

would a safepoint triggering on an overflowing stack be correctly identified? I'm not sure what of the many types of fixes for that would be the least disruptive.

If you question is "can the code for a safepoint be called when the stack is overflowing"? I'm pretty sure the answer is no:

  1. it'll behave like any other pure C code stack overflow.
  2. if you call the safepoint code from the sigaltstack, (and a safepoint is needed and performed), it will be confused - the stack copying code expects a stack pointer to be in bounds for the thread.

If I had to guess, LLVM and mono's old mechanism are placing the safepoint in slightly different places with respect to the try/catch and that's somehow resulting in a stack overflow in the safepoint code instead of earlier in managed code.

@alexanderkyte
Copy link
Contributor

Difficulties reproducing on my linux desktop, but I think I have a good defensive strategy after looking over it. Will push a fix tomorrowish and see what CI finds.

@alexanderkyte
Copy link
Contributor

After some poking, I don't think I'm going to be able to prevent this without reproducing. Let me redouble my efforts and try an ubuntu VM on my linux host with the same version we use.

@alexanderkyte
Copy link
Contributor

I've been able to repro now. Looking into it.

@alexanderkyte
Copy link
Contributor

Looks like it's trying to lazily init the trampoline during the StackOverflow.

  thread #4, name = 'tid_2603'
    frame #0: 0x00007fff6c0dbd82 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff6c056724 libsystem_c.dylib`nanosleep + 199
    frame #2: 0x000000010f3c82a3 mono`monoeg_g_usleep(microseconds=1000000) at gdate-unix.c:54
    frame #3: 0x000000010ef616d9 mono`mono_handle_soft_stack_ovf(jit_tls=0x00007f9485043600, ji=0x0000000000000000, ctx=0x0000000110dc6f48, siginfo=0x0000000110dc6ee0, fault_addr="") at mini-exceptions.c:3174
    frame #4: 0x000000010ee572fe mono`mono_sigsegv_signal_handler_debug(_dummy=10, _info=0x0000000110dc6ee0, context=0x0000000110dc6f48, debug_fault_addr=0x0000700005ac5ff8) at mini-runtime.c:3365
    frame #5: 0x000000010ee57133 mono`mono_sigsegv_signal_handler(_dummy=10, _info=0x0000000110dc6ee0, context=0x0000000110dc6f48) at mini-runtime.c:3434
    frame #6: 0x00007fff6c299f5a libsystem_platform.dylib`_sigtramp + 26
    frame #7: 0x000000010f39e7e5 mono`mono_memory_write_barrier at mono-membar.h:77
    frame #8: 0x000000010f39eafb mono`mono_get_hazardous_pointer(pp=0x00007f9483f38a28, hp=0x0000000110cae648, hazard_index=1) at hazard-pointer.c:214
    frame #9: 0x000000010f1cee9e mono`jit_info_table_chunk_index(chunk=0x00007f9483f38950, hp=0x0000000110cae648, addr=0x0000000110d1c120) at jit-info.c:200
    frame #10: 0x000000010f1cdb0a mono`jit_info_table_find(table=0x00007f9483f38680, hp=0x0000000110cae648, addr=0x0000000110d1c120) at jit-info.c:222
    frame #11: 0x000000010f1cd8f6 mono`mono_jit_info_table_find_internal(domain=0x00007f9483f11e80, addr=0x0000000110d1c120, try_aot=1, allow_trampolines=0) at jit-info.c:293
    frame #12: 0x000000010ef5c78b mono`mini_jit_info_table_find_ext(domain=0x00007f9483f11e80, addr=0x0000000110d1c120, allow_trampolines=0, out_domain=0x0000000000000000) at mini-exceptions.c:1936
    frame #13: 0x000000010ef5e9a9 mono`mini_jit_info_table_find(domain=0x00007f9483f11e80, addr=0x0000000110d1c120, out_domain=0x0000000000000000) at mini-exceptions.c:1974
    frame #14: 0x000000010ef67008 mono`mini_add_method_trampoline(m=0x00007f948600c290, compiled_method=0x0000000110d1c120, add_static_rgctx_tramp=0, add_unbox_tramp=0) at mini-trampolines.c:338
    frame #15: 0x000000010ef6822a mono`common_call_trampoline(regs=0x0000700005ac6598, code="?????\x88D$\x06\x8aD$\x06\x88D$\a\x8aD$\aH\x83\U00000098\U00000088\x89D$\x10H\x8bD$\x10?", m=0x00007f948600c290, vt=0x0000000000000000, vtable_slot=0x0000000000000000, error=0x0000700005ac64c8) at mini-trampolines.c:643
    frame #16: 0x000000010ef673f8 mono`mono_magic_trampoline(regs=0x0000700005ac6598, code="?????\x88D$\x06\x8aD$\x06\x88D$\a\x8aD$\aH\x83\U00000098\U00000088\x89D$\x10H\x8bD$\x10?", arg=0x00007f948600c290, tramp="???") at mini-trampolines.c:771
    frame #17: 0x0000000110c4d393
    frame #18: 0x0000000110dbc679 bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 25
    frame #19: 0x0000000110dbc67e bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 30
    frame #20: 0x0000000110dbc67e bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 30

@alexanderkyte
Copy link
Contributor

Looks like it will break outside of init as well. Why this wasn't happening before, I'm not sure.

    frame #0: 0x00007fff6c0dbd82 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff6c056724 libsystem_c.dylib`nanosleep + 199
    frame #2: 0x000000010d6fc2a3 mono`monoeg_g_usleep(microseconds=1000000) at gdate-unix.c:54
    frame #3: 0x000000010d2956d9 mono`mono_handle_soft_stack_ovf(jit_tls=0x00007f9e99832e00, ji=0x0000000000000000, ctx=0x000000010f178f48, siginfo=0x000000010f178ee0, fault_addr="") at mini-exceptions.c:3174
    frame #4: 0x000000010d18b2fe mono`mono_sigsegv_signal_handler_debug(_dummy=10, _info=0x000000010f178ee0, context=0x000000010f178f48, debug_fault_addr=0x0000700002ce3ffc) at mini-runtime.c:3365
    frame #5: 0x000000010d18b133 mono`mono_sigsegv_signal_handler(_dummy=10, _info=0x000000010f178ee0, context=0x000000010f178f48) at mini-runtime.c:3434
    frame #6: 0x00007fff6c299f5a libsystem_platform.dylib`_sigtramp + 26
    frame #7: 0x000000010d6e0c00 mono`mono_threads_suspend_policy at mono-threads-coop.c:583
    frame #8: 0x000000010d6e0159 mono`mono_threads_is_blocking_transition_enabled at mono-threads-coop.h:81
    frame #9: 0x000000010d6dfef1 mono`mono_threads_state_poll_with_info(info=0x00007f9e99831800) at mono-threads-coop.c:123
  * frame #10: 0x000000010d6dfed1 mono`mono_threads_state_poll at mono-threads-coop.c:117
    frame #11: 0x00000001113b73d1 mscorlib.dll.dylib`wrapper_managed_to_native_object___icall_wrapper_mono_threads_state_poll + 81
    frame #12: 0x000000010f16e679 bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 25
    frame #13: 0x000000010f16e67e bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 30
    frame #14: 0x000000010f16e67e bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 30
    frame #15: 0x000000010f16e67e bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 30
    frame #16: 0x000000010f16e67e bug-60862.exe.dylib`StackOverflowTest_Program_WaitOne_bool_bool + 30

@luhenry
Copy link
Contributor Author

luhenry commented Mar 5, 2019

We are still observing the following error on iOS SDK:

duplicate symbol _gc.safepoint_poll in:
    /Users/builder/jenkins/workspace/test-mono-pull-request-amd64-osx-products-sdks-ios/sdks/ios/aot-cache/mscorlib.dll.llvm.o
    /Users/builder/jenkins/workspace/test-mono-pull-request-amd64-osx-products-sdks-ios/sdks/ios/aot-cache/I18N.dll.llvm.o
duplicate symbol _gc.safepoint_poll in:
    [...]

@alexanderkyte
Copy link
Contributor

@luhenry interesting, I hadn't been looking for that one. Looks like a static linking issue. Will fix.

@luhenry
Copy link
Contributor Author

luhenry commented Mar 6, 2019

@monojenkins build failed

@alexanderkyte
Copy link
Contributor

Looks like this should be good to merge once those two arm lanes come back.

@luhenry luhenry merged commit 6527e21 into mono:master Mar 6, 2019
@luhenry
Copy link
Contributor Author

luhenry commented Mar 6, 2019

@alexanderkyte thanks for pushing it through! :)

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Oct 9, 2019
- Use python tool.mk instead of searching more files to patch
@PYTHONBIN@ in.
- Add some preliminary ideas for how to get netbsd/aarch64 and solaris
working. it shouldn't be enough to complete a build.
(They can't use Mono's outdated libgc)

notable for us, this release re-adds FreeBSD supports.

Mono 6.4.0 release notes:
Highlights

    C# compiler support for C# 8 language version
    .NET Standard 2.1 support
    Updated libgdiplus to 6.0.2
    Notarized macOS installer package

In Depth
Runtime
Hardened Runtime and Notarization support on macOS

The Mono binary installed by the .pkg for macOS is now using the Hardened Runtime capabilities and the package was notarized to comply with Apple’s new restrictions: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution.

This allows the package to work on the upcoming macOS 10.15 Catalina without showing warning dialogs.
Interpreter improvements

The Mono interpreter was updated to support the Windows operating system.

We also completed a lot of groundwork for upcoming future optimizations in the interpreter, like constant folding.
Bitness independent AOT cross compiler

The Ahead-Of-Time (AOT) cross compiler was updated to no longer require being executed with the same bitness that it should generate code for. This means a 64bit Mono can now emit AOT code for 32bit targets.

This work was mainly done to support executing the AOT cross compiler on macOS 10.15 Catalina (which is 64bit only) as we still need to generate code for 32bit targets like older iPhone and Apple Watch devices.
WebAssembly

We continue to work on making our WebAssembly support better. Various sets of issues with the debugger have been resolved in this release and general performance and feature work is happening as well.
LLVM improvements

We now leave it up to the LLVM framework to insert safepoints. Later optimizations can understand safepoints then which leads to better generated code. See mono/mono#11789

The LLVM backend is also supported on the Windows operating system now.
PPC JIT optimizations

The PowerPC JIT received a bunch of optimization from community contributor Calvin Buckley (@NattyNarwhal).
Experimental build support for Fuchsia

A very minimal and experimental support for building Mono targeting the Fuchsia OS landed in the build system.
Class Libraries
.NET Standard 2.1 support

We updated our class libraries to support the latest additions to .NET Standard. You can now run a library compiled against the .NET Standard 2.1 specification on Mono.
CoreFX integration

We continued to replace some of our classes with the implementation from CoreFX to improve performance and compatibility with .NET.
libgdiplus update to 6.0.2

The libgdiplus native library is used for implementing System.Drawing on Unix platforms. This release contains many important improvements from our community members.

Special thanks go to Hugh Bellamy (@hughbe), Frederik Carlier (@qmfrederik) and Filip Navara (@filipnavara) for their awesome contributions!
System.Windows.Forms

More fixes and layout improvements for different controls made by external contributors have landed in this release .
Tools
C# 8 language version support in csc and msbuild

The C# compiler and msbuild tooling were updated to versions that support the final C# 8 language specification.

The Default Interface Methods (DIM) feature also received a few runtime enhancements.
NuGet

Bundled NuGet version has been upgraded to 5.2 RTM.
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Oct 18, 2019
- Use python tool.mk instead of searching more files to patch
@PYTHONBIN@ in.
- Add some preliminary ideas for how to get netbsd/aarch64 and solaris
working. it shouldn't be enough to complete a build.
(They can't use Mono's outdated libgc)

notable for us, this release re-adds FreeBSD supports.

Mono 6.4.0 release notes:
Highlights

    C# compiler support for C# 8 language version
    .NET Standard 2.1 support
    Updated libgdiplus to 6.0.2
    Notarized macOS installer package

In Depth
Runtime
Hardened Runtime and Notarization support on macOS

The Mono binary installed by the .pkg for macOS is now using the Hardened Runtime capabilities and the package was notarized to comply with Apple’s new restrictions: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution.

This allows the package to work on the upcoming macOS 10.15 Catalina without showing warning dialogs.
Interpreter improvements

The Mono interpreter was updated to support the Windows operating system.

We also completed a lot of groundwork for upcoming future optimizations in the interpreter, like constant folding.
Bitness independent AOT cross compiler

The Ahead-Of-Time (AOT) cross compiler was updated to no longer require being executed with the same bitness that it should generate code for. This means a 64bit Mono can now emit AOT code for 32bit targets.

This work was mainly done to support executing the AOT cross compiler on macOS 10.15 Catalina (which is 64bit only) as we still need to generate code for 32bit targets like older iPhone and Apple Watch devices.
WebAssembly

We continue to work on making our WebAssembly support better. Various sets of issues with the debugger have been resolved in this release and general performance and feature work is happening as well.
LLVM improvements

We now leave it up to the LLVM framework to insert safepoints. Later optimizations can understand safepoints then which leads to better generated code. See mono/mono#11789

The LLVM backend is also supported on the Windows operating system now.
PPC JIT optimizations

The PowerPC JIT received a bunch of optimization from community contributor Calvin Buckley (@NattyNarwhal).
Experimental build support for Fuchsia

A very minimal and experimental support for building Mono targeting the Fuchsia OS landed in the build system.
Class Libraries
.NET Standard 2.1 support

We updated our class libraries to support the latest additions to .NET Standard. You can now run a library compiled against the .NET Standard 2.1 specification on Mono.
CoreFX integration

We continued to replace some of our classes with the implementation from CoreFX to improve performance and compatibility with .NET.
libgdiplus update to 6.0.2

The libgdiplus native library is used for implementing System.Drawing on Unix platforms. This release contains many important improvements from our community members.

Special thanks go to Hugh Bellamy (@hughbe), Frederik Carlier (@qmfrederik) and Filip Navara (@filipnavara) for their awesome contributions!
System.Windows.Forms

More fixes and layout improvements for different controls made by external contributors have landed in this release .
Tools
C# 8 language version support in csc and msbuild

The C# compiler and msbuild tooling were updated to versions that support the final C# 8 language specification.

The Default Interface Methods (DIM) feature also received a few runtime enhancements.
NuGet

Bundled NuGet version has been upgraded to 5.2 RTM.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants