[Vm-dev] Amazing ARM simulator experience

Ben Coman btc at openinworld.com
Wed May 3 16:23:05 UTC 2017

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?

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/20170504/2ddf1208/attachment-0001.html>

More information about the Vm-dev mailing list