barraclough at apple.com
Wed May 27 16:53:40 PDT 2009
> I don't think so. It is not worth to do it on a desktop pc since
> interpreter is always slower than JIT. However, the story is
> different for
> embedded systems, when they enter low-memory mode.
Whilst it is certainly true that this would likely be of most benefit
on embedded platforms, we anticipate mixed-mode to be desirable on the
In addition to having the potential to providing a more memory
efficient representation than JIT code (assuming a switch to a more
compact intermediate code representation – our current bytecode is
more tuned towards performance then size), this could also be
beneficial for performance. As JS application size grows, avoiding
JIT generation for infrequently executed code (e.g. setup/
initialization code can often be run only once) may become more
important (although right now we not seeing code generation as a
significant overhead). Additionally, by running the code through the
interpreter prior to JIT generation this may give us an opportunity to
gather information to improve the quality of generated code.
> We made some
> experiments before, and it seems possible to switch between jit and
> interpreter, but I am not sure that the community is interested in
Whilst not something we have prioritized yet, it is definitely an area
of interest. If you have an implementation, even in a partially
complete state, it might be worth filing an enhancement request on the
bug tracker and attaching a patch.
>>> The last step depends on the architecture (supported or not) and C++
>>> compiler directives. If JIT is enabled (see wtf/Platform.h), it
>>> generates machine code. Otherwise an interpreter executes the byte
>>> mixed environment (both jit and interpreter) is not yet supported.
>> Are there plans for that ? Mozilla's TraceMonkey supports triggering
>> JIT execution at runtine already, iirc.
>> --Antonio Gomes
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev