v8/test/cctest/test-roots.cc

95 lines
3.3 KiB
C++
Raw Normal View History

// Copyright 2018 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#include "src/common/globals.h"
#include "src/heap/basic-memory-chunk.h"
#include "src/heap/heap-inl.h"
#include "src/objects/cell.h"
#include "src/objects/feedback-cell.h"
#include "src/objects/script.h"
#include "src/roots/roots-inl.h"
#include "test/cctest/cctest.h"
namespace v8 {
namespace internal {
namespace {
AllocationSpace GetSpaceFromObject(Object object) {
DCHECK(object.IsHeapObject());
BasicMemoryChunk* chunk =
BasicMemoryChunk::FromHeapObject(HeapObject::cast(object));
if (chunk->InReadOnlySpace()) return RO_SPACE;
return chunk->owner()->identity();
}
} // namespace
#define CHECK_IN_RO_SPACE(type, name, CamelName) \
HeapObject name = roots.name(); \
CHECK_EQ(RO_SPACE, GetSpaceFromObject(name));
// The following tests check that all the roots accessible via ReadOnlyRoots are
// in RO_SPACE.
TEST(TestReadOnlyRoots) {
ReadOnlyRoots roots(CcTest::i_isolate());
READ_ONLY_ROOT_LIST(CHECK_IN_RO_SPACE)
}
#undef CHECK_IN_RO_SPACE
namespace {
bool IsInitiallyMutable(Factory* factory, Address object_address) {
// Entries in this list are in STRONG_MUTABLE_MOVABLE_ROOT_LIST, but may
// initially point to objects that are in RO_SPACE.
#define INITIALLY_READ_ONLY_ROOT_LIST(V) \
V(api_private_symbol_table) \
V(api_symbol_table) \
[diagnostics] Support --turbo-profiling for builtins Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
2020-05-21 15:51:40 +00:00
V(basic_block_profiling_data) \
V(builtins_constants_table) \
[async] Introduce the notion of a "current microtask". Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 07:49:50 +00:00
V(current_microtask) \
V(detached_contexts) \
V(feedback_vectors_for_profiling_tools) \
Reland x6 [arraybuffer] Rearchitect backing store ownership This reverts commit 9da3483136b5e71e830ed9a9c34802ad8d605e58 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5aeba9ceb13f8bfc401c5ba2521c2207ffb > > Contributed by titzer@chromium.org > > 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. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63617}
2019-09-09 10:19:34 +00:00
V(shared_wasm_memories) \
V(materialized_objects) \
V(public_symbol_table) \
V(retaining_path_targets) \
V(serialized_global_proxy_sizes) \
V(serialized_objects) \
V(weak_refs_keep_during_job)
#define TEST_CAN_BE_READ_ONLY(name) \
if (factory->name().address() == object_address) return false;
INITIALLY_READ_ONLY_ROOT_LIST(TEST_CAN_BE_READ_ONLY)
#undef TEST_CAN_BE_READ_ONLY
#undef INITIALLY_READ_ONLY_ROOT_LIST
return true;
}
} // namespace
// The CHECK_EQ line is there just to ensure that the root is publicly
// accessible from Heap, but ultimately the factory is used as it provides
// handles that have the address in the root table.
#define CHECK_NOT_IN_RO_SPACE(type, name, CamelName) \
Handle<Object> name = factory->name(); \
CHECK_EQ(*name, heap->name()); \
if (name->IsHeapObject() && IsInitiallyMutable(factory, name.address()) && \
!name->IsUndefined(CcTest::i_isolate())) { \
CHECK_NE(RO_SPACE, GetSpaceFromObject(HeapObject::cast(*name))); \
}
// The following tests check that all the roots accessible via public Heap
// accessors are not in RO_SPACE with the exception of the objects listed in
// INITIALLY_READ_ONLY_ROOT_LIST.
TEST(TestHeapRootsNotReadOnly) {
Factory* factory = CcTest::i_isolate()->factory();
Heap* heap = CcTest::i_isolate()->heap();
MUTABLE_ROOT_LIST(CHECK_NOT_IN_RO_SPACE)
}
#undef CHECK_NOT_IN_RO_SPACE
} // namespace internal
} // namespace v8