llvm dev - Apr 2019 - Feasibility of cling/llvm interpreter for JIT replacement (jacob navia via llvm-dev)

> 
> 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
> 	replacement
> 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 
> principle?
> 
> 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
> 
> FRANCE
Would going the WebAssembly path + JavaScriptCore on iOS makes sense?

Stéphane Letz