- 30 Jul, 2019 5 commits
-
-
Peter Marshall authored
We can get repeated positions from optimized code objects in some cases but for our purposes of looking up a line number from a PC, we can only return one line number so just use the first one that is reported in the source position table on the code object. Change-Id: I4c0e866fb1948f65bf6c988d992ef55f520dd874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724375Reviewed-by:
Alexei Filippov <alph@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62972}
-
Simon Zünd authored
R=yangguo@chromium.org Change-Id: If4c158e339b603268563223d900e6879f43ec63b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725611 Commit-Queue: Simon Zünd <szuend@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62971}
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/cfe8887..d0793a0 Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1e5d7d6..a9a0d9b Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/67b293c..74cfb57 Rolling v8/buildtools/linux64: git_revision:972ed755f8e6d31cae9ba15fcd08136ae1a7886f..git_revision:152c5144ceed9592c20f0c8fd55769646077569b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/53913ce..ff7e2eb Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ee7b9dd..c075833 Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/6077f44..a45c24a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f485a21..57e1363 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ibeee90a7c8f165f85e402f7892eff900efb7fe4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725433Reviewed-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@{#62970}
-
Ng Zhi An authored
-0.0 and 0.0 compare equals, so a < b ? a : b for min would pick b incorrectly. We need to use JS semantics here, which returns -0.0. Bug: v8:8425 Change-Id: I8ab094b566ece9c586de86aad4594dfdf8da930b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724802Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62969}
-
Deepti Gandluri authored
Performance is comparable on newer hardware, movddup performs slightly better on older chips Change-Id: Ic3248dd2807bf2c49311cba45ba4f0e8baa47730 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715981Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#62968}
-
- 29 Jul, 2019 22 commits
-
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I1ba49fed9500f0cadd307da02a3b6a0d1a5e2785 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1721711 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I185b110df3832dfd1b657d04a85efc96628b02b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719038 Auto-Submit: Zhi An Ng <zhin@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Georg Neis authored
Serialize for all cases of JSNativeContextSpecialization::ReduceJSInstanceOf. Bug: v8:7790 Change-Id: I147991353b86619808257a92961b7051105511f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722558 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#62965}
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I1307b2b7daa33c621501489619ae5f6913354db4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719037 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Seth Brenith authored
Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this change is inspired by attempting to exit earlier from generated RegExp code, when no further matches are possible because any match would be too long. The motivating example this time is the following expression, which tests whether a string of Unicode playing cards has five of the same suit in a row: /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u A human reading this expression can readily see that any match requires at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for each repeated option reports its minimum distance to the end of a match as zero. This is correct, because the LoopChoiceNode's behavior depends on additional state (the loop counter). However, the preceding node, a SET_REGISTER action that initializes the loop counter, could confidently state that it consumes at least 10 characters. Furthermore, when we try to emit a quick check for that action, we could follow only paths from the LoopChoiceNode that are possible based on the minimum iteration count. This change implements both of those "could"s. I expect this improvement to apply pretty broadly to expressions that use minimum repetition counts and that don't meet the criteria for unrolling. In this particular case, I get about 12% improvement on the overall UniPoker test, due to reducing the execution time of this expression by 85% and the execution time of another similar expression that checks for n-of-a-kind by 20%. Bug: v8:9305 Change-Id: I319e381743967bdf83324be75bae943fbb5dd496 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62963}
-
Dan Elphick authored
Fixes a bytecode mismatch for arrow functions with default arguments between eager and lazy compilation. In the former case, parameters with default values are marked as assigned even if the value never changes within the function because the parser does not know it's an arrow-function at the point it sees the assignment. So this changes ArrowHeadParsingScope::ValidateAndCreateScope to clear the is_assigned flag on its parameter VariableProxies before it binds them. Bug: chromium:988304, v8:8510 Change-Id: I68bf205c73471386181e5fdcec6c8c3b2e527c8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724384Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62962}
-
Joey Gouly authored
Instead of storing the values of the single precision floating point registers, get their values from the aliased double precision registers. This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total) and 128 bytes in the RegisterValues class. Change-Id: I681ad46efbb610e94d1e45871e012d2c0a3cfa3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669687 Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
-
Darius Mercadier authored
Bug: v8:9329 Change-Id: Ic9b107667e90ef975240e915fec86d6bf0692f8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720818 Commit-Queue: Darius Mercadier <dmercadier@google.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62960}
-
Clemens Hammacher authored
This is a reland of 658ff200 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} Bug: v8:9396, v8:7629 Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by:
-
Clemens Hammacher authored
This reverts commit 658ff200. Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} TBR=yangguo@chromium.org,clemensh@chromium.org Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396, v8:7629 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62958}
-
Thibaud Michaud authored
R=mstarzinger@chromium.org Bug: v8:9554 Change-Id: Id09bb2d98ae62fcbd7b444d467d7ff446991f020 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722555Reviewed-by:
-
Clemens Hammacher authored
We have hundreds of classes that derive from {BitField} without adding any functionality. This CL switches all such occurrences to 'using' declarations instead. Before: class MyBitField : public BitField<int, 6, 4, MyEnum> {}; After: using MyBitField = BitField<int, 6, 4, MyEnum>; This might reduce compilation time by reducing the number of existing classes. The old pattern is forbidden now by making {BitField} final. R=yangguo@chromium.org Bug: v8:9396, v8:7629 Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: -
Thibaud Michaud authored
Prefer using the wasm engine's allocator, as the isolate may not be available during asynchronous compilation. Bug: v8:9554 Change-Id: Iee3777efb62d18de6b2a64fa7a71d4ef4c6b3a92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722559 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:9396 Change-Id: Ic1c49aed8110b982ca793ba5ee94d5135619c2fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722567Reviewed-by:
-
Michael Starzinger authored
This makes function objects constructed via the {WebAssembly.Function} constructor callable directly from JavaScript (not just from within WebAssembly modules). Semantics are as if the function performed the transition JS-to-Wasm and then Wasm-to-JS in sequence. R=clemensh@chromium.org TEST=mjsunit/wasm/type-reflection BUG=v8:7742 Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: -
Clemens Hammacher authored
The preprocessor of MSVC works differently for empty __VA_ARGS__. Another hack is needed to make this compile in both MSVC and clang. R=tebbi@chromium.org Bug: v8:9555 Change-Id: Ie8f2e1ed302730419dae95e49ab0cca35a4a8131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720669Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62952}
-
Georg Neis authored
Change-Id: I7dbc632ea3eff419d6670519f7005382e2cadce4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720815 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Darius Mercadier authored
Bug: v8:9329 Change-Id: Id92ab58179a5b5765560f22beefef842055d7e28 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715461 Commit-Queue: Darius Mercadier <dmercadier@google.com> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
In export wrapper compilation, the isolate was used to get enabled features. This prevents asynchronous compilation, so this is replaced with an enabled_features argument passed from the main thread. R=mstarzinger@chromium.org Bug: v8:9554 Change-Id: Iab8a090841170dc235273dda58997cde716ee13f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722554Reviewed-by:
-
Jakob Gruber authored
Prior to this CL, the regexp fast path check is stricter than it needs to be. For example, adding any arbitrary property on the regexp prototype would move the execution of all regexp builtins in the same context onto the slow path. This actually happens in the real world: popular web frameworks commonly monkey-patch builtin prototypes to add functionality. The intent of this CL is to widen the fast path for regexp builtins s.t. modifications of the prototype that do not conflict with our requirements stay on the fast path. This is done by extending the current fast path check with an additional step. If checking the prototype map identity or relevant prototype property constness fails, we now compare the actual value of all relevant properties against the expected value. If these match, the prototype can be considered fast. The new step as described in the previous paragraph is part of the permissive fast path check (BranchIfFastRegExp_Permissive). The strict variant (BranchIfFastRegExp_Strict) is also still required by a few spots. We should refactor these to also allow the permissive check in follow-up work. Bug: v8:5577,chromium:977382 Change-Id: I69b2244e68ccfbd00edf17fc326aa4b5f5d089fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706056 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62948}
-
Michael Achenbach authored
This enables the recipe to set FORCE_MAC_TOOLCHAIN and decide if hermetic or system xcode is used. TBR=tmrts@chromium.org Bug: chromium:986701 Change-Id: I2c1ba75d5d62e493bd9dc7a5ec5f7e40465d8f98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722557Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#62947}
-
Thibaud Michaud authored
In export wrappers generated code, load the undefined value from the wasm instance rather than from the isolate. With asynchronous compilation, the isolate may not be available. R=mstarzinger@chromium.org Bug: v8:9554 Change-Id: Ic448bda82c2125fc9c9f8715bce26870308715d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722556Reviewed-by:
-
- 27 Jul, 2019 1 commit
-
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: Ia9ffb214738fca17fc36a4323d5e6c4d82a36f2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719036 Auto-Submit: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
- 26 Jul, 2019 12 commits
-
-
Ng Zhi An authored
Bug: v8:9557 Change-Id: Iff790b82a362b3919a63485011745dcb7d2061c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1721203 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Andrew Comminos authored
Implements ProfilerCodeObserver, a class to track the generation and movement of code on the heap for the lifetime of each CpuProfiler. When sampling is inactive, logged code is committed directly to the CodeMap. During profiling, ProfilerCodeObserver redirects these events onto the profiling thread for later dispatch. Bug: v8:9151 Change-Id: Ib5b152446d2a3838e1b00a80253fc4fbd2f6e8c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1604143Reviewed-by:
-
Seth Brenith authored
This change updates the RegExp bytecode generator to emit checks for larger eats_at_least values when they are available, so we can fail to match earlier in some cases. Bug: v8:9305 Change-Id: I96740531e142ff8dced41c49b774845b07df6ae6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709768 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Santiago Aboy Solanes authored
In some cases, we end up with a ChangeCompressedPointerToTaggedPointer next to a CheckedTaggedToTaggedPointer. In this case, the checked one is not needed since we are sure we are dealing with a pointer (and not a Smi). This doesn't get resolved in the simplfied lowering phase due to having a Phi[Tagged] in the middle of those two nodes. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:7703 Change-Id: Ia4a44b36423c2242d5c663f9b93b09924190fe8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709426 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62941}
-
Santiago Aboy Solanes authored
If we are sure that we are dealing with a Compressed value, we can check for sminess in 32 bits. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:7703 Change-Id: Icf77d8bcd1decfd392b4887241a9b559f11814c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718146Reviewed-by:
-
Georg Schmid authored
This CL removes the built-in reference type in favor of a Torque-implemented generic struct, i.e., internal::Reference<T>. It also adds various infrastructure for getting and creating new generic struct instances, as well as matching against them. R=tebbi@chromium.org Change-Id: I1e3d6afe355a0603fa9c3ad789c6b8a97d1b3c26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718148 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
-
Santiago Aboy Solanes authored
The propagation of tenuring from outer allocations to inner allocations was blocked in pointer compression since we now had Compress nodes between AllocateRaw and StoreField. This was causing issues in GC. It popped up in the Octane2.1/Splay benchmark, where we had big regressions. This CL updates the memory optimizer so that it can use the Compress nodes as bridges and can perform the optimization successfully. Note that the Compress nodes only appear on the value input of the StoreField. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:7703, v8:9519 Change-Id: I6b0cc67955c6cc696e8c426b85c87a1794098ed0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714650Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62938}
-
Maya Lekova authored
This reverts commit a0728e86. Reason for revert: Times out on Windows & debug builds - https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/34484 Original change's description: > [d8] Remove maximum workers limitation > > This CL refactors the lifetime management of the v8::Worker C++ object > and in the process lifts the 100 maximum worker limitation. To do this, > it uses a Managed<v8::Worker> heap object and attaches the managed to > the API worker object. > > R=mstarzinger@chromium.org > BUG=v8:9524 > > Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453 > Commit-Queue: Ben Titzer <titzer@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62932} TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org Change-Id: I3a27937cba13b5413390f49268a107c184515153 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9524 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720590Reviewed-by:
-
Dan Elphick authored
Use the position of commas in arrow expressions to mark the initializer position of any parameters that might have been set in the preceding parameter. To enable this, this makes variable_list_ in ExpressionParsingScope a ScopedList<pair<VariableProxy*, int>> and changes ScopedList::at to return references so its elements can be modified in place. This fixes a source of bytecode mismatches when collecting source positions lazily and is a second attempt at fixing this after https://chromium-review.googlesource.com/c/v8/v8/+/1683267 introduced problems due to destructuring. Bug: chromium:980422, chromium:981701, v8:8510 Change-Id: I948f89f34fb75d7463a13183e363f7f96ad09d13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710671Reviewed-by:
-
Ulan Degenbaev authored
This reverts commit 1320c917. Reason for revert: The code in SFI is also flushed by the serializer with FunctionCodeHandling::kClear, so this fix does not work with --no_flush_bytecode. Original change's description: > [snapshot] Fix clearing of feedback vector in serializer (follow-up 2) > > Bug: v8:7857 > Change-Id: I3940ae2830adb6c572e079551b7bba7d84462afd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715444 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62881} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7857 Change-Id: If85fe29b2cdf6523ee53895628da38d942d45c2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719190Reviewed-by:
-
Mythri A authored
This is short-term fix for flaky failures on GC fuzzer. The closures g1 and g2 have the same SFI and pending optimzed table treats them as a single entry. This cl, adds %PrepareFunctionForOptimize after one of them is optimized. Bug: v8:9556 Change-Id: I1fd72da1baa5de2f7650e080f9b6d04b69dd6a16 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719188Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#62934}
-
David Carlier authored
using file descriptor's free approach instead. Change-Id: I9baa3d471b4ed6f624985a5b6325648ef7875596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710665Reviewed-by:
-
