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