- 29 Aug, 2017 28 commits
-
-
Michael Starzinger authored
This simplfies the code for lowering of {JSCreateArguments} nodes under the assumption that deoptimization support is always enabled, and that arguments objects are only materialized for JavaScript frames and not for internal stub frames. R=tebbi@chromium.org Change-Id: I5f86ae0f0442a03b516904d737c5a0eac293b5b9 Reviewed-on: https://chromium-review.googlesource.com/640381Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47685}
-
jgruber authored
Crashes are still happening despite tentative fixes, but unfortunately without a local repro. This adds a couple of additional checks to help flush out the root cause. TBR=yangguo@chromium.org Bug: chromium:754422 Change-Id: Ib3c8a2e0271fc724a4351ce6aec8298cf520a20a Reviewed-on: https://chromium-review.googlesource.com/640691Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47684}
-
Jeremy Roman authored
Chromium side: https://chromium-review.googlesource.com/c/chromium/src/+/639552 Bug: chromium:759831 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I1b217c4fa4c930733dcfab982879bf41936a3a83 Reviewed-on: https://chromium-review.googlesource.com/639551 Commit-Queue: Jeremy Roman <jbroman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47683}
-
Ulan Degenbaev authored
The current processing of a transition array is not safe because the targets in the array have conditional weakness, which can change concurrently. Bug: chromium:694255 Change-Id: I86bf7151af39307dc4101a0b0ca02ef7c704df53 Reviewed-on: https://chromium-review.googlesource.com/641410Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47682}
-
Peter Marshall authored
Bug: v8:6333 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iabaef0e63c81db503eb2f19bf63a1f77313f2a5a Reviewed-on: https://chromium-review.googlesource.com/635591 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47681}
-
Clemens Hammacher authored
{info->optimization_id()} DCHECKS that {info->IsOptimizing()} is true. Hence, it fails for graphs generated from wasm code. The bug was introduced in https://chromium-review.googlesource.com/c/v8/v8/+/592028. R=mstarzinger@chromium.org CC=leszeks@chromium.org Change-Id: Ic192017fd7801797eb9ec7adc67a4bf94d219a7a Reviewed-on: https://chromium-review.googlesource.com/640951Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47680}
-
Andreas Haas authored
Originally the call to RelocatableMemoryReferences() in WasmCompiledModule::Reset() was guarded behind a condition.This condition, however, is redundant, because it is checked later again when the code is patched. This CL removes the check in WasmCompiledModule::Reset(). R=clemensh@chromium.org Change-Id: I10d277072f2223c2e067789a1efc3bd259f0ce5e Reviewed-on: https://chromium-review.googlesource.com/640709 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47679}
-
Clemens Hammacher authored
This is a reland of 6b4dc039 Original change's description: > [wasm] Refactor function body decoder > > This refactoring separates graph building from wasm decoding. The > WasmGraphBuilder is just a consumer of the decoded information. > Decoding without any consumer (i.e. just validation) gets 16% faster by > this refactoring, because no TFNode* have to be stored in the value > stack, and all dynamic tests to determine whether the graph should be > build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after: > 92.2 +- 3.1 ms). > > This new design will allow us to also attach other consumers, e.g. a > new baseline compiler. > > R=titzer@chromium.org > > Bug: v8:6600 > Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54 > Reviewed-on: https://chromium-review.googlesource.com/571010 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47671} TBR=titzer@chromium.org Bug: v8:6600 Change-Id: Idd867c5a1917437de5b6e3de5917cc1c9f194489 Reviewed-on: https://chromium-review.googlesource.com/640591Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47678}
-
Clemens Hammacher authored
It's disabled in gn and on several platforms, so also disable it for linux systems in general. R=machenbach@chromium.org Change-Id: Id5d0e5d30cc27c449d05352df6dd0aade5d9e6fd Reviewed-on: https://chromium-review.googlesource.com/640708Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47677}
-
Michael Starzinger authored
This adds support to specify the maximum memory size when building a WebAssembly module. Default is not maximum, one can be explicitly set. It is mainly used by the WebAssembly fuzzers to prevent OOMs. R=ahaas@chromium.org BUG=chromium:759973 Change-Id: Ibf5fa63a7e36e5f3b65ced528c73a65355d5632f Reviewed-on: https://chromium-review.googlesource.com/640386Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47676}
-
Jaroslav Sevcik authored
Bug: v8:5267 Change-Id: Ib93b4e5110061a0dcae0a6879f5d0e878cf1bf3f Reviewed-on: https://chromium-review.googlesource.com/640704 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47675}
-
Enrico Bacis authored
This CL introduces 4 test that verify that the effects of a grow_memory instruction executed in a function invoked inside a loop are visible also when the loop is over. This is needed because the AnalyzeLoopAssignment method in function-body-decoder.cc is creating Phi nodes only for variables assigned inside the loop. The test cases introduced by this CL verify that the mem_size and mem_start variables are always correct. The tests verify the output of the current_memory instruction and the result of loading a variable stored in the grown memory inside the loop in the following cases: * the memory is grown in a directly called function inside a loop; * the memory is grown in an indirectly called function inside a loop. R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org Change-Id: I2992bf4086b5eac9580c87e2e0ca06364b99714c Reviewed-on: https://chromium-review.googlesource.com/637911Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Enrico Bacis <enricobacis@google.com> Cr-Commit-Position: refs/heads/master@{#47674}
-
Mythri authored
We reset profiler ticks when the feedback changes so that we could tier up functions with more stable feedback. We missed resetting these ticks for call / construct bytecodes. This cl fixes it. Bug: Change-Id: Ia912dfee0495c776d9fc517a887a2fdd999773ab Reviewed-on: https://chromium-review.googlesource.com/635846Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#47673}
-
Clemens Hammacher authored
This reverts commit 6b4dc039. Reason for revert: Mips build failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/11749 Original change's description: > [wasm] Refactor function body decoder > > This refactoring separates graph building from wasm decoding. The > WasmGraphBuilder is just a consumer of the decoded information. > Decoding without any consumer (i.e. just validation) gets 16% faster by > this refactoring, because no TFNode* have to be stored in the value > stack, and all dynamic tests to determine whether the graph should be > build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after: > 92.2 +- 3.1 ms). > > This new design will allow us to also attach other consumers, e.g. a > new baseline compiler. > > R=titzer@chromium.org > > Bug: v8:6600 > Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54 > Reviewed-on: https://chromium-review.googlesource.com/571010 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47671} TBR=titzer@chromium.org,clemensh@chromium.org Change-Id: I76a50e355f0390cc53a2da4ceedd8830ca20a9c6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6600 Reviewed-on: https://chromium-review.googlesource.com/640870Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47672}
-
Clemens Hammacher authored
This refactoring separates graph building from wasm decoding. The WasmGraphBuilder is just a consumer of the decoded information. Decoding without any consumer (i.e. just validation) gets 16% faster by this refactoring, because no TFNode* have to be stored in the value stack, and all dynamic tests to determine whether the graph should be build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after: 92.2 +- 3.1 ms). This new design will allow us to also attach other consumers, e.g. a new baseline compiler. R=titzer@chromium.org Bug: v8:6600 Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54 Reviewed-on: https://chromium-review.googlesource.com/571010 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47671}
-
Jaroslav Sevcik authored
Bug: v8:5267 Change-Id: Ib103fbc3cabaac191dde817724308b19361c443b Reviewed-on: https://chromium-review.googlesource.com/640385Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47670}
-
Jaroslav Sevcik authored
Bug: chromium:758983 Change-Id: Iea65c6c6330b4eed0969eee1f8b261e1446771f5 Reviewed-on: https://chromium-review.googlesource.com/640382 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47669}
-
Jaroslav Sevcik authored
This removes overflow check in addition when we have Smi or Int32 feedback for the addition, and the result is truncated to word32. Here is an example, assuming that we passed only integers to this function so far. function f(a) { return a + 1 | 0; } If the result of the addition is word32-truncated, there is no need for an overflow check. Until now, we would only eliminate the overflow check if we knew that the static types of the inputs guaranteed that the result is in safe integer range. With this CL, we use the checked type from the feedback, too (but we do not propagate the truncation!). Bug: v8:5267,v8:6764 Change-Id: Ia2f929600758f58e6e7db52fef638a0e56c936a9 Reviewed-on: https://chromium-review.googlesource.com/635083 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47668}
-
Andreas Haas authored
R=titzer@chromium.org Change-Id: I637cbafc99caf1ada1d92d41f7796cf5551bc532 Reviewed-on: https://chromium-review.googlesource.com/588895 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47667}
-
Alexei Filippov authored
Make sure there is a matching Leave for each Enter. Otherwise it ends up with a dead stack-allocated object in the timer chain. The patch incorporates the following fixes: - RuntimeCallTimerScope::RuntimeCallTimerScope(HeapObject* ...) did create a local object instead of calling an overloaded constructor. - InterpreterCompilationJob::ExecuteJobImpl made an implicit call to a default copy constructor of TimerScope which led to a single Enter was made per two Leaves. - InterpreterCompilationJob::FinalizeJobImpl was calling RuntimeCallTimerScope from a background thread, which caused timer scopes become unbalanced. - RuntimeCallTimerScope constructors were put into counters-inl.h which is not included into most usages of RCS. That led to a suboptimal performance. - Added thread check into Enter and Leave BUG=chromium:669329 Change-Id: Ib5cff0e02e0b6c8b56a03ca3a5ebc37d93fcde55 Reviewed-on: https://chromium-review.googlesource.com/637307Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#47666}
-
Andreas Haas authored
When we use a WasmCompiledModule for a second instance (i.e. the first instance has been collected already by the GC), we reset all instance specialization data the WasmCompiledModule contains, and then patch in the new instance specialization data. However, we guarded the reset of memory references, and in the referenced issue the memory references were not reset and therefore later patched incorrectly during instantiation. With this CL we change the condition and reset now every time the current version of a WasmCompiledModule contains non-default values. R=mtrofin@chromium.org CC=mstarzinger@chromium.org TEST=mjsunit/regress/regress-crbug-759327 Bug: chromium:759327 Change-Id: I9a147afd6ad4000b782850dae0b90685759c9dc7 Reviewed-on: https://chromium-review.googlesource.com/638571 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47665}
-
Marja Hölttä authored
This won't affect the real release but will give more clusterfuzz + test coverage on V8 side. BUG=v8:5516 Change-Id: I6ed29b1a1b23b5bf1ce9a9a9dfe741c53312ee54 Reviewed-on: https://chromium-review.googlesource.com/640373Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47664}
-
Peter Marshall authored
Bug: v8:6333 Change-Id: I6292bc6b31c696dddd3e3361a519e7275404b144 Reviewed-on: https://chromium-review.googlesource.com/631879Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#47663}
-
Michael Achenbach authored
Change-Id: I6e61dd1e4173432d38cc546a102f6843021866c2 Reviewed-on: https://chromium-review.googlesource.com/640374Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47662}
-
Michael Achenbach authored
This reverts commit de839c56. Reason for revert: Breaks chromium compilation, e.g.: https://build.chromium.org/p/client.v8.fyi/builders/Linux%20Debug%20Builder/builds/6010 Original change's description: > Inspector: Runtime.callFunctionOn to accept executionContextId > > This patch: > - teaches Runtime.callFunctionOn to accept executionContextId instead of > objectId. > - adds the optional objectGroup parameter to the Runtime.callFunctionOn. > > R=kozy > > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel > Change-Id: Ia29ee37f37a1e8cbe2d9f15ae75e841534ecf727 > Reviewed-on: https://chromium-review.googlesource.com/639751 > Reviewed-by: Pavel Feldman <pfeldman@chromium.org> > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47659} TBR=lushnikov@chromium.org,pfeldman@chromium.org,kozyatinskiy@chromium.org Change-Id: I2586a6accde6c1f79d628b8999d90222b5714dc1 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Reviewed-on: https://chromium-review.googlesource.com/640590Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47661}
-
Jaroslav Sevcik authored
Bug: v8:5267 Change-Id: I0a94b1c2df3d5d0871e36c0f688a5d7d88179a09 Reviewed-on: https://chromium-review.googlesource.com/640370 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47660}
-
Andrey Lushnikov authored
This patch: - teaches Runtime.callFunctionOn to accept executionContextId instead of objectId. - adds the optional objectGroup parameter to the Runtime.callFunctionOn. R=kozy Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia29ee37f37a1e8cbe2d9f15ae75e841534ecf727 Reviewed-on: https://chromium-review.googlesource.com/639751Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org> Cr-Commit-Position: refs/heads/master@{#47659}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2887ee5..48a2b7b Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/68a8df6..7149cbf TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: Ib8667ab4ff0b2310f725a0942732ac861d25b57a Reviewed-on: https://chromium-review.googlesource.com/640350Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#47658}
-
- 28 Aug, 2017 12 commits
-
-
Mircea Trofin authored
The validator was trying to finalize virtual register assignments in phi cases, however, since phis may create aliases, we ended up with an unnecessarily complex design that was the source of pretty much all validator bugs since its introduction. This change embraces the fact that phis may create aliases: pending assessments (==phis) carry a bag of aliased virtual registers. Bug: chromium:758778 Change-Id: Ib7ded350a726fbc77e9d0ff3eeda7f00acc4de13 Reviewed-on: https://chromium-review.googlesource.com/639530 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#47657}
-
Mateusz Czeladka authored
As part of J2V8 development (https://github.com/eclipsesource/J2V8), we realized that we had a subtle bug in how Isolate scope was created and it's lifetime managed, see: https://github.com/eclipsesource/J2V8/issues/313. Mentioned above bug was fixed, however, what we also noticed is that V8 API has been constantly and slowly moving to such an API, in which one has to pass Isolate explicitly to methods and/or constructors. We found two more places that might have been overlooked. This contribution adds passing of Isolate pointer explicitly to constructors of String::Utf8Value and String::Value classes. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I61984285f152aba5ca922100cf3df913a9cb2cea Reviewed-on: https://chromium-review.googlesource.com/593309 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47656}
-
Ulan Degenbaev authored
Change-Id: I62e3ad6dc294b575d2b50a68d7dd7c8167fa517d Reviewed-on: https://chromium-review.googlesource.com/637309 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47655}
-
Adam Klein authored
Per https://tc39.github.io/ecma262/#sec-array.prototype.concat, step 6. Bug: v8:6707, v8:6708 Change-Id: Iad3eb94a3b5fe35e5ecd1b8632612a7f2f169434 Reviewed-on: https://chromium-review.googlesource.com/636695 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47654}
-
Michael Lippautz authored
Bug: Change-Id: I857f8b3f992faf950917060b3fe705bdd45c3ada Reviewed-on: https://chromium-review.googlesource.com/638339Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47653}
-
Ben L. Titzer authored
R=ahaas@chromium.org,mtrofin@chromium.org Bug: chromium:759624 Change-Id: I032755698c4f404cfd5bf3298df57a4bcfbe6f2c Reviewed-on: https://chromium-review.googlesource.com/638590Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47652}
-
Jaroslav Sevcik authored
Now we create merges, effect phis and phis eagerly. This should make it easier to add loop support in future. Bug: v8:5267 Change-Id: I5324aec323feff581f5b34235a0b3d3b8987127c Reviewed-on: https://chromium-review.googlesource.com/637834 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47651}
-
Camillo Bruni authored
Bug: v8:6211 Change-Id: I0f15c59b7b786ab327e4ab548523095dd85ba83e Reviewed-on: https://chromium-review.googlesource.com/637835Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47650}
-
Yang Guo authored
We now only require API references to be provided when we actually deserialize them. Also changed the internal implementation to avoid copying API references into V8. R=petermarshall@chromium.org Bug: v8:6448 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iddb0465ff6e95020006d41b5e87614dce8f0140b Reviewed-on: https://chromium-review.googlesource.com/632098Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47649}
-
Michael Hablich authored
This reverts commit 49e3bfd5. Reason for revert: Primary suspect for blocked roll: 759552 Original change's description: > [snapshot] Move builtins to dedicated snapshot area > > As a first step towards lazy builtin deserialization, this CL moves > builtins to their own dedicated area in the snapshot blob, physically > located after startup data and before context-specific data. > > The startup- and partial serializers now serialize all seen builtins as > references, i.e. they only encode the relevant builtin id (taking care > to preserve special behavior around the interpreter trampoline and > CompileLazy). Builtins are later fully serialized by the > BuiltinSerializer. The separate blobs are finally glued together by > CreateSnapshotBlob. > > Deserialization takes the same steps: when we see builtin reference > bytecodes before builtins have been deserialized, we push to a list of > deferred builtin references. After builtin deserialization, this list is > iterated and all builtin references are fixed up. > > Bug: v8:6624 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004 > Reviewed-on: https://chromium-review.googlesource.com/610225 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47596} TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6624 Change-Id: I9906c9ea15a623226b890f63bc65876a6f5203f8 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/638331Reviewed-by: Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#47648}
-
Michael Lippautz authored
The deadlock can happen when we lock a page for processing old to new references as part of the scavenger while at the same time trying to lazily sweep another page for retrieving memory. If two tasks decide to sweep each others pages they will deadlock. Bug: v8:6754 Change-Id: Ic9fae0eafa5b5a5cb5eaa1c0aac61de24d1b9486 Reviewed-on: https://chromium-review.googlesource.com/636371 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47647}
-
Michael Starzinger authored
This makes sure the minimum memory size for WebAssembly modules derived from asm.js is set to zero. It allows instatiation without allocating an underlying memory, when such memory is unused. It also fixes a bug in patching of embedded memory sizes for asm.js modules. R=ahaas@chromium.org TEST=mjsunit/regress/regress-crbug-759327 BUG=chromium:759327 Change-Id: If5a965b96a03cbb5ba15bc41fbaf359f74961f41 Reviewed-on: https://chromium-review.googlesource.com/637912 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#47646}
-