[llvm-dev] Feasibility of cling/llvm interpreter for JIT replacement

[Vassil Vassilev via llvm-dev]

Hi Jacob,

On 4/10/19 11:21 AM, jacob navia via llvm-dev wrote:
>
> 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.
>
   How do you do the strip? I have nightly releases of cling here: 
https://github.com/vgvassilev/cling/releases the release is around 23MB 
and unzipped is around 80. I am pretty sure we can strip it further down.
>
> What would be the minimum requirements for CLING in terms of RAM size?
>
   That's a hard question: running `./bin/cling ".q"` shows around 23Mb 
peak rss. `./bin/cling "#include <vector>" ".q"` shows 34 Mb and so on. 
It depends on what sort of things you will be compiling/interpreting.
>
> 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?
>
   `./bin/cling '#include <iostream>' 'printf("hello world!\n");'` 
works. Did you mean a different use-case?
>
> 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.
>
   I am not a lawyer. LLVM is licensed under a MIT-like (University of 
Illinois/NCSA) license (soon will be Apache-2.0). Cling is dual licensed 
under "UI/NCSAOSL" and "LGPL".

   Let me know if you need any further help on cling!

Best, Vassil

> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/00d8d971/attachment-0001.html>