- 07 Nov, 2017 1 commit
-
-
Yang Guo authored
This change - adds new maps for elements, global, and named dictionaries. - adds support to embed these dictionaries in the startup snapshot. - adds support to embed these dictionaries in the code cache. - refactors the rehashing logic. TBR=mstarzinger@chromium.org, ishell@chromium.org, jgruber@chromium.org Bug: v8:6593 Change-Id: I2455fe2a9cc6e93247940de99de5f124c2ada137 Reviewed-on: https://chromium-review.googlesource.com/756693Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#49167}
-
- 06 Nov, 2017 3 commits
-
-
Adam Klein authored
This reverts commit 3877bf6f. Reason for revert: failed compilation on Win64/clang: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/9015 Original change's description: > Snapshot: support rehashing property and element dictionaries. > > This change > - adds new maps for elements, global, and named dictionaries. > - adds support to embed these dictionaries in the startup snapshot. > - adds support to embed these dictionaries in the code cache. > - refactors the rehashing logic. > > R=ishell@chromium.org, jgruber@chromium.org, mstarzinger@chromium.org > > Bug: v8:6593 > Change-Id: I8d9a7ba7145f1af4e6e15301a4d5611f07c77f33 > Reviewed-on: https://chromium-review.googlesource.com/753323 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49155} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org Change-Id: I0b45d2d07da97b9a7953abf4ad24eec4ea944306 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6593 Reviewed-on: https://chromium-review.googlesource.com/755493Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49156}
-
Yang Guo authored
This change - adds new maps for elements, global, and named dictionaries. - adds support to embed these dictionaries in the startup snapshot. - adds support to embed these dictionaries in the code cache. - refactors the rehashing logic. R=ishell@chromium.org, jgruber@chromium.org, mstarzinger@chromium.org Bug: v8:6593 Change-Id: I8d9a7ba7145f1af4e6e15301a4d5611f07c77f33 Reviewed-on: https://chromium-review.googlesource.com/753323Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#49155}
-
Toon Verwaest authored
Bug: v8:5561 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I47b7df39e80a66449a1ebe98e30052ced2ef2bd3 Reviewed-on: https://chromium-review.googlesource.com/753326Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#49151}
-
- 26 Oct, 2017 1 commit
-
-
jgruber authored
This is the first step towards lazy-deserializing bytecode handlers. Bytecode handler code objects are now serialized into the builtins snapshot area (which, like many other related concepts, has become somewhat of a misnomer now that it contains both builtins and handlers). Handlers are still eagerly-deserialized upon Isolate creation. This will change in follow-up CLs. Bug: v8:6624 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I7b257f76f5e9e90d5f7b183980bae7bc621171fc Reviewed-on: https://chromium-review.googlesource.com/738030 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#48977}
-
- 17 Oct, 2017 1 commit
-
-
jgruber authored
A continuation of the work in 59e4b751, this extracts logic around memory reservation and allocations out of the Deserializer class. Follow-up work is planned to create a specialized allocator for builtin deserialization. Bug: v8:6624 Change-Id: I7081cdc557ab8fb2571aadb816399e136ea2cdbb Reviewed-on: https://chromium-review.googlesource.com/716036 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48634}
-
- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 28 Sep, 2017 1 commit
-
-
Peter Marshall authored
The members of HandleScopeImplementer are copied with memcpy when the isolate is transferred to another thread. List contained some primitives which allowed us to manually free the backing store, which was needed in order to ensure that threads would not hold on to old pointers and use them later. With std::vector, we can't do that. Here we change the HandleScopeImplementer to instead use a custom structure DetachableVector, which contains a std::vector but allows manual detaching and freeing of the backing store. This allows us to maintain the old behavior. Bug: v8:6333 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0 Reviewed-on: https://chromium-review.googlesource.com/660125Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#48197}
-
- 11 Sep, 2017 2 commits
-
-
jgruber authored
This fixes two issues related to Code object allocation: Code objects need to be aligned to kCodeAlignment (= 32), and the instruction cache needs to be flushed after deserialization. Both bugs combined manifested as a crash at a basically arbitrary point in the code after the Runtime::kDeserializeLazy call: 0x286bc8dc: blx r12 // Call to Runtime::kDeserializeLazy, // generated through // GenerateTailCallToReturnedCode. 0x286bc8e0: mov r2, r0 // This seemingly innocent register move // crashes hard. Bug: v8:6624,v8:6796 Change-Id: I88c7eaf57ac851745fb7e800c92b0f5978b33466 Reviewed-on: https://chromium-review.googlesource.com/660119Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47947}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0554f01068fb76228e85cfe120630eda86de41d Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47945}
-
- 05 Sep, 2017 1 commit
-
-
jgruber authored
This adds support for lazy deserialization of JS-linkage (TFJ) builtins, still gated behind the --lazy-deserialization flag. If enabled, we proceed as follows: During isolate initialization, only eager builtins are deserialized. All references to lazy builtins are replaced by the DeserializeLazy builtin. In particular, this happens in the builtin table (Builtins::builtins_) and in SharedFunctionInfo objects. When calling into a not-yet deserialized function (i.e. the JSFunction's code object is the DeserializeLazy builtin), the DeserializeLazy builtin takes over. It checks the builtin table to see if the target builtin (determined by looking at the builtin id stored on the SharedFunctionInfo) has already been deserialized. If so, it simply copies the builtin code object to the JSFunction and SharedFunctionInfo. Otherwise, we enter Runtime::kDeserializeLazy to deserialize the builtin. With --lazy-deserialization, isolate deserialization is 11% faster (1.5ms vs. 1.7ms), and code_space->Size() is 33% lower (984K vs. 1475K). Moving relocation infos & handler tables out of the partial snapshot cache would additionally let us save up to 30K per isolate. Adding code stubs to that list increases further potential savings to 262K. Bug: v8:6624 Change-Id: I0ac7d05d165d2466998269bd431ac076a311cbeb Reviewed-on: https://chromium-review.googlesource.com/649166 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47818}
-
- 04 Sep, 2017 1 commit
-
-
jgruber authored
Our current deserializers (startup & partial) use a system of static memory reservations: required memory is determined at serialization time, which we then request before deserialization and dole out as-needed during deserialization. Lazy builtin deserialization needs a bit more flexibility. On the one hand, the amount of required memory varies since --lazy-deserialization can be switched on and off at runtime. On the other, builtin deserialization has been made order-independent, and we can encounter references to builtins before they have been deserialized. Both problems are solved by dynamically allocating required memory and initializing the builtins table with the (yet uninitialized) builtin Code objects. Bug: v8:6624 Change-Id: Iee90992e91adb4ab45dae1acc81f64a108d12584 Reviewed-on: https://chromium-review.googlesource.com/647748 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47789}
-
- 30 Aug, 2017 1 commit
-
-
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:
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@{#47705}
-
- 28 Aug, 2017 1 commit
-
-
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}
-
- 25 Aug, 2017 1 commit
-
-
Jakob Gruber authored
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/610225Reviewed-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}
-
- 23 Aug, 2017 1 commit
-
-
Peter Marshall authored
Bug: v8:6333 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I50d4357a7e7a0e8f2d04d5d34952cf524c012d5f Reviewed-on: https://chromium-review.googlesource.com/625740 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47538}
-
- 08 Aug, 2017 2 commits
-
-
Jakob Gruber authored
This moves deserializer setup boilerplate inside the deserializers, and makes improper usage less likely. For instance: ObjectDeserializer deserializer(&scd); /* ... deserializer setup ... */ MaybeHandle<HeapObject> obj = deserializer.Deserialize(isolate); /* ... result checks and casts ... */ has now become: /* All setup and casts inside deserializer, impossible to illegally use the same instance multiple times. */ MaybeHandle<SharedFunctionInfo> maybe_result = ObjectDeserializer::DeserializeSharedFunctionInfo( isolate, &scd, source); Bug: v8:6624 Change-Id: Id5a1848e024e89cf86e5292389ba7c89f31d8e6b Reviewed-on: https://chromium-review.googlesource.com/604791 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47219}
-
Jakob Gruber authored
Another pure refactoring CL. This extracts methods used only by Deserializer subclasses. Bug: v8:6624 Change-Id: Ib4dd7cdc591dff217e282e68a490c8c7129b9c96 Reviewed-on: https://chromium-review.googlesource.com/602188 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47211}
-
- 03 Aug, 2017 1 commit
-
-
jgruber authored
This begins splitting up the Deserializer class into {Object,Partial,Startup}Deserializer. For now, all functionality remains in the Deserializer base clase, to be refactored in future CLs. Empty .cc files are added here to avoid having to touch build files again. Bug: v8:6624 Change-Id: If563e03492991bd55c91cd2e09312c0a26aaab2c Reviewed-on: https://chromium-review.googlesource.com/598067Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47107}
-
- 11 Apr, 2017 1 commit
-
-
Caitlin Potter authored
Fix error message printed by Runtime_ThrowCalledNonCallable. As noted on the bug, this has a slight problem in that it will always print that "asyncIterator" was not callable for GetIterator with an async IteratorType, though it may be referring to a different call. This issue is present regardless of the change I introduced to perform this desugaring in the BytecodeGenerator. BUG=v8:6187 R=adamk@chromium.org, verwaest@chromium.org Change-Id: I2077b7cd5976d9d9ba044f0dff44ee8c312d1263 Reviewed-on: https://chromium-review.googlesource.com/470806Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#44543}
-
- 28 Feb, 2017 1 commit
-
-
Georg Neis authored
The order in which things were done wasn't quite correct and lead to wrong behaviour for certain circular module graphs. BUG=v8:1569,chromium:694566 Change-Id: I291186e261268c853a30ad891ff362904e0b28ef Reviewed-on: https://chromium-review.googlesource.com/447399Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#43497}
-
- 17 Feb, 2017 1 commit
-
-
vabr authored
https://codereview.chromium.org/2694003002/ introduced "SyntaxError: Lexical declaration cannot appear in a single-statement context" for the case when let + desctructuring from a list happen. As was pointed out in https://codereview.chromium.org/2694003002/#msg18, the case without destructuring would also benefit from a better message: if a single statement is expected and "let identifier = ..." is seen, the error is indeed again that the lexical declaration is not a statement. However, the current error is "Unexpected identifier", because the parser tries to accept "let" as an identifier in an expression statement, and then gives up seeing the other identifier after "let". This CL ensures that the parser recognises the error properly and reports accordingly. It also renames the existing test, which contains destructuring, and adds the one with a non-destructuring lexical declaration. BUG=v8:5686 Review-Url: https://codereview.chromium.org/2697193007 Cr-Commit-Position: refs/heads/master@{#43275}
-
- 16 Feb, 2017 1 commit
-
-
vabr authored
ES2017 forbids the sequence of tokens "let [" in in expression statements [1]. This CL makes ParserBase report those instances as SyntaxError. It also adds a customised error message for that, because the standard "Unexpected token" is not applicable: "let" itself is not forbidden in those context, only the sequence of "let [". [1] https://tc39.github.io/ecma262/#sec-expression-statement BUG=v8:5686 Review-Url: https://codereview.chromium.org/2694003002 Cr-Commit-Position: refs/heads/master@{#43258}
-
- 16 Jan, 2017 1 commit
-
-
yangguo authored
TBR=tebbi@chromium.org BUG=chromium:679841 Review-Url: https://codereview.chromium.org/2631163002 Cr-Commit-Position: refs/heads/master@{#42375}
-
- 12 Jan, 2017 1 commit
-
-
marja authored
The bug was caused by AstTraversalVisitor refactoring: https://codereview.chromium.org/2169833002/ InitializerRewriter::VisitRewritableExpression in parser.cc didn't recurse; so it fails when a rewritable expression contains another rewritable expression. See the bug for more details. BUG=chromium:679727 Review-Url: https://codereview.chromium.org/2629623002 Cr-Commit-Position: refs/heads/master@{#42274}
-
- 04 Jan, 2017 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org BUG=chromium:677757 Review-Url: https://codereview.chromium.org/2606383005 Cr-Commit-Position: refs/heads/master@{#42066}
-