searching for reviewer(luke)
e964138e796b526597daac4125a79dca43233c6e: Bug 1535194 - Always check error return from BufferOffset::diffB. r=luke a=pascalc
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Mar 2019 16:10:58 +0100 - rev 526026
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1535194 - Always check error return from BufferOffset::diffB. r=luke a=pascalc We were missing error checks at two points. In one case an error return is meaningful; in another case it is not, as the problem should have been guarded against at a higher level by emitting far jump islands soon enough during pasteup of compiled code. Differential Revision: https://phabricator.services.mozilla.com/D23506
e0f62b77623697545dd2eb5c7e061a65a723f68e: Bug 1540944 - Get new group from the correct realm in SetProto. r=luke a=pascalc
Jan de Mooij <jdemooij@mozilla.com> - Tue, 02 Apr 2019 19:41:07 +0000 - rev 525975
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1540944 - Get new group from the correct realm in SetProto. r=luke a=pascalc Differential Revision: https://phabricator.services.mozilla.com/D25803
7b9be2d40a83d028ef43b3ad88c16a616c4e178b: Bug 1529933 - Execute a fence before mprotect. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Mar 2019 17:22:50 +0100 - rev 525069
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1529933 - Execute a fence before mprotect. r=luke Differential Revision: https://phabricator.services.mozilla.com/D23527
759a68d0af0fbdf24b36101503d8c61a879cfc25: Bug 1529933 - Execute a fence before mprotect. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Mar 2019 17:22:50 +0100 - rev 525062
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1529933 - Execute a fence before mprotect. r=luke Differential Revision: https://phabricator.services.mozilla.com/D23527
abac6267ab6281e4002d23563253994128f57bc9: Bug 1533744 - Properly gate anyref. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 11 Mar 2019 16:29:11 +0000 - rev 524427
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1533744 - Properly gate anyref. r=luke When I removed the guard on anyref for gcTypesEnabled I should have added a couple more ifdefs so that anyref is only accepted when the reftypes are enabled. This patch adds those guards, and expands test cases that check that the feature is properly disabled to include more possible error messages. Differential Revision: https://phabricator.services.mozilla.com/D22893
9cd8b6db0567d942d21ed34c7e2cad9f61405832: Bug 1532927 - Secondary wasm opcodes are not bytes. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 06 Mar 2019 12:49:28 +0100 - rev 523998
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1532927 - Secondary wasm opcodes are not bytes. r=luke Changes to decoding, dispatch, and encoding to handle a uint32_t representation for the secondary opcode. Also a drive-by fix to remove an orphaned enum in WasmTypes.h Differential Revision: https://phabricator.services.mozilla.com/D22295
18e50a1447d24e2e89d576a79ba43249f42eeea2: Bug 1530608 part 1 - Add an isSameCompartment JS testing function. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Fri, 01 Mar 2019 07:55:53 +0000 - rev 523087
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1530608 part 1 - Add an isSameCompartment JS testing function. r=luke Differential Revision: https://phabricator.services.mozilla.com/D21568
b4cc238408111d01cf9230debb2bf0c6cb235c92: Bug 1530311 - Add a length check to HashTable::reserve(). r=luke
Nicholas Nethercote <nnethercote@mozilla.com> - Wed, 27 Feb 2019 00:08:13 +0000 - rev 522158
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1530311 - Add a length check to HashTable::reserve(). r=luke Also add an assertion to a similar function in PLDHashTable.cpp. Differential Revision: https://phabricator.services.mozilla.com/D21167
a00f8b23be0c481a64a48ecfb333338b42833c48: Bug 1526276 - Add a fake unwind code to arm64 JIT function entries r=luke
David Major <dmajor@mozilla.com> - Mon, 25 Feb 2019 21:04:41 +0000 - rev 521864
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1526276 - Add a fake unwind code to arm64 JIT function entries r=luke This works around the issue where if the PC and SP don't change while unwinding our JIT frame, we'll fail the unwinder's sanity checks and it won't call our exception handler. Ideally we'd store proper unwind info, but that's a larger change for another day. Differential Revision: https://phabricator.services.mozilla.com/D20858
024508ba77dec75d13a8756701cdebc8485742c1: Bug 1529622 - Initialize jsJitArgsRectifier_, jsJitExceptionHandler_ and preBarrierCode_ in wasm::Instance's constructor; r=luke
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 21 Feb 2019 21:54:46 +0000 - rev 521345
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1529622 - Initialize jsJitArgsRectifier_, jsJitExceptionHandler_ and preBarrierCode_ in wasm::Instance's constructor; r=luke Differential Revision: https://phabricator.services.mozilla.com/D20675
bbb1ed3f3dfddb23e68ab2bbe3c117f7390e770c: Bug 1518785 - wasm-via-Ion: incorrect logic to decide on whether to omit a stack overflow check. r=luke.
Julian Seward <jseward@acm.org> - Thu, 21 Feb 2019 06:25:42 +0100 - rev 521073
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1518785 - wasm-via-Ion: incorrect logic to decide on whether to omit a stack overflow check. r=luke. MacroAssembler::wasmReserveStackChecked takes a parameter |amount|, which appears to be the number of bytes pushed by the prologue, not including for the wasm::Frame, up to this point. If this value is zero, the stack overflow check is omitted. I believe this logic is incorrect and that the stack overflow check should never be omitted. There's no way any non-leaf call could really use zero bytes of stack in total, since there would be no place to store the return address. I believe this code worked by accident, for the following reason: |amount| is never zero. That happens because, currently, wasm::Frame is 3 words (except on ARM64). That's 12 bytes or 24 bytes, depending on word size. At some point I imagine that |amount| is rounded upwards, prior to the call to MacroAssembler::wasmReserveStackChecked, so that |amount| + sizeof(wasm::Frame) is 0 % 16. If amount was originally zero, then it will be adjusted upwards to 4 (16-12) on a 32-bit system and to 8 (32-24) on a 64-bit system. The end effect is that |amount| can never be zero here. The fix is simply to remove the early exit.
17d8de567ea416b9a995fcec56897b1bc138b9c6: Bug 1521906 part 2 - Replace remaining CheckedUnwrap calls in js/src. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 19 Feb 2019 11:22:55 +0000 - rev 520749
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1521906 part 2 - Replace remaining CheckedUnwrap calls in js/src. r=luke This uses CheckedUnwrapStatic in places where we don't expect WindowProxy/Location objects to show up or where we will throw an exception in that case anyway. I also used this in the more complicated cases (the compartment situation in PromiseObject for example is very complicated). Differential Revision: https://phabricator.services.mozilla.com/D20155
6f42a0b6c8dea3a07850db4bfe5966f56c5a8a58: Bug 1507491 - Let WebAssembly.Table.prototype.grow take a fill argument. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 29 Nov 2018 14:57:44 +0100 - rev 520683
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1507491 - Let WebAssembly.Table.prototype.grow take a fill argument. r=luke There is no real spec for this feature yet but we assume for now that grow with a fill value is like growing without a fill value and then storing the fill value repeatedly. The default value is null. However, since the second argument to this method was previously ignored, non-function values are ignored (rather than causing an error) when the table is a table-of-anyfunc. Since we're extending the semantics for grow() on tables of anyfunc I have opted to gate the functionality on ENABLE_WASM_GC. (Additional WPT tests land separately.)
cd56d5e49b75d048ab940baf13836c8ce678565f: Bug 1527563 - Remove defunct nested-call optimisation in WasmIonCompile.cpp. r=luke.
Julian Seward <jseward@acm.org> - Fri, 15 Feb 2019 07:45:32 +0100 - rev 520420
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1527563 - Remove defunct nested-call optimisation in WasmIonCompile.cpp. r=luke. Translation of wasm into MIR is currently set up to handle multiple nested function call instances simultaneously, using a stack of CallCompileState records to keep track of the per-open-call state. This is an optimisation intended to allow interleaved evaluation and pushing of stack-resident outbound arguments. However, this was predicated on the assumption of pre-order Wasm encoding, which is no longer valid -- encoding is post-order. The compiler's operand (wasm) stack tracks MIR value nodes, which are by definition already evaluated -- it doesn't track unevaluated expression trees. Consequently, by the time we arrive at a wasm call instruction, we have to hand the MIR nodes for all the arguments, so the possibility of evaluating arguments whilst marshalling the arguments no longer exists. This patch: * removes FunctionCompiler::callStack_ and CallCompileStateVector * removes CallCompileState::{maxChildStackBytes_, spIncrement_, stackArgs_ and childClobbers_}, since they are no longer necessary. * removes CallCompileState::lineOrBytecode_ and just passes it directly to where it's needed. It's only remaining use inside CallCompileState was to carry that value (eg) from EmitCall up to callDirect/callImport. * removes CallCompileState::startCall as that becomes a no-op * propagates the fact that CallCompileState::spIncrement_ is always zero, through the MIR (MWasmCall et al) and into emitWasmCallBase(). Hence the field disappears from MWasmCall.
2d7295e1d7230c60a563aa66bce028d32cd2b29c: Bug 1524337: Move WebAssembly reftypes/gc configuration to moz.configure; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 14 Feb 2019 12:59:38 +0100 - rev 520414
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1524337: Move WebAssembly reftypes/gc configuration to moz.configure; r=luke Differential Revision: https://phabricator.services.mozilla.com/D19788
4248681622989fb38ac10c07e9f9c82b32dc8f0c: Bug 1524337: Use moz.configure for the WebAssembly bulk memory proposal; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 14 Feb 2019 12:54:43 +0100 - rev 520413
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1524337: Use moz.configure for the WebAssembly bulk memory proposal; r=luke Differential Revision: https://phabricator.services.mozilla.com/D19787
86c5f309b36931b2295a6fdb7360e202ba1fc896: Bug 1524337: Rename ENABLE_BINARYDATA to ENABLE_TYPED_OBJECTS and use moz.configure; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 14 Feb 2019 12:44:25 +0100 - rev 520412
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1524337: Rename ENABLE_BINARYDATA to ENABLE_TYPED_OBJECTS and use moz.configure; r=luke Differential Revision: https://phabricator.services.mozilla.com/D19786
322de2cc80194c4fe859989738f7c3c2b70b98a4: Bug 1526653 - Document some ARM Linux compile problems. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 13 Feb 2019 08:34:48 +0100 - rev 520002
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1526653 - Document some ARM Linux compile problems. r=luke Not every ARM Linux distro (all of them tier-3 apart from Android) has a sys/user.h that provides the necessary structures for us to emulate unaligned FP accesses. Raspbian is a case in point; the only user.h on the system is some generic glibc thing that is completely wrong for ARM. We can't really hope to #ifdef our way out of this -- for example, there does not seem to be a reliable preprocessor name for Raspbian, nor is there a canonical preprocessor name that sys/user.h exports when the desired structures are defined. Therefore, add some comments to explain the problem and introduce a choke point that tier-3 porters can use if they run into the problem. Differential Revision: https://phabricator.services.mozilla.com/D19637
e8f7092b8d5dd3c92a3520b9d5a502f6a8d171bd: bug 1245108 - Fixed uninitialized variables warnings in js/ r=luke
Paul Bignier <paul.bignier@gmail.com> - Tue, 12 Feb 2019 18:29:39 +0100 - rev 519597
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
bug 1245108 - Fixed uninitialized variables warnings in js/ r=luke
491fc771924f074b997d18be782b70e22a07021b: Bug 1526219 - Guard atomicity tests on a plausible core count. r=luke
Lars T Hansen <lhansen@mozilla.com> - Fri, 08 Feb 2019 11:09:01 +0100 - rev 519407
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1526219 - Guard atomicity tests on a plausible core count. r=luke The atomicity test cases require multiple cores so that multiple workers can run concurrently; if enough cores are not available then the tests will just take forever to execute because they'll be waiting on preemption. (In practice, the tests will time out.) So guard execution of the test on the availability of enough cores. The guard may mean that the tests are not run on all test platforms, but they should be run on developer systems and on platforms where we run tests non-virtualized, eg, android hardware -- provided there are enough cores. This is a real improvement over the current situation, in which the tests are marked slow and thus never run at all. Differential Revision: https://phabricator.services.mozilla.com/D19259
e7dc5234c6567ed6ff2c7db0c83314e3812f58c1: Bug 1521906 part 1 - Use obj->maybeUnwrapAs<T>() or obj->maybeUnwrapIf<T>() instead of CheckedUnwrap where possible. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Sun, 10 Feb 2019 17:37:14 +0000 - rev 519330
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1521906 part 1 - Use obj->maybeUnwrapAs<T>() or obj->maybeUnwrapIf<T>() instead of CheckedUnwrap where possible. r=luke Differential Revision: https://phabricator.services.mozilla.com/D18990
de9bc20a8ed58c9224319e73d76cc0bec6ed1f22: Bug 1523993: Spew debug information for wasm calls; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 31 Jan 2019 15:42:44 +0100 - rev 518434
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1523993: Spew debug information for wasm calls; r=luke Differential Revision: https://phabricator.services.mozilla.com/D18342
6a66a76627b3c2ee0f01f738010a31ee6d0182c2: Bug 1523993: Add JitOptions to disable wasm fast paths; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 31 Jan 2019 18:29:02 +0100 - rev 518433
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1523993: Add JitOptions to disable wasm fast paths; r=luke This adds a new configure option `--enable-wasm-codegen-debug`, which defaults to true in debug builds (disable otherwise). It's a first step so as to be able to use this in both the shell and browser, using the env variables JIT_OPTION_{JitOption field name}. Differential Revision: https://phabricator.services.mozilla.com/D18341
e8a0e28d1443a7f423418b7aea637ce4cc8f4818: Bug 1523993: Spew debug information for wasm calls; r=luke
Benjamin Bouvier <benj@benj.me> - Wed, 06 Feb 2019 16:38:24 +0000 - rev 518318
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1523993: Spew debug information for wasm calls; r=luke Differential Revision: https://phabricator.services.mozilla.com/D18342
454d1b05007a69eb2933e83d1646091535224c25: Bug 1523993: Add JitOptions to disable wasm fast paths; r=luke
Benjamin Bouvier <benj@benj.me> - Wed, 06 Feb 2019 16:39:31 +0000 - rev 518317
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1523993: Add JitOptions to disable wasm fast paths; r=luke This adds a new configure option `--enable-wasm-codegen-debug`, which defaults to true in debug builds (disable otherwise). It's a first step so as to be able to use this in both the shell and browser, using the env variables JIT_OPTION_{JitOption field name}. Differential Revision: https://phabricator.services.mozilla.com/D18341
8993106d37a62df5e66c61b0e7d56d7d818d23a5: Bug 1145201: Document OffThreadPromiseRuntimeState fields in more detail. r=luke
Jim Blandy <jimb@mozilla.com> - Wed, 30 Jan 2019 18:59:02 +0000 - rev 518223
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1145201: Document OffThreadPromiseRuntimeState fields in more detail. r=luke Differential Revision: https://phabricator.services.mozilla.com/D17543
7bcedc06aad40dc1fca97af177f62bc14b27fd54: Bug 1522945: Dequeue OffThreadPromiseTasks one at a time, to support reentrant draining. r=luke
Jim Blandy <jimb@mozilla.com> - Thu, 31 Jan 2019 16:12:50 +0000 - rev 517184
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1522945: Dequeue OffThreadPromiseTasks one at a time, to support reentrant draining. r=luke `OffThreadPromiseRuntimeState::internalDrain` assumes that if `internalDispatchQueue_` is empty but `live_` is not, then there must be `OffThreadPromiseTasks` still in flight that it should block for. To support reentrant calls to `internalDrain`, we need to make two changes: - First, `internalDrain` needs to dequeue jobs one at a time, rather than swapping out the entire queue, which makes the queue look empty when there are still jobs yet to be run. - Second, `OffThreadPromiseTask::run` needs to remove each task from `live_` *before* calling its `resolve` method, so that if the last task in the queue reenters `internalDrain`, that won't mistake the final entry in `live_` for something it must block on. Since there are still `OffThreadPromiseTasks` that get registered in `live_` but then get destructed without being run (for example, in `WasmJS.cpp`'s `ResolveResponse_OnFulfilled`), we cannot assume that the `run` method will unregister all tasks; the destructor still needs to check if unregistration is necessary. So we factor out unregistration into its own method. Differential Revision: https://phabricator.services.mozilla.com/D17704
3dc4b57837a41022356afbdf803c5787cbfc3a18: Bug 1522945: Use a FIFO for OffThreadPromiseRuntimeState::internalDispatchQueue. r=luke
Jim Blandy <jimb@mozilla.com> - Thu, 31 Jan 2019 16:12:49 +0000 - rev 517183
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1522945: Use a FIFO for OffThreadPromiseRuntimeState::internalDispatchQueue. r=luke To support reentrant calls to OffThreadPromiseRuntimeState::internalDrain, we need to be able to tell reliably whether the queue is empty or not. The present implementation tactic of using a Vector to represent the queue, pushing new jobs onto the end, and then stealing the entire vector and processing all the jobs in one pass over its make it appear that the queue is empty when, in fact, there remain jobs that have not yet been run. Since we have a true FIFO type ready at hand, we can use that to give the off-thread promise machinery a more traditional implementation that dequeues one job at a time. Differential Revision: https://phabricator.services.mozilla.com/D17702
17fb0284bb5d0ecc4e0f8e87d5738e19fcc6090d: Bug 1526276 - Add a fake unwind code to arm64 JIT function entries r=luke a=lizzard
David Major <dmajor@mozilla.com> - Mon, 25 Feb 2019 21:04:41 +0000 - rev 516189
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1526276 - Add a fake unwind code to arm64 JIT function entries r=luke a=lizzard This works around the issue where if the PC and SP don't change while unwinding our JIT frame, we'll fail the unwinder's sanity checks and it won't call our exception handler. Ideally we'd store proper unwind info, but that's a larger change for another day. Differential Revision: https://phabricator.services.mozilla.com/D20858
426bafe23415b19d83dc3e084f66f71f156d53c7: Bug 1502035 - DataCount section. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 23 Jan 2019 16:06:16 +0100 - rev 515445
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1502035 - DataCount section. r=luke We now require the presence of a DataCount section to forward-declare the number of data segments if the code uses memory.init or data.drop. Those instructions may only reference segments in the range [0..dataCount-1]. If there is a DataCount section then the number of forward-declared segments must match the actual count of segments. We no longer need the deferred validation state, so we can remove it. That's pretty mechanical and comprises the bulk of the patch. text->binary translation will insert a DataCount section if memory.init or data.drop is used and the DataCount section is not present in the text (this will be the common case); however, if the section is present in the text then translation will just encode whatever the text contains. The section is not synthesized if it is not needed. Also: test cases for all of this. Also: drive-by fix the passive-segments test cases: do not duplicate functionality from wasm-binary.js, and use opcode names when possible.
dc3f5f51778c917e2c67a9ebb82ec666bb725c76: Bug 1516697 - Remove the implementation of the asm.js caching mechanism. (APIs to invoke it still remain in place; they just don't do anything.) r=luke
Jeff Walden <jwalden@mit.edu> - Thu, 17 Jan 2019 12:39:02 -0500 - rev 515382
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1516697 - Remove the implementation of the asm.js caching mechanism. (APIs to invoke it still remain in place; they just don't do anything.) r=luke
ced24b663e6593c79917f8af47256e2ea9ca83d1: Bug 1522075 part 4 - Some JitContext assertions and clean up. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 24 Jan 2019 17:36:42 +0000 - rev 515317
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1522075 part 4 - Some JitContext assertions and clean up. r=luke When we generate the Baseline interpreter and other trampolines, JitContext's realm is nullptr. We now assert it's non-null in JitContext::realm(). I also replaced JitContext::zone with JitContext::isCompilingWasm_. Differential Revision: https://phabricator.services.mozilla.com/D17368
1230184adda1d000a3b339a599416c015eea4119: Bug 1283121 - Handle SIGBUS for unaligned FP load/store on ARM Linux. r=luke, r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 09 Jan 2019 13:51:12 +0100 - rev 514071
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1283121 - Handle SIGBUS for unaligned FP load/store on ARM Linux. r=luke, r=jseward Accesses that are not flagged as unaligned in the wasm bytecode may still be unaligned in practice; this is allowed by the wasm spec. This is not a problem on x86 but may be on ARM (depending on the chip and the OS), since ARM has more stringent alignment requirements; however, our initial ARM work knowingly ignored the problem, as we had insufficient data. Now we have data, and it turns out that 32-bit ARM Linux and Android usually signal SIGBUS for unaligned floating-point accesses, this is observed broadly on current (2017-2018) devices. It is still chip-dependent, in principle, but I've found no recent device or Android version where the signal does not occur. So we have to handle the signal or avoid it being generated in the first place. As we expect unaligned FP accesses to be infrequent (multibyte data read directly out of packed data streams, etc) it provides best performance overall to emulate the faulting instruction within the trap handler. The main problem with doing so is that the Linux sigcontext does not quite expose the FP registers. However, the sigcontext contains a data structure that has the data we need; it is self-identifying; and it has been stable for nearly a decade and many Linux versions, at least back to the 2.6 line. Android has merged the code in question. A secondary problem is that we don't want a general disassembler in the signal handler, so code generation becomes slightly constrained by this, but only on ARM, and not in a way that required any changes.
070316635c495a75684a55168d734a1f7df5edca: Bug 1520189 - Remove the ToWindowProxyIfWindow call in LexicalEnvironmentObject::thisValue; handle this in js::SetWindowProxy instead. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 15 Jan 2019 20:33:13 +0000 - rev 514051
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1520189 - Remove the ToWindowProxyIfWindow call in LexicalEnvironmentObject::thisValue; handle this in js::SetWindowProxy instead. r=luke This simplifies LexicalEnvironmentObject::thisValue so it's easier to inline in JIT code. Differential Revision: https://phabricator.services.mozilla.com/D16586
ffef7bf31900e6bd360017e414338b454bfffa41: Bug 1519809 - Replace IsActiveEval/IsCachedEval flags on JSScript with a single IsForEval flag. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Mon, 14 Jan 2019 15:56:15 +0000 - rev 513886
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1519809 - Replace IsActiveEval/IsCachedEval flags on JSScript with a single IsForEval flag. r=luke Differential Revision: https://phabricator.services.mozilla.com/D16449
4d932b82695c7ac58901ef0a03f44fed6ce2d1f0: Bug 1484835 - Extend the Windows JIT unwind handler to ARM64 r=luke
David Major <dmajor@mozilla.com> - Mon, 14 Jan 2019 14:06:24 +0000 - rev 513713
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1484835 - Extend the Windows JIT unwind handler to ARM64 r=luke Because the .xdata format on ARM64 can only encode sizes up to 1M (much too small for our JIT code regions), we register a function table callback to provide RUNTIME_FUNCTIONs at runtime. Windows doesn't seem to care about the size fields on RUNTIME_FUNCTIONs that are created in this way, so the same RUNTIME_FUNCTION can work for any address in the region. We'll set up a generic one in RegisterExecutableMemory and the callback can just return a pointer to it. Differential Revision: https://phabricator.services.mozilla.com/D16261
0985217ed619be2fc84eeefc895321f4c88dc21e: Bug 1518331 - corner case optimization. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 08 Jan 2019 17:48:00 +0100 - rev 513014
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1518331 - corner case optimization. r=luke
16819308720e1aa1228ff31f84bd233599fb5e23: Bug 1442540 - Empirical ARM64 policy values for wasm tiering. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 08 Jan 2019 20:43:01 +0100 - rev 513013
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1442540 - Empirical ARM64 policy values for wasm tiering. r=luke These values were computed by measuring compilations of a set of programs on ARM64 reference hardware using --no-threads and then applying sane multipliers to estimate Ion values where we don't yet have them (because we don't have Ion on ARM64). See the bug for a table of raw data. See comments in the code for more information about what the values mean.
81ddd47b2cae63f03d4e70853f5bd5262ff1afc4: Bug 1517412 - Adapt wasm buffer management parameters for android-on-arm64. r=luke
Lars T Hansen <lhansen@mozilla.com> - Fri, 04 Jan 2019 16:49:36 +0100 - rev 512883
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1517412 - Adapt wasm buffer management parameters for android-on-arm64. r=luke Android on ARM64 only has 4TB of available address space per process, leaving room for relatively few wasm memory objects (6GB each currently). We therefore adjust the wasm GC trigger parameters to account for this limitation.
5510614c90e62a810e3c0c92934afba301b09315: Bug 1515010 - Update core wasm tests; r=luke
Ms2ger <Ms2ger@igalia.com> - Wed, 02 Jan 2019 12:19:13 +0100 - rev 512278
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1515010 - Update core wasm tests; r=luke
a3025b3c5c6ad2c3a3bd3fcb3d15dda5ff4b1fd1: Bug 1515010 - Update core wasm tests; r=luke
Ms2ger <Ms2ger@igalia.com> - Wed, 02 Jan 2019 12:19:13 +0100 - rev 512274
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1515010 - Update core wasm tests; r=luke
3e8268f13176bda200ed81decb06575aec6e0c04: Bug 1510216 - Add WasmAnyRef type to the TypedObject system. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 28 Nov 2018 12:47:19 +0100 - rev 511654
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1510216 - Add WasmAnyRef type to the TypedObject system. r=luke We add support for the wasm "anyref" type to the TypedObject system, so that TypedObjects can represent wasm objects faithfully and we can get proper boxing/unboxing when JS writes and reads these properties. The new type is a reference type named "WasmAnyRef" / TYPE_WASM_ANYREF internally, and it also appears as TypedObject.WasmAnyRef in JS. Accesses to AnyRef fields are not optimized by the JIT at the moment, but call into intrinsic functions in the wasm subsystem for sundry predicates and boxing and unboxing. More can be done here. Currently the code knows that an anyref in wasm is a possibly-null JSObject* representing either an Object or a boxed value. More complexity will appear when we box more values in the pointer. There are "TODO/AnyRef-boxing" comments left in the code to mark places that must definitely be adapted.
c42679c7a94dc37f3c0284651847cc98673f1ab4: Bug 1505768 - Box/unbox non-pointers for anyref as WasmValueBox objects. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 20 Nov 2018 18:36:27 +0100 - rev 511653
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1505768 - Box/unbox non-pointers for anyref as WasmValueBox objects. r=luke This is stage 0 of the anyref boxing/unboxing work. At the JS->wasm boundary, when a JS value flows into an anyref, we box everything that isn't already an Object or null into a WasmValueBox (a distinguished NativeObject subclass with a null prototype). At the wasm->JS boundary, when an anyref value flows out from wasm, we unbox it back into the proper JS value. Note that strings and atoms and other non-Object reference types are also boxed/unboxed this way. This patch handles boxing and unboxing for function anyref parameters and anyref returns (on the interpreter-only stubs path, since the JIT stubs path is not used for reference types at this time), for wasm globals-of-anyref, and for wasm tables-of-anyref. We don't have to handle (ref T) parameters, returns, or globals, since they are not exported to JS so as not to expose their types. And there are no tables of (ref T) type. The patch does *not* handle boxing/unboxing for values flowing into and out of anyref struct fields for the prototype GC work. Doing so will require work on our TypedObject implementation and can be deferred to a later patch: the current system will simply fail to box some JS values that flow into an anyref field or will incorrectly convert those values to JS Object types; it may also reveal the WasmValueBox object to JS in some cases when an anyref field is read. This is annoying but safe. The many "TODO/AnyRef-boxing" comments and accompanying asserts left in the code mark places that we have to update when we implement an optimized boxing, which will use a tagged format to avoid allocation for small immediate values (integers, booleans, undefined) and probably strings. Generally, the TypedObjects code that needs to change to accomodate boxing/unboxing is not tagged in this way.
800851f0399e30215c03323373cf63cbc0f2c67a: Bug 1145201: Document OffThreadPromiseTask. r=luke
Jim Blandy <jimb@mozilla.com> - Thu, 20 Dec 2018 17:27:51 +0000 - rev 511529
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1145201: Document OffThreadPromiseTask. r=luke Differential Revision: https://phabricator.services.mozilla.com/D14927
95e3de1d66432b6029b10d5a653e176c65462543: Bug 1508873 - part 3 - reorganize HashTable's internal storage; r=luke
Nathan Froyd <froydnj@mozilla.com> - Thu, 13 Dec 2018 12:21:19 -0500 - rev 510425
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1508873 - part 3 - reorganize HashTable's internal storage; r=luke As discussed in the previous commit message, HashTableEntry wastes space for common entry types. This commit reorganizes the internal storage to store all the hashes packed together, followed by all the entries, which eliminates the aforementioned waste.
20d92a98e3a37f3fd5a58717f28567f214429b3e: Bug 1508873 - part 2 - convert HashTable to work primarily in terms of slots; r=luke
Nathan Froyd <froydnj@mozilla.com> - Thu, 13 Dec 2018 12:21:19 -0500 - rev 510424
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1508873 - part 2 - convert HashTable to work primarily in terms of slots; r=luke HashTableEntry's data layout currently wastes a fair amount of space due to ABI-mandated padding. For instance, HashTableEntry<T*> on a 64-bit platform looks like: class HashTableEntry { HashNumber mKeyHash; // Four bytes of wasted space here to pad mValueData to the correct place. unsigned char mValueData[sizeof(T*)]; }; This wasted space means that sets of pointers backed by mozilla::HashTable waste a quarter of their entry storage space. Maps of pointers to pointers waste a sixth of their entry storage space. We'd like to fix this by packing all the cached hashes together, followed by all the hash table entries. As a first step to laying out the hash table storage differently, we have to make HashTable not access entries directly, but go through an abstraction that represents the key and the entry. We call this abstraction "slots". This commit is similar to the change done for PLDHashTable previously. Parts of HashTable still work in terms of Entry; the creation and destruction of tables was not worth changing here. We'll address that in the next commit.
ff944ef6b8a4bf09a8a8083ee7bf7dfa964e75b0: Bug 1508873 - part 1 - statically assert alignment for hashtable entries; r=luke
Nathan Froyd <froydnj@mozilla.com> - Thu, 13 Dec 2018 12:21:19 -0500 - rev 510423
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1508873 - part 1 - statically assert alignment for hashtable entries; r=luke We do this to make our lives easier in later patches; this check guarantees that we don't need padding between the block of cached hash values and the block of entries immediately after it.
a356b2566ae2e8f6d5ac676b39fd74aea6604664: Bug 1508873 - part 3 - reorganize HashTable's internal storage; r=luke
Nathan Froyd <froydnj@mozilla.com> - Wed, 12 Dec 2018 14:57:21 -0500 - rev 510337
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1508873 - part 3 - reorganize HashTable's internal storage; r=luke As discussed in the previous commit message, HashTableEntry wastes space for common entry types. This commit reorganizes the internal storage to store all the hashes packed together, followed by all the entries, which eliminates the aforementioned waste.
4bb5dd072865ae619c3a39296d124c483bdc86ca: Bug 1508873 - part 2 - convert HashTable to work primarily in terms of slots; r=luke
Nathan Froyd <froydnj@mozilla.com> - Wed, 12 Dec 2018 14:57:21 -0500 - rev 510336
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1508873 - part 2 - convert HashTable to work primarily in terms of slots; r=luke HashTableEntry's data layout currently wastes a fair amount of space due to ABI-mandated padding. For instance, HashTableEntry<T*> on a 64-bit platform looks like: class HashTableEntry { HashNumber mKeyHash; // Four bytes of wasted space here to pad mValueData to the correct place. unsigned char mValueData[sizeof(T*)]; }; This wasted space means that sets of pointers backed by mozilla::HashTable waste a quarter of their entry storage space. Maps of pointers to pointers waste a sixth of their entry storage space. We'd like to fix this by packing all the cached hashes together, followed by all the hash table entries. As a first step to laying out the hash table storage differently, we have to make HashTable not access entries directly, but go through an abstraction that represents the key and the entry. We call this abstraction "slots". This commit is similar to the change done for PLDHashTable previously. Parts of HashTable still work in terms of Entry; the creation and destruction of tables was not worth changing here. We'll address that in the next commit.
a6657732fdbe6d28b3096bdfd7ab843f2394e39a: Bug 1508873 - part 1 - statically assert alignment for hashtable entries; r=luke
Nathan Froyd <froydnj@mozilla.com> - Wed, 12 Dec 2018 14:57:21 -0500 - rev 510335
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1508873 - part 1 - statically assert alignment for hashtable entries; r=luke We do this to make our lives easier in later patches; this check guarantees that we don't need padding between the block of cached hash values and the block of entries immediately after it.