Current XPIDL native arrays currently also require a custom entry point. With
the new arraylen parameter we can handle them in JSData2Native/NativeData2JS. As
these methods are more complex and don't share logic with an existing codepath,
I keep them in external helper methods.
XPIDL supports explicitly sized string types. These types currently have to be
handled by a separate entry point into XPCConvert, and don't share any logic
with the implicitly sized string types.
If we just add an array length parameter to the basic JSData2Native and
NativeData2JS methods we can handle them in the same place as every other type.
This also allows us to share a lot of code with non-sized string types, which is
nice :-).
When a jsval passed from JS code it needs to be stored in a nsXPTCVariant
object. This object is not rooted by default, as it is stored in some
C++-allocated memory. Currently, we root the values by adding a custom root
using the `js::AddRawValueRoot` API, which is deprecated, and only used by this
code and ErrorResult.
This also has the unfortunate effect that we cannot support XPCOM arrays of
jsvals, as we cannot root all of the values in the array using this API.
Fortunately, the JS engine has a better rooting API which we can use here
instead. I make the call context a custom rooter, like the SequenceRooter type
from WebIDL, and make sure to note every jsval when tracing, both in arrays and
as direct values.
This should allow us to avoid some hashtable operations with roots when
performing XPConnect calls, and remove a consumer of this gross legacy API.
In addition it allows us to support arrays. This will be even more useful in the
future when I add support for sequence<T> (which is a nsTArray<T>) to xpidl and
xpconnect.
In XPConnect, native values are passed around within nsXPTCMiniVariant objects.
an [nsXPTCMiniVariant] contains 64-bits of data in a union type.
nsXPTCMiniVariant values are created by the platform-specific glue code and
passed into XPConnect proper when calling from C++ into JS.
When calling from JS into C++, we instead create nsXPTCVariant objects and pass
them into the glue code. These objects have extra information in addition to the
nsXPTCMiniVariant: namely they also have a `type` field with the type stored in
the variant, space for flags, and a `ptr` field which is passed over IPC instead
of the inner nsXPTCMiniVariant when a flag (`PTR_IS_DATA`) is set.
The JSValue type in XPConnect is always passed as a pointer to a JSValue object,
both for in parameters and out parameters. This is handled by making the JSValue
type be unconditionally flagged as [`IsIndirect()`] This flag is also used for
all types of outparameters.
When the `IsIndirect()` flag is set, it means that the actual data is stored in
the nsXPTCVariant's val field, and it sets the flag to tell the glue code to
instead pass the `ptr` field (which is always pointing to the `val` field for
[legacy reasons]) into the C++ code.
In contrast "dipper" is a different and super weird flag. Currently only the
string class types (nsACString & nsAString) are marked as "dipper". A "dipper"
type is always passed as an "in" type (and thus always passed "directly"), even
when it's actually an out parameter.
XPConnect treats these types as though they are pointer types (nsAString*). This
means that there is no space in the nsXPTCVariant to store the actual nsAString
types when passing from JS into C++, so these values have to be allocated by a
different mechanism (in the current code, there is a size 2 buffer for each
string type in the context and once that buffer is exceeded, we heap allocate
the nsString values).
In effect, the current state looks something like this:
+------------+---------------------+---------------------+
| type | out (xpt/native) | in (xpt/native) |
+------------+---------------------+---------------------+
| TD_INT32 | indirect (int32_t*) | direct (int32_t) |
+------------+---------------------+---------------------+
| TD_JSVAL | indirect (JSValue*) | indirect (JSValue*) |
+------------+---------------------+---------------------+
| TD_ASTRING | direct (nsAString*) | direct (nsAString*) |
+------------+---------------------+---------------------+
This patch ensures there is enough space in the nsXPTCVariant to fit the
nsString value, and switches string class types to being unconditionally
indirect instead of using the dipper system. This allows us to delete a ton of
dipper-specific code, and unify the indirect and string class codepaths.
This only affects the size of nsXPTCVariant objects, and does not affect
nsXPTCMiniVariant objects. nsXPTCVariant objects are never allocated by the
platform-specific binding code, rather, they are allocated in an AutoTArray on
the stack as part of the CallMethodHelper object.
The size increase is a total of 1 word, so 4 bytes in 32-bit builds, and 8 bytes
in 64-bit builds, which is ignorable for stack allocated objects.
[nsXPTCMiniVariant]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#20-47
[`IsIndirect()`]: https://searchfox.org/mozilla-central/rev/c0d81882c7941c4ff13a50603e37095cdab0d1ea/xpcom/reflect/xptinfo/xptinfo.h#371
[legacy reasons]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#66-79
It used to be that in XPConnect there were many different pieces of code for
each place where we may need to clean up some untyped values based on their
nsXPTType information. This was a mess, and meant that every time you needed to
add a new data type you'd have to find every one of these places and add support
for your new type to them.
In fact, this was bad enough that it appears that I missed some places when
adding my webidl support! Which means that in some edge cases we may clean up
one of these values incorrectly D:!
This patch adds a new unified method which performs the cleanup by looking at a
nsXPTType object. The idea is that this function takes a void* which is actually
a T* where T is a value of the nsXPTType parmaeter. It clears the value behind
the pointer to a valid state such that free-ing the memory would not cause any
leaks. e.g. it free(...)s owned pointers and sets the pointer to `nullptr`, and
truncates nsA[C]String values such that they reference the static empty string.
I also modify every one of these custom cleanup codepaths to instead call into
this unified cleanup method.
This also involved some simplification of helper methods in order to make the
implementation cleaner.
We actually don't want to allow aliased array buffers at all, so this
removes the ref argument from JS_NewExternalArrayBuffer() and renames
"unref" to "free".
Adjusts some comments, and also adds tests to make sure buffers are not
aliased when cloning.
For x86(32), BaseCompiler::load() loads indirectly via the scratch reg (ebx)
when the data size is 8 bits and the eventual destination is esi or edi.
This is pointless because the actual load created by |masm.wasmLoad(*access,
srcAddr, out);| is a mov{s,z}bl instruction and so is unconstrained as to
the output register. This patch removes the indirection.
--HG--
extra : rebase_source : 55131b8b582fbde287b993f5aefa01730e6b42cf
Bug 1446930 added a basic implementation of Wasm memory.copy/fill, and
tests. Unfortunately, as-is the tests run on all branches but the
implementation is ifdef'd so as only to be compiled into Nightly (as
present), which will cause breakage on Beta. This patch fixes the tests by
conditionalising them in the same way that tests for other experimental Wasm
features have been conditionalised.
--HG--
extra : source : 98b2e9629ed4b831876b66299d59d4ef85e2b406
Bug 1446930 added a basic implementation of Wasm memory.copy/fill, and
tests. Unfortunately, as-is the tests run on all branches but the
implementation is ifdef'd so as only to be compiled into Nightly (as
present), which will cause breakage on Beta. This patch fixes the tests by
conditionalising them in the same way that tests for other experimental Wasm
features have been conditionalised.
--HG--
extra : rebase_source : 160ad70799ac79f7ba660c371cb46585bd144d04
The name Cpp was confusing, because C++ functions are in the native stack, not
in the pseudo stack. The pseudo stack only contains frames for manually
instrumented code that uses AutoProfilerLabel, and JS frames.
MozReview-Commit-ID: 9ptfhREo0qy
--HG--
extra : rebase_source : 76a1a32acb4c946aeb2ad45e904e419c1c9e2ad1
For some reason, the CC spends a lot of time tracing jsids on
ObjectGroups when an addon is installed. This patch avoids that by
adding a canSkipJsids flag to JSTracer, and using it in
ObjectGroup::traceChildren. If this is true, then the tracer is free
to not report every jsid. This flag is set to true for the two CC
tracers.
MozReview-Commit-ID: CWFqQEr0SxV
--HG--
extra : rebase_source : cc31c22717f8990166454db191e0d40c145e09f0
The propid is a jsid, and a jsid can never be anything the CC cares
about, so there's no reason to trace it. In at least one profile of
Google Inbox, tracing shape propids is taking the majority of time in
the CC and causing very long pauses.
MozReview-Commit-ID: HcjnawBHLx1
--HG--
extra : rebase_source : 3682b2ac84752b200be780401059c2907dc7d6af
This option does nothing if it's provided, and things will probably
break in some most peculiar manner if somebody uses --without-pthreads.
Given that neither outcome is useful, we should remove the option.
This should be somewhat more efficient, and will make it easier for me to make
a future change to add some additional paths.
It also removes the unused |filename| variable from |get_command|.
This is somewhat simpler, and yields a clearer error message if the file can't
be opened. (In this case, an exception is thrown before |fp| is defined, and
the |fp.close()| call then throws another exception, hiding the first one.)
This will have its behavior defined by ECMA-402 in the future; for now,
it returns the same result as the toString method (which is permitted by
the BigInt spec).
This rephrases the stub field code in terms of a policy type.
--HG--
extra : rebase_source : 61a2cea84cde95eb3391c2a009ea6dafe9d7a15a
extra : amend_source : eb7fdc1095e47600ddd9a6caebfa91cf47a4346d
This patch:
(1) renames the NumericPrefix top level encoding byte to MiscPrefix, as
somewhat vaguely implied by
https://github.com/WebAssembly/bulk-memory-operations/issues/9, and uses
the value 0xFC for it.
(2) installs the memory.copy/fill encodings as secondary opcodes of
MiscPrefix, with values 0x40 and 0x41 respectively. The 0x40 and 0x41
values are our own choice and haven't yet been agreed more broadly.
This isn't entirely simple, because the uses of 'enum class NumericOp'
(which is renamed MiscOp) now have to be divided into two different
ifdef-guarded sections, rather than being an all-or-nothing thing. As a
result, a number of switches that previously looked like this
case uint16_t(Op::NumericPrefix): {
#ifdef ENABLE_WASM_SATURATING_TRUNC_OPS
switch (op.b1) {
case uint16_t(NumericOp::I32TruncSSatF32):
case uint16_t(NumericOp::I32TruncUSatF32):
default:
return iter.unrecognizedOpcode(&op);
#else
return iter.unrecognizedOpcode(&op);
#endif
}
first have to be rearranged like this
case uint16_t(Op::NumericPrefix): {
switch (op.b1) {
#ifdef ENABLE_WASM_SATURATING_TRUNC_OPS
case uint16_t(NumericOp::I32TruncSSatF32):
case uint16_t(NumericOp::I32TruncUSatF32):
#endif
default:
break;
}
return iter.unrecognizedOpcode(&op);
(that is, have the ifdef pushed inwards to the inner |case| level, and have
the after-the-switch control flow fixed up) before it is possible to add
similarly guarded cases for memory.copy/fill.
I'm assuming that the degenerate configuration, where the innermost switch
has no active entries
switch (op.b1) {
default:
break;
}
is optimised away by the C++ compiler, so there's no perf loss. This seems
reasonable to me.
--HG--
extra : rebase_source : 153590a84e802a1b0581f3061efa7caba081e7a4
This patch adds an initial implementation, along with test cases, for the
memory.fill and memory.copy instructions that form part of the
bulk-memory-operations proposal at
https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md.
This covers code generation for the baseline and optimising compilers, as
well as supporting infrastructure for conversion to/from binary and text
representations.
The implementation is simple in the sense that -- for both compilers -- it
is done by a call to a helper function, which eventually devolves to a call
to memset/memmove respectively.
Per subsequent clarification requests:
* https://github.com/WebAssembly/bulk-memory-operations/issues/8
The arguments to these instructions are all interpreted as unsigned 32 bit
ints.
* https://github.com/WebAssembly/bulk-memory-operations/issues/11
Zero length fills/copies that have starting point offsets out of bounds
trap rather than are treated as no-ops.
--HG--
extra : rebase_source : 79c74cbe467905f03b796428ee80b643c105ca72
