[llvm-dev] Feasibility of cling/llvm interpreter for JIT replacement
Vassil Vassilev via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 10 03:49:53 PDT 2019
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!
> 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
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev