[webkit-dev] Replacing the JSC classic C++ interpreter with a llint generated C++ interpreter

[Thiago Marcos P. Santos]

On Thu, Sep 6, 2012 at 11:02 PM, Mark Lam <mark.lam at apple.com> wrote:
> As part of an effort to simplify future development, the JSC team is
> deprecating the classic C++ interpreter (and will delete it shortly on Sept
> 24).  In its place, we will use the LLINT (low level interpreter) with the
> C++ back-end (see https://bugs.webkit.org/show_bug.cgi?id=91052) to generate
> a llint C++ interpreter for new ports that do not support the JITs yet.
>
> In order to deprecate the classic C++ interpreter, we will need your help to
> convert your ports to use the llint (if you are using JSC for your port).  I
> will lay out some details below on how this conversion works:
>
>
> Why deprecate the classic C++ interpreter?
> =================================
> The llint is where active development will take place as we add new JIT and
> runtime enhancements.  Having the classic C++ interpreter around only slows
> down the development effort.  The classic C++ interpreter is also prone to
> experience bit-rot, and hence will easily get buggy over time.
>
>
> How will you bring up a new platform without the classic C++ interpreter?
> ========================================================
> You will have to add the llint offline ASM build phase to generate the llint
> C++ interpreter (see below for details on the llint offline build phase).
> Alternatively, you can generate the llint C++ interpreter on a port that
> already supports it, and use the generated LLIntAssembly.h from there to
> bootstrap your port.  It is preferred that every port supports the llint
> natively because this will enable you to get the latest bug fixes and
> performance enhancements.
>
>
> What is the performance of the llint C++ interpreter?
> ========================================
> The performance of the new llint C++ interpreter is currently slower than
> the classic C++ interpreter, but within approximately 10% on average.  The
> goal of the llint C++ interpreter is not to achieve the highest performance,
> but to provide a functional C++ interpreter to help bootstrap new ports.  As
> such, we don't plan to spend a lot of time on optimizing it.
>
> sunspider results:
>                    classic C++ interpreter       llint C++ interpreter
> <arithmetic> *     18.3123+-0.1593          !    18.6551+-0.1095        !
> definitely 1.0187x slower
>
>
> v8-real results:
>                    classic C++ interpreter       llint C++ interpreter
> <geometric> *      15.31772+-0.22338        !    16.92580+-0.09735      !
> definitely 1.1050x slower
>
>
> How is the llint built?
> ================
> Here's a summary of the steps:
>
> Step 1: Generate LLIntDesiredOffsets.h
>
> mkdir -p "${BUILT_PRODUCTS_DIR}/LLIntOffsets/"
>
> /usr/bin/env ruby "${SRCROOT}/offlineasm/generate_offset_extractor.rb"
> "${SRCROOT}/llint/LowLevelInterpreter.asm"
> "${BUILT_PRODUCTS_DIR}/LLIntOffsets/LLIntDesiredOffsets.h"
>
> Step 2: Build LLIntOffsetsExtractor from LLIntDesiredOffsets.h (from step 1)
> and Source/JavaScriptCore/llint/LLIntOffsetsExtrator.cpp using the
> cross-compiler for your target.
>
> LLIntOffsetsExtractor is supposed to be an executable binary for your target
> port.  However, we will only be using it to extract offsets that we need for
> the next step, and won't be running it.
>
> Step 3: Generate LLIntAssembly.h
>
> /usr/bin/env ruby JavaScriptCore/offlineasm/asm.rb
> JavaScriptCore/llint/LowLevelInterpreter.asm
> ${BUILT_PRODUCTS_DIR}/JSCLLIntOffsetsExtractor LLIntAssembly.h || exit 1
>
> LLIntAssembly.h provides the body of the interpreter, and will be #included
> in Source/JavaScriptCore/llint/LowLevelInterpreter.cpp to be built into JSC.
>
>
> How to get JSC to build with the llint C++ interpreter?
> ========================================
>
> In Platform.h (or equivalent), set the following settings:
>
> #define ENABLE_JIT 0
> #define ENABLE_LLINT 1
> #define ENABLE_CLASSIC_INTERPRETER 0
>
> This combination of settings will ENABLE(LLINT_C_LOOP) which builds the
> llint C++ interpreter.  Eventually, ENABLE_CLASSIC_INTERPRETER won't be
> needed when the classic C++ interpreter gets deprecated and deleted.
>
>
> What do you need to do for your port?
> =============================
> The Mac port already works with the llint.  I'm planning to fix the Windows
> port to also work with the llint.  On Sept 24, we plan to delete the classic
> C++ interpreter.  This means your port will cease to build if you are still
> relying on the classic C++ interpreter then.
>
> Please look into migrating your port to use the llint C++ interpreter (if
> not the Assembly one) within the next few weeks.  If you encounter issues
> and need some help getting the llint to work for your port, please feel free
> to contact me.  I will do my best to help you out.

The work for CMake-based port is being done here:
https://bugs.webkit.org/show_bug.cgi?id=92682

Cheers,