Hi,
This week we're having a QtScript workshop in Oslo, primarily centered
around the research into V8.
Participants:
From QtDev Oslo: Jedrzej, Olivier, Gabriel, Kent.
From INdT, Brazil: Caio.
From University of Szeged, Hungary: Peter, Zoltan.
Here are some notes from the first day (Monday).
INTRODUCTION
- Kent gave some background on QtScript and why we're pursuing V8
- JSC public API is crippled
- Slow process of getting new API upstream
- JSC is a JS engine for WebKit, not for general-purpose JS
embedding in applications
- Zoltan: JSC development is "obsessed with SunSpider", no room for
other stuff
- V8 API is quite powerful already, project seems more open to
contributions
- Affirming the mission of the QtScript team: Make JS integration in QML
awesome
- Public C++ API has lesser importance
- We should shift the focus from compatibility tests, to QML/JS
benchmarks
- So far we haven't made changes to the QML implementation, but we
need to seriously consider that now
- Zoltan said he now has a better understanding of what we're trying
to accomplish
COMMUNICATION
- Public IRC channel #qt-script on FreeNode
- We'll only create a private channel if it's needed
- Daily status updates @ 2pm: A one-liner about what you've done /
are working on
- Weekly phone conference
- Let's try it for a few weeks and see if it's useful
- It's nice to have this "human" interaction, even if it's only to
say "Hello"
- Short update on what everyone has worked on the last week, and
plan for this week
- Longer technical discussions done after the status round, so those
not interested are free to leave
- No time slot proposed, but I suggest Mondays @ 3pm
- Make sure we have open communication with QML developers in Brisbane
(and vice versa)
- Find out more about QML plans and how they affect us [talk with
Roberto]
- Try to avoid private email; use public qt-qml@ or qt-script@
mailing lists [Kent will ask the QML developers to subscribe]
CODE REVIEWS
- Reviewing eachother's code is important and is part of our job
- Pinging on IRC or posting a patch to the mailing list is fine
- We plan to adopt the code review tool that's selected by the Qt Open
Governance project; for now we use pastebin and friends
WORKING WITH V8
- Zoltan to verify that he and Peter can sign Google's contributor's
agreement:http://code.google.com/intl/no-NO/legal/individual-cla-v1.0.html
- Those of us who are Nokia employees will create upstream V8 bugs
(http://code.google.com/p/v8/issues/list) for Peter and Zoltan to work on
- Ideally we can get rid of QtScript's V8 fork, so Szeged guys can test
with V8 bleeding edge
- Zoltan was not too concerned about the fork slowing us down,
though (we can live with the patches being private while the legal scan
is ongoing)
- We continue to update the QtScript wiki with the list of V8 bugs that
are relevant to QtScript (http://developer.qt.nokia.com/wiki/V8_Port)
- Caio expressed some concern about putting Qt-specific information in
the V8 upstream bugs
- In general, try to formulate bugs and testcases independent of Qt
- V8 developers won't care if it's written as Qt-specific
- But if those tasks are for Peter and Zoltan specifically, it makes
sense to put Qt specifics there
- If there will be many such "Qt-specific" tasks, we could consider
asking for a Qt keyword in the bug tracker
TESTING ON DEVICE
- Szeged guys have N900s, which is still the most relevant QML mobile
environment publicly available
- Kent stressed the importance of being able to run QML on such a device
to see real impact of V8 changes
AREAS WHERE SZEGED CAN START CONTRIBUTING
- Zoltan pointed to Szeged's QtWebKit build bots and
benchmarks:http://webkit.sed.hu
- Zoltan to try to get a build bot set up for QtWebKit-V8
- Zoltan would like to do benchmarking of V8 vs JSC in WebKit
- Zoltan offered to help the QML developers with using the JSC macro
assembler in the QML binding evaluator [Kent to forward contact information]
- Kent suggested that they can get involved in the Isolates work
(http://code.google.com/p/v8/issues/detail?id=510)
- My observation at the end of the day: Teaching Peter and Zoltan as
much about QML as possible will make them understand the needs placed on
QtScript/V8 much better, and likely feel more ownership of the work (as
opposed to the rest of us dumping "requirements" for V8 extensions on them)
JIT PRESENTATION
Zoltan gave a presentation about JITs, specifically comparing techniques
in JSC and V8. They're quite similar. Both are optimized for working on
integers. JSC uses 64 bits to represent JSValues, while V8 uses only 32,
which is more compact and efficient on e.g. ARM.
Zoltan suggested that we could sit down sometime during the week and
look at what kind of code V8 generates for various JavaScript input (the
V8 shell has a flag for printing the generated code).
QTSCRIPT'S V8 PATCHES
- Kent went through the API additions that we did in order to implement
existing QtScript/C++ API on top of V8
- V8::String::Hash() and V8::String::Equals()
- Wouldn't be needed for QML if we could let V8 do the hashing
itself (rather than doing it in our property interceptors)
- Patches to enable QScriptEngine::pushContext() and
QScriptContext::pushScope()
- Used by QML to create binding expression functions
- Patches to enable QScriptEngine::evaluate() to evaluate a script in
"inner-most" context
- Normal V8::Script::Compile() always compiles in global context; we
need "eval() for C++"
- A few others, but we agreed to focus on those important to QML first
QML AND JS INTEGRATION: FIRST LOOK
- Peter and Zoltan were gently (?) introduced to QML
- The two different uses of JavaScript in QML: Binding expressions, and
imported .js files
- We looked at some examples to try to understand how QML scoping works
- Nobody really knows for sure
- Pointed out that QML has its own mini-VM for handling "simple" binding
expressions
- With QtScript, binding expressions are implemented as anonymous JS
functions, where QML tracks the changed() signal of properties that are
referenced by the expression, and calls the anonymous function to
calculate the new value
- Looked at the QML import statement and explained how it's implemented
with JSC (proxying variable and function declarations to a QML-created
"static scope" object)
- The "QML object contract": No shadowing of global variables. No
properties can be added or deleted. How to communicate this to the JS
engine so it knows it's safe to make optimizations across scope chain
objects?
- Instead of implementing with-statement-in-C++-API: get rid of the with's!
- Idea: Compress the scope chain to a single object (that delegates to
the individual ones)
- Idea: Rewrite the JavaScript expression to explicitly refer to the
object where the property will be found
- We should have the QML type information to be able to determine this
BENCHMARKING
- Getting relevant benchmarks for QML/JS is perhaps our biggest
challenge right now
- Without benchmarks, we have no effective way of finding
bottlenecks, tracking progress, and comparing to Qt/master
- Help is coming from Brisbane, but not in the very short term
- Suggestion: Try to convert existing QML demos to benchmarks
- Caio will try to get us access to QML game(s) developed at INdT
- We have a (currently internal) tool, BM, for gathering, analyzing and
displaying benchmark results; should check how it differs from Szeged's
tools and learn about Szeged guys' experiences
- Olivier said that there might be a problem with the current benchmark
results because V8 is not built correctly in Qt release mode
DINNER TALK
- Jedrzej proposed his Ultimate Solution to all performance issues:
Support multiple engines, evaluate the same script in parallel, and take
the result from the engine that finishes first
- Olivier pointed out how many times we parse a binding expression
before it's executed: Once by the QML parser, once by the JSC parser to
check the syntax (again), and then a second time by the JSC parser to
actually compile the anonymous function
- Jedrzej proposed that the QML input is transformed to standard
JavaScript syntax, so that the whole thing can be passed to QtScript in
one go, rather than splitting out the binding expressions and evaluating
them one by one
- Kent argued that the fact that the QML developers invest more and more
in their own binding expression evaluator, means that the problem space
for QtScript becomes smaller (we can focus on the import-js case)
- Caio pointed out that, No, as long as there are expressions that the
QML evaluator can't handle, there will be QML applications that hit the
"worst case" (falling back to QtScript), so it still needs to be fast
- Zoltan was curious whether the usage of snapshots in V8 had
performance implications for the serialized/deserialized code (e.g.
inserting nops to ensure that there's enough space to encode pointers)
SUGGESTED FOLLOW-UP ITEMS FOR DAY 2
- Kent to fix the qt-script-v8 build (integration from Qt/master went wrong)
- Zoltan would like to see how we work on QtScript/V8 day-to-day (tools,
tests, benchmarks, etc.)
- Investigate the Qt/V8 release build issue
- See if there's an easy way to disable QML's binding expression
evaluator (so we can stress the QtScript integration)
- Running tests/declarative autotests to see what failures there are
- Explore the idea of rewriting binding expressions to include direct
references to objects (AKA "Death of with")
- Look for QML demos and examples that are candidates for creating
benchmarks
Regards,
Kent
_______________________________________________
Qt-script mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-script
