[webkit-dev] Using OfflineAsm

[Mark Lam]

Hi Chris,
I’ll try to answer your questions below …

> On Sep 5, 2014, at 3:23 PM, Vienneau, Christopher <cvienneau at ea.com> wrote:
> 
> Hello,
>  
> I’m looking for some information about the Java script interpreter ASM backend, aka OfflineAsm.  
>  
> First a bit of background information; the code I have been using is about a year old, on several platforms we don’t run with JIT and won’t be able to enable it.  This means that we’ve been using the LLINT_C_LOOP path in these cases.  It was considered that the ASM backend may be able to improve performance in this case, currently I’m taking a look at how things are done in a more recent snapshot of the trunk to be sure this development effort will be going in the right direction on what is done there.  As a side note I see that LLINT_C_LOOP has been replaced with #if !ENABLE(JIT) which I guess is pretty much how it has always behaved.

Yes, LLINT_C_LOOP is synonymous with !ENABLE_JIT.  The C loop is only meant as stand-in for ports that don’t want to spend the effort to get the JIT running.


> So my questions are:
> 1)      How is the ASM backend intended to be used? Is there a doc that covers this?

The code is the only documentation on this.  Some context that may help guide you in understanding how it works:

1. The “ASM" code for the interpreter is in Source/JavaScriptCore/llint/LowLevelInterpreter*.asm.
2. This ASM code is assembled using the offlineasm assembler which is a ruby program.
3. The code for the offlineasm assembler is in Source/JavaScriptCore/offlineasm.
4. At build time:
    1. LLIntOffsetsExtractor.cpp (which contains a lot of offsets that the LLINT needs) is built for the target platform.
    2. The offlineasm will parse the binary generated from step 1 for the offset values.
    3. The offlineasm will parse the LLINT ASM files plus the previously computed offsets, and emit target specific assembly code using an appropriate backend.
        See Source/JavaScriptCore/offlineasm/backends.rb for a list of current backends.
    4. The generated target specific “assembly" file (typically named LLIntAssembly.h) is assembled with the target build tools.
        For most platforms, LLIntAssembly.h contains inline assembly that is #include’d into llint/LowLevelInterpreter.cpp and built.
        On Windows, an actual ASM file is generated (not inline assembly) and is built using MASM.
    5. The built assembler is linked with the JSC VM.

> 2)      Can I essentially move from the “C LOOP” to neither “C LOOP” nor “JIT”? or is the ASM backend dependent on JIT itself?  It appears this would be handled by the defines in Source\JavaScriptCore\llint\LLIntOfflineAsmConfig.h

LLINT_C_LOOP and ENABLE_JIT are mutually exclusive.  If you want the JIT, you must support the ASM LLINT.  Once you have the ASM LLINT, you will essentially have JIT support (unless you’re working with some exotic CPU that is not currently supported).

That said, you can build the ASM LLINT and not run with the JIT.  You can set Options::useJIT() = false to only run with the LLINT.

> 3)      If JIT is expected to use the ASM backend is there a way this can be worked around?

Already answered above.

> 4)      Should I actually expect a performance increase compared to the “C LOOP”?

Yes.  The ASM LLINT should be faster than the C LOOP LLINT.

> 5)      Are there any other suggestions on how to improve performance of Java script code in a non-JIT port?

I presume options that are current supported.  The ASM LLINT is your best bet.  Alternatively, you can try optimizing the C Loop LLINT if you don’t want to tackle the ASM LLINT.  The C Loop LLINT is intended to be simple and not intended to be super optimized, but any improvements that does not come at the cost of too much added complexity is welcomed.

Regards,
Mark


>  
> Thanks for any feedback
>  
> Chris Vienneau
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140905/777a3c6b/attachment.html>