- 31 Jul, 2019 10 commits
-
-
Ben L. Titzer authored
This is a reland of bc33f5ae Original change's description: > [arraybuffer] Rearchitect backing store ownership > > This CL completely rearchitects the ownership of array buffer backing stores, > consolidating ownership into a {BackingStore} C++ object that is tracked > throughout V8 using unique_ptr and shared_ptr where appropriate. > > Overall, lifetime management is simpler and more explicit. The numerous > ways that array buffers were initialized have been streamlined to one > Attach() method on JSArrayBuffer. The array buffer tracker in the > GC implementation now manages std::shared_ptr<BackingStore> pointers, > and the construction and destruction of the BackingStore object itself > handles the underlying page or embedder-allocated memory. > > The embedder API remains unchanged for now. We use the > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > keep the backing store alive properly, even in the case of aliases > from live heap objects. Thus the embedder has a lower chance of making > a mistake. Long-term, we should move the embedder to a model where they > manage backing stores using shared_ptr to an opaque backing store object. R=mlippautz@chromium.org BUG=v8:9380,v8:9221,chromium:986318 TBR=ulan@chromium.org Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#63007}
-
Milad Farazmand authored
Port 556e4859 Original Commit Message: 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. R=joey.gouly@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If38a721cfaefb7980902f4f963119cb88061e342 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726857Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63006}
-
Georg Schmid authored
With the arrival of generic structs (https://chromium-review.googlesource.com/c/v8/v8/+/1714868) the existing type inference procedure for generic calls became incomplete, since it could not infer types that were only constrained as part of generic types. For instance, given struct Box<T: Type> { ... } macro unbox<T: type>(box: Box<T>): T the type argument (Smi) at the following call site const box: Box<Smi> = ...; unbox(box); could not be inferred. This CL re-implements the inference procedure and documents the semantics of type argument inference in Torque a bit more clearly. R=tebbi@chromium.org Change-Id: I868f16afbd9864b9c810ac49bc1639b467df939c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720812 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63005}
-
Dan Elphick authored
Removes static modifier from global inline functions defined in globals.h. R=rmcilroy@chromium.org Bug: v8:9396 Change-Id: Ieacbcbf592d219fb50ab2d23dfbaba27246fb7ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728610Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63004}
-
Michael Achenbach authored
Change-Id: Ica3d8ca233278e50e390aad37138942d23b5b8b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728612Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63003}
-
Tom Tan authored
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
-
v8-ci-autoroll-builder authored
Rolling v8/test/wasm-js/data: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/b0c936c..a221f25 [spec] Upgrade to IEEE 754-2019 (#1050) (Andreas Rossberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/a221f25 TBR=ahaas@chromium.org,clemensh@chromium.org Change-Id: Id90c6e3228c4e5943e8bb49bc82fd4a9b01c424f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726578Reviewed-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@{#63001}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a9a0d9b..496479d Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ff7e2eb..2568b37 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/57e1363..8215b08 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I54127742991c381ebbac0e8688f7dafe50621ac2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726577Reviewed-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@{#63000}
-
Joran Siu authored
The s390 port uses the auxvector APIs to detect hardware/OS support for various z/Architecture features. These checks only make sense if we are running native, non-simulator mode. Moving the include<auxv.h> under V8_HOST_ARCH_S390 enables compilation of s390 simulation on platforms that do not have auxv.h header available. R=miladfar@ca.ibm.com,jyan@ca.ibm.com Change-Id: I685681a4f8786509beb181d8ae63876b3a4235b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726844Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Joran Siu <joransiu@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62999}
-
Yu Yin authored
port 556e4859 https://crrev.com/c/1669687 Original Commit Message: 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: Ic178de717d27a63b3f510b3a93e8f33a1730dc8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725669Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yu Yin <xwafish@gmail.com> Cr-Commit-Position: refs/heads/master@{#62998}
-
- 30 Jul, 2019 30 commits
-
-
Ng Zhi An authored
REX prefix should be after mandatory prefix and before opcode. Change-Id: I9829384d7d617d3be203026ae84ffa30aaef6d2e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726983 Commit-Queue: Bill Budge <bbudge@chromium.org> Auto-Submit: Zhi An Ng <zhin@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#62997}
-
Thibaud Michaud authored
Original CL: > [wasm] Simplify module creation > > This includes WasmEngine::NewNativeModule() and WasmModuleObject::New(). > The intent is to make the various ways of creating a module (sync, > async, deserialize, import) more similar. > > After this change, a NativeModule will always be created before a > WasmModuleObject. This will make it easier to look up a cached > NativeModule given its wire bytes. > > The following changes are made: > > * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code > size estimate by default. A different code size estimate is only used in > tests. > * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of > assuming the array was created with the correct size. This simplifies > WasmModuleObject::New(), and matches what CompileToNativeModule() > does. > * Remove the WasmModuleObject::New() constructor that creates a > NativeModule. This case was only used in DeserializeNativeModule() and > in test code. > > Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497 > Commit-Queue: Ben Smith <binji@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62925} R=ahaas@chromium.org, clemensh@chromium.org CC=binji@chromium.org Change-Id: I03aa901a1df65af28f864d9aabe2b134ea132e99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724213 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#62996}
-
Deepti Gandluri authored
- Add new instruction variants for psllq, psrlq (x64), vshl (ARM) - Add instruction selection, code generation for register shifts - Remove implicit immediate for shift operators - Fix interpreter, tests Bug:v8:8934, v8:8460 Change-Id: I3481d7ba34a34f7792ff1a61d4a726a1a9abab8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722198 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62995}
-
Joshua Litt authored
Numeric separators are not allowed in NonOctalDecimalIntegerLiterals. Bug: v8:9437 Change-Id: Ic62b35b361de36fc622e207c140c365665021029 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722194 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62994}
-
Toon Verwaest authored
The DCHECK related to a time when dictionary mode prototypes were the payload of complex data driven handlers. Now the additional data is used to hold entirely different kinds of objects. The DCHECK made no sense anymore. Cleaning up the names makes this clearer. Bug: chromium:986187 Change-Id: I7173d7d2824396c04c01acb4ceb74693ee9ce6b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724215 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62993}
-
Ben L. Titzer authored
D8 workers were leaking all messages due to a missing HandleScope within the message loop. Add one to fix leaks. R=verwaest@chromium.org BUG=v8:9524 Change-Id: I2f2f6ba0b8c58bf38bf68b7464dffdf1d826a29d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724212Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62992}
-
Georgia Kouveli authored
Do not pass the deoptimization index in a register, instead infer it from the address we made the deoptimization call from. This makes the deoptimization exit sequence one instruction long instead of two. This requires emitting all deoptimization exits at the end of the function in a contiguous block, making sure no constant or veneer pools are emitted in between. This means that soft deoptimizations require an additional branch to the end of the function, which counteracts the removal of the move instruction, however soft deoptimizations are rare compared to eager and lazy ones. This reduces the code size of optimised functions for benchmarks like Octane and ARES-6 by about 4%. Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62991}
-
Clemens Hammacher authored
This method will be used for a test with multiple code spaces, to encode large function indexes. The current implementation in {wasmI32Const} just always uses 5 bytes for encoding the LEB value. This CL adds a {wasmSignedLeb} function which properly encodes the value, and adds tests for that. Drive-by: Clean up the rest of {test-wasm-module-builder.js}. R=mstarzinger@chromium.org Bug: v8:9477 Change-Id: Ide2d90eed9d40aa28df680fbb413275346d9c0b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725623Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62990}
-
Michael Achenbach authored
iOS still uses the recipe-side toolchain, so calling the mac_toolchain script on src-side is useless in iOS checkouts. Bug: chromium:986701 Change-Id: I1252d01088eca69e6b465c30856f9434eea99aab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725612Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#62989}
-
Joyee Cheung authored
This patch adds: - VariableMode::kPrivateMethod - VariableMode::kPrivateSetterOnly - VariableMode::kPrivateGetterOnly - VariableMode::kPrivateGetterAndSetter And replace the previous RequiresBrandCheckFlag by inferring whether the brand check is required from these VariableModes. It is then possible to check duplicate non-complementary accessors in the parsers and throw early errors, and allow complementary accessors to be associated with the same private name variable. This patch also adds the following AssignType: - PRIVATE_METHOD - PRIVATE_GETTER_ONLY - PRIVATE_SETTER_ONLY - PRIVATE_GETTER_AND_SETTER corresponding to the new VariableModes so that it's possible to generate specialized code for different type of private accessor declarations. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62988}
-
Leszek Swirski authored
The tests rely too much on OS state (thread allocation) to be predictable. Change-Id: I9a562369a3c72522630a23ee47e3e819b9411c65 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725626 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62987}
-
Andreas Haas authored
On Windows, the FP stack registers are used with less precision. This causes rounding errors in the uint64 to float32 conversion. This CL replaces the implementation based on FP stack registers with an implementation based on bit operations. This implementation is 2x slower than the original implementation. An alternative would be to change the precision of the FP stack registers just for the uint64 to float32 conversion. However, in a micro-benchmark this is 5-6x slower than the original implementation. It is also not clear if changing the precision could cause side effects. R=clemensh@chromium.org Change-Id: Iaab6b6f258ff01e0c6e93f3632daf516fae3e74b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708486 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62986}
-
Thibaud Michaud authored
Revert reason should be fixed with this CL: https://chromium-review.googlesource.com/c/v8/v8/+/1722554 The underlying problem was the isolate being accessed from the background compilation thread. Other known places where the isolate was used have also been fixed in these CLs: https://chromium-review.googlesource.com/c/v8/v8/+/1722555 https://chromium-review.googlesource.com/c/v8/v8/+/1722559 https://chromium-review.googlesource.com/c/v8/v8/+/1722556 Original CL: > Reland "[wasm] Compile JS to WASM wrappers asynchronously" > > Original CL had an issue with builtins being accessed through the > isolate after the isolate died. See: > https://ci.chromium.org/p/v8/builders/try.triggered/v8_win64_rel_ng_triggered/b8907837534672203296 > > Initial upload is the original CL and the following patch sets will > attempt to fix it. > > Original CL: > > > [wasm] Compile JS to WASM wrappers asynchronously > > > > R=mstarzinger@chromium.org, ahaas@chromium.org > > > > Bug: v8:9231 > > Change-Id: I9e18073bbe25bf8c9c5f9ace102316e6209d0459 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669699 > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62672} > > R=mstarzinger@chromium.org, ahaas@chromium.org > > Bug: v8:9231 > Change-Id: I1b01d5d2b9f728d6f6a90fe9b642f5ba3bf686eb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708485 > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62918} R=mstarzinger@chromium.org Bug: v8:9231, v8:9554 Change-Id: I40443e7228eb26d6669e826e96073b20fa038c15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725619Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62985}
-
Sathya Gunasekaran authored
Previously, this was run as a microtask and this CL changes it to run as a separate task as mandated by the current WeakRef spec. This CL also introduces a FinalizationGroup type to the V8 API representing the JSFinalizationGroup. This has a `Cleanup` function that runs the cleanup callback associated with it. SetHostCleanupFinalizationGroupCallback is added to set the embedder defined HostCleanupFinalizationGroupCallback. ClearKeptObject is exposed on the v8::Isolate to reset the strongly held set of objects. The general workflow is the following: (a) When the GC notices that a given finalization group has dirty cells, it calls HostCleanupFinalizationGroupCallback with the given finalization group. (b) As part of HostCleanupFinalizationGroupCallback, the embedder enqueues a task that at some point later calls FinalizationGroup::Cleanup. (c) At some point in the future, FinalizationGroup::Cleanup is called, which runs the cleanup callback of the finalization group. This patch also includes d8 changes to use these new APIs. Currently, d8 cycles through the enqueued finalization groups after a synchronous turn (and it's microtask checkpoint) and runs the cleanup callbacks. Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc Bug: v8:8179 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62984}
-
Michael Achenbach authored
Change-Id: If57fdeeaef9a45ad7d17c0fc27dc89fbc83e4a02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725627Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#62983}
-
Toon Verwaest authored
This drops possible remaining pattern errors from the access target. This is necessary since sub patterns with default values (assignment expression) aren't otherwise identifiable as being property accesses. Bug: v8:9560 Change-Id: Ie6781c0d161e00790268f7d9db81377d045f93b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725624Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62982}
-
Georgia Kouveli authored
Change-Id: I208c8189bded5dfc4fd997cac6a41acc73bf31ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725620Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#62981}
-
Dominik Inführ authored
FLAG_max_semi_space_size could be used to allow arbitrarily huge semi spaces. Limit semi space size to kMaxSemiSpaceSize also in the case this flag is used. Change-Id: Id52cea6ef73eb1957265cf38c109dd490d7feccc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725618Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#62980}
-
Tobias Tebbi authored
This allows to return bool values from Torque macros and branch on them without performance penalty, reconstructing good control flow. Drive-by cleanup: Delete EnsureDeferredCodeSingleEntryPoint(), since it's no longer needed. Constructing a graph and then re-inferring deferred blocks based on branch hints achieves this effect automatically. Bug: v8:7793 Change-Id: Idb6802372b407549e4760f290933d5b8f1e9d952 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681132Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62979}
-
Yuki Shiino authored
Object::Get, Set, etc. properly invoke an interceptor registered via SetAccessCheckCallbackAndHandler, however, Object::GetOwnPropertyDescriptor does not invoke an interceptor. This patch supports access-check-interceptor for descriptors. Change-Id: Ie2b2f2456be95c6eef8c2cdfee2bdd651c011fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720969Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#62978}
-
Leszek Swirski authored
This reverts commit 4b15b984. Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0). Original change's description: > [regexp] Better quick checks on loop entry nodes > > 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} TBR=jgruber@chromium.org,seth.brenith@microsoft.com Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9305 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62977}
-
Clemens Hammacher authored
Currently, each single CSA_ASSERT invokation creates its own lambda, which is then wrapped in a {std::function} and passed to {CodeStubAssembler::Assert}. It takes a lot of compile time for clang to generate all the code for that. This CL introduces a more light-weight alternative to {CodeStubAssembler::Assert} which just receives the node directly. This reduces compile time of {code-stub-assembler.cc} in optdebug mode from ~30 seconds to ~17 seconds locally. R=tebbi@chromium.org Bug: v8:7629 Change-Id: I4520a7b587cb96319d75048cf11c1124be583d6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724370Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62976}
-
Richard Townsend authored
This fixes a build failure for arm64 on Windows. Bug: v8:9564 Change-Id: I845b7687379ae12c27fa2924775553c83dc5d1ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724386 Commit-Queue: Richard Townsend <richard.townsend@arm.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62975}
-
Ben L. Titzer authored
This is a reland of a0728e86 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} Bug: v8:9524 Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62974}
-
Maya Lekova authored
Bug: v8:7790 Change-Id: I31502a8023564e88e0a28a421e3c7fb3404847dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722566 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62973}
-
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}
-