- 01 Sep, 2020 7 commits
-
-
Martin Bidlingmaier authored
Bug: v8:10765 Change-Id: I49e425d861d900ab66b6f7801cddec8a7175ac03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385462 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69637}
-
Leszek Swirski authored
Change the serialization protocol to ensure that maps are serialized before objects using them. This ensures that as soon as we allocate space for an object, we can immediately write the object's map into that allocation. In the future, this will allow us to make deserialized object visible to the GC. Specifically, this forces map serialization to happen after emitting a kNewObject for an object, but before allocating the space for it. We have to serialize the map after kNewObject because otherwise the map itself would be written into the "current" slot, into which the object is supposed to be deserialized. Objects whose maps are currently being deserialized are considered "pending" -- started, but not yet allocated. The map might point to a pending object (e.g. if an object's constructor points to the object). This is solved by introducing a new concept of forward references, where the field referring to the pending object is serialized as a "pending forward reference" which is "resolved" once the object is allocated. It might also point to itself, in the case of the meta map -- this is simply solved by introducing a new bytecode for the meta map; this cannot be a pending forward reference because the meta map is not yet allocated, so its map slot cannot be registered as pending. Finally, we may need to go to a new chunk after serializing the map; so after the map serialization, we peek to see if there's a next chunk bytecode before the object allocation. Bug: v8:10815 Change-Id: Ifa8f25bdaf3b15b5d990a1d2e7be677c2fa80013 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362953 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Rewrite the deserializer case macros to look, to formatters, more like a single case value, and clean up some of the repetition to be more explicit, e.g. replace SIXTEEN_CASES(kFoo) impl() with case CASE_REPEAT(kFoo, 16): impl() This should help with auto-formatting issues when modifying the big deserializer switch statement. As a drive-by, also clean up the per-space case macros to use a function rather than a macro for specifying the bytecode, and add helpers for encoding fixed raw data size in the bytecode (similar to the existing helper for fixed repeat counts). Change-Id: I885ba79afef03b95ad64cd78bdfba5dffc82be1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367853 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: -
Santiago Aboy Solanes authored
Mostly a cleanup for x64. Also enable two tests for Arm and Arm64 since they do not make use of JSEntry frames. Bug: v8:10833 Change-Id: Id6adadf582bdca0076460842ffe4ec856ca99393 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381455 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69634}
-
Clemens Backes authored
{std::atomic} is being used in the header without including the <atomic> header. It was reported on the v8-users list that this causes compile errors on Windows. R=ulan@chromium.org Change-Id: I1de19c301ce47787628416bf0e744d0dd7507fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387562Reviewed-by:Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69633}
-
Frank Tang authored
This is a reland of c6d3516f Original change's description: > [Intl] Ship Intl.Segmenter > > Spec: https://tc39.es/proposal-intl-segmenter/ > ECMA402 site: https://github.com/tc39/proposal-intl-segmenter > I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/MJ1OpvkcA8s/m/mYNxpwqSCAAJ > I2I: https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/rB_2I9t0CQAJ > Design Doc: https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit > CPS: https://www.chromestatus.com/feature/6099397733515264 > Test262 Tests: https://github.com/tc39/test262/tree/main/test/intl402/Segmenter > v8 tests: https://source.chromium.org/chromium/chromium/src/+/master:v8/test/intl/segmenter/?q=test%2Fintl%2Fsegmenter&ss=chromium > > Approved by API Owners: yoav@yoav.ws / chrishtr@chromium.org / bratell.d@gmail.com > > Bug: v8:6891 > Change-Id: I64775ed63557a9e1af77560abd42349742bc4c03 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376967 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69593} Bug: v8:6891 Change-Id: I0908c859ce4c7875860f5839a2548b55daea3c89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380440 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69632}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2dbf41f..482dd77 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/77fb6d1..1eb42f5 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c73782c..ed15af5 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/89d15db..fcef86e TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Id3cf39f4f058d8cd46c93c6ccc5edf6c345f7d0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386623Reviewed-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@{#69631}
-
- 31 Aug, 2020 16 commits
-
-
Omer Katz authored
Heap growing estimates when to start incremental gc such that it will finish when we are expecting to finalize (i.e. when an atomic gc would be triggered). There is also a minimum ratio between limit for atomic gc and limit for incremental gc, to guarantee that incremental gc get's some time to run even with the application rarely allocates. This is a continuation of: https://chromium-review.googlesource.com/c/v8/v8/+/2377691 Bug: chromium:1056170 Change-Id: I8c87e98d60b6f8b5748558771a236f15385f7858 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381454Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 524fa743 Original Commit Message: This regression test does not work on MIPS without SIMD since the scalar lowering is not complete yet. Skip it for now. R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I0338593de3160dc0864c066e607b6030956e3efa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386141Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69629}
-
bcoe authored
Incrementing coverage counter was triggering EvalError for evaluateOnCallFrame when throwOnSideEffect is true. R=jgruber@chromium.org, sigurds@chromium.org, yangguo@chromium.org Bug: v8:10856 Change-Id: I0552e19a3a14ff61a9cb626494fb4a21979d535e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384011 Commit-Queue: Benjamin Coe <bencoe@google.com> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#69628}
-
Brendan Shanks authored
When running 64-bit Windows binaries on macOS using Wine, there is a conflict between macOS's use of GS to point to pthread thread-specific data, and Windows' use of GS to point to the TEB. Apple has reserved some TSD slots for use by Wine to store commonly-used TEB members (such as 0x30, the 'Self' pointer to the TEB). But, other direct GS accesses by Windows programs (such as to 'StackBase') will return macOS pthread data rather than the TEB member. This was causing a V8 unit test to crash on macOS under Wine. Using NtCurrentTeb() gets the 'Self' pointer first, then dereferences it to access the correct 'StackBase', fixing the crash. This turns GetStackStart() from one instruction into two. Chrome (http://crrev.com/c/2380425) and Crashpad also use NtCurrentTeb(). The 32-bit change isn't needed, but is just for consistency. Bug: chromium:1121842 Change-Id: I824f893aa451d8570142226be91840c964426f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381941Reviewed-by:
-
Ng Zhi An authored
This regression test does not work on MIPS without SIMD since the scalar lowering is not complete yet. Skip it for now. Bug: v8:10831 Change-Id: Icc407488a96d4c965c1cf956f7a74abde078d421 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385855Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69626}
-
Arthur Eubanks authored
v8/test/cctest/interpreter/test-bytecode-generator.cc contains lots of string arrays with intentional concatenation. Bug: chromium:1114873 Change-Id: Ie9d35c3849b5b0a6d1d01b6ce21fb80a320d8736 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366829 Commit-Queue: Arthur Eubanks <aeubanks@google.com> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69625}
-
Tianping Yang authored
By eager compile all functions in the startup snapshot, the startup snapshot can contain all function codes without warm-up. BUG=v8:4836 R=yangguo@chromium.org Change-Id: I07e86b6940c2fe75816df8ae429d110272216d0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379535Reviewed-by:
-
Alex Kodat authored
While the sampler checked if the sampled thread had the Isolate locked (if locks are being used) under Linux, the check was not done under Windows (or Fuchsia) which meant that in a multi-threading application under Windows, thread locking was not checked making it prone to seg faults and the like as the profiler would be extracting info from a heap in motion. The fix was to move the lock check into CpuSampler and Ticker (--prof) so all OSes would do the correct check. The basic concept is that on all operating systems a CpuProfiler, and so its corresponding CpuCampler, the profiler is tied to a thread. This is not based on first principles or anything, it's simply the way it works in V8, though it is a useful conceit as it makes visualization and interpretation of profile data much easier. To collect a sample on a thread associated with a profiler the thread must be stopped for obvious reasons -- walking the stack of a running thread is a formula for disaster. The mechanism for stopping a thread is OS-specific and is done in sample.cc. There are currently three basic approaches, one for Linux/Unix variants, one for Windows and one for Fuchsia. The approaches vary as to which thread actually collects the sample -- under Linux the sample is actually collected on the (interrupted) sampled thread whereas under Fuchsia/Windows it's on a separate thread. However, in a multi-threaded environment (where Locker is used), it's not sufficient for the sampled thread to be stopped. Because the stack walk involves looking in the Isolate heap, no other thread can be messing with the heap while the sample is collected. The only ways to ensure this would be to either stop all threads whenever collecting a sample, or to ensure that the thread being sampled holds the Isolate lock so prevents other threads from messing with the heap. While there might be something to be said for the "stop all threads" approach, the current approach in V8 is to only stop the sampled thread so, if in a multi-threaded environment, the profiler must check if the thread being sampled holds the Isolate lock. Since this check must be done, independent of which thread the sample is being collected on (since it varies from OS to OS), the approach is to save the thread id of the thread to be profiled/sampled when the CpuSampler is instantiated (on all OSes it is instantiated on the sampled thread) and then check that thread id against the Isolate lock holder thread id before collecting a sample. If it matches, we know sample.cc has stop the sampled thread, one way or another, and we know that no other thread can mess with the heap (since the stopped thread holds the Isolate lock) so it's safe to walk the stack and collect data from the heap so the sample can be taken. It it doesn't match, we can't safely collect the sample so we don't. Bug: v8:10850 Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108Reviewed-by:
-
Gus Caplan authored
PerformCheckCast<Data>() itself should not invoke Data::Cast(), since there is no such method and every publicly available value can be casted to it anyway. This is an issue in e.g. GetDataFromSnapshotOnce<Data>(). Change-Id: I5d9ee89657c31bc0ca1fb16e704df58911c85f6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2383030 Commit-Queue: Gus Caplan <snek@chromium.org> Reviewed-by:
-
Martin Bidlingmaier authored
This CL adds support for disjunctions and some quantification in EXPERIMENTAL regexp patterns. It is implemented using a new bytecode format and an NFA-based breadth-first interpreter. R=jgruber@chromium.org Bug: v8:10765 Change-Id: Idd49a3bbc9a9fcc2be80d822c9d84a638e53e777 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370634 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69621}
-
Nico Hartmann authored
Bug: chromium:1120729 Change-Id: I27533a2426a63ec6b67d34d94f3cae554fc95d91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379852 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69620}
-
Jakob Gruber authored
The graph assembler calls MergeControlToEnd as part of Unreachable node creation; this causes issues when used inside the GraphReducer framework, since the reducer is not notified by gasm that the end node should be revisited. The (hacky) fix in this CL is to always mark the end node for revisitation after a gasm reduction has taken place. Bug: v8:8888,chromium:1123379 Change-Id: I350bb7144add04a0c3fd7f3d88c07fcfe1cd42e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384772 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69619}
-
Marja Hölttä authored
The goal is to have one graph per test case, and inside the graph, 4 different lines: - baseline - baseline noopt - super-ic - super-ic noopt Bug: v8:9237 Change-Id: I511b5555487a3d96698a3fb648abf76a13f76858 No-Try: True Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384770Reviewed-by:
-
Jakob Kummerow authored
A recent unrelated change caused these tests to get unlucky in GC stress mode. Their "assertOptimized" expectations rely on certain type feedback data not getting flushed at the wrong time. Bug: v8:10846 Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69617}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0efd610..2dbf41f Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6c48487..c73782c TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I6ca1f3428fd4c73446ecc2927a5493b42c39a73d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384549Reviewed-by:
-
Jake Hughes authored
With conservative stack scanning enabled, a snapshot of the call stack upon entry to GC will be used to determine part of the root-set. When the collector walks the stack, it looks at each value and determines whether it could be a potential on-heap object pointer. However, unlike with Handles, these on-stack pointers aren't guaranteed to point to the start of the object: the compiler may decide hide these pointers, and create interior pointers in C++ frames which the GC doesn't know about. The solution to this is to include an object start bitmap in the header of each page. Each bit in the bitmap represents a word in the page payload which is set when an object is allocated. This means that when the collector finds an arbitrary potential pointer into the page, it can walk backwards through the bitmap until it finds the relevant object's base pointer. To prevent the bitmap becoming stale after compaction, it is rebuilt during object sweeping. This is experimental, and currently only works with inline allocation disabled, and single generational collection. Bug: v8:10614 Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
- 29 Aug, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/f9767b5..0efd610 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ffb1227..6c48487 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b64a74c..89d15db TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ic0508bbd94bd2fa1e9d58002694bc9bb939bcd7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382433Reviewed-by:
-
- 28 Aug, 2020 16 commits
-
-
Ng Zhi An authored
For SIMD instructions that use aligned moves (like movaps or movapd), we don't have correct memory alignment for SIMD moves yet. Switch to to movupd. Bug: v8:9198 Bug: v8:10831 Change-Id: Ic60fba5d08dda9676f6091ce505ac7be54957d00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380240 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
This allows tests to be skipped on nosse41 builds. For SIMD, nosse41 means that we need to scalar lower all SIMD instructions, which is not fully implemented yet. Bug: v8:10831 Change-Id: I27dd2840b376da672237fed764cbd2491c244627 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380710Reviewed-by:
Liviu Rau <liviurau@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69612}
-
Clemens Backes authored
Even though we provide a --wasm-max-code-space flag (defaulting to {kMaxWasmCodeMB}, we still had checks in place that the actual committed code space is not bigger than that constant. This CL fixes that by always comparing against the value of the flag. This will allow us to specify a code space limit which is larger than the default. This is useful when debugging larger Wasm apps which exceed the limit, but are not meant to be shipped that way. Drive-by: Remove a dead use of the {kMaxWasmCodeMemory} constant. R=ecmziegler@chromium.org Bug: chromium:1117033, chromium:1114093, chromium:1107649, chromium:1111266 Change-Id: I2684446230a8a6f0a27ad963dd6f36e5764b25e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376810Reviewed-by:Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69611}
-
Zeynep Cankara authored
This CL adds a source code panel to display source code positions of Map/IC log events. * Clicking file positions on the Ic Panel emits FocusEvent with SourcePositionLogEvent as entry to highlight code related with the selected icLogEvent. * Clicking map details on the Map Panel emits FocusEvent with SourcePositionLogEvent as entry to highlight code related with the selected mapLogEvent. Bug: v8:10644 Change-Id: Icaf3e9e3f7fae485c50ad685f9ec5dc8ac28b3dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358734 Commit-Queue: Zeynep Cankara <zcankara@google.com> Reviewed-by:
-
Clemens Backes authored
Those globals must have type float instead of int to preserve the sign bit. R=ahaas@chromium.org Bug: chromium:1069173 Change-Id: I9769f47f087aaba94a6172118be44f70adeded0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379861Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69609}
-
Clemens Backes authored
These trace events can be used for triaging profiling issues. We already have one event if code logging is triggered via an interrupt. The new events will be emitted if called via the foreground task, or just directly (e.g. after deserialization). R=ecmziegler@chromium.org Change-Id: I67ad9568f38d9a6eb98abf53ce5542ed56170c60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376811Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2841b25..f9767b5 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f9ede33..77fb6d1 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/7d98e22..ffb1227 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ica76a0a38bda603347cb3e97ebf2884507415d8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381179Reviewed-by:
-
Marja Hölttä authored
LoadICParameters already has separate fields for receiver and holder, though, in practice, they were always equal. Moreover, the holder didn't mean holder, but the lookup start object. This CL makes parts of the IC layer reusable for cases where they are not equal, by clarifying whether we're accessing the receiver, the lookup_start_object, or the holder. List of changes: StoreICParameters: - Detached from LoadICParameters, now they are independent classes. LoadICParameters: - Renamed holder to lookup_start_object. TryProbeStubCache: - Renamed receiver to lookup_start_object. LoadIC: LoadIC_BytecodeHandler: LoadIC_NoFeedback: KeyedLoadIC: KeyedLoadICGeneric: KeyedLoadICPolymorphicName: - These won't be reused in the receiver != lookup_start_object case, so added asserts that receiver == lookup_start_object. TryMonomorphicCase: HandlePolymorphicCase: LoadIC_Noninlined: GenericElementLoad: - Renamed receiver_map param to lookup_start_object_map. The callers either assert receiver == lookup_start_object, or read the map from the lookup start object. GenericPropertyLoad: - Renamed receiver param to lookup_start_object. - Renamed receiver_map param to lookup_start_object_map. The callers either assert receiver == lookup_start_object, or read the map from the lookup start object. CallGetterIfAccessor: - Added the holder parameter and used it accordingly. Bug: v8:9237 Change-Id: I27aca08f58bd66cc9bd1b1baf9f1ff5565d795eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362918 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#69606}
-
Ulan Degenbaev authored
Bug: v8:10848 Change-Id: Icf014ecd5b0014be258d05aa0f958001f838286b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381450 Auto-Submit: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Marja Hölttä authored
This is the first step in a series of CLs. The goal is to make super property access faster. Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing This CL: - Add bytecode LdaNamedPropertyFromSuper - IGNITION_HANDLER just calls Runtime::LoadFromSuper - JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node with a runtime call to Runtime::LoadFromSuper Bug: v8:9237 Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69604}
-
Anton Bikineev authored
Explicit nullification aims to simplify migration to Oilpan, in the case when unique_ptrs are converted to Member and user code relies on source pointers to be in "empty" state. Change-Id: Ia54137d53ca03f93932b3c1f2eaba439a416a06e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379857Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Omer Katz authored
Schedule is simpler compared to the schedule in blink since it now returns deadlines based on marked bytes instead of time. If marking is ahead of schedule, return the minimum step size. Otherwise, set step size to catch up to schedule (ignoring the time passed while performing the step). No more default initial step size (needed in blink since marking speed was unknown). If estimated schedule is exceeded (marking takes longer than 500ms), the steps will try to mark all remaining objects but would still be capped by the maximum step duration of 2ms. Bug: chromium:1056170 Change-Id: I09857db161c621a12d064f9c8c21b646c34f9d71 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375200 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Omer Katz authored
Starting marking required Creating a Marker and calling StartMarking. StartMarking should always have been called immediately after creating the marker. Since markers are not persisted between GC (a marker exists only while marking is in progress), it makes sense to start marking implicitly when a marker is created. Calling StartMarking in MarkerBase ctor is inadvisable since subclasses might still to initialize fields. Using MarkerFactory instead guarantees that StartMarking is always called immediately after creating a Marker. Bug: chromium:1056170 Change-Id: Icbf11afd848e1618c204ca6bf951600b3ae9fef2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375199 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Zeynep Cankara authored
Changes: * Transition edges on timeline-track with the same color of the map type. * Log file reader loading background adapted to light theme. * Support additional IC log event colors. * Move theme switch button to top of the app. Bug: v8:10644, v8:10673 Change-Id: Ib086b6f4a8bc5f86a4925b251112c640e37278ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379869Reviewed-by:
-
Omer Katz authored
Bug: chromium:1056170 Change-Id: I2e0947c5acfd110f0add7ae5b4e3e54e3c827478 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379864 Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Zeynep Cankara authored
Bug fixes: * Wrong time range selection of timeline chunks handled by mouse events. * Consecutive file uploads does not create a new Model object causing bugs on timeline-track start and end times. Bug: v8:10644 Change-Id: I3d31ddda1ffca70c18c87dd103f2b788713c2911 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379863Reviewed-by:
-
