searching for reviewer(luke)
f285d37402e2: Bug 1423917 - P9 - Remove asmjs client in the 2_1to2_2 upgrade for QuotaManager; r=luke
Tom Tung <shes050117@gmail.com> - Wed, 13 Mar 2019 15:59:34 +0000 - rev 465429
Push 112505 by opoprus@mozilla.com at Thu, 21 Mar 2019 23:01:57 +0000
Bug 1423917 - P9 - Remove asmjs client in the 2_1to2_2 upgrade for QuotaManager; r=luke Differential Revision: https://phabricator.services.mozilla.com/D21732
7b9be2d40a83: Bug 1529933 - Execute a fence before mprotect. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Mar 2019 17:22:50 +0100 - rev 464127
Push 112440 by lhansen@mozilla.com at Fri, 15 Mar 2019 12:24:15 +0000
Bug 1529933 - Execute a fence before mprotect. r=luke Differential Revision: https://phabricator.services.mozilla.com/D23527
759a68d0af0f: Bug 1529933 - Execute a fence before mprotect. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Mar 2019 17:22:50 +0100 - rev 464101
Push 112436 by lhansen@mozilla.com at Fri, 15 Mar 2019 07:37:02 +0000
Bug 1529933 - Execute a fence before mprotect. r=luke Differential Revision: https://phabricator.services.mozilla.com/D23527
abac6267ab62: Bug 1533744 - Properly gate anyref. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 11 Mar 2019 16:29:11 +0000 - rev 463541
Push 112400 by btara@mozilla.com at Tue, 12 Mar 2019 10:04:06 +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
9cd8b6db0567: 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 463005
Push 112353 by lhansen@mozilla.com at Fri, 08 Mar 2019 08:41:44 +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
18e50a1447d2: 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 462221
Push 112282 by aciure@mozilla.com at Mon, 04 Mar 2019 21:54:47 +0000
Bug 1530608 part 1 - Add an isSameCompartment JS testing function. r=luke Differential Revision: https://phabricator.services.mozilla.com/D21568
b4cc23840811: 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 461394
Push 112174 by ncsoregi@mozilla.com at Wed, 27 Feb 2019 04:40:22 +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
a00f8b23be0c: 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 461026
Push 112146 by nerli@mozilla.com at Tue, 26 Feb 2019 04:26:08 +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
024508ba77de: 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 460517
Push 112096 by ccoroiu@mozilla.com at Fri, 22 Feb 2019 16:41:57 +0000
Bug 1529622 - Initialize jsJitArgsRectifier_, jsJitExceptionHandler_ and preBarrierCode_ in wasm::Instance's constructor; r=luke Differential Revision: https://phabricator.services.mozilla.com/D20675
bbb1ed3f3dfd: 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 460144
Push 112054 by jseward@mozilla.com at Thu, 21 Feb 2019 06:40:27 +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.
17d8de567ea4: 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 459877
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +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
6f42a0b6c8de: 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 459735
Push 111998 by lhansen@mozilla.com at Mon, 18 Feb 2019 15:28:22 +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.)
cd56d5e49b75: 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 459480
Push 111956 by jseward@mozilla.com at Fri, 15 Feb 2019 11:15:46 +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.
2d7295e1d723: 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 459430
Push 111952 by bbouvier@mozilla.com at Fri, 15 Feb 2019 09:34:21 +0000
Bug 1524337: Move WebAssembly reftypes/gc configuration to moz.configure; r=luke Differential Revision: https://phabricator.services.mozilla.com/D19788
424868162298: 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 459429
Push 111952 by bbouvier@mozilla.com at Fri, 15 Feb 2019 09:34:21 +0000
Bug 1524337: Use moz.configure for the WebAssembly bulk memory proposal; r=luke Differential Revision: https://phabricator.services.mozilla.com/D19787
86c5f309b369: 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 459428
Push 111952 by bbouvier@mozilla.com at Fri, 15 Feb 2019 09:34:21 +0000
Bug 1524337: Rename ENABLE_BINARYDATA to ENABLE_TYPED_OBJECTS and use moz.configure; r=luke Differential Revision: https://phabricator.services.mozilla.com/D19786
322de2cc8019: 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 459078
Push 111916 by lhansen@mozilla.com at Thu, 14 Feb 2019 11:24:59 +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
e8f7092b8d5d: 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 458716
Push 111877 by sledru@mozilla.com at Tue, 12 Feb 2019 17:30:53 +0000
bug 1245108 - Fixed uninitialized variables warnings in js/ r=luke
e7dc5234c656: 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 458454
Push 111836 by cbrindusan@mozilla.com at Mon, 11 Feb 2019 09:36:45 +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
491fc771924f: 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 458452
Push 111835 by lhansen@mozilla.com at Mon, 11 Feb 2019 07:39:44 +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
de9bc20a8ed5: Bug 1523993: Spew debug information for wasm calls; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 31 Jan 2019 15:42:44 +0100 - rev 457554
Push 111745 by bbouvier@mozilla.com at Thu, 07 Feb 2019 10:32:50 +0000
Bug 1523993: Spew debug information for wasm calls; r=luke Differential Revision: https://phabricator.services.mozilla.com/D18342
6a66a76627b3: 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 457553
Push 111745 by bbouvier@mozilla.com at Thu, 07 Feb 2019 10:32:50 +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
e8a0e28d1443: Bug 1523993: Spew debug information for wasm calls; r=luke
Benjamin Bouvier <benj@benj.me> - Wed, 06 Feb 2019 16:38:24 +0000 - rev 457466
Push 111729 by rgurzau@mozilla.com at Wed, 06 Feb 2019 22:00:03 +0000
Bug 1523993: Spew debug information for wasm calls; r=luke Differential Revision: https://phabricator.services.mozilla.com/D18342
454d1b05007a: 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 457465
Push 111729 by rgurzau@mozilla.com at Wed, 06 Feb 2019 22:00:03 +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
8993106d37a6: Bug 1145201: Document OffThreadPromiseRuntimeState fields in more detail. r=luke
Jim Blandy <jimb@mozilla.com> - Wed, 30 Jan 2019 18:59:02 +0000 - rev 457363
Push 111717 by opoprus@mozilla.com at Wed, 06 Feb 2019 10:10:24 +0000
Bug 1145201: Document OffThreadPromiseRuntimeState fields in more detail. r=luke Differential Revision: https://phabricator.services.mozilla.com/D17543
7bcedc06aad4: 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 456322
Push 111620 by shindli@mozilla.com at Fri, 01 Feb 2019 04:08:08 +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
3dc4b57837a4: Bug 1522945: Use a FIFO for OffThreadPromiseRuntimeState::internalDispatchQueue. r=luke
Jim Blandy <jimb@mozilla.com> - Thu, 31 Jan 2019 16:12:49 +0000 - rev 456321
Push 111620 by shindli@mozilla.com at Fri, 01 Feb 2019 04:08:08 +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
426bafe23415: Bug 1502035 - DataCount section. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 23 Jan 2019 16:06:16 +0100 - rev 455397
Push 111453 by lhansen@mozilla.com at Fri, 25 Jan 2019 12:00:13 +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.
dc3f5f51778c: 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 455326
Push 111442 by jwalden@mit.edu at Thu, 24 Jan 2019 22:53:02 +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
ced24b663e65: 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 455317
Push 111440 by nbeleuzu@mozilla.com at Thu, 24 Jan 2019 21:48:07 +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
070316635c49: 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 454081
Push 111205 by rmaries@mozilla.com at Wed, 16 Jan 2019 17:09:49 +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
1230184adda1: 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 454042
Push 111192 by lhansen@mozilla.com at Wed, 16 Jan 2019 07:38:50 +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.
ffef7bf31900: 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 453919
Push 111173 by btara@mozilla.com at Tue, 15 Jan 2019 16:15:06 +0000
Bug 1519809 - Replace IsActiveEval/IsCachedEval flags on JSScript with a single IsForEval flag. r=luke Differential Revision: https://phabricator.services.mozilla.com/D16449
4d932b82695c: 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 453740
Push 111147 by cbrindusan@mozilla.com at Mon, 14 Jan 2019 21:55:21 +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
0985217ed619: Bug 1518331 - corner case optimization. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 08 Jan 2019 17:48:00 +0100 - rev 453006
Push 111019 by lhansen@mozilla.com at Wed, 09 Jan 2019 08:01:16 +0000
Bug 1518331 - corner case optimization. r=luke
16819308720e: 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 453005
Push 111018 by lhansen@mozilla.com at Wed, 09 Jan 2019 07:09:12 +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.
81ddd47b2cae: 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 452800
Push 110983 by lhansen@mozilla.com at Tue, 08 Jan 2019 08:01:06 +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.
5510614c90e6: Bug 1515010 - Update core wasm tests; r=luke
Ms2ger <Ms2ger@igalia.com> - Wed, 02 Jan 2019 12:19:13 +0100 - rev 452255
Push 110857 by Ms2ger@gmail.com at Wed, 02 Jan 2019 15:45:14 +0000
Bug 1515010 - Update core wasm tests; r=luke
a3025b3c5c6a: Bug 1515010 - Update core wasm tests; r=luke
Ms2ger <Ms2ger@igalia.com> - Wed, 02 Jan 2019 12:19:13 +0100 - rev 452251
Push 110854 by Ms2ger@gmail.com at Wed, 02 Jan 2019 11:29:30 +0000
Bug 1515010 - Update core wasm tests; r=luke
3e8268f13176: 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 451652
Push 110702 by lhansen@mozilla.com at Fri, 21 Dec 2018 10:43:23 +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.
c42679c7a94d: 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 451651
Push 110702 by lhansen@mozilla.com at Fri, 21 Dec 2018 10:43:23 +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.
800851f0399e: Bug 1145201: Document OffThreadPromiseTask. r=luke
Jim Blandy <jimb@mozilla.com> - Thu, 20 Dec 2018 17:27:51 +0000 - rev 451568
Push 110693 by nbeleuzu@mozilla.com at Thu, 20 Dec 2018 22:05:28 +0000
Bug 1145201: Document OffThreadPromiseTask. r=luke Differential Revision: https://phabricator.services.mozilla.com/D14927
95e3de1d6643: 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 450393
Push 110492 by nfroyd@mozilla.com at Thu, 13 Dec 2018 17:21:43 +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.
20d92a98e3a3: 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 450392
Push 110492 by nfroyd@mozilla.com at Thu, 13 Dec 2018 17:21:43 +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.
ff944ef6b8a4: 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 450391
Push 110492 by nfroyd@mozilla.com at Thu, 13 Dec 2018 17:21:43 +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.
a356b2566ae2: 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 450268
Push 110469 by nfroyd@mozilla.com at Wed, 12 Dec 2018 19:57:47 +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.
4bb5dd072865: 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 450267
Push 110469 by nfroyd@mozilla.com at Wed, 12 Dec 2018 19:57:47 +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.
a6657732fdbe: 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 450266
Push 110469 by nfroyd@mozilla.com at Wed, 12 Dec 2018 19:57:47 +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.
09493e80dbe7: Bug 1512410 part 2 - Don't create a TypeNewScript for cross-realm constructors, add more asserts. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Sat, 08 Dec 2018 18:10:29 +0000 - rev 449663
Push 110408 by rgurzau@mozilla.com at Sat, 08 Dec 2018 21:37:52 +0000
Bug 1512410 part 2 - Don't create a TypeNewScript for cross-realm constructors, add more asserts. r=luke Depends on D13903 Differential Revision: https://phabricator.services.mozilla.com/D13904
c24a1c1237ba: Bug 1512410 part 1 - Add a realm check to the NewObjectCache to fix a bug with same-compartment realms. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Sat, 08 Dec 2018 18:06:17 +0000 - rev 449662
Push 110408 by rgurzau@mozilla.com at Sat, 08 Dec 2018 21:37:52 +0000
Bug 1512410 part 1 - Add a realm check to the NewObjectCache to fix a bug with same-compartment realms. r=luke Differential Revision: https://phabricator.services.mozilla.com/D13903