Don't use recursive function calls anymore. Instead, push marked
objects onto the JS stack, and then pop them off when their children
are being marked.
Should reduce stack memory usage, and improves performance by ~5%.
Change-Id: I2d37d97579144fcba87ec8e9fd545dd220c01fbb
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This class is not required anymore to generate stack traces, as
we now store the required information in the JS context stack.
Change-Id: I3893c805ca89dda70efde07fdd120e7dfaf3639f
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Run the binding expressions, functions and signal handlers through
the V4 codegen _per_ component, and run the isel at the end for the
entire file. We need to do per-component codegen because we want to
set up the correct id and object scopes, which are different for the
root component and anonymous components.
* Changed V4IR::Module to allow for the concept of "qml modules" where
there is no root function defined. This is a logical consequence of
running v4 codegen multiple times with different input but the same
V4IR::Module.
Change-Id: Ib3a719f83507cbab7c2e4e145ccad5b663c795cf
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This can (and does crash) when a gc gets triggered during the
linking stage of a compilation unit.
Change-Id: I06f1299adab68ff8e0a4755d02e246870797e7f2
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Now that we store them per QML file, they live in the type cache and
can outlive the engine. Therefore the engine needs to free to unlink
any remaining units upon destruction. This needs to be done after the
"death" of the memory manager, which is likely to sweep away any
function objects that also hold a reference to the compilation units.
Change-Id: I3968d5995289e8d2bc1e3abbb1f8be88a0ab4e03
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Don't crash when a CompilationUnit is created, never linked into an engine but instead
deleted (because there was an error elsewhere compililing the rest of QML
before it could reach the link-to-engine stage)
Change-Id: Iff535009b6b4d1fc4004987c98730251a3a7d8d8
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Surround all calls into generated code with a
try {} catch {} statement that resets the jstack
to the correct position.
Like this we properly unwind the js stack in all cases, and
can also use stricter assertions in our ScopedCallData, etc.
classes to check that the stack is healthy.
Change-Id: I7ca03e06ea55007be683305d9c2a6898cf5fc689
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This is needed for QML unit generation, when we share the JS generator
for QML types/strings and JS code.
Change-Id: I50f0c1fa6721d6e3e59417c6c256c82aec124e8f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Rather use the correct internalClass directly when constructing
the objects.
Change-Id: I8e916f1ce8f83d291c08ca6332fe85b1f57b90b5
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
The prototype is actually the same for most objects. By
moving it into the internal class, we can save 8 bytes
per object, as well as allowing for some future
optimizations.
Also fix a bug in the implementation of the Error
prototype objects.
Change-Id: I4d4b641055f644a9b088f27be34bfdb0446279b7
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
At the moment we collect a lot of compilation units (one per binding
expression!), which for long running QML accumulates and creates a horrible
performance when trying to retrieve back traces. There is work in progress
to reduces the number of units down to one per QML file, and then the
fixed sorted QVector might proof to be a more efficient data structure
for the lookups.
But until that code lands, this patch proposes to use a QMap instead for the
time being, that tracks all functions. This brings down the qtquickcontrols
auto-test run from 2.5 minutes to just under a minute on my machine.
Change-Id: I45bf609055877081daa984de90f291a030f2f24f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
It may happen that a dynamically created compilation unit disappears before any
QV4::Strings it created. Those strings would still have a reference to the
QString data in the compilation unit. I don't see a choice other than making a
copy of the string data ;(. But this patch adds a flag that would allow for
avoiding it if we happen to know that the compilation unit data is static.
Change-Id: Ib35a4d2a566b301a25ffe56e392809e44e7b4ae8
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Runtime strings are identifiers, but they still require to be marked. Keep
track of all compilation units in the engine (one per file) and mark its
run-time strings.
Change-Id: Ie70b00dfa373c4567279591de2f717e8103c288f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Keep the run-time functions as-is by taking String pointers and use a little
bit of inline assembly to resolve the string ids to string pointers, by
adding a runtimeStrings array pointer next to the lookups in the context
(similar mechanism).
Change-Id: Ib5a70bdf47fef7c447d646ccfe03f3dc30d39f20
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Change-Id: I172a504f8b4f8284967a4a02e207bf4c0a04c2a4
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Lars Knoll
Erik Verbruggen
Simon Hausmann
Giuseppe D'Angelo