- 30 Aug, 2017 19 commits
-
-
Leszek Swirski authored
Use the DEFINE_FIELD_OFFSET_CONSTANTS macro to define the fields in the BytecodeArray layout description. Change-Id: I89ff2d7cd967aa1a503cbedd5d95dcd80f4d038c Reviewed-on: https://chromium-review.googlesource.com/643130Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47713}
-
jgruber authored
Lazy deserialization needs to determine the underlying builtin by looking at the SharedFunctionInfo. This packs the builtin_id into the SFI::function_data field, and adds convenience functions to Code as a drive-by addition. Bug: v8:6624 Change-Id: I59093815aa6937342302153ebc95dd60edb0064e Reviewed-on: https://chromium-review.googlesource.com/641490 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47712}
-
Clemens Hammacher authored
And reuse the CHECK_ERROR and VALIDATE macros. R=titzer@chromium.org Bug: v8:6600 Change-Id: Ibeabdf0815418b6c70e2441ed9267261eb8883b6 Reviewed-on: https://chromium-review.googlesource.com/643131Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47711}
-
Michael Lippautz authored
Bug: chromium:738865, chromium:750084 Change-Id: Ife30da4be118cd6f3212e84752978ebb39500f15 Reviewed-on: https://chromium-review.googlesource.com/641414 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47710}
-
Ben L. Titzer authored
R=rossberg@chromium.org Bug: v8:6651 Change-Id: Iaa9217cacded9bdd3f0a35775275e79c231c272a Reviewed-on: https://chromium-review.googlesource.com/642969Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47709}
-
jgruber authored
To deserialize builtins individually, we need to preserve their starting offsets within the serialized data. Bug: v8:6624 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I48a48330aeb63de2c8cfcbea6fb94e1b2917495c Reviewed-on: https://chromium-review.googlesource.com/637774Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47708}
-
Michael Lippautz authored
Aligns behavior with other allocate calls in factory that allow choosing the generation depending on the use case. Bug: v8:6771 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I63b95de7e664a51af8ca24a75f2122dfe1792c42 Reviewed-on: https://chromium-review.googlesource.com/642799Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47707}
-
Peter Marshall authored
Bug: v8:6333 Change-Id: I5a38c1bcc6cd3b030ea2dd57fb2198009e8920e6 Reviewed-on: https://chromium-review.googlesource.com/638290 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47706}
-
jgruber authored
This is a reland of 49e3bfd5 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} Bug: v8:6624 Change-Id: I8bfac56c482d992987c270bf0fea7acd9e4ca0c7 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/638271Reviewed-by:
-
Maya Lekova authored
Bug: chromium:760268 Change-Id: Id9b24ddee61926a5d1324d7da12efccf2c1eb9c2 Reviewed-on: https://chromium-review.googlesource.com/642798Reviewed-by:
-
Mostyn Bramley-Moore authored
Daniel Bratell reports: > v8 had a couple of files that were very slow to compile before jumbo > and if those now end up in the same translation unit, then I can see > how that translation unit can take an extreme time to get through > the compiler. > > From one of my test builds (times in seconds): > 49.7 v8_base/objects.o > 44.0 v8_base/code-stub-assembler.o > 32.9 v8_base/api.o > 30.5 v8_base/elements.o > 25.9 v8_builtins_generators/builtins-regexp-gen.o > 22.8 v8_base/parser.o > 21.2 v8_base/heap.o > > All of these are in the slowest 0.1% ninja jobs so they are extreme > in some way. I think I would just exclude them all (or at least the > 30s+ ones) completely from jumbo. BUG=chromium:746958 Change-Id: I01741109def4f9ac7c946319374076eb7b9d03b6 Reviewed-on: https://chromium-review.googlesource.com/637971 Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47703}
-
Enrico Bacis authored
This CL introduces two tests to verify that the correct memory is accessed when a wasm module invokes an wasm function imported from a second module that accesses its (i.e., second module's) memory. The first test verifies that the second module's memory is accessed in case the first module does not have memory. In the second test, both the modules have memory. R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org Change-Id: I75c3a5335583a91af0e7e4179c482142165b1c01 Reviewed-on: https://chromium-review.googlesource.com/637837 Commit-Queue: Enrico Bacis <enricobacis@google.com> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#47702}
-
Peter Marshall authored
Bug: v8:6333 Change-Id: I53d321292b0a2c7b7f72ee90bd119484f163bdc1 Reviewed-on: https://chromium-review.googlesource.com/637913 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47701}
-
Sergei D authored
To enable executing code in a context of a particular time or date (e.g. when codepath depends on whether it's say evening or New Year) there is a need for a way to provide it bypassing actual system time. Bug: chromium:751993 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iee35d97b74345f63fff814a65a6f134d7c970341 Reviewed-on: https://chromium-review.googlesource.com/598666 Commit-Queue: Sergei Datsenko <dats@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47700}
-
Tobias Tebbi authored
Bug: Change-Id: Ib9e0d0844ad5e7bc6cd038f736546cad77669321 Reviewed-on: https://chromium-review.googlesource.com/641530Reviewed-by:
-
Benedikt Meurer authored
Cleanup for 562663d5. Bug: v8:6702 Change-Id: I7fbacbe6e4b52dc56d810cab3123b497329be3ca Tbr: jarin@chromium.org Reviewed-on: https://chromium-review.googlesource.com/641874Reviewed-by:
-
Benedikt Meurer authored
Introduce a proper empty_descriptor_array, which has the proper layout (length is 2 and the two fields are set properly). Also add a special EnumCache class and a matching empty_enum_cache. The contract now is that we only need to check the EnumLength on the map to know whether we are allowed to use the enum cache. This greatly simplifies the handling of the enum cache (and also the descriptor arrays), especially for the future work on optimizing keyed access via the enum cache indices. Bug: v8:6702 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83 Reviewed-on: https://chromium-review.googlesource.com/641030 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Jaroslav Sevcik authored
Bug: chromium:760434 Change-Id: I50ed6779f79ed1b17053a0a0f2013cae53091a3a Reviewed-on: https://chromium-review.googlesource.com/641873Reviewed-by:
-
Adam Klein authored
Also rename options key from "no_network" to "network" to avoid too many levels of double-negatives. Change-Id: I6d29edce8abde64199b27ef0f3453ab370a9937b Reviewed-on: https://chromium-review.googlesource.com/642516Reviewed-by:
-
- 29 Aug, 2017 21 commits
-
-
Jaideep Bajwa authored
Port 51a15140 Original Commit Message: This change adapts the Call bytecode handlers such that they don't require a stack frame. It does this by modifying the call bytecode handler to tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the callee function will return to the InterpreterEntryTrampoline when it returns (since this is the return address on the interpreter frame), which is adapted to dispatch to the next bytecode handler. The return bytecode handler is modified to tail-call a new InterpreterExitTramoline instead of returning to the InterpreterEntryTrampoline. Overall this significanlty reduces the amount of stack space required for interpreter frames, increasing the maximum depth of recursive calls from around 6000 to around 12,500 on x64. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:753705 LOG=N Change-Id: Ieac490d82098c13741080061eda762d54baf8c04 Reviewed-on: https://chromium-review.googlesource.com/639315Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47694}
-
Franziska Hinkelmann authored
No need to reassign those JSTypedArrays. Bug: v8:6704 Change-Id: Ide1f8bb119285b57ea85b8e710358c917244f801 Reviewed-on: https://chromium-review.googlesource.com/641474 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Adam Klein authored
There was only one case where this wasn't the case, having to do with variable declarations, and for that case the information need not actually be stored on the block, but should rather be propagated to the VariableProxy. Bug: v8:6092 Change-Id: I0d0025ec73d3dd4f9402606105d3e883a9417283 Reviewed-on: https://chromium-review.googlesource.com/639911 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
-
Adam Klein authored
The vast majority of callers pass null |labels| and kNoSourcePosition, so make those the default arguments. Bug: v8:6092 Change-Id: Ifac3f0d49f56b680ec75b1a7afde5e5e788d9cfd Reviewed-on: https://chromium-review.googlesource.com/639761 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
-
Adam Klein authored
Also remove last internal callers of the to-be-deprecated APIs. Bug: v8:2487 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id72cf363eac86e4b4dbf7df83bdb848071260b90 Reviewed-on: https://chromium-review.googlesource.com/639326Reviewed-by:
-
Adam Klein authored
The vast majority of blocks we create in the parser have no associated labels, so it seems silly to waste a pointer on labels_ for all such blocks. This is accomplished by delegating responsibility for labels storage to each subclass of BreakableStatement, and then further-specializing Block by creating a new subclass, LabeledBlock. Bug: v8:6092 Change-Id: I88c824639254e5890b25a86cc156bfc4310bf2b1 Reviewed-on: https://chromium-review.googlesource.com/639063Reviewed-by:
-
Adam Klein authored
Also a few bits of related dead code in Parser. Bug: v8:6092 Change-Id: Ie30aa1bd769b78fec2563fc6ba82ef0bcd7668bb Reviewed-on: https://chromium-review.googlesource.com/639311Reviewed-by:
-
Clemens Hammacher authored
This reimplements functionality that was present before the decoder refactoring. It's implemented a bit differently though by generating the code for re-throwing an uncaught exception earlier (when generating code for the catch). R=titzer@chromium.org, kschimpf@chromium.org Bug: v8:6600 Change-Id: Ie2f11837851c0602ab31506fa63475fc2d0b5047 Reviewed-on: https://chromium-review.googlesource.com/641550 Commit-Queue: Brad Nelson <bradnelson@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#47687}
-
Jakob Kummerow authored
The score is computed based on how often the benchmark's function can be run within one second. Simply importing a Module repeatedly doesn't do any work, so to make the test score meaningful, we must wrap the payload into a function that can be called explicitly for every run. NOTRY=true Bug: v8:1569 Change-Id: Iadaed6df1f1652d8860271e327c505f0b8f20c2d Reviewed-on: https://chromium-review.googlesource.com/639396 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47686}
-
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:
-
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:
-
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:
-
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: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 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 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:
-
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:
-
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:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Enrico Bacis <enricobacis@google.com> Cr-Commit-Position: refs/heads/master@{#47674}
-
