Re: [Mono-dev] Custom messaging provider doesn't seem to work
Not really; changes that make it to load other assemblies are also good (but _if_ that's too much, then it'd be still okay to hard code others). Atsushi Eno On 2015年01月28日 08:51, Philip Garrett wrote: On Jan 27, 2015, at 3:22 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: Hard-coded, run-time resolution to assemblies that don't exist in mono itself would be fine Are you saying that _only_ hard-coded resolution is acceptable? My intent was to allow the user to specify any type that can be resolved using an assembly-qualified name (via Type.GetType(string)). - Philip ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] NUnit versions that come with mono
Hi all, So I am having trouble understanding (and upgrading) NUnit versions that come with mono. In particular, it seems that on openSUSE mono 3.8.0 comes with NUnit 2.4.8. On the other hand, on Ubuntu mono 3.2.8 seems to come with NUnit 2.6.0. I find this to be a bit bizarre since it seems that a higher version of mono comes by default with a lower version if NUnit :). This causes portability issues with respect to NUnit and So I would appreciate if somebody could clarify these choices. In addition, I would also like to know how I could update the default version of NUnit. Is there a simple way of doing that? Thanks a lot in advance! -- View this message in context: http://mono.1490590.n4.nabble.com/NUnit-versions-that-come-with-mono-tp4665376.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re. PR 1501: Mark hot functions in the runtime.
Hello Jonathan, There seems to have been a couple of regressions on the test suite, but it is hard to read from the graph. Do we know what could have caused this? On Mon, Jan 26, 2015 at 8:45 PM, Jonathan Purdy jonathan.pu...@xamarin.com wrote: In this pull request[1] I add GCC/Clang’s “__attribute__((hot))” to various hot GC functions. This increases code size a small amount, and makes a very small improvement in performance—see the attached graph. I think actually marking some slow-path/error-handling functions as “__attribute__((cold))” would do more to improve branch prediction in cases where we haven’t marked things as “G_UNLIKELY”. [1]: https://github.com/mono/mono/pull/1501 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] llvm and mini
Hey, This has a couple of stages: - Easy, allow for re-JITing of a method (in fact, I think this is one of our interview questions) - Easy, support regular + LLVM code generation - Easy, instrument the code to track hot methods, and set a flag to do LLVM code gen - Easy, use the first and third bullet points to achieve what you want - Very hard: replace a running method with a re-JITed version, this is hard because you would need to transplant the state from one set of generated code to another one. - Very hard: hijack returns to return to re-JITed methods, has the same problem as above, but also requires some system to return to the new code. Miguel On Wed, Jan 28, 2015 at 2:19 PM, Alex Rønne Petersen a...@alexrp.com wrote: We don't have such a system in Mono. When you run `mono --llvm`, Mono will try to use LLVM for all methods. I could see a system like this being implemented based on the instrumentation functions we have in the JIT. I think the real challenge would lie in notifying the rest of the runtime/program that an already-JITed method has been re-JITed, and in a non-racy way. Regards, Alex On Wed, Jan 28, 2015 at 7:59 PM, Jerry Maine crashfou...@gmail.com wrote: I am wondering if mono could have (or already has) a feature that could use mini (the current jit) to quickly compiling code and then recompile certain critical pieces with llvm if warranted and want would it take to develop it if mono does not have it already. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] llvm and mini
We don't have such a system in Mono. When you run `mono --llvm`, Mono will try to use LLVM for all methods. I could see a system like this being implemented based on the instrumentation functions we have in the JIT. I think the real challenge would lie in notifying the rest of the runtime/program that an already-JITed method has been re-JITed, and in a non-racy way. Regards, Alex On Wed, Jan 28, 2015 at 7:59 PM, Jerry Maine crashfou...@gmail.com wrote: I am wondering if mono could have (or already has) a feature that could use mini (the current jit) to quickly compiling code and then recompile certain critical pieces with llvm if warranted and want would it take to develop it if mono does not have it already. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] llvm and mini
I am wondering if mono could have (or already has) a feature that could use mini (the current jit) to quickly compiling code and then recompile certain critical pieces with llvm if warranted and want would it take to develop it if mono does not have it already. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
