Multi-threaded safety is simply due to JIT controlling the visibility of the newly compiled code. First flush, then make it visible for execution, can't go wrong with that and scheduling won't matter.
Things get a lot more complicated when it comes to code patching, but the principle is similar.
That approach is harder to use in practice that in sounds. It's not like people have not tried it.
The OS only let you alloc in large granules, like 4k or 16k, and the vast majority of the methods are significantly smaller than that, meaning a JIT must colocate multiple methods in the same allocation block or waste a significant amount of memory.
We could get around that by remapping memory between read/write to read/execute and have the OS solve the problem for us. Except for a couple of small details, modifying a memory mapping is very expensive and we're, well, in the performance business, and that mono is multi-threaded so one thread might be executing code from the exact page we just made non-executable.
This approach, IIRC, was tried by Firefox as it has some security advantages, but discarded due to the measurable performance impact - and they don't have the second problem as JS is single threaded.
Core migration don't need to reach a global synchronization point, just enough so that the 2 cores in question agree with each other. This can be done without requiring global visibility of all operations of the source core.
Moving to a startup when under H-1B could be a very risky and possibly disastrous choice.
If those are companies that are illiterate on the most basic things, such the difference between an H-1B application and a transfer then there's a good chance they will fuck it up on the important parts.
Important things like H-1B renewal schedule, green card sponsorship, visa renewal expenses and so on.
You change jobs and the next thing you know is that you're stuck in the USA for up to 6 months because one of the overworked founders didn't apply for the renewal early enough.
The above is an easily manageable one compared to all the horror scenarios that a mismanaged H-1B immigration can be.
Maybe you'd be interested in mkbundle[1]. A tool mono has for close to a decade that allows you to bundle your app and all its dependencies into a single file.
We use it extensively at Xamarin with our platform.
Xamarin doesn't provide its products on Linux. But it doesn't mean MonoDevelop doesn't work there. The latest versions run on it, it's just a matter that we don't have the manpower to keep up with packaging.
On GTK+ 2, it's still the main toolkit used by the IDE, but on windows/mac some bits of the native toolkits are used to improve the user experience.
QT on iOS and Android means you get non-native UIX. So why bother with C++?
Mono's new gc is quite solid now. Mono for Android customers use it by default.
Yes, performance is not the best nor does it support a concurrent mode. But a garbage collector is one of those projects that is never done and always have an infinite amount of work left. Our gc has been improving a lot and the next release, for example, features a lot of scalability and performance work.
Said that, if you compare it to other gcs offered on mobile environment we're doing very well.
Mono features a much simpler JIT and runtime and this is a competitive advantage for us or do you think MS ships its desktop/server VM on winphone? We do, and it has teached us a lot about how been slim and simple makes you much more adaptable.
Now on the subject of AOT, mono features a much more sofisticated system than .net, it's the only one that supports running without a JIT while retaining generics.
BTW, I work for Xamarin but those are my personal opinions on the matter.
Plus there's no discussion against zstd itself and its container format.