searching for reviewer(luke)
64ac5acae26bd63323e2f62890eae27380119bb3: Bug 1546544 - Reduce navigator.hardwareConcurrency to account for TCSM r=luke
Haik Aftandilian <haftandilian@mozilla.com> - Tue, 07 May 2019 22:16:28 +0000 - rev 531821
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1546544 - Reduce navigator.hardwareConcurrency to account for TCSM r=luke Differential Revision: https://phabricator.services.mozilla.com/D29437
d4b67960c0f921396353762c413b0bd2ef234cb0: Bug 1546544 - Reduce navigator.hardwareConcurrency to account for TCSM r=luke
Haik Aftandilian <haftandilian@mozilla.com> - Mon, 06 May 2019 06:09:11 +0000 - rev 531589
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1546544 - Reduce navigator.hardwareConcurrency to account for TCSM r=luke Differential Revision: https://phabricator.services.mozilla.com/D29437
fd41eefaf1b95320034e755a8b773de4781d62fc: Bug 1545086: Merge wasm exported function info to not overwrite the explicit bit; r=luke
Benjamin Bouvier <benj@benj.me> - Fri, 19 Apr 2019 11:51:14 +0200 - rev 529745
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1545086: Merge wasm exported function info to not overwrite the explicit bit; r=luke Differential Revision: https://phabricator.services.mozilla.com/D28068
4ff589e86c0a0c5c9a36c3876977633eedbab153: Bug 1542130 - Fix asm.js check in PrivateScriptData::Clone to check for realms instead of compartments. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Mon, 08 Apr 2019 09:30:23 +0000 - rev 527142
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1542130 - Fix asm.js check in PrivateScriptData::Clone to check for realms instead of compartments. r=luke Differential Revision: https://phabricator.services.mozilla.com/D26318
a3b68989fb59cf0c0a29d95f3955ee8239b2c51b: Bug 1540944 - Get new group from the correct realm in SetProto. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 02 Apr 2019 19:41:07 +0000 - rev 526575
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1540944 - Get new group from the correct realm in SetProto. r=luke Differential Revision: https://phabricator.services.mozilla.com/D25803
320b3be39f9f96014157d09cee445e5dd6b64f26: Bug 1535482 - Limit the assembler buffer size to encodable offsets. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Mar 2019 08:41:52 +0100 - rev 524734
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1535482 - Limit the assembler buffer size to encodable offsets. r=luke Several closely interrelated changes: - Introduce a platform-specific constant to limit the size of the assembler buffer so that it cannot grow larger than what is representable in our branch/label logic, see large comment in the patch itself for more. It turns out this constant is only interesting on ARM and ARM64. When the max size is exceeded, signal OOM. - As fallout from that, remove all the "bail()" logic from the IonAssemblerBuffer because it is now impossible to get into a situation where we bail - bailing was a consequence of having too long a distance between a branch and its target. Leave release asserts in their place. - Propagate the oom() value from the IonAssemblerBuffer up to the JitContext so that the debugging logic in ~Label() can see whether OOM occurred or not. As it was (and this was the cause for this bug) we would have false positives because OOMs and bails in the IonAssemblerBuffer were hidden from ~Label(). - When appending a function's code to a compilation task, make sure we check for task size overflow first, in an effort to ensure that we never will need to generate so much machine code that we might go over the assembler buffer. - Perform call linking also before linking in stubs code, since otherwise it is much more likely that we'll fail to patch up far jumps properly when the stubs code is large. - Lift the assembler buffer limit on the buffer that is used for the final pasteup, since we manage far jumps explicitly for this buffer and it's normal for it to be much larger than a standard buffer. We still have to deal with the problem where the stubs code is larger than a single assembler buffer, but this problem is no worse than before so it's being handled separately. Differential Revision: https://phabricator.services.mozilla.com/D24164
8a5f78452005e5d4c692872e9ff3492cc97ca39e: Bug 1535482 - Limit the assembler buffer size to encodable offsets. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Mar 2019 08:41:52 +0100 - rev 524732
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1535482 - Limit the assembler buffer size to encodable offsets. r=luke Several closely interrelated changes: - Introduce a platform-specific constant to limit the size of the assembler buffer so that it cannot grow larger than what is representable in our branch/label logic, see large comment in the patch itself for more. It turns out this constant is only interesting on ARM and ARM64. When the max size is exceeded, signal OOM. - As fallout from that, remove all the "bail()" logic from the IonAssemblerBuffer because it is now impossible to get into a situation where we bail - bailing was a consequence of having too long a distance between a branch and its target. Leave release asserts in their place. - Propagate the oom() value from the IonAssemblerBuffer up to the JitContext so that the debugging logic in ~Label() can see whether OOM occurred or not. As it was (and this was the cause for this bug) we would have false positives because OOMs and bails in the IonAssemblerBuffer were hidden from ~Label(). - When appending a function's code to a compilation task, make sure we check for task size overflow first, in an effort to ensure that we never will need to generate so much machine code that we might go over the assembler buffer. - Perform call linking also before linking in stubs code, since otherwise it is much more likely that we'll fail to patch up far jumps properly when the stubs code is large. - Lift the assembler buffer limit on the buffer that is used for the final pasteup, since we manage far jumps explicitly for this buffer and it's normal for it to be much larger than a standard buffer. We still have to deal with the problem where the stubs code is larger than a single assembler buffer, but this problem is no worse than before so it's being handled separately. Differential Revision: https://phabricator.services.mozilla.com/D24164
52041aed6398f0139a2d2eafb4ce0306ca0d9726: Bug 1535194 - Always check error return from BufferOffset::diffB. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Mar 2019 16:10:58 +0100 - rev 524729
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +0000
Bug 1535194 - Always check error return from BufferOffset::diffB. r=luke 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
f285d37402e2d138d4567e623c6a578e942ff8e5: 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 524235
Push 11265 by ffxbld-merge at Mon, 13 May 2019 10:53:39 +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
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 523028
Push 11031 by archaeopteryx@coole-files.de at Mon, 08 Apr 2019 10:37:16 +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 522977
Push 11012 by dvarga@mozilla.com at Fri, 05 Apr 2019 19:46:08 +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 522071
Push 10871 by cbrindusan@mozilla.com at Mon, 18 Mar 2019 15:49:32 +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 522064
Push 10871 by cbrindusan@mozilla.com at Mon, 18 Mar 2019 15:49:32 +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 521429
Push 10866 by nerli@mozilla.com at Tue, 12 Mar 2019 18:59:09 +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 521000
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 520089
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 519160
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 518866
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 518347
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 518075
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517751
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517685
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517422
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517416
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517415
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517414
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 517004
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 516599
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 516409
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 516332
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 515436
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 515435
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 515320
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 515319
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 515225
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 514186
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 514185
Push 10862 by ffxbld-merge at Mon, 11 Mar 2019 13:01:11 +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 513308
Push 10793 by apavel@mozilla.com at Wed, 27 Feb 2019 22:36:04 +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 512564
Push 10566 by archaeopteryx@coole-files.de at Mon, 28 Jan 2019 12:41:12 +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 512501
Push 10566 by archaeopteryx@coole-files.de at Mon, 28 Jan 2019 12:41:12 +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 512436
Push 10566 by archaeopteryx@coole-files.de at Mon, 28 Jan 2019 12:41:12 +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 511189
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 511169
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 511004
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 510831
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 510132
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 510131
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 510001
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 509396
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +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 509392
Push 10547 by ffxbld-merge at Mon, 21 Jan 2019 13:03:58 +0000
Bug 1515010 - Update core wasm tests; r=luke