- 19 Sep, 2018 25 commits
-
-
Sigurd Schneider authored
This CL ensures that ConstructBoundFunction and ConstructedNonConstructable preserve the kRootRegister (ebx). Bug: v8:6666 Change-Id: I5aaee07aee9377f62028c98ccc8c6fdfe23dbc6d Reviewed-on: https://chromium-review.googlesource.com/1233615 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56033}
-
Benedikt Meurer authored
Make the RedundancyElimination handle all simplified operators that are listed in the SIMPLIFIED_CHECKED_OP_LIST, and fix a couple of bugs and oversights in the code. This also adds a lot of test coverage for all the cases that we care about in RedundancyElimination (with respect to Check/Checked simplified operators). Bug: v8:8015 Change-Id: I57d29113389841b09abcd013313bf5dd1c67735f Reviewed-on: https://chromium-review.googlesource.com/1233655Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56032}
-
Leszek Swirski authored
This reverts commit 3bb5cb63. Reason for revert: Breaks Win64 bot https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/26418 Original change's description: > [wasm] Introduce a soft limit on reserved memory > > Currently, wasm memory and wasm code use a shared limit for the total > size of reservations. This can cause wasm code reservations to fail > because wasm memories used all available reservation space. > This CL introduces a soft limit which is used when allocating wasm > memory with full guards. If this limit is reached and the respective > flag is set, we fall back to allocation without full guards and check > against the hard limit. Code reservations always check against the hard > limit. > > R=ahaas@chromium.org > > Bug: v8:8196 > Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d > Reviewed-on: https://chromium-review.googlesource.com/1233614 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56028} TBR=ahaas@chromium.org,clemensh@chromium.org Change-Id: If645e738b4a5800eceabd993738ac2285f4a63bc No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8196 Reviewed-on: https://chromium-review.googlesource.com/1233834Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56031}
-
Marja Hölttä authored
Unification: now BodyDescriptor deals with all weakness types. This doesn't replace the weak list pointers with in-place weak references, since it would cause extra work: we anyway recreate the lists after GC, so we shouldn't track them at all during GC. BUG=v8:7308 Change-Id: Ifb2f573d3e7ee311136b59e185cc659487c9cab3 Reviewed-on: https://chromium-review.googlesource.com/1229894Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#56030}
-
Georg Neis authored
Instead, remember the canonical handle during SerializeStandardObjects. Bug: v8:7790 Change-Id: Id57d861e92088fbc64c05fbee1612376000c06c9 Reviewed-on: https://chromium-review.googlesource.com/1233494Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56029}
-
Clemens Hammacher authored
Currently, wasm memory and wasm code use a shared limit for the total size of reservations. This can cause wasm code reservations to fail because wasm memories used all available reservation space. This CL introduces a soft limit which is used when allocating wasm memory with full guards. If this limit is reached and the respective flag is set, we fall back to allocation without full guards and check against the hard limit. Code reservations always check against the hard limit. R=ahaas@chromium.org Bug: v8:8196 Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d Reviewed-on: https://chromium-review.googlesource.com/1233614Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56028}
-
Michael Achenbach authored
TBR=sathya@chromium.org NOTRY=true Bug: v8:8197 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I3bb3f8e551e34ba3a1b5d05703121989ecfe4e3c Reviewed-on: https://chromium-review.googlesource.com/1233734 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56027}
-
Stephan Herhut authored
When module instantiation fails, we need to throw an exception or raise an error additionally to just returning an empty handle. This change adds an extra DCHECK to make sure this is not forgotten. Bug: v8:8015 Change-Id: Ib5d580ccfa2fb689e01c2bdabe856c8c4a47a853 Reviewed-on: https://chromium-review.googlesource.com/1233259Reviewed-by:
-
Clemens Hammacher authored
This is a reland of 15d6d7b4. Original change's description: > [wasm] Increase code space limit to 1024 MB > > Liftoff increases code size, and people start deploying bigger modules. > Increase the wasm code space limit from 512 MB to 1024 MB to account > for this. > > R=titzer@chromium.org > > Bug: chromium:883639, chromium:872684 > Change-Id: I3a2ca29d456635f7f3aa1daef5fa2b0249dc1645 > Reviewed-on: https://chromium-review.googlesource.com/1226971 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56003} TBR=titzer@chromium.org Bug: chromium:883639, chromium:872684 Change-Id: I54461d2a5f32eeaf90c71768eb9f37223dd5ebb6 Reviewed-on: https://chromium-review.googlesource.com/1233256Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56025}
-
Creddy authored
IIFE`s within a function are not guaranteed to be executed only once. They can be called multiple times and compiler can inline them. Do the one-shot optimizations only for IIFE`s from top-level code. Bug: v8:8072, chromium:886580 Change-Id: I02370681cc3eab270edcc75ee120ca7ad768ed52 Reviewed-on: https://chromium-review.googlesource.com/1231174 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#56024}
-
Simon Zünd authored
This CL is part of the effort to remove the usage of 'ebx' as it will be the kRootRegister on ia32. R=jgruber@chromium.org Bug: v8:6666 Change-Id: Iad3d4718423a22790908d5028b2ec9e8b2253126 Reviewed-on: https://chromium-review.googlesource.com/1233258Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#56023}
-
Benedikt Meurer authored
Teach TurboFan about representation changes from Float64 to Word64 where the input value is already known to be within the Int64 or Uint64 range. While not all of these values have representations in Float64, those that do can be converted to Word64 without loss of precision. Same is true for Tagged to Word64 conversions, although here we don't (currently) need the case for Uint64 ranges, so we can skip adding an operator for that until it becomes necessary (there's a hard check in the code so it'll not silently cause trouble). Bug: v8:8178 Change-Id: Ie99b0bc9af096bd927f63b26b0a61e66454bc4ae Reviewed-on: https://chromium-review.googlesource.com/1231593Reviewed-by:
-
Maya Lekova authored
This CL implements the following design doc: https://docs.google.com/document/d/1h5kdfemMQMpUd15PSKW1lqikJW5hsGwrmOvoqhGFRts/edit?ts=5b978756#heading=h.urs7r34mx9p Bug: v8:7790 Change-Id: I5f758c6d906ea9275c30b28f339063c64a2dc8d8 Reviewed-on: https://chromium-review.googlesource.com/1221807Reviewed-by:
-
Sigurd Schneider authored
Change-Id: I09cb1ea773c84891cefc54e8bc016b5b201280bd Bug: v8:7327 NOTRY=true Change-Id: I09cb1ea773c84891cefc54e8bc016b5b201280bd Reviewed-on: https://chromium-review.googlesource.com/1227973Reviewed-by:
-
Benedikt Meurer authored
The JSTypedArray instance is created early on in the TypedArray constructors, using EmitFastNewObject, which puts Undefined into all slots. But the code might still produce an exception afterwards leaving the JSTypedArray in a weird state. It's not a security issue since the object doesn't escape, but it confuses the heap verifier. Bug: chromium:885404, v8:4153, v8:7881, v8:8171 Change-Id: I5fb8131fcae69edf4a92602ed477dca305c3d6c7 Reviewed-on: https://chromium-review.googlesource.com/1233257 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56019}
-
Michael Lippautz authored
The flag was not used anymore and any CollectGarbage call will finalize marking. Change-Id: I29ee60b187c9038acc4b42b8334546498f54f117 Reviewed-on: https://chromium-review.googlesource.com/1228013Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#56018}
-
Yang Guo authored
This is a reland of f4c14fd9 TBR=jgruber@chromium.org Original change's description: > [regexp] implement regexp property sequence proposal > > Also-By: mathias@chromium.org > Bug: v8:7467 > Change-Id: I9fd6e61f4da1097c2375f671b4801e9730f792c4 > Reviewed-on: https://chromium-review.googlesource.com/1227974 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Mathias Bynens <mathias@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55991} Bug: v8:7467 Change-Id: If07137dea5a8ea42dbff1d749d997eb4ae055d80 Reviewed-on: https://chromium-review.googlesource.com/1232634Reviewed-by:
-
Jaroslav Sevcik authored
Bug: chromium:856973 Change-Id: Ib0feeb18e27dc455ecf8547b3dd5bd284c39735a Reviewed-on: https://chromium-review.googlesource.com/1225899Reviewed-by:
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: Ibc5a81aea25f797e90db891e90b2977f27e13990 Reviewed-on: https://chromium-review.googlesource.com/1224410 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by:
-
Yang Guo authored
This reverts commit 15d6d7b4. Reason for revert: speculative revert for this failure: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8934981003100286416/+/steps/Check/0/logs/Fixed/0 Original change's description: > [wasm] Increase code space limit to 1024 MB > > Liftoff increases code size, and people start deploying bigger modules. > Increase the wasm code space limit from 512 MB to 1024 MB to account > for this. > > R=titzer@chromium.org > > Bug: chromium:883639, chromium:872684 > Change-Id: I3a2ca29d456635f7f3aa1daef5fa2b0249dc1645 > Reviewed-on: https://chromium-review.googlesource.com/1226971 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56003} TBR=titzer@chromium.org,clemensh@chromium.org Change-Id: I77b3eb694edef122fb3467ca1938c5aff833911d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:883639, chromium:872684 Reviewed-on: https://chromium-review.googlesource.com/1232958Reviewed-by:
-
Clemens Hammacher authored
The test allocates a code object of maximum size. This was recently increased to 1GB. This makes the test run OOM on some native arm and mips devices. TBR=ahaas@chromium.org No-Try: true Change-Id: Ie6cc50e92493c341c3205e9a6efa547d3d489275 Reviewed-on: https://chromium-review.googlesource.com/1233333 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
tzik authored
This CL introduces the global default microtask queue as the replacement of Heap::microtask_queue and Isolate::pending_microtask_count. Bug: v8:8124 Change-Id: I0a6a7618a1a6ca7ceaf370dc15917a6b3690542c Reviewed-on: https://chromium-review.googlesource.com/1226760Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Cr-Commit-Position: refs/heads/master@{#56012}
-
Camillo Bruni authored
Change-Id: Ie741a8e4452b6d65ec73bd91ecdea869d7eedc25 BUG: v8:8192 Reviewed-on: https://chromium-review.googlesource.com/1230100 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56011}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c4b8ad9..786a3d9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/460fd88..c968ea0 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ea4301e..79c6513 Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/0953bbd..dc90d99 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I524678f69b7810ce492d73395178067024c6237f Reviewed-on: https://chromium-review.googlesource.com/1232692Reviewed-by:
V8 Autoroller <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: V8 Autoroller <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#56010}
-
Michael Lippautz authored
V8 does not abort incremental marking anymore. Bug: chromium:843903 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Id39e9cf8ef2afc388bab2bbad1d458ee2649f8e8 Reviewed-on: https://chromium-review.googlesource.com/1226889Reviewed-by:
-
- 18 Sep, 2018 15 commits
-
-
Benedikt Meurer authored
This is the next step to support large array buffers. On 64-bit archs the full safe integer range is available (up to 2^53-1 bytes in theory). On 32-bit platforms the full Unsigned31 range is allowed, so that we can continue to use CheckBounds for typed arrays and data views in the optimizing compiler (it's generally unlikely that the kernel will give you more than 1GiB of contiguous memory anyways). Drive-by-fix: This introduces proper chokepoints for the byte_offset and byte_length accesses in the CSA code, and also does some renaming for consistency. Bug: v8:4153, v8:7881, v8:8171 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I92a767638532ca9f86084398ce72556c5180cc6e Reviewed-on: https://chromium-review.googlesource.com/1228377Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Ali Ijaz Sheikh authored
This is a reland of bf5ea813 Original change's description: > [tracing] allow dynamic control of tracing > > If the trace_buffer_ was null, we were returning a pointer to a static > flag back that permanently disabled that particular trace point. > > This implied an assumption that tracing will be statically enabled at > process startup, and once it is disabled, it will never be enabled > again. On Node.js side we want to dynamically enable/disable tracing as per > programmer intent. > > Change-Id: Ic7a7839b8450ab5c356d85e8e0826f42824907f4 > Reviewed-on: https://chromium-review.googlesource.com/1161518 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> > Cr-Commit-Position: refs/heads/master@{#54903} Change-Id: Ie2a9ebbaf59d3be1918864cc3c192671fb5550c3 Reviewed-on: https://chromium-review.googlesource.com/1188529 Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-by:
-
Benedikt Meurer authored
For 64-bit indices it's not safe to pass Truncation::Word32() for indices, as operations will incorrectly truncate the outputs to 32-bit integers. There's also not really a point in not passing Truncation::Any(), but it might have performance impact (since we misuse IsUsedAsWord32 in various places). Bug: v8:8178 Change-Id: Ie33b8e03a82e46e314dfb3f268c74c9356653aec Reviewed-on: https://chromium-review.googlesource.com/1230653Reviewed-by:
-
Ali Ijaz Sheikh authored
Change-Id: Icf7ff0661cb5d5866af0ffa7bd4aa3d78da84754 Reviewed-on: https://chromium-review.googlesource.com/1228419Reviewed-by:
-
Deepti Gandluri authored
Handle the case when one or both of the output nodes of an I64Atomic op are optimized, for code-gen instructions that use a set of fixed registers, use temp registers to ensure the registers are not clobbered. BUG:v8:6532 Change-Id: I52763c48d615cdf3ae8d754402b11da2df31a4a1 Reviewed-on: https://chromium-review.googlesource.com/1195910Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#56004}
-
Clemens Hammacher authored
Liftoff increases code size, and people start deploying bigger modules. Increase the wasm code space limit from 512 MB to 1024 MB to account for this. R=titzer@chromium.org Bug: chromium:883639, chromium:872684 Change-Id: I3a2ca29d456635f7f3aa1daef5fa2b0249dc1645 Reviewed-on: https://chromium-review.googlesource.com/1226971 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Hannes Payer authored
Change-Id: I93726a98978b8b18a16a253f55fc698704d27be4 Reviewed-on: https://chromium-review.googlesource.com/1228376 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
The WasmMemoryTracker keeps track of reserved memory in order to avoid running out of virtual address space. So far, we were only tracking reservations for wasm memory, and not for code. This CL changes that to also include code reservations. Drive-by: Some cleanup around the allocation of the WasmCodeManager. R=titzer@chromium.org Bug: chromium:883639 Change-Id: I0c2586a742022ae00752132e048346d54e2a1a7c Reviewed-on: https://chromium-review.googlesource.com/1230134Reviewed-by:
-
Jakob Gruber authored
This CL is the first in a series of work that will remove ebx (the new kRootRegister) use from all ia32 ASM builtins and stubs. Bug: v8:6666 Change-Id: If417f1194a27ddae9e38d50e0a651dfc129e8b05 Reviewed-on: https://chromium-review.googlesource.com/1230095Reviewed-by:
-
Jakob Gruber authored
Indirect calls need a scratch register to load the target address. On ia32 there's no easily-available scratch register. This removes invalid code and documents a potential solution. But ideally, this will remain unreachable since all inter-builtin calls will be pc-relative. Bug: v8:6666 Change-Id: I19e0ac699ee4757e3d5ec130b3e34a67cd1f851c Reviewed-on: https://chromium-review.googlesource.com/1230096Reviewed-by:
-
Michael Starzinger authored
This fixes a race on the {WasmCodeManager::lookup_map} data structure when requesting more code memory on architectures for which we have the corresponding {kCanAllocateMoreMemory} flag set. Note that there is no TSAN coverage for these architectures. R=clemensh@chromium.org BUG=chromium:875189 Change-Id: I11a082359b4cb6cc69c3168a956c5152f1dcc833 Reviewed-on: https://chromium-review.googlesource.com/1230136 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: -
Georg Neis authored
This function was only used in one place and its name was confusing because it was fundamentally different from the other Serialize functions. Bug: v8:7790 Change-Id: I2af384e41ecc2d97e644e6797a4200e00e840b23 Reviewed-on: https://chromium-review.googlesource.com/1230099 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This reverts commit f4c14fd9. Reason for revert: Breaks noi18n build Original change's description: > [regexp] implement regexp property sequence proposal > > Also-By: mathias@chromium.org > Bug: v8:7467 > Change-Id: I9fd6e61f4da1097c2375f671b4801e9730f792c4 > Reviewed-on: https://chromium-review.googlesource.com/1227974 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Mathias Bynens <mathias@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55991} TBR=yangguo@chromium.org,jgruber@chromium.org,mathias@chromium.org Change-Id: I10c67ad3ade35af920d32a7eea8ae0297677fa07 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7467 Reviewed-on: https://chromium-review.googlesource.com/1230137Reviewed-by:
-
Sergiy Byelozyorov authored
It is moved to a recipe module as a resource in https://crrev.com/i/678188. R=machenbach@chromium.org Bug: chromium:880732 Change-Id: If64b349d92d5da8452b32474d9d0c22d18155bc8 Reviewed-on: https://chromium-review.googlesource.com/1222126Reviewed-by:
-
Georg Neis authored
This removes the last unconditional read accesses to the heap, but required a significant refactoring. - Remove HeapObjectRef::type(). - Change HeapObjectData::Is* testers to look at the instance type in HeapObjectData::map(). - Remove ObjectRef::oddball_type() - Add MapRef::oddball_type() - Add MapRef::is_undetectable(). - Add MapRef::is_callable(). - Remove JSHeapBroker::HeapObjectTypeFromMap() - Remove Type::For(JSHeapBroker*, Handle<Map>) - Add BitsetType::Lub(MapRef). - Add Type::For(MapRef). - Add Type::For(HeapObjectType). - Add HeapObjectRef::GetHeapObjectType(). THIS IS TEMPORARY. As the last item suggests, I couldn't actually remove the HeapObjectType class yet. See the explanation in the code. Bug: v8:7790 Change-Id: I508e4bd5337277b0050f2204392fc36f41032fe9 Reviewed-on: https://chromium-review.googlesource.com/1228033Reviewed-by:
-
