... and do a GC run when it exceeds a threshold. The issue with Strings
is that they hold on to QString instances that store the real content.
However, the GC only sees the light-weight JS handle, and doesn't take
the size of the backing content into account. So it could happen that
big QStrings accumulate in the heap as long as the GC didn't reach its
threshold.
The newly introduced unmanaged heap threshold is upped by a factor of
two when exceeded, and lowered by a factor of 2 when the used heap space
falls below a quarter of the threshold. Also grow the threshold if there
is enough space after running the GC, but another GC run would be
triggered for the next allocation.
There is a special case for Heap::String::append, because this method
will copy the data from the left and right substrings into a new
QString. To track this, append notifies the memory manager directly of
the new length. The pointer to the memory manager is stored in
Heap::String, growing it from 40 bytes to 48 bytes (which makes it still
fit in the same bucket, so no extra memory is allocated).
Task-number: QTBUG-42002
Change-Id: I71313915e593a9908a2b227b0bc4d768e375ee17
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
There's many types that aren't being covered by DropArea API, such as
images. getDataAsString is not acceptable, since fromUtf8 chokes on
reading non-utf8.
This patch introduces getDataAsArrayBuffer method that won't try to convert
the data into a QString and simply pass a QV4::ArrayBuffer, that internally
keeps a QByteArray.
Change-Id: I65411b3d365ee6c5e13effd9167156771ee08a05
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Dyld will take the debug library and link it against the release
versions of the frameworks. (Using the debug versions is an option to
dyld when starting an application.) This requires all symbols in both
debug and release libraries in frameworks to be the same.
Change-Id: I6d96bcdf8577f1dffc63c508cb7adc0db2acc486
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
To protect against situations where we accidentally mark an object that belongs
to a different engine - there are many possible entry points - this patch adds
an assertion in debug builds for this situation. When it happens, it will point
more or less directly to the code that tries to push an object to the wrong JS
stack for marking. This helped in the investigation of QTBUG-44895
Change-Id: I311b9ff6d282d52e725044b03a62cd77085536be
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
On architectures where the stack grows upwards (i.e. HP PA-RISC) the
stack limit calculation fails because the variables used to check the
offset are usually close to the bottom of the stack, which is in this
case the origin of the stack grows. Since these machines are a rare
obscurity simply assume that everything is fine on these machines. The
few people that are indeed running QML on such machines will probably
be able configure their stack size properly by default.
Task-number: QTBUG-44268
Change-Id: Ia83a39179a0f6e0602ba7a5032d386e12d8d1ba3
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Don't spend any time repeatedly building the same internal class for the simple
binding functions. We can do that once at engine construction time.
Change-Id: I3777b5bd15ad4a8aaf78ae13bee27e8d8cadc2ee
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Avoid calling QMetaType::construct/destruct(typeId, ...) as that requires
repeated lookups in the type registry. Instead cache the constructor/destructor/etc.
function addresses in the QQmlValueType singletons as QMetaType
* Allocate memory for the gadget pointer lazily, to accommodate the common case of
a value type binding by property reference.
Change-Id: I98a3ac73453b8f80027c06401b4f29a9707949d2
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
ExecutionEngine performs shallow copy of internal data for ArrayBuffer
created from QByteArray.
Change-Id: I514cd9708a7fbe9a989937fac62d00b464d7362d
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Valery Kotov <kotov.valery@gmail.com>
Reviewed-by: Pasi Keränen <pasi.keranen@digia.com>
If a QChar (or char) was used to set a QString property, the
intermediate value used by the QML engine (int), would be
converted to a string representation of the integer and not the actual
character. To avoid this behavior, characters are now stored as string
objects and the string is then converted to the target char type if
possible.
A side effect of this solution is that it is makes it possible to
assign a string to a char property as well, but only if the string
contains exactly one character.
[ChangeLog][QtQml][Important Behavior Changes] Assigning a char to a
string will now create a string with the actual character instead of a
string representation of the character's code-point. A side effect of
this change is that a one-character string also can be assigned to a
character type.
Task-number: QTBUG-44934
Change-Id: Ifd15386933ee11354ee1bbb5598a5f0b00a08616
Reviewed-by: Alan Alpert (Personal) <416365416c@gmail.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Support for "arraybuffer" response type for QQmlXMLHttpRequest was
added.
[ChangeLog][QtQml][QQmlXMLHttpRequest] QQmlXMLHttpRequest now
supports "arraybuffer" binary response type.
Change-Id: I866e543cc7bc6ab037ffff1ef6628057b73daf90
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Avoid repeated instantiation of end() in loops, use variable instead.
Change-Id: I3bb1c6918cfd16a5dcefbcc03c442e99fe9bf76b
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
On FreeBSD pthread_attr_t is a pointer and is dereferenced when calling
pthread_attr_get_np() so if we don't initialize it will probably crash.
This is not a problem on glibc systems since there pthread_attr_t is an
opaque union an doesn't need to be allocated using malloc().
Change-Id: I227685ddf9981974ade08aee8917f7262c301787
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Makes more sense than storing a Value in there.
Change-Id: I2e6ca71477100c1e1639bb89cced4f4049b5e5c2
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Simplify some code in BooleanObject
Simplify access to call arguments and thisObject
Change-Id: I2f8e844019bc587385608beb02f05b15f827535c
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Remove duplicated methods. Remove some mostly unused methods,
and simplify some others.
Change-Id: I605b249e54417bb32c3dfc8e22f2c8b6b684a1e1
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Instead pass a const Value & into the functions
With our new inheritance structure, we can get rid of ValueRef
and instead simply pass a pointer to a Value again. Pointers to
Values are safe to use again now, as they are now guaranteed to
be in a place where the GC knows about them.
Change-Id: I44c606fde764db3993b8128fd6fb781d3a298e53
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Use a flagged pointer to either store a pointer to a
QV4::Value (from the persistent storage) or a pointer to
a QVariant in QJSValue::d. Like this we don't need to malloc
to create a QJSValue for most use cases.
Significantly reduces the memory consumption of QJSValue and
speeds it up a lot.
Change-Id: I10902cc4b6cc3f43d3f816875dc6c4bbb6b4490f
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Move semantics should optimize some copy operations on QJSValues,
and the internal constructor will simplify refactoring the
QJSValue class to get rid of the extra allocated private.
Change-Id: I24863b30523af2432aa81ad6b87fda7fe35749c4
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
The other classes that derive from Heap::Base don't need it
at all. So get rid of it there and save a pointer.
Change-Id: I9c5df2e43cd6eeac2e6e41f3d3b8077d3afbc8f2
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
We can move the internalClass to Object later on, and such save
having the internalClass on lots of Heap objects.
This commit basically adds and starts making use of a new
vtable pointer in Heap::Base. In addition, the construction
methods in the memory manager now automatically setup the
correct vtable.
Removing the vtable code from InternalClass and moving it into
Object will come in a separate commit
Change-Id: If49e8d73c769bf65bf47fe4dbf8b9546c8019dbc
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Use a page wise allocation mechanism for persistent
values. This significantly reduces memory consumption
of persistent values and also improves their performance
a lot.
Change-Id: I8499d2ca5bdd871e029f643ae605a94544558bb5
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Revert the flag (ie. flag == 0 means the item is used), and fold it
into the second lowest bit of the internalClass/nextFree field.
Change-Id: I7b690fdce00d16aa538fa70a269a755511477c5c
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Make public methods proper members of the ExecutionEngine, and
move private methods into the .cpp file only.
Change-Id: I3ca49e39bb1c4e559a2c63346e6ae6cfa446147d
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This completes the first milestone towards being able to move
objects across the GC heap.
Change-Id: I8e6ce90254ea767188a31f0dc85b133534c87eb0
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
We actually need to put the returned value into a ScopedFunctionObject
before calling it, as the Property could get deleted during the call
leading to a dangling pointer. With a GC that moves objects this will
become even more important.
Change-Id: I43bece6f80eb3501c1291065846e230a59ae8aed
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This is no longer required, and simply uglifies the code
Change-Id: Iba91a1d7735ebe23a43437f137a488423b6eb743
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This is the only way we can support a GC that moves
objects around in memory.
Change-Id: I1d168fae4aa9f575b730e469e762bc5b5549b886
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>