Thanks for anwers. Can you please tell more about LLInt and is it turned on by default? On Wed, Apr 18, 2012 at 12:48 PM, Filip Pizlo <[email protected]> wrote:
> JavaScript is a dynamically typed language. Therefore, we cannot know for > sure what types of values may flow into an instruction at the time we > compile it. a + b may be an integer addition that produces an integer > result, an integer addition that overflows and produces a double, an > addition of a double to an integer, an addition of an integer to a double, > a double addition, a string concatenation, or an "object-to-value" > conversion followed by any of the previous. > > But the common case is typically going to be an integer addition or a > double addition. > > Therefore, the baseline JIT (which you seem to be looking at) has a fast > path for the common cases and a slow path for the uncommon ones. The slow > path almost always results in a C function call, which then does all of the > magic necessary to satisfy JS semantics. > > Similar things happen for almost all other JS instructions: there is a > simple path for the cases we have found to be common and a slow-path C > function call for the rare cases. > > The slow paths are emitted as a separate piece of out-of-line code because > that optimizes instruction cache locality for the main path, and helps a > bit with branch prediction. > > However, if you want to see how JSC actually makes JavaScript run fast, > you should probably also look at either the LLInt (which enables very fast > start-up by using a well-tuned threaded OSR-capable interpreter) or the DFG > (which enables high throughput for longer-running code by leveraging value > profiling to avoid having to deal with JS's dynamism in most cases). The > baseline JIT is still probably important for performance, but this is > becoming less and less true as the LLInt is likely to get faster and the > DFG is likely to expand coverage to more kinds of code (DFG still cannot > compile some functions at all due to missing opcode support). > > -F > > > > On Apr 18, 2012, at 1:39 AM, wingoog moon wrote: > > Hi! > As I understand there are two passes to translate SFX bytecode to the > native code(functions privateCompileMainPass() and > privateCompileSlowCases()). > So whats the purpose of privateCompileSlowCases(). Why we need > slow cases for each bytecodeInstruction? Is it needed when arguments of > instruction not integer or something else? > > Thanks for attention! > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
