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@lists.llvm.org>
To: LLVM Dev <llvm-dev@lists.llvm.org>, Schwartz Jean-Georges
Subject: [llvm-dev] Feasibility of cling/llvm interpreter for JIT
Message-ID: <6dc7cf4d-0369-151b-369a-f33148879b25@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


Would going the WebAssembly path + JavaScriptCore on iOS makes sense?

Stéphane Letz