[llvm-dev] Feasibility of cling/llvm interpreter for JIT replacement (jacob navia via llvm-dev)
Stéphane Letz via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 10 09:21:53 PDT 2019
> Message: 7
> Date: Wed, 10 Apr 2019 10:21:19 +0200
> From: jacob navia via llvm-dev <llvm-dev at lists.llvm.org>
> To: LLVM Dev <llvm-dev at lists.llvm.org>, Schwartz Jean-Georges
> <jg at 4js.com>
> Subject: [llvm-dev] Feasibility of cling/llvm interpreter for JIT
> Message-ID: <6dc7cf4d-0369-151b-369a-f33148879b25 at jacob.remcomp.fr>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> Dear Sir/Madam
> Our company, 4Js software, has developed an SQL data base software that
> runs under different operating systems: Windows, Linux, Mac OS X. This
> software compiles each SQL statement into a C program that is compiled
> "on the fly" and executed by our JIT, Just In Time compiler.
> We wanted to port it to Apple's iOS, and spent a lot of time
> retargetting the JIT for supporting the ARM 64 CPU, but to our surprise,
> when everything was ready, we learned that Apple iOS forbids software to
> generate dynamically an executable.
> After several months of reflections we think we can get around this
> problem by using a C interpreter. Instead of compiling it to machine
> code, we would pass the generated C program to a C interpreter that
> would interpret the C program.
> After looking at several interpreters, we think that the llvm based
> CLING interpreter could do the job. To test these ideas, we have
> recompiled the llvm/Clang system in a small linux/ARM64 based machine.
> Our preliminary tests seem to work and cling is able to load the
> generated program.
> There are several possible problems that we see.
> The first and most obvious one is the incredible size of the CLING
> interpreter (200MB stripped). Our whole data base is 80MB stripped. We
> are targetting an Apple iPad, boosted with 1TO SSD/6GB RAM. What would
> be the minimum requirements for CLING in terms of RAM size?
> The second question is that we have still concerns over the overall
> approach. Do you see any problems with this architecture? Can it work on
> The third question concerns the feasibility of our JIT generating byte
> codes for the LLVM interpreter, boosting performance and reducing RAM
> footprint. Would that be a better solution than using the CLING
> interpreter? Is that possible within Apple's iOS?
> And yet another question is the need to modify the CLING interpreter so
> that it receives its input from a character buffer instead of a file,
> and other small tweaks. Is that possible?
> Are there any copyright issues? Are we allowed to embed the llvm
> software into our system? Of course we would publish any modifications
> done to the source code.
> We thank you in advance for any answers to the questions above.
> Yours sincerely
> Jacob Navia
> iOS Project Manager
> 4Js Software. https://4js.com
> 28 Quai Gallieni, 92150 Suresnes
More information about the llvm-dev