- 13 Jun, 2019 14 commits
-
-
Sigurd Schneider authored
Previously, the handle's location was used as a proxy for the heap object, i.e, we put the handle into the constant pool, to avoid the need for GC visiting the constant pool entries during code generation. The handle locations are replaced by the corresponding heap object when the code is copied to the heap. This CL changes the handling in the assembler: Instead of putting in the handle location (which is a machine word) we put in a small index number into a table. This will be useful for putting 32bit constants into the constant pool. This new approach also has the advantage that ordering the constant pool entries by value produces a deterministic order after this change. Change-Id: Id47d56d487a0b64d1d1504a47937c8779ee02b13 Bug: v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648094 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62144}
-
Toon Verwaest authored
Bug: chromium:973363 Change-Id: Id2e46702f73e901df5f26b764d98fb3d4f681a98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657914 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62143}
-
Milad Farazmand authored
Bug: v8:8193 GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Change-Id: Ia5ecf96ad409705e3d54fc77b081fc4907d0aa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649711Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62142}
-
Jakob Gruber authored
Refactor-only, this moves interrupt scopes and stack guard code into their own dedicated files. Change-Id: I5723a04786a04bba31a0da54622f3cd0b926ef07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655288 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62141}
-
Tamer Tas authored
{V8 Linux 64 - pointer compression} builder uploads dchecks enabled builds. This CL creates a new builder that compiles V8 without dchecks enabled. This CL uses the inverted naming predicate {without dchecks} to avoid renaming the existing builder to {with dchecks} to avoid doing renames over multiple repositories for a temporary builder that we'll remove after the ptr compression merge to master. R=sergiyb@chromium.org CC=machenbach@chromium.org Bug: v8:9345 Change-Id: I9e8cc1a9eb59325fd8eecc8fdcd2778b4da005c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657922 Commit-Queue: Tamer Tas <tmrts@chromium.org> Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Auto-Submit: Tamer Tas <tmrts@chromium.org> Reviewed-by:Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#62140}
-
Pierre Langlois authored
As shown in the commit description of https://crrev.com/c/1619763, the JSON format was supposed to refer to a list of "spaces" and not "pages", this was a typo. Bug: v8:9186 Change-Id: I1a674dac8af4b27b7ee46041e8c7a533bad8e68b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657917Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#62139}
-
Mythri A authored
This check shouldn't have been there. Even with lazy feedback allocation we still transition to pre-monomorphic from uninitialized. We could remove pre-monomorphic states with lazy-feedback allocation but that requires changes at several other places. Change-Id: I8f878a83f0fe3200eb530a34a74811639dcdc153 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634920Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#62138}
-
Maya Lekova authored
This is a reland of ca10d2ba Original change's description: > [turbofan] Brokerize reduction of API calls > > JSCallReducer::ReduceCallApiFunction is now heap access free. > > Bug: v8:7790 > Change-Id: I5718d73589d0bed14149ef0bc084b8a6ab1b9b5b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624792 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62014} Bug: v8:7790 Change-Id: Idc6acd18f0bf703ed072353c17471b4067ff1e61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648236Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#62137}
-
Sathya Gunasekaran authored
Align with the spec defined names. Bug: v8:8179 Change-Id: I892a2627c7712112b47a87e7a658dc4066540482 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655654Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62136}
-
Sathya Gunasekaran authored
- Return true or false, not undefined - Check that unregister token is an object Bug: v8:8179 Change-Id: I1a4ff7730158dba16efb552fb2f4892c8d31412c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653120Reviewed-by:
-
Toon Verwaest authored
Swap bits between bitfield2 and bitfield3 so that bitfield2 doesn't change across named property transitions. This will allow us to share bf1/bf2 through the descriptor array. Change-Id: I3579ae89189ae0729cd492db1afb29cf90981f6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657908Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This is a reland of 823795fc, the reason for the revert was flushing out a bug that was now fixed independently in https://chromium-review.googlesource.com/c/v8/v8/+/1655307 Drive-by-fix: Correct wrong offset in CloneObjectIC fast-path. Original change's description: > [ic] Fix typo in Runtime_CloneObjectIC_Miss. > > https://chromium-review.googlesource.com/1649554 introduced a typo into > Runtime_CloneObjectIC_Miss, where it wouldn't update the IC state UNLESS > the source map is deprecated, which is the wrong way around of course. > > Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 > Change-Id: I7d6e0709e66ce4aaaf4a628d64ab801b84c8993c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655291 > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62106} Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Change-Id: I763d9eeab95043bed3bc4849fc3ddcda7787169a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655651 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Jakob Gruber authored
StackGuard::HandleInterrupts used to take a lock for testing and clearing each individual interrupt bit. This CL changes that to a single read up front. Slight behavioral changes: 1. A TERMINATE_EXECUTION interrupt is now handled first; we immediately exit and preserve all other interrupts (in case V8 is later resumed). 2. Since interrupts are read once, it is no longer possible to request an interrupt *within* HandleInterrupts that will later be processed within the same HandleInterrupts call. 3. Stack limits are reset immediately after reading the interrupt bits, and prior to actually processing the interrupts. Bug: v8:9328 Change-Id: I3048bb413213d11307df49e0014b64a2b43444e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653115 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4b9a126..afe9cbd Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/2e18a95..5b97b40 Rolling v8/buildtools/third_party/libc++/trunk: https://chromium.googlesource.com/chromium/llvm-project/libcxx/+log/5938e05..78822a6 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4d6b614..727d7ca TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: I3e4002f3059491dabcdc10bb2caffacfd35bcc75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657450Reviewed-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@{#62131}
-
- 12 Jun, 2019 26 commits
-
-
Z Nguyen-Huu authored
ObjectPreventExtensions and ReflectPreventExtensions are now Torque builtins (previously CPP) and the Proxy path is implemented completely in Torque while everything else calls into runtime (and is thus a bit slower than previously). Perf improvement in micro-benchmark JSTests/Proxies Before: PreventExtensionsWithoutTrap-Proxies(Score): 1978 PreventExtensionsWithTrap-Proxies(Score): 739 After: PreventExtensionsWithoutTrap-Proxies(Score): 3017 PreventExtensionsWithTrap-Proxies(Score): 2044 Bug: v8:6664 Change-Id: I6505d730cea6b0d197f6f5d0540b39056c8b763d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652688 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#62130}
-
Andrey Lushnikov authored
This was originally reported at https://github.com/GoogleChrome/puppeteer/issues/4545 R=ulan, alph Change-Id: I5134506e56cd40e49b358cd47590913b81013b6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649473 Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
-
Aleksei Koziatinskii authored
JSModuleNamespace does not have well defined CreationContext: current implementation of JSReceiver::GetCreationContext crashes on CHECK. R=lushnikov@chromium.org,yangguo@chromium.org Bug: none Change-Id: Ie2c0bfa39117d42d81f9709c21376c177b18e5ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652559Reviewed-by:
-
Z Nguyen-Huu authored
Extend same approach for FastJSArray to FastJSArrayForRead in ArrayMap builtin ~6x perf improvement in micro-benchmark JSTests/ObjectFreeze Before: ArrayMap ArrayMap-Numbers(Score): 0.0887 After: ArrayMap ArrayMap-Numbers(Score): 0.531 Bug: v8:6831 Change-Id: I06cba44ca4c9198977c6da522b782b61f9df04fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653732 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62127}
-
Milad Farazmand authored
Port ea420655 Original Commit Message: API calls made via the CallApiCallback builtin, which is used from the ICs and optimized code, are currently misattributed to the wrong counter InvokeFunctionCallback instead of FunctionCallback. In addition we don't use the C trampoline when only runtime call stats are enabled, but the Chrome DevTools profiler is not active, which means that these calls will not be attrituted properly at all, and that had to be worked around using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is active and not inlining calls/property accesses into optimized code depending on the state of RCS). All of this was really brittle and only due to the fact that the central builtin didn't properly check for RCS (in addition to checking for the CDT profiler). With this fix it's now handled in a central place and attributed to the correct category, so user code doesn't need to worry about RCS anymore and can just call straight into the fast-path. core hand-written native code with the API callback logic. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2d200be4544cf62393330bb2891b6ba6f088db68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655343Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62126}
-
Milad Farazmand authored
Original commit: 303ca9ac Change-Id: I276bc68253fe4cedecdd2a77db0e8dbbc998c1a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652504Reviewed-by:
-
Z Nguyen-Huu authored
Bug: v8:6831 Change-Id: I79cd1e25ddca17f0d5026bee737cd3fde0041e85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653733 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Seth Brenith authored
This change adjusts object initialization order for a few classes so that the GC can never see those objects in an invalid, partially- initialized state. AccessorInfo: Just zeros out a few fields upon construction. This is the simplest case. FunctionTemplateInfo: Slightly changes the order in which fields are set, so that the Smi field is set ahead of the call to SetCallHandler, which can GC. Also a pretty simple case. JSListFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter: The spec requires that we start with OrdinaryCreateFromConstructor, which has observable side effects (it fetches the prototype from the new.target). So we split JSObject::New in half: the first half does all of the user- visible things and returns a Map, which we can pass to the second half when we're ready to actually allocate the object. JSTypedArray: Extends the pattern from JSListFormat into Torque code: start with a Map and don't allocate the object until we're ready to set all of its properties. Bug: v8:9311 Change-Id: Id7703e8a0727ec756c774cfbb56af787658a111a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646844 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Sathya Gunasekaran authored
Make sure to use the callback passed to cleanupSome Bug: v8:8179 Change-Id: Ia5d90b56edf80e05bdaf0dc520b555c29042b64c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655306Reviewed-by:
-
Georg Schmid authored
R=jarin@chromium.org, tebbi@chromium.org Change-Id: Iec887aec4ae0fc477176a7431a1bd0de0775c060 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645325 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62121}
-
Seth Brenith authored
I originally marked AllocationMemento::allocation_site as @noVerifier out of an abundance of caution because AllocationMemento::IsValid checks whether allocation_site is an AllocationSite. However, I can't find any way for allocation_site to not be an AllocationSite. Bug: v8:9311 Change-Id: I8b7ab51978c90d9baff42dace28d176a1cd2921a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653520Reviewed-by:
-
Mathias Bynens authored
With bytecode flushing and lazy feedback allocation, we need to call %PrepareForOptimization before we call %OptimizeFunctionOnNextCall, ideally after declaring the function. Bug: v8:8801, v8:8394, v8:9183 Change-Id: I3fb257282a30f6526a376a3afdedb44786320d34 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648255 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#62119}
-
Jakob Gruber authored
This adds regexp-macro-assembler-arch.h which contains the arch-specific include dispatch. Change-Id: Ibc2be8059d54b57afeed9b7ce244229ce1bd79bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655296 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62118}
-
Benedikt Meurer authored
Make sure that we pop the async function promise from the catch prediction stack when `await`ing inside an async function, and push it back onto the stack when we're resuming execution. This is to ensure that we don't leak memory when there are suspended async functions while navigating away to a new page. Bug: chromium:968603 Change-Id: I004715bc95d426958f1a89ce76c4856da1d4ceee Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655652 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Reuse helpers and move generic functions to char-predicates Change-Id: I63bf704bdd8e8cd788e80ad2d42b689527865e00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653118Reviewed-by:
-
Georg Schmid authored
[turbofan] Extend BitcastTaggedToWord(BitcastWordToTaggedSigned(...)) elimination to BitcastTaggedSignedToWord R=tebbi@chromium.org Bug: chromium:973047 Change-Id: I33de86258e04140c6da8099a0d9e4aee3f74abe9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655298 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
-
Benedikt Meurer authored
Previously the object cloning fast-path had a single loop which would initialize the object _and_ at the same time clone MutableHeapNumbers. But since that can trigger GCs, the heap verifier was a bit sad to see double fields holding undefined values. This was flushed out by the CL https://chromium-review.googlesource.com/1655291, which changed the GC timing slightly and thus made the test crash in the verifier. So instead of the one loop, we now have a second loop that takes care of cloning any MutableHeapNumbers. This has the advantage that the first loop can always run without write barriers. Bug: chromium:964748, chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Change-Id: I724a1c1e534243ce9ecde95bf0c07ca26363b515 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655307 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62114}
-
Jakob Gruber authored
bytecodes-irregexp.h -> regexp-bytecodes.h interpreter-irregexp.{cc,h} -> regexp-interpreter.{cc,h} Change-Id: I98ca9d5c3264ad0adbd280b93082aa3e01b45b67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655294 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: -
Sigurd Schneider authored
This is pre-work for a refactoring that changes how heap objects are handled in the assembler: Currently, we put the handle location in the constant pool, and replace these with the actual heap object when we copy the code from the assembler's buffer to the heap. In the future, we will put a small index in the constant pool, which will ultimately enable 32bit constant pool slots for compressed heap objects. This small index will be fixed up when we copy the code to the heap. This CL makes the assembler tests copy the code to the heap, which ensures that the fix-up phase is actually run. Change-Id: I80cd69dc57414a3bd0a27f8d558616aadcae05a2 Bug: v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647166 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Mike Stanton authored
As a component of the wider Turbofan logging scheme, it makes sense for JSHeapBroker logging to come through flags specified in the OptimizedCompilationInfo class, which uses --trace-turbo-filter to control which functions are logged. Bug: v8:7790 Change-Id: I3b068d8be78867ab0bd9607dda9eca4123b9d7b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655297Reviewed-by:
-
Leszek Swirski authored
This reverts commit 823795fc. Reason for revert: Breaks mjsunit/es9/regress/regress-904167 on bots (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/26342) Original change's description: > [ic] Fix typo in Runtime_CloneObjectIC_Miss. > > https://chromium-review.googlesource.com/1649554 introduced a typo into > Runtime_CloneObjectIC_Miss, where it wouldn't update the IC state UNLESS > the source map is deprecated, which is the wrong way around of course. > > Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 > Change-Id: I7d6e0709e66ce4aaaf4a628d64ab801b84c8993c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655291 > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62106} TBR=bmeurer@chromium.org,verwaest@chromium.org Change-Id: Ie651523c556b220e57ec5e11e37b0a67936bb291 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655299Reviewed-by:
-
Benedikt Meurer authored
API calls made via the CallApiCallback builtin, which is used from the ICs and optimized code, are currently misattributed to the wrong counter InvokeFunctionCallback instead of FunctionCallback. In addition we don't use the C trampoline when only runtime call stats are enabled, but the Chrome DevTools profiler is not active, which means that these calls will not be attrituted properly at all, and that had to be worked around using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is active and not inlining calls/property accesses into optimized code depending on the state of RCS). All of this was really brittle and only due to the fact that the central builtin didn't properly check for RCS (in addition to checking for the CDT profiler). With this fix it's now handled in a central place and attributed to the correct category, so user code doesn't need to worry about RCS anymore and can just call straight into the fast-path. Drive-by-fix: Do the same for AccessorInfo getter calls, which share the core hand-written native code with the API callback logic. Bug: v8:9183 Change-Id: Id0cd99d3dd676635fe3272b67cd76a19a9a9cea4 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1651470 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Nico Weber authored
The C++ standard says that template functions should be parsed immediately, and only type-dependent things should be deferred. cl.exe (MSVC's compiler) instead deferred parsing of all template functions until the end of the translation unit, and unreferenced template functions are not parsed at all. clang-cl emulates cl.exe's behavior. Recently, cl.exe (and clang-cl) grew a /Zc:twoPhase flag that opts in to the standards-conforming behavior, and system headers are now clean enough to build with this flag set. This cleans up v8 to also build with this flag. There was just a single issue: RecyclingZoneAllocator() is unused and contains invalid code: It calls the superclass ctor using `ZoneAllocator(nullptr, nullptr)`, when it should be doing `ZoneAllocator<T>(nullptr, nullptr)`. With /Zc:twoPhase, this is now a parsing error. However, since the RecyclingZoneAllocator() default constructor isn't used anywhere, just delete it. Finally, improve the comment for ZoneAllocator's default constructor to explain why it's needed on Windows. Bug: chromium:969702 Change-Id: I7a516afde67fe090a512d7c7214a3c6932754aca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652503 Auto-Submit: Nico Weber <thakis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Igor Sheludko authored
... in favor of Isolate*. It seems that it's better to be uniform in using Isolate* or isolate root value, so if we decide to pass isolate root value instead of Isolate* it should better be done everywhere and it will be a separate CL anyway. Regarding the "optionality" of the isolate parameter - C++ compilers are smart enough to optimize it away during inlining. Bug: v8:9353 Change-Id: Idf86a792476f49393041ced1c54b8671f5b1794a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653121 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
https://chromium-review.googlesource.com/1649554 introduced a typo into Runtime_CloneObjectIC_Miss, where it wouldn't update the IC state UNLESS the source map is deprecated, which is the wrong way around of course. Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Change-Id: I7d6e0709e66ce4aaaf4a628d64ab801b84c8993c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655291 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Frank Tang authored
Add special condiction in ecma262 #sec-runtime-semantics-canonicalize-ch Step 3.g-h. Bug: chromium:971636 Change-Id: Id533beb66749af6e38ee114cf79f995a1156df20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652795Reviewed-by:
-
