- 19 Feb, 2021 1 commit
-
-
Mike Stanton authored
Code objects are exposed through JSFunction and SharedFunctionInfo. If they are builtins, we don't have to worry about background threads seeing partially initialized code objects. If they are optimized code objects, we may. Background threads read the code fields with AcquireLoad semantics. The fields are set on the main thread with ReleaseStore semantics when appropriate. Special care is taken when setting an optimized code object in a closure in the interpreter entry stub. Since the MacroAssembler doesn't support ReleaseStore semantics, this CL ensures that the optimized code object is stored with those semantics in the feedback vector, where the interpreter entry stub finds it. Bug: v8:7790 Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72869}
-
- 16 Feb, 2021 1 commit
-
-
Leszek Swirski authored
Pass an explicit Isolate* argument to Compiler::Compile*, rather than grabbing the Isolate from the function Change-Id: I37a38103c67305077225ea3951d36007cf07beea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696655Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72762}
-
- 09 Feb, 2021 1 commit
-
-
Michael Lippautz authored
Embedders may use cppgc (or v8::CppHeap) earlier than V8's Isolate and platform are initialized. Require explicit initialization of cppgc to avoid recurring init calls with potentially conflicting parameters. Bug: chromium:1056170 Change-Id: I613452954b322c9a5bf074eefd25107b4579958c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682648Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72573}
-
- 26 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Scopes in V8 are used to guarantee one or more properties during its lifetimes. If a scope is not named e.g MyClassScope(args) instead of MyClassScope scope(args) it will get created and automatically destroyed and therefore, being useless as a scope. This CL would produce a compiling warning when that happens to ward off this developer error. Follow-up to ccrev.com/2552415 in which it was introduced and implemented for Guard classes. Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71425}
-
- 18 Nov, 2020 1 commit
-
-
Maya Lekova authored
This CL introduces a new fast_api_call_target field on the isolate, which is set by Turbofan before making the fast call. It then uses the field when creating a stack sample and stores it in the existing external_callback_entry used for regular API callbacks. The CL also adds a cctest with simple usage scenario and introduces a minor refactoring in test-api.cc. Design doc: https://docs.google.com/document/d/1r32qlPzGz0P7nieisJ5h2qfSnWOs40Cigt0LXPipejE/edit Bug: chromium:1052746 Change-Id: I2dab1bc395ccab0c14088f7c354fb52b08df8d32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488683 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#71254}
-
- 30 Sep, 2020 1 commit
-
-
Jakob Gruber authored
CodeKind::OPTIMIZED_CODE -> TURBOFAN Kinds are now more fine-grained and distinguish between TF, TP, NCI. CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING Code stubs (like builtins, but generated at runtime) were removed from the codebase years ago, this is the last remnant. This kind is used only for deopt entries (which should be converted into builtins) and for tests. Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#70234}
-
- 16 Sep, 2020 1 commit
-
-
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 using isolate->js_entry_sp to determine the stack to walk but isolate->js_entry_sp is the stack pointer for the thread that currently has the Isolate lock so, if the sampled thread does not have the lock, the sampler woud be iterating over the wrong stack, one that might actually be actively changing on another thread. 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: Iba6cabcd3e11a19c261c004103e37e806934dc6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69952}
-
- 11 Sep, 2020 1 commit
-
-
Daniel Bevenius authored
The commit updates the way the usage is printed for cctest to make use of HelpOptions which allows the usage string to be passed into SetFlagsFromCommandLine function. Change-Id: I8dcd48ca8bb7b025f77c0f05ab37ce4f7b6fae04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402032Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#69839}
-
- 03 Sep, 2020 1 commit
-
-
Ulan Degenbaev authored
This is a reland of 9eb090d2 The android-pie-arm64-dbg compiler error was fixed in: https://chromium-review.googlesource.com/c/v8/v8/+/2381450 Original change's description: > [heap] Add concurrent typed slot recording > > Since the typed slot set is not thread-safe, each concurrent marking > barrier collects typed slots locally and publishes them to the main > typed slot set in safepoints. > Bug: v8:10315 > > Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69576} Bug: v8:10315 Change-Id: Iae2882bad1cd0ffcae28c96318ba5fd7937f2215 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390763Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69694}
-
- 01 Sep, 2020 1 commit
-
-
Peter Marshall authored
This reverts commit dfb3f7da. Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861 Original change's description: > [cpu-profiler] Ensure sampled thread has Isolate lock under Windows > > 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/+/2377108 > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69623} TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10850 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69638}
-
- 31 Aug, 2020 1 commit
-
-
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:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69623}
-
- 28 Aug, 2020 1 commit
-
-
Piotr Bialecki authored
This reverts commit 9eb090d2. Reason for revert: breaks trybot android-pie-arm64-dbg, repro steps: build cctest with target_cpu="arm64" in the args. See thread: https://chromium.slack.com/archives/CGJ5WKRUH/p1598563610118900 Original change's description: > [heap] Add concurrent typed slot recording > > Since the typed slot set is not thread-safe, each concurrent marking > barrier collects typed slots locally and publishes them to the main > typed slot set in safepoints. > Bug: v8:10315 > > Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69576} TBR=ulan@chromium.org,dinfuehr@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:10315 Change-Id: Iade0443e5eccef06e3ea77913e18fd1f563995f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380613 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69597}
-
- 26 Aug, 2020 1 commit
-
-
Ulan Degenbaev authored
Since the typed slot set is not thread-safe, each concurrent marking barrier collects typed slots locally and publishes them to the main typed slot set in safepoints. Bug: v8:10315 Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69576}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 24 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... that controls whether the TF graph zones should support compression. Bug: v8:9923 Change-Id: Ifbe237b75e9c92e62eb32b69d6b3b1a818269b83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308347 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69036}
-
- 06 Jul, 2020 1 commit
-
-
Leszek Swirski authored
This will allow it to take an OffThreadIsolate in the future, without requiring GetIsolate on SharedFunctionInfo. Change-Id: I7db56d5f0587585f829b26e60683c133760d8ff1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282534Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68696}
-
- 15 Jun, 2020 1 commit
-
-
Jakob Gruber authored
... to OptimizedCompilationInfo, BytecodeGraphBuilder, and JSHeapBroker. Also add first uses of these flags in pipeline.cc by skipping certain phases when nci is enabled. With this change, tests in the NCI variant will start to fail since generic lowering is not fully implemented. These implementations will follow incrementally in the next days. Bug: v8:8888 Change-Id: I3f570fb92f09059d1f1f4015f88ffe80ccf746ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239572 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68339}
-
- 10 Jun, 2020 1 commit
-
-
Jakob Gruber authored
... for more consistent naming and less boilerplate. Getters now use the `lower_case_flag()` style. Setters now use the `set_lower_case_flag()` style. Bug: v8:8888 Change-Id: I5af35b13a013bf303c4ca8d86f926754af28bfce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237139 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68293}
-
- 03 Jun, 2020 1 commit
-
-
Mythri A authored
This is a followup of the cl [1] that fixes a bug where bytecode was getting flushed when allocating feedback vector. The fix added IsCompiledScope before allocating a new feedback vector. We now pass IsCompiledScope to JSFunction::EnsureFeedbackVector. This makes it explicit that EnsureFeedbackVector expects a function that is compiled and the bytecode shouldn't be flushed during the allocation.Also adds a test. [1] https://chromium-review.googlesource.com/c/v8/v8/+/2218066 Bug: v8:10560 Change-Id: I552c449a57555dffa625b2e4efa04c2c276fc0b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222347 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68142}
-
- 26 May, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Several tests were using them and we can dedup code. Change-Id: I4ef5ae5772856d1f36e965b6b62ff5895b4e04fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215173Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#67974}
-
- 17 Apr, 2020 1 commit
-
-
Sami Kyostila authored
This patch replaces V8's tracing implementation (i.e., the TRACE_EVENT macros) with the track event base implementation from Perfetto. The advantages of doing this are: 1) This allows us to remove most tracing-related backend code from V8. 2) V8 can start writing strongly typed trace event arguments, which are more compact, easier to process and more extensible than legacy JSON-based trace arguments. For the time being, we still support the old trace macros when V8 is embedded into Chrome and other embedders. Design doc: https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/edit#heading=h.398p6b4eaen2 Bug: chromium:1006766 Change-Id: Ie71474fbe065821772b13d851487ebbca680c4ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947688 Commit-Queue: Sami Kyöstilä <skyostil@chromium.org> Auto-Submit: Sami Kyöstilä <skyostil@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67217}
-
- 10 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
Since we switched to C++14 now, we can use {std::make_unique} instead of our own {base::make_unique} from {template-utils.h}. R=mstarzinger@chromium.org, yangguo@chromium.org Bug: v8:9687 No-Try: true Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63642}
-
- 18 Jul, 2019 1 commit
-
-
Peter Marshall authored
Previously both tracing implementations would be run side-by-side when perfetto was enabled with the V8_USE_PERFETTO build flag. This CL makes them run separately. Both implementations now use the trace file provided by the user in D8 or the default v8_trace.json. Add tests for perfetto events (which must be tested differently due to the proto output format). Drive-by fix: Fix pass-by non-const ref in GetJSONStrings. Remove the TraceEvent struct for testing; we can just store a copy of the protobuf directly. Bug: v8:8339 Change-Id: Id50003e0f96e44b99a63a26693da6bdaca989504 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702619Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62810}
-
- 08 Jul, 2019 1 commit
-
-
Peter Marshall authored
The client API provides a much simpler interface so that we don't have to deal with producers, consumers etc. directly. This CL removes all the code that dealt with the more complex API used previously. The architecture used here requires that the embedder call into Tracing::Initialize() to set up the tracing backend. The tracing controller then connects to this backend when calling DataSource::Register() and Tracing::NewTrace(). This will ultimately avoid the need for a virtual call (or two) for every trace event that need to be dispatched over the API - chrome can provide a backend and V8 will connect to it opaquely with the same code when tracing is enabled. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: I6b74fbb49ffcc89638caeb59ed3d5cc81238f3e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634916Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62568}
-
- 05 Jul, 2019 1 commit
-
-
Maciej Goszczycki authored
Once read-only space is not a Heap space it makes little sense to have it in the Heap class. Bug: v8:7464 Change-Id: I2230ce7cbf1cec3c83065c91bc14a9c23f72478b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688841Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#62540}
-
- 23 May, 2019 2 commits
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
Clemens Hammacher authored
This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org Bug: v8:9183, v8:3770 No-Try: true No-Tree-Checks: true Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61764}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 02 May, 2019 2 commits
-
-
Maciej Goszczycki authored
Code relocation info is now always allocated in old-space. Before relocation info allocated for placeholders and builtins (which get replaced with trampolines in nosnap builds) would become unreachable. Since read-only space is not GCed and ReadOnlyHeapIterator doesn't check for reachability, ValidateSnapshot would fail finding unreachable objects returned by ReadOnlyHeapIterator. Because trampoline relocation info gets replaced with canonical one, this only affects no-embdded-builtins nosnap builds, which don't get much benefit from read-only relocation info anyway. A new check has been added to the read-only deserializer to verify that every read-only object is reachable at mksnapshot-time. The CombinedHeapIterator iteration order was changed to iterate over read-only space first, because that's how HeapIterator worked. This is a reland of 3d1d8eae Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} Bug: v8:7464 Change-Id: I49ae070955b77956962334a84f762ab29052d5ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#61185}
-
Georg Neis authored
This fixes a memory leak. Bug: v8:9191, v8:7790 Change-Id: I0df49cd3a6791600638a67b4b7ad9687562e500b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588426 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61166}
-
- 12 Apr, 2019 2 commits
-
-
Clemens Hammacher authored
This reverts commit 3d1d8eae. Reason for revert: Speculative revert; seems to break all nosnap bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap/25240 Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} TBR=ulan@chromium.org,hpayer@chromium.org,delphick@chromium.org,goszczycki@google.com Change-Id: I64b58b1b0c5eb073a6d2cfae81bb4de65f0511bf No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7464 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565895Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60825}
-
Maciej Goszczycki authored
Read-only space sharing requires an iterator independent of heap. This also enables future removal of read-only space from heap. Bug: v8:7464 Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#60819}
-
- 01 Feb, 2019 1 commit
-
-
Clemens Hammacher authored
This way we can remove them correctly and avoid leaks. R=mstarzinger@chromium.org, ulan@chromium.org Bug: v8:8725 Change-Id: I52cbbf34a94171aaeb581b55aecb25311465544d Reviewed-on: https://chromium-review.googlesource.com/c/1446453Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59266}
-
- 29 Jan, 2019 3 commits
-
-
Maya Lekova authored
This is a reland of acb60162 Original change's description: > [test] Add testing facility for SerializerForBackgroundCompilation > > R=neis@chromium.org > > Bug: v8:7790 > Change-Id: Id759112d0c780ff857eb094102245b38fcbb1709 > Reviewed-on: https://chromium-review.googlesource.com/c/1434375 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59153} Bug: v8:7790 Change-Id: I1593a768c77c563707b498d47b34a2b1e7fa5dea Reviewed-on: https://chromium-review.googlesource.com/c/1442234 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59171}
-
Maya Lekova authored
This reverts commit acb60162. Reason for revert: Breaks arm build - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/2035 Original change's description: > [test] Add testing facility for SerializerForBackgroundCompilation > > R=neis@chromium.org > > Bug: v8:7790 > Change-Id: Id759112d0c780ff857eb094102245b38fcbb1709 > Reviewed-on: https://chromium-review.googlesource.com/c/1434375 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59153} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: I5e6a3b94a9b177242aebb582c5184bb35e999314 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/1442232Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#59154}
-
Maya Lekova authored
R=neis@chromium.org Bug: v8:7790 Change-Id: Id759112d0c780ff857eb094102245b38fcbb1709 Reviewed-on: https://chromium-review.googlesource.com/c/1434375Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#59153}
-
- 23 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
This was disabled in 2014 (https://crrev.com/267383002), together with a comment about a broken serializer. The conditional v8 initialization was since then moved back to be unconditional, but the TearDown was never restored. Now we need it for wasm, since during tear down the wasm engine synchronizes on all background compile jobs. Omitting this leads to uses of the disposed platform (see https://crrev.com/c/1429861). R=mstarzinger@chromium.org Bug: v8:8689, v8:7921, v8:8725 Change-Id: Ia24f746094f38fc6ce349532587b622384379125 Reviewed-on: https://chromium-review.googlesource.com/c/1430059 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59032}
-
- 18 Jan, 2019 1 commit
-
-
Peter Marshall authored
We found the nexus 5x flake so this is no longer needed. Leave the printing functions themselves as they will still be useful for local debugging. Bug: v8:8649 Change-Id: Ie0af2bc9b0fc7fb8ac00ec0039b6898553865189 Reviewed-on: https://chromium-review.googlesource.com/c/1420957Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58923}
-
- 16 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
After moving to its own header, this CL cleans up some parts of the interface. It fixes names and const-declarations of simple accessors, and adds a named constructor to make it explicit that an EnumSet should be constructed from an integral value. Also refactor the use in cctest.h to have less statically declared constants. Instead, just create the set of extensions in the individual tests. R=titzer@chromium.org Bug: v8:8562 Change-Id: I6178d1aba25afa1d7f54c29ccf81505c165e7cd3 Reviewed-on: https://chromium-review.googlesource.com/c/1409366 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#58862}
-
- 08 Jan, 2019 1 commit
-
-
Peter Marshall authored
These flakes can't be reproduced locally so we need more information when they fail. Add some logging so that we can figure out why they are breaking. Bug: v8:8649, v8:8648 Change-Id: I2fb1384bb7592c6fc68c08952505e79329f00bec Reviewed-on: https://chromium-review.googlesource.com/c/1400418 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58641}
-