[Vm-dev] Amazing ARM simulator experience

Clément Bera bera.clement at gmail.com
Wed May 3 17:15:27 UTC 2017

On Wed, May 3, 2017 at 6:23 PM, Ben Coman <btc at openinworld.com> wrote:

> Hi Clement,
> On Thu, Jun 2, 2016 at 6:10 PM, Clément Bera <bera.clement at gmail.com>
> wrote:
>> On Thu, Jun 2, 2016 at 7:49 AM, Ben Coman <btc at openinworld.com> wrote:
>>> On Thu, Jun 2, 2016 at 10:19 AM, Ryan Macnak <rmacnak at gmail.com> wrote:
>>> >
>>> > I'll second that simulators are an essential tool for building a JIT.
>>> In the Dart VM, we have our own simulators for ARM, ARM64 and MIPS that
>>> allow us to test changes against all the architectures we support, locally
>>> on our x64 workstations. When we first got the VM running on iOS, we were
>>> even running the ARM simulator on the iPhone to work around the
>>> no-JITing-unless-you're-Apple policy (we have since completed an AOT mode).
>>> Although it was sluggish compared to its JIT counterpart running on
>>> Android, it was certainly usable. And given our loading code is also
>>> implemented in Dart, having simulators allows us to cross-compile AOT code
>>> for Android and iOS from x64 desktops.
>>> One thing I've been contemplating for a while, given that Sista will
>>> IIUC cache hotspot info in the Image, enabling a hot-start, would that
>>> be a reasonable workaround for Apple's no-JIT policy.  You could use
>>> unit tests to warm up Sista then code-sign the whole resultant image
>>> ??
>>> Yes and no.
>> One problem is that the sista image has optimized code in the form of
>> bytecoded method. The baseline JIT is still required to generate the
>> machine code. So the application would need a prepackaged machine code
>> zone, which is not possible without some work right now. Currently sista
>> methods are optimized to use the baseline JIT as the back-end and are not
>> optimized for the interpreter.
>> Another problem is things like inline caches that patch the machine code.
>> We would need to change that logic. One way would be to keep in the cache
>> values in a non executable memory zone, another one would be to have inline
>> cache failure never patch the code.
>> Currently the Stack VM works on iOS and the Stack VM interpreter is very
>> fast (between 10 and 20% overhead compared to the ASM template production
>> version of Java's hotspot). There are multiple solutions to boost the
>> performance on iOS using the existing infrastructure, but there is no
>> obvious way on how to make that production ready in less than
>> (optimistically) 6 months of work.
> As I bump into this in the archives and re-read it with an improved
> understanding of Sista,
> I wonder if it would be fair to expect that Sista's in-Image bytecode
> inlining would improve the performance on iOS even without JITing?

Just a detail, the performance of Sista is not only about inlining...

My experience with inlining is that closure inlining improve performance,
inlining of specific methods may improve performance if it leads to
specific patterns optimised by the VM (like smallinteger comparison
followed by a branch), but overall inlining of method does not improve the
performance significantly enough to be noticeable on Linux/Mac on modern
macbook pros (and I have a hundred benchmarks to prove this for the ones
which disagree).

The sista bytecode set is not designed for fast interpretation, but if one
design such a set (basically you need to encode the same operations but
performance critical instructions needs to be encoded in a single byte
while uncommon instructions needs to be encoded in multiple bytes), and
change the StackInterpreter to use optimisation flags it currently ignores
(like no store check for a given store), I am pretty sure you could get
some speed-up.

I guess I could provide a Sista Pharo image + VM for the ones which are
interested. Building a Sista Squeak image is possible, it worked a couple
years ago, but the Sista VM requires FullBlockClosures instead of
BlockClosures to work and currently Squeak does not feature those AFAIK.

> cheers -ben
>>> btw I got curious what exactly the policy[1] was... "Further
>>> protection is provided by iOS using ARM’s Execute Never (XN) feature,
>>> which marks memory pages as non-executable. Memory pages marked as
>>> both writable and executable can be used only by apps under tightly
>>> controlled conditions: The kernel checks for the presence of the
>>> Apple-only dynamic code-signing entitlement. Even then, only a single
>>> mmap call can be made to request an executable and writable page,
>>> which is given a randomized address. Safari uses this functionality
>>> for its JavaScript JIT compiler."
>> Ahah. "Apple-only". How fancy.
>>> [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
>>> cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170503/e11cd0f5/attachment.html>

More information about the Vm-dev mailing list