similar to: [LLVMdev] Using MCJIT in a dynamic REPL environment

Sure, that makes a lot of sense. The implementation details may get tricky, of course, but the concept is great. -Jim On Oct 30, 2013, at 12:20 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > I'm trying to transition from the JIT to MCJIT. The requirements are fast response time and dynamic unloading/replacement of modified functions. Lazy evaluation is *not*

The new MCJIT is module-oriented, like a classic compiler+linker (which it is) while the old JIT is function-oriented. If I understand correctly, the main problems with the old JIT were the duplication of the debug information code and EH code (both gone now). Moreover, if we ignore the lazy evaluation mechanism then the current JIT is actually quite simple module. Would it be possible to keep

Hi Yaron, I think a lot of what I said in my reply to Gaël also applies to your situation. In particular, I think that it's probably best for your code to manager the function stubs and replacement. I talked last week with a developer who works on the Julia language (which shares a lot of features your situation) and it's my understanding that the Julia runtime handles function stubs

Hi Andy, I have been following Julia with interest, as it's a type-optional language designed to be as nice as dynamic languages but run at the speed of compiled C++ programs. They achieve this by deducing as many types at compile time and JITing code for the unknown types at runtime when they are known. That's a smart use of a JIT. In C++ terms it's analog to instantiating templates

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

The functionality of MCJIT vs JIT had diverged. Not only they have different operating models (lazy function vs. multi-module), the API is almost completely different. There is a set of functions just for JIT, another set of functions just for MCJIT, with comments saying which ones work for JIT and which ones work for MCJIT. It would make sense for the EE to have only the shared functionality

Yes, we've been planning to separate the execution engines for a while now, and we've made some small steps (such as breaking out the RTDyldMemoryManager interface) in preparation for doing so. There are some serious entanglements, not least of which there are MCJIT clients (LLDB, for instance) which are using memory managers derived from the JITMemoryManager. Eventually (and soon)

Hi Andrew, hi all, I already saw that the old jit was (almost) deprecated. So, I'm currently playing with the new jit and it's look very interesting. (I'm working locally and I haven't pushed anything new on VMKit because I'm also changing a little the design vmkit). For the moment, MCJIT does not work with VMKit (but I haven't yet tested the safepoint/stackmap patch), I

Hi Andy, I added the runStaticConstructorsDestructors and FindFunctionNamed functions. This also required making them virtual in EE.h. I'm not sure about FindFunctionNamed: In addition to searching finalized modules, should it search Added and Loaded modules? If it finds a Function in these, should it compile and finalize it before returning the Function* ? I modified the implementation

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but

I'm running in MCJIT a module generated from one C++ function. Every line of the source function uses C++ classes and may throw an exception. As long as there are less than (about) 1000 lines, everything works. With more lines the compiled code crashes when running it, with no sensible stack trace. Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic Linker / ELF codegen /

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit. The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader. Code model, relocation model and and memory manager are whatever default for this - did not modify. The Module comes from clang. The source is 1000 or more lines repeating C++ code in one big function: A+1; A*B.t(); where A and B are

Hi Yaron, Overall this looks great. There are a couple of remaining holes. Specifically, MCJIT inherits implementations of the FindFunctionNamed and runStaticConstructorsDestructors methods from ExecutionEngine which use the old Modules vector, so you'll need to override these in MCJIT. (The implementations are fairly trivial.) Beyond that I just have a couple of questions. First,

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have

Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows

YES, this is the problem! The program work ok, even a 5x larger version works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not

This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) >

I'm not aware of such a limitation. What architecture, code model and relocation model are you using? Are you using the SectionMemoryManager? -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Tuesday, October 22, 2013 8:12 AM To: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew Subject: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? I'm running in MCJIT a