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
Member

luhenry commented Nov 26, 2018

Depends on mono/llvm#35

mono/mini/mini-llvm.c Outdated Show resolved Hide resolved
@luhenry luhenry force-pushed the luhenry:llvm-safepoints branch from b5aac5f to 27a06af Nov 26, 2018
mono/mini/mini.c Outdated Show resolved Hide resolved
@luhenry luhenry force-pushed the luhenry:llvm-safepoints branch from 27a06af to 47518b4 Nov 28, 2018
This is to avoid safepoints to stop optimizations from happening.
@luhenry luhenry force-pushed the luhenry:llvm-safepoints branch from 47518b4 to 4150f06 Nov 28, 2018
mono/mini/mini.c Outdated Show resolved Hide resolved
@vargaz
vargaz approved these changes Nov 28, 2018
@luhenry luhenry removed the do-not-merge label Nov 28, 2018
This is to avoid safepoints to stop optimizations from happening.
@lewurm

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member 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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

lambdageek commented Jan 18, 2019

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

@luhenry

This comment has been minimized.

Copy link
Member 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

This comment has been minimized.

Copy link
Member

lambdageek commented Jan 22, 2019

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Feb 14, 2019

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

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

@vargaz

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Feb 14, 2019

Thanks @vargaz, trying that now.

@alexanderkyte

This comment has been minimized.

Copy link
Member

alexanderkyte commented Feb 21, 2019

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Feb 21, 2019

@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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Feb 25, 2019

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

This comment has been minimized.

Copy link
Member

lambdageek commented Feb 25, 2019

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 4, 2019

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

@alexanderkyte

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 4, 2019

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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 4, 2019

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

This comment has been minimized.

Copy link
Member 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

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 5, 2019

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

@luhenry

This comment has been minimized.

Copy link
Member Author

luhenry commented Mar 6, 2019

@monojenkins build failed

@alexanderkyte

This comment has been minimized.

Copy link
Member

alexanderkyte commented Mar 6, 2019

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
39 checks passed
39 checks passed
API Diff No public API changes found.
Details
Linux AArch64 Build finished. 217229 tests run, 1298 skipped, 0 failed.
Details
Linux AArch64 Coop Suspend Build finished. 217219 tests run, 1298 skipped, 0 failed.
Details
Linux AArch64 FullAOT Build finished. 21195 tests run, 554 skipped, 0 failed.
Details
Linux AArch64 FullAOT+Interpreter Build finished. 22391 tests run, 564 skipped, 0 failed.
Details
Linux AArch64 FullAOT+Interpreter+LLVM Build finished. 22391 tests run, 564 skipped, 0 failed.
Details
Linux AArch64 FullAOT+LLVM Build finished. 21195 tests run, 554 skipped, 0 failed.
Details
Linux AArch64 Interpreter Build finished. 19392 tests run, 230 skipped, 0 failed.
Details
Linux ARMv5 Build finished. 217096 tests run, 1296 skipped, 0 failed.
Details
Linux ARMv7 Build finished. 217097 tests run, 1296 skipped, 0 failed.
Details
Linux ARMv7 Interpreter Build finished. 19347 tests run, 228 skipped, 0 failed.
Details
Linux WebAssembly Build finished. No test results found.
Details
Linux i386 Build finished. 217231 tests run, 1293 skipped, 0 failed.
Details
Linux x64 Build finished. 360 tests run, 0 skipped, 0 failed.
Details
Linux x64 Acceptance Tests Build finished. 6676 tests run, 5 skipped, 0 failed.
Details
Linux x64 All Profiles Build Build finished.
Details
Linux x64 Bitcode Build finished. 5023 tests run, 135 skipped, 0 failed.
Details
Linux x64 Bitcode+Interpreter Build finished. 516 tests run, 7 skipped, 0 failed.
Details
Linux x64 C++ Build finished. 360 tests run, 0 skipped, 0 failed.
Details
Linux x64 Checked Private Types Build Build finished.
Details
Linux x64 Coop Suspend Build finished. 217224 tests run, 1292 skipped, 0 failed.
Details
Linux x64 FullAOT Build finished. 21199 tests run, 554 skipped, 0 failed.
Details
Linux x64 FullAOT+Interpreter Build finished. 22393 tests run, 564 skipped, 0 failed.
Details
Linux x64 FullAOT+Interpreter+LLVM Build finished. 22391 tests run, 564 skipped, 0 failed.
Details
Linux x64 FullAOT+LLVM Build finished. 21198 tests run, 554 skipped, 0 failed.
Details
Linux x64 Interpreter Build finished. 199183 tests run, 1167 skipped, 0 failed.
Details
Linux x64 mcs Build finished.
Details
OS X i386 Build finished. 216361 tests run, 1185 skipped, 0 failed.
Details
OS X x64 Build finished. 216364 tests run, 1186 skipped, 0 failed.
Details
OS X x64 Android SDK Build finished. 21490 tests run, 835 skipped, 0 failed.
Details
OS X x64 C++ Build finished. 216364 tests run, 1186 skipped, 0 failed.
Details
OS X x64 iOS SDK Build finished. No test results found.
Details
PR Trigger Docs Click to view available PR triggers (Xamarin internal).
Details
Project Files Diff No csproj file changes found.
Details
Windows i386 Build finished. 210104 tests run, 1109 skipped, 0 failed.
Details
Windows x64 Build finished. 210126 tests run, 1111 skipped, 0 failed.
Details
Windows x64 C++ Build finished. 210126 tests run, 1111 skipped, 0 failed.
Details
Windows x64 FullAOT Build finished. 21859 tests run, 545 skipped, 0 failed.
Details
license/cla All CLA requirements met.
Details
@luhenry

This comment has been minimized.

Copy link
Member 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
Projects
None yet
6 participants
You can’t perform that action at this time.