- 11 Apr, 2019 2 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/6f0224b..ba0d0b9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f8d4d2d..dc0c991 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/224e075..6379cd3 Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/8e8db13..a42c2f6 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/69c72a6..4ae7482 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f822215..5f253f8 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Id9387595f335c5fceff1dba6066f8440cae0a02d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563210Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#60760}
-
Shawn Anastasio authored
v8 currently detects ABI by checking OS and endianness, but this is not sufficient to properly detect cases in which the ELFv2 ABI is used on big-endian Linux systems. Update these checks to use additionally use the _CALL_ELF macro in order to properly handle such cases. This issue was initially discovered by the Adélie Linux team. Change-Id: Iefc0510963d93e59d6c62469a505c70c594bb14a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1555424Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#60759}
-
- 10 Apr, 2019 32 commits
-
-
Paolo Severini authored
In file include/v8config.h we define: ifdef V8_OS_WIN ... if defined(_M_X64) || defined(__x86_64__) define V8_OS_WIN_X64 true endif and V8_OS_WIN_X64 is supposed to be defined when targeting X64 on Windows only. But this is wrong because V8_OS_WIN_X64 gets defined also on an ARM64 builds when the host machine is X64. It should instead be: ifdef V8_OS_WIN ... if defined(V8_TARGET_ARCH_X64) define V8_OS_WIN_X64 true endif Bug: v8:9090 Change-Id: I88e4c46bb6df1efa2070d4e1785081d71df96f0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554222Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60758}
-
Paolo Severini authored
This CL makes sure that Crashpad on Chromium will behave exactly like it did before we added code to emit unwinding info, even when FLAG_win64_unwinding_info is not set. In particular, before merging the Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/1474703/ that modifies Crashpad to use the new function SetUnhandledExceptionCallback(), we need to make sure that Isolate::Init() will call win64_unwindinfo::RegisterNonABICompliantCodeRange() even when FLAG_win64_unwinding_info is false. In that case RegisterNonABICompliantCodeRange will only register unwind info to invoke the Crashpad exception handler for unhandled exceptions. Note that RegisterNonABICompliantCodeRange will be a no-op with the current Crashpad code that never calls SetUnhandledExceptionCallback(). Bug: v8:8661 Change-Id: I63d845e9dca79ddd5978dfb43b626ace50078e80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554119Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:8318 Change-Id: I1c4bb26270c4ea9ede99a131f804568e6f721fc6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560657Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60756}
-
Ben Smith authored
When getting the starting address of a data segment, you can't use `&vector[offset]` if offset is equal to the length of the vector. This can happen when the length of the segment is 0. The fix is to use Vector::SubVector instead. Bug: v8:9106 Change-Id: Icf8968cc246c6d217d8061f76fb2631c2292433c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560405 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
The wasm engine is the same for all units, thus we should store (or get) it in the compilation task, and not store it duplicated in each compilation unit. R=mstarzinger@chromium.org Bug: v8:8916, v8:8343 Change-Id: Id4b062b5b8a52228b4d6051a67e025088a61d466 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559863 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Maya Lekova authored
Bug: v8:8746, v8:9057 NOTRY=true Change-Id: Idf6b204469e0f8b547014465ecfc46388a05f264 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561318 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60753}
-
Jaroslav Sevcik authored
If the runtime does not transition in keyed store IC miss handler, avoid generating transitioning handler since this could make the receiver map non-stable. (The optimizing compiler does not like non-stable fast prototype maps.) Bug: chromium:950328 Change-Id: I113880d2033518e3eb8fd11df1599e56a67d7fd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559867 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60752}
-
Sergiy Belozorov authored
R=machenbach@chromium.org, tmrts@chromium.org No-Try: true Bug: chromium:841700 Change-Id: I18552e928223dd8ea03ac518f6b1b2460d10135d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559851 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
-
Mythri A authored
This is a reland of Ie3ac389e1c082d1671efd4d74abc076ce943301b with a fix for MSAN failures. Interrupt budget was store in bytecode array and used to be shared across all contexts. With lazy feedback allocation, using context independent interrupt budget might lead to performance cliffs when we have closures that do not share the same feedback (for ex: across contexts). This would be a problem even earlier but it could be more pronounced with feedback vector allocation, since the budgets for optimization is much higher (144x) than the budget for feedback allocation. Bug: chromium:948835, v8:8394 Change-Id: I74f998c30e27caf3bd34510f4d7f57b65e6c7f0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561072Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#60750}
-
Michael Achenbach authored
TBR=mslekova@chromium.org NOTRY=true Bug: v8:9026 Change-Id: Ib529a9d24cdf391a19014f874b0cdd79f0d79b18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561312Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#60749}
-
Peter Marshall authored
Bug: v8:9092 Change-Id: I1839651c0a47dbbefa93c7441597c98653132ff8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554692 Auto-Submit: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Maya Lekova authored
This reverts commit 251d1623. Reason for revert: Breaks ASAN debug builders for ClusterFuzz, see https://ci.chromium.org/p/v8/builders/ci/V8%20Clusterfuzz%20Linux64%20ASAN%20-%20debug%20builder/8115 Original change's description: > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 3bd49f9b > > The issue on the windows bot is apparently a compiler bug in MSVC related to > move construction. The fix seems to be to change the order of the fields in > "JsonParseResult" (go figure). > > Drive-by-change: Fix LS on windows by emitting correct line endings and > enabling exceptions for the LS executable as well. > > Original change's description: > > [torque] Throw exception instead of aborting if something goes wrong > > > > This CL enables exceptions for the Torque compiler and Torque language > > server. Instead of aborting when something goes wrong during > > compilation, a TorqueError is thrown, containing the error message > > and a source position. The compiler executable still prints the error > > and aborts, while the language server will pass this information > > along to the client (not included in this CL). > > > > R=danno@chromium.org > > > > Bug: v8:8880 > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60512} > > Bug: v8:8880 > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60736} TBR=danno@chromium.org,tebbi@chromium.org,szuend@chromium.org Change-Id: I0b22db1652bd46fbb7167f75b710ed5e408ea8ac No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8880 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561311Reviewed-by:
-
Simon Zünd authored
This CL moves frames.tq and arguments.tq to the front of the file list when compiling Torque files. Note that order independent compilation will most likely be implemented in the near future, at which point this code becomes obsolete. R=tebbi@chromium.org Bug: v8:8880 Change-Id: I7e32637925c28202f9b017a568bc06ae5bd595b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561210Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60746}
-
Georg Neis authored
Make the tracing code and output more consistent and/or compact. Also, restrict --trace-heap-broker to reports about missing data and introduce a new flag --trace-heap-broker-verbose that prints everything. Bug: v8:7790 Change-Id: I6e678fb97bf8631428594f77d8b5f0909ab2e281 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559864Reviewed-by:
-
Clemens Hammacher authored
Avoiding the helper function to get the time in milliseconds avoids redundantly getting the current platform and simplifies code. R=mstarzinger@chromium.org Bug: v8:8916 Change-Id: Ie7214f896a14f45aef359ea095a4b0532aeccf77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561070 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=sigurds@chromium.org BUG=v8:9089 Change-Id: I6092ff322588e42e83251464b8a4c61ad0324384 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559860 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Georg Neis authored
R=jarin@chromium.org Change-Id: I82a8173bb3ecd86d980ccb5169c4bedac49989f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561071Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:8557 Change-Id: If6e70c30c0553f8742980590875c4892535e5863 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559749Reviewed-by:
-
Clemens Hammacher authored
Instead of having sequential compilation implemented as a separate path, we can just use the existing parallel compilation path, and restrict the number of parallel compilations (if deterministic compilation is required). R=mstarzinger@chromium.org Bug: v8:9104 Change-Id: Ia12c6e45455834a131b3d2ed55f5fe9132903d8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552782 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Jakob Gruber authored
Instead of adding conditionally everywhere, write the condition once in v8_maybe_icu and include that. Essentially, if (v8_enable_i18n_support) { public_deps = [ "//third_party/icu", ] } becomes public_deps = [ ":v8_maybe_icu", ] Bug: v8:8834 Change-Id: I091b14c85f1495a967eaa2b272904fdf41e6e7eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532337 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: -
Jaroslav Sevcik authored
Bug: v8:8361 Change-Id: I43ed0901949de1174336d5a69e9a23bafe468b4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558085Reviewed-by:
-
Benedikt Meurer authored
The generic HashTableBase approach was producing the wrong results for the over-allocation, so I'm using the HashTable template now, which seems to produce the right results. Also distinguish properties backing stores for prototypes from regular properties backing stores (since we're primarily interested in the prototypes for now). Bug: v8:7266 Change-Id: I5bbda6851f0320168ada1beb104042d0052c9a17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559869Reviewed-by:
-
Simon Zünd authored
This is a reland of 3bd49f9b The issue on the windows bot is apparently a compiler bug in MSVC related to move construction. The fix seems to be to change the order of the fields in "JsonParseResult" (go figure). Drive-by-change: Fix LS on windows by emitting correct line endings and enabling exceptions for the LS executable as well. Original change's description: > [torque] Throw exception instead of aborting if something goes wrong > > This CL enables exceptions for the Torque compiler and Torque language > server. Instead of aborting when something goes wrong during > compilation, a TorqueError is thrown, containing the error message > and a source position. The compiler executable still prints the error > and aborts, while the language server will pass this information > along to the client (not included in this CL). > > R=danno@chromium.org > > Bug: v8:8880 > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > Reviewed-by: Daniel Clifford <danno@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60512} Bug: v8:8880 Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995Reviewed-by:
-
Michael Achenbach authored
This reverts commit f3994485. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/26128 Original change's description: > [interpreter] Move interrupt budget from BytecodeArray to FeedbackCell > > Interrupt budget was store in bytecode array and used to be shared > across all contexts. With lazy feedback allocation, using context > independent interrupt budget might lead to performance cliffs when > we have closures that do not share the same feedback (for ex: across > contexts). This would be a problem even earlier but it could be > more pronounced with feedback vector allocation, since the budgets > for optimization is much higher (144x) than the budget for feedback > allocation. > > Bug: chromium:948835, v8:8394 > Change-Id: Ie3ac389e1c082d1671efd4d74abc076ce943301b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558088 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60734} TBR=jarin@chromium.org,mlippautz@chromium.org,mythria@chromium.org,jgruber@chromium.org,bmeurer@chromium.org Change-Id: Icbec4d28d6ac258827e222461cff51f2a2f42472 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:948835, v8:8394 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560990Reviewed-by:
-
Mythri A authored
Interrupt budget was store in bytecode array and used to be shared across all contexts. With lazy feedback allocation, using context independent interrupt budget might lead to performance cliffs when we have closures that do not share the same feedback (for ex: across contexts). This would be a problem even earlier but it could be more pronounced with feedback vector allocation, since the budgets for optimization is much higher (144x) than the budget for feedback allocation. Bug: chromium:948835, v8:8394 Change-Id: Ie3ac389e1c082d1671efd4d74abc076ce943301b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558088 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#60734}
-
Jakob Gruber authored
@@replace should only call ToString(replaceValue) once. Prior to this CL this was not the case when 1. the given regexp is fast 2. the replacement is not callable 3. and its string representation contains a '$'. In such a situation we'd call ToString both in the RegExpReplace builtin, and after bailing out again in the RegExpReplaceRT runtime function. The fix is to pass the result of ToString(replaceValue) to the runtime function. ToString in RegExpReplaceRT will be a no-op since the value is already guaranteed to be a string. Bug: chromium:947822 Change-Id: I14b4932a5ee29e49de4c2131dc2e98b50d93da49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559739 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60733}
-
Sathya Gunasekaran authored
The resolve/reject callbacks to PerformPromiseAll is refactored out so that we can just pass different closures for PerformPromiseAllSettled. Similarly, a closure to update the value is passed to Generate_PromiseAllResolveElementClosure so that we can create a diferrent value in case of Promise.allSettled. Bug: v8:9060 Change-Id: I4e1bebe6da4ea0965a67cccc8365ed91cf4683c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559216 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:9109 Change-Id: I5a79192c8168c81d8f35711f8983fb1acb260a10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559214Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e7cb8dd..6f0224b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/072a6f1..f8d4d2d TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I281966c8ecbc8cc625202b63493692a41cf99c08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560652Reviewed-by:
-
John Budorick authored
Example failure caused by this race: https://ci.chromium.org/p/chromium/builders/ci/linux-dbg/7157 Introduced in crrev.com/c/1557152 Tbr: sigurds@chromium.org,tebbi@chromium.org Bug: v8:7793 Change-Id: I06f4c95e97577b7ba51e55faa50b844d773e976b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559215 Auto-Submit: John Budorick <jbudorick@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#60729}
-
Simon Zünd authored
This reverts commit 8b917cd9. Reason for revert: Breaks the noi18n build. The header js-date-time-format.h expects i18n to be enabled. Original change's description: > [torque] Convert few class layout definitions to torque. > > Converted JSGlobalObject, JSIteratorResult, JSLocale, JSDateTimeFormat, > JSListFormat, JSNumberFormat, JSPluralRules, JSRelativeTimeFormat, > JSSegmenter, JSAsyncFromSyncIterator to torque. > > Bug: v8:8952 > Change-Id: I760a658c5bef7e12bc8f07b741245e9d1933164e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529262 > Commit-Queue: Suraj Sharma <surshar@microsoft.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60727} TBR=jgruber@chromium.org,tebbi@chromium.org,surshar@microsoft.com Change-Id: Ibbcb3667be1042b3b0290d68369da597ea07102d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8952 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559866Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60728}
-
Suraj Sharma authored
Converted JSGlobalObject, JSIteratorResult, JSLocale, JSDateTimeFormat, JSListFormat, JSNumberFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter, JSAsyncFromSyncIterator to torque. Bug: v8:8952 Change-Id: I760a658c5bef7e12bc8f07b741245e9d1933164e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529262 Commit-Queue: Suraj Sharma <surshar@microsoft.com> Reviewed-by:
-
- 09 Apr, 2019 6 commits
-
-
Joyee Cheung authored
- Add a new ClassScope for block scopes created for classes. - Add a VariableMap in the class scope for private name resolution, and a separate UnresolvedList for private names that will be resolved only using ClassScopes. These are stored in RareData and will only be allocated when there are private name declaration or access in the class. Design: https://docs.google.com/document/d/1l-D70uaHzXU8QVgQZ3ACikb3FLO6LTAfQVdGDXsh5mw/edit?usp=sharing TBR: hpayer@chromium.org Bug: v8:8330 Bug: v8:7468 Change-Id: I78191fc075f7f195f6c56c959773c382346cce8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1488271 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
-
Frank Tang authored
While dateStyle or timeStye is specified, we should not add property listed in "Table Components of date and time formats" per https://tc39.github.io/proposal-intl-datetime-style/#sec-initializedatetimeformat Bug: v8:9107 Change-Id: I3e39112ed5f99b05f30b2f50f3cd3102d094f98e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559213Reviewed-by:
-
Benedikt Meurer authored
Avoid divide by zero for empty elements backing stores, and generally don't account for empty_property_array / empty_fixed_array. Bug: v8:7266 Change-Id: I5d1c5f43165810f7ec3bcebf3caf1bc737b46e59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559865 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Z Duong Nguyen-Huu authored
Design docs: bit.ly/fast-frozen-sealed-elements-in-v8 This change is only support the transition from packed elements to packed sealed elements (via object.seal) or to packed frozen elements (via object.freeze). Added tests for non-extensible, sealed, frozen packed elements in https://chromium-review.googlesource.com/c/v8/v8/+/1474559 Added tests for non-extensible array in optimized code in https://chromium-review.googlesource.com/c/v8/v8/+/1531030 and https://chromium-review.googlesource.com/c/v8/v8/+/1544274 Using JSTests/ObjectFreeze micro-benchmarks for release build Before: TaggedTemplate-Numbers(Score): 0.967 TaggedTemplateLoose-Numbers(Score): 8.82 After: TaggedTemplate-Numbers(Score): 1.51 TaggedTemplateLoose-Numbers(Score): 8.89 Bug: v8:6831 Change-Id: Ib1089f1bc02eafb8d76ffe617f8fa3e406abd5a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1474559Reviewed-by:
-
Clemens Hammacher authored
This stages wasm code gc behind "--future" to get test coverage while implementing this feature. R=mstarzinger@chromium.org Bug: v8:8217 Change-Id: Id620ee92518c4dd9cebc0fd47817bfc80e5cf3f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559741 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
This adds the {CurrentGCInfo} data structure to the wasm engine. It holds all information needed for the current GC cycle, which is currently only the set of Isolates that still need to report their live code, and the set of dead wasm code (which is potentially reduced when Isolates report live code). Running the GC is guarded by the new '--wasm-code-gc' flag. I will add this to the --future variant in a follow-up CL. R=mstarzinger@chromium.org Bug: v8:8217 Change-Id: I82e96d986cf5a758bc0f94e49e13ad78fae4e935 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559738 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
