- 22 Sep, 2020 27 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Z Nguyen-Huu authored
Using associative property of addition: (x + A) + B => x + (A + B). Note: A and B need to have the same sign and we need to check that (x + A) isn't used anywhere else. 20% perf improvement of the following function. function f(n) { var c = 0; for (var i = 0; i < n; i++) { c = c + 2 + 3; } return c; } for n = 10_000_000. Before: 7.31s. After: 6.05s. Bug: v8:10305 Change-Id: If45d1cad6128a9a25cb9f43a4828ae28d594a84b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2365221 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70064}
-
Ng Zhi An authored
We are hitting some limits in number of opcodes on ARM64. Try to reduce it by merging AnyTrue opcodes (from 4 to 1) since the codegen is identical. Bug: v8:10930 Change-Id: Ib0bcedbd24d122a4da1ffcb29c1e4b5656fa6ac2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422087Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70063}
-
Shu-yu Guo authored
The detach CHECK is currently crashing on a non-TypedArray and non-Array input source to TypedArray#set that detaches the destination TypedArray in its length getter. Bug: v8:10885 Change-Id: I80bcb4ffb4e4122afbff5c412623c008dc9509df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419655Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#70062}
-
Ng Zhi An authored
Strange things happen if we add too many opcodes such that we exceed the number of bits ArchOpcodeField has, and in some arch (ARM64), we are only one away from requiring 10 bits (at 0x1ff) now. Bug: v8:10930 Change-Id: I8dc6b7e0822291f2403db4e4e1dfaf90b9416a8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422843 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70061}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Dominik Inführ authored
It is not allowed to invoke ResetPendingObject() in MarkCompactCollector::StartMarking(). This method is invoked when starting incremental marking, at this point the object might not be initialized. Bug: v8:10315 Change-Id: I7659855d78fbb28536f57b26e8a7d33c1ba4092e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424267Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#70059}
-
Dominik Inführ authored
Avoid race with concurrent allocation thread by updating the flag conditionally. Bug: v8:10315 Change-Id: I63df8ab5a6a506e9337281c9fef7555b9deaaee6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424264Reviewed-by:
-
Leszek Swirski authored
Also remove yangguo@ at his behest. Change-Id: Ief4176663ab01ff7b1d75aa8d6907c96ab519310 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421822Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Andreas Haas authored
The tests are flaky because of missing safepoint information for stack checks. Adding the safepoint information there is not trivial though, so I disable these tests for now to keep at least the bots green. An alternative would be to revert the CLs that add safepoints in the first place. However, I would prefer to avoid the overhead that would be caused by it. The implementation is completely hidden behind a flag, so it does not have impact on production code. R=clemensb@chromium.org Bug: v8:10929 Change-Id: I38c0e3c3806de2cc39ba26bc3b47c2ea8d1cf81a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423705Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#70056}
-
Tobias Tebbi authored
Bug: v8:10577 Change-Id: I28aaec30b73def5034294f71bb6bda466172b4ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400978 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#70055}
-
Dominik Inführ authored
Otherwise concurrent allocation might start incremental marking, which would then mark the global handle. Bug: v8:10315 Change-Id: Ibc681b001847a7c52e9fd8a0420e42a0d0ecfbda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424004Reviewed-by:
-
Cong Zuo authored
Change-Id: I257cd745966cbd9ee87eb725b3f80fbf5bf40ca3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423743Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70053}
-
Clemens Backes authored
This flag has no uses in any tests, and it's hard to image a use case for debugging or similar. R=ahaas@chromium.org Bug: v8:10933 Change-Id: I2e96187e4410805824d213e9a9df152b54dd3fb2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421825Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70052}
-
Michael Achenbach authored
No-Try: true Bug: chromium:1126457 Change-Id: Iea2f8f37b172fb130c13b0f1d397eb5789c82893 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423720 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#70051}
-
Vicky Kontoura authored
This CL improves the condition that checks all parameters received from JavaScript when calling an exported WebAssembly function to determine whether they can be transformed without calls to built-in functions. The condition is now updated to stop checking if one parameter that cannot be transformed quickly is encountered. Bug: v8:10943 Change-Id: If199aa8d2ffcef86f973c23d9663f8091dfced8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423713Reviewed-by:
-
Nico Hartmann authored
This reverts commit 4a2b2b2e. Reason for revert: Speculative revert due to https://ci.chromium.org/p/chromium/builders/try/linux-rel/495075? Original change's description: > [Heap]: Marking use Jobs. > > StopRequest is removed in favor of: > COMPLETE_TASKS_FOR_TESTING -> JoinForTesting() > PREEMPT_TASKS -> Pause() > COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS > - we should avoid waiting on the main thread as much as possible. > > Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70037} TBR=ulan@chromium.org,etiennep@chromium.org Change-Id: I63f24bffa0f56c6ffa1d1977fc4fb8a76b6f3ba2 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423722Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#70049}
-
Dominik Inführ authored
Tests fails sometimes with concurrent allocation. Bug: v8:10315 Change-Id: Ic055a3573f6daacc435670efcf2e310f4c746451 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423714Reviewed-by:
-
Jakob Kummerow authored
Choose the page size based on V8_HOST_ARCH_ARM64 (i.e. we're building an arm64 binary) instead of V8_TARGET_ARCH_ARM64 (i.e. V8's compilers are emitting arm64 instructions, which is the case in simulator builds as well). Drive-by: - use V8_TARGET_OS_MACOSX instead of __APPLE__ - drop implementation difference between AllocatePageSize and CommitPageSize on POSIX (they must return the same value anyway) This continues and obsoletes the work at https://chromium-review.googlesource.com/c/v8/v8/+/2314102 . Bug: chromium:1107945, chromium:1128932 Change-Id: Iaaa509dd496ff581ddda4d957bc3d35d806cf81e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421817 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Marja Hölttä authored
It's inherently timing-dependent, leading to false positives. Bug: chromium:1127612, v8:10239 Change-Id: Ibf6f3cb07f520a404daf8e860a0c2e5f2319529e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423707 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70046}
-
Marja Hölttä authored
The actual fix is in LoadIC::ComputeHandler (checking lookup_start_object == holder instead of receiver == holder) + the LookupIterator changes for preserving lookup_start_object. The rest is renaming / refactoring. Bug: v8:9237, chromium:1127653 Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Dominik Inführ authored
StressConcurrentAllocatorTask now checks whether tear down was started for the isolate to avoid allocation failures. As a drive-by change remove the unused method ConcurrentAllocator::PerformCollectionAndAllocateAgain. Bug: v8:10315 Change-Id: Iba329ebbd782e9f8f11e9b8ec644bf28ab9c80ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423703Reviewed-by:
-
Almothana Athamneh authored
Bug: v8:10875 Change-Id: Idde7011b82a292c83758e5a181442960e55a8592 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421824 Auto-Submit: Almothana Athamneh <almuthanna@chromium.org> Reviewed-by:
Liviu Rau <liviurau@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Added scopes to diallow/allow GCs from happening using a DCHECK. It is stricter than DisallowHeapAllocation, since this also doesn't allow safepoints. As soon as Turbofan is ready, we can replace all usages of DisallowHeapAllocation with DisallowGarbageCollection. Bug: v8:10315 Change-Id: I12c144ec099d9af57d692ff343adbe7aec46c0c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362960Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#70042}
-
Ulan Degenbaev authored
Building and running tests with v8_enabled_concurrent_marking=false currently produces two failures: 1) Segmentation fault on attempt to mark a read-only object. This is fixed by changing MarkBit::Set to be a no-op if the object is already marked (which is the case for the readonly space). 2) Missing write-barrier due to bogus condition in the bailout. The barrier can be skipped only if the host object is not marked yet. This also disables two concurrent allocation tests that rely on concurrent marking write-barrier. Bug: v8:10875 Change-Id: Ib3a238fc34c8f20c697470e0bd4ac427fb4bdc0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421816Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70041}
-
johnx authored
See b/169093796 for details Change-Id: Icdb6fac9d3063cc0dedd68e318805b88f4c06bc6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421982 Auto-Submit: John Xu <johnx@google.com> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4070870..e78873c Rolling v8/third_party/aemu-linux-x64: LUFkW5GTwXItfKWgJt7kkk1hEf35ZueIbx73KwUN5K0C..zVhDYckO5pABaht9PlF8y1S_JicWTnMzwymJyNabQj4C Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/244d770..cc29098 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/92b3622..7c1d1f3 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ief975fc418bf135578e441c849e41f1635897980 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422777Reviewed-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@{#70039}
-
- 21 Sep, 2020 13 commits
-
-
Ng Zhi An authored
Instantiating a module that contains a function (exported) with a v128 in its signature is fine, but then later calling it will trap. So v128 values are technically not callable from JS, but we can give it a default argument of 0, and will later trap anyway. This is useful when fuzzers generate functions with v128 in the signature of the main function that we then later try to call. Bug: chromium:1129068 Change-Id: I93f239a0355b8059e25b8bd5f1274d151d71ee11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419657 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Etienne Pierre-doray authored
StopRequest is removed in favor of: COMPLETE_TASKS_FOR_TESTING -> JoinForTesting() PREEMPT_TASKS -> Pause() COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS - we should avoid waiting on the main thread as much as possible. Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Avoid resetting log flags as this could cause data races with allocating background threads. Bug: v8:10315 Change-Id: I7be01ff54e349652f182b944ed3f3366d1239ad7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421814 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Test doesn't finish in 60s with --stress-concurrent-allocation, similar to --stress-gc. Bug: v8:10315 Change-Id: Id46231616387605ee49bfb54512828c0c8e84745 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422000 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Test was asserting heap size before and after GC. With background thread allocation those assertions might not hold. Bug: v8:10315 Change-Id: I4f8c0f6d0b80040b3c89f85e801416abb29ed30e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421999Reviewed-by:
-
Vicky Kontoura authored
This CL introduces a fast path for transforming JavaScript parameters to WebAssembly when calling an exported WebAssembly function from JavaScript. A transformation is considered fast when it does not require a call to a built-in function, thus spilling registers for the call can be avoided. Bug: v8:10943 Change-Id: I5563bfdf77a68bef7ab8afc6d0f4ab2d2ea67bd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418857Reviewed-by:
-
Manos Koukoutos authored
Changes: - When checking if a table is a function table, check for subtyping to funcref instead of equality. - Add WasmModuleObject argument to GetFunctionTableEntry. - Implement WasmTableObject::Get/Set for all legal table types. - Factor out SetFunctionTableEntry from WasmTableObject::Set. - Write unittests and JS tests. Bug: v8:9495 Change-Id: I4f0c7a7013f17c561afb3039c5e0811634a4d313 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416387 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Seth Brenith authored
Change-Id: I65ed798968b602891e7f8d13c08c9065ab58d6d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418367Reviewed-by:
-
Tobias Tebbi authored
regarding --no-enable-experimental-regexp-engine Bug: v8:10941 Change-Id: I9c3d9f8616b4ba9464ae699e1edf458c1f994952 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421812 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
Drive-by: add const modifier to some StructType fields Bug: v8:7748 Change-Id: Ic0b4bb51ed01502f19d082c669683f69b85e76e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419015 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Clemens Backes authored
Remove the hack introduced in https://crrev.com/c/2412176, use the existing {ValueTypeToConstantName} function instead. R=ahaas@chromium.org Bug: chromium:1127717 Change-Id: I4ac50346825d7b00ea8dadccd7798a273ae84499 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421568Reviewed-by:
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: Ibe41dcc3d1717326b8ce7bf3491bf32a8d0882b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421810 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Martin Bidlingmaier authored
Assertions are implemented with the new ASSERTION instruction. The nfa interpreter evaluates the assertion based on the current context in the subject string every time a thread executes ASSERTION. This is analogous to what re2 and rust/regex do. Alternatives to this approach: - The interpreter could calculate eagerly for all assertion types whether they are satisfied whenever the current input position is advanced. This would make evaluating the ASSERTION instruction itself cheaper, but at the cost of making every advance in the input string more expensive. I suspect this would be slower on average because assertions are not that common that we typically evaluate >= 2 assertions at every input position. - Assertions in a regexp could be desugared into CONSUME_RANGE instructions, so that no new instruction would be necessary. For example, the word boundary assertion \b is satisfied at a given position/state if we have just consumed a word character and will consume a non-word character next, or vice-versa. The tricky part about this is that the assertion itself should not consume input, so we'd have to split (automaton) states according to whether we've arrived at them via a word character or not. The current compiler is not really equipped for this kind of transformation. For {start,end} of {line,file} assertions, we'd need to introduce dummy characters indicating start/end of input (say, 0x10000 and 0x10001) which we feed to the interpreter before respectively after the actual input. I suspect that this approach wouldn't make much of a difference for NFA execution. It would likely speed up (lazy) DFA execution though because assertions would be dealt with in the fast path. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
