[webkit-dev] LLInt without JIT

[Gabor Rapcsanyi]

Hello!

I tried to compile JSC with LLInt CLoop backend and JIT but it didn't 
work for me. I tried it on Mac and Linux as well.
When I looked into it a little I saw some strange guards like this:

Source/JavaScriptCore/llint/LLIntOpcode.h

#if ENABLE(LLINT_C_LOOP)

#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
     macro(getHostCallReturnValue, 1) \
     macro(ctiOpThrowNotCaught, 1)

#else // !ENABLE(LLINT_C_LOOP)

#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
     // Nothing to do here. Use the JIT impl instead.

#endif // !ENABLE(LLINT_C_LOOP)


It seems if we have CLoop we don't have JIT.
So is this configuration supported anyway or we just want to use CLoop 
backend if we don't have JIT support?

Regards,
   -Gabor


> Awesome, thanks for the detailed response.
>
> I did not realize that going to the assembly backend would not produce 
> a substantial improvement.  But after you explanation, I can see the 
> reasons.
>
> I'll do some more testing to see the impact.  If I see it to 
> be worthwhile and I can fix it, I'll submit a patch, otherwise a bug.
>
>
> On Fri, Mar 8, 2013 at 11:28 PM, Filip Pizlo <fpizlo at apple.com 
> <mailto:fpizlo at apple.com>> wrote:
>
>     Yes.  You can use the assembly LLInt backend without using the
>     JIT.  That's how I was running it when I first wrote it.
>
>     I think that the code in Platform.h is being conservative, in the
>     sense that it assumes that if ENABLE(JIT) is not set then you're
>     compiling for a target that the LLInt wouldn't have a backend for.
>      This makes sense, if you think about it: ENABLE_JIT is defined to
>     1 if we detect that we are on a hardware/OS configuration that the
>     JIT knows how to handle, and the LLInt has backends for strictly
>     fewer platforms than the JIT has backends for: JIT supports x86
>     (32 and 64), ARM (traditional and THUMB2), MIPS, and SH4; while
>     the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and
>     MIPS.  In short, requiring the JIT to use LLInt assembly backends
>     is not a strong requirement of the LLInt; it's just an artifact of
>     Platform.h's logic.
>
>     On hardware/OS configurations where ENABLE(JIT) is set, and the
>     LLInt is compiled to assembly, it is still possible to run with
>     the JIT disabled. The JIT ends up being disabled at run-time in
>     that case. We often use this for testing - you can set the
>     JSC_useJIT environment variable to 'false' and then you're running
>     in a LLInt-only mode. This allows for quickly checking if a bug is
>     due to the JITs, or not.
>
>     But I would also note that the purpose of the LLInt assembly
>     backends is _not_ performance of the LLInt itself, but for
>     performance of the triple-tier system as a whole.  What those
>     assembly backends give us is the ability to run the LLInt using
>     the same ABI that the JSC JITs use; this in turn allows us to do
>     two things: (1) zero-cost OSR from the LLInt to the baseline JIT,
>     and (2) perform every JS function call assuming opportunistically
>     that the callee has been JITed; if it isn't then the machine code
>     entrypoint that the callee reports is just the shared LLInt
>     entrypoint.  That entrypoint, in turn, doesn't really have to do
>     anything special - it just loads the callee from the callee stack
>     frame, loads the bytecode pointer from the callee, and
>     indirect-jumps into the first bytecode instruction.  We wouldn't
>     be able to do either (1) or (2) easily with a C (or C++)
>     interpreter. I mean, we could do it, but JIT->interpreter calls
>     would be more expensive (because of the need to set up a C
>     interpreter stack frame). And OSR would take more effort - it
>     wouldn't be possible for the LLInt to just jump straight into
>     JITed code like it does now.
>
>     In summary, I don't expect the LLInt cloop backend to be any
>     slower than the LLInt assembly backends. Last I checked, it wasn't
>     slower. I would assume that a decent C compiler will take the
>     LLInt cloop code and do sufficient optimizations that it ends up
>     generating roughly the same assembly code that the LLInt assembly
>     backends generate. So, I wouldn't devote too much effort to
>     switching from the cloop to the assembly backends unless you had
>     evidence that (a) it would actually be faster on the benchmarks
>     you care about; or (b) you wanted to take advantage of the LLInt's
>     ability to rapidly tier-up to one of the JSC JITs. It is because
>     of (b), not (a), that JSC's triple tier configuration uses the
>     LLInt assembly backends instead of cloop.
>
>     But if you have reason to believe that the LLInt assembly backends
>     will be better for your purposes then I think all it will take is
>     hacking Platform.h appropriately. If this turns out to be hard,
>     then you should file a bug, or even better, I would love to see a
>     patch from you to improve the logic in Platform.h to make this use
>     case easier.
>
>     Hope this helps!
>
>     -Filip
>
>
>
>     On Mar 8, 2013, at 4:59 PM, Fritz Koenig <frkoenig at google.com
>     <mailto:frkoenig at google.com>> wrote:
>
>>     LowLevelInterpreter.asm is processed to create LLIntAssembly.h
>>     for the built platform.  It appears that if there is no jitting
>>     configured[1], this will always create the C Loop.
>>
>>     Is there any way of using the assembly backends to create
>>     LLIntAssembly.h when not jitting?
>>
>>     [1]: Source/WTF/wtf/Platform.h:815 /* If the jit is not
>>     available, enable the LLInt C Loop: */
>>     _______________________________________________
>>     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
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130313/b5736fe4/attachment.html>