2020-03-24 13:35:51 +00:00
|
|
|
// Copyright 2020 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.
|
|
|
|
|
2020-04-07 21:54:43 +00:00
|
|
|
#ifndef INCLUDE_CPPGC_INTERNAL_GC_INFO_H_
|
|
|
|
#define INCLUDE_CPPGC_INTERNAL_GC_INFO_H_
|
2020-03-24 13:35:51 +00:00
|
|
|
|
2021-03-17 12:17:42 +00:00
|
|
|
#include <atomic>
|
|
|
|
#include <cstdint>
|
2021-05-20 09:36:52 +00:00
|
|
|
#include <type_traits>
|
2020-03-24 13:35:51 +00:00
|
|
|
|
2020-04-20 18:19:29 +00:00
|
|
|
#include "cppgc/internal/finalizer-trait.h"
|
2020-10-08 11:20:09 +00:00
|
|
|
#include "cppgc/internal/name-trait.h"
|
2020-05-13 23:20:23 +00:00
|
|
|
#include "cppgc/trace-trait.h"
|
2020-04-27 16:29:03 +00:00
|
|
|
#include "v8config.h" // NOLINT(build/include_directory)
|
2020-03-24 13:35:51 +00:00
|
|
|
|
|
|
|
namespace cppgc {
|
|
|
|
namespace internal {
|
|
|
|
|
|
|
|
using GCInfoIndex = uint16_t;
|
|
|
|
|
cppgc: Optimize GCInfo setup
In Blink's version of Oilpan, GCInfo objects would reside in .bss and
a table would translate between an index and the .bss address. Upon
retrieving a GCInfoIndex, the slow path merely passes a .bss pointer
to a slow path setup method to create the table mapping.
In cppgc, we set up GCInfo entries directly in the table. This is
slightly faster for actually using GCInfo objects as there's no
indirection between table and .bss, and it also saves one pointer (the
indirection) per type that is set up. The downside of this approach is
that individual components of a GCInfo objects, that are all
type-dependent, need to be passed to the conditional setup method.
Since GCInfo indices must be retrieved on each allocation, this
pollutes the fast path with additional instructions.
However, GCInfo components are actually known at compile-time for many
objects. In such cases, we can use a compile-time static dispatch to
encode the known parameters in different functions. This saves around
40KiB of memory on ChromePublic.apk and also creates a more compact
fast path for allocation.
Bug: chromium:1238884, chromium:1056170
Change-Id: Iedd809a8baefcc02f131d2b2c77d341b0abe43bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094007
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76291}
2021-08-13 08:01:26 +00:00
|
|
|
struct V8_EXPORT EnsureGCInfoIndexTrait final {
|
|
|
|
// Acquires a new GC info object and returns the index. In addition, also
|
|
|
|
// updates `registered_index` atomically.
|
|
|
|
template <typename T>
|
|
|
|
V8_INLINE static GCInfoIndex EnsureIndex(
|
|
|
|
std::atomic<GCInfoIndex>& registered_index) {
|
|
|
|
return EnsureGCInfoIndexTraitDispatch<T>{}(registered_index);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
template <typename T, bool = std::is_polymorphic<T>::value,
|
|
|
|
bool = FinalizerTrait<T>::HasFinalizer(),
|
|
|
|
bool = NameTrait<T>::HasNonHiddenName()>
|
|
|
|
struct EnsureGCInfoIndexTraitDispatch;
|
|
|
|
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback,
|
|
|
|
FinalizationCallback,
|
|
|
|
NameCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback,
|
|
|
|
FinalizationCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback, NameCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexNonPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback,
|
2021-09-07 10:41:44 +00:00
|
|
|
FinalizationCallback,
|
|
|
|
|
cppgc: Optimize GCInfo setup
In Blink's version of Oilpan, GCInfo objects would reside in .bss and
a table would translate between an index and the .bss address. Upon
retrieving a GCInfoIndex, the slow path merely passes a .bss pointer
to a slow path setup method to create the table mapping.
In cppgc, we set up GCInfo entries directly in the table. This is
slightly faster for actually using GCInfo objects as there's no
indirection between table and .bss, and it also saves one pointer (the
indirection) per type that is set up. The downside of this approach is
that individual components of a GCInfo objects, that are all
type-dependent, need to be passed to the conditional setup method.
Since GCInfo indices must be retrieved on each allocation, this
pollutes the fast path with additional instructions.
However, GCInfo components are actually known at compile-time for many
objects. In such cases, we can use a compile-time static dispatch to
encode the known parameters in different functions. This saves around
40KiB of memory on ChromePublic.apk and also creates a more compact
fast path for allocation.
Bug: chromium:1238884, chromium:1056170
Change-Id: Iedd809a8baefcc02f131d2b2c77d341b0abe43bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094007
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76291}
2021-08-13 08:01:26 +00:00
|
|
|
NameCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexNonPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback,
|
|
|
|
FinalizationCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexNonPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback,
|
|
|
|
NameCallback);
|
|
|
|
static GCInfoIndex EnsureGCInfoIndexNonPolymorphic(std::atomic<GCInfoIndex>&,
|
|
|
|
TraceCallback);
|
|
|
|
};
|
|
|
|
|
|
|
|
#define DISPATCH(is_polymorphic, has_finalizer, has_non_hidden_name, function) \
|
|
|
|
template <typename T> \
|
|
|
|
struct EnsureGCInfoIndexTrait::EnsureGCInfoIndexTraitDispatch< \
|
|
|
|
T, is_polymorphic, has_finalizer, has_non_hidden_name> { \
|
|
|
|
V8_INLINE GCInfoIndex \
|
|
|
|
operator()(std::atomic<GCInfoIndex>& registered_index) { \
|
|
|
|
return function; \
|
|
|
|
} \
|
|
|
|
};
|
|
|
|
|
|
|
|
// --------------------------------------------------------------------- //
|
|
|
|
// DISPATCH(is_polymorphic, has_finalizer, has_non_hidden_name, function)
|
|
|
|
// --------------------------------------------------------------------- //
|
|
|
|
DISPATCH(true, true, true, //
|
|
|
|
EnsureGCInfoIndexPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace, //
|
|
|
|
FinalizerTrait<T>::kCallback, //
|
|
|
|
NameTrait<T>::GetName)) //
|
|
|
|
DISPATCH(true, true, false, //
|
|
|
|
EnsureGCInfoIndexPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace, //
|
|
|
|
FinalizerTrait<T>::kCallback)) //
|
|
|
|
DISPATCH(true, false, true, //
|
|
|
|
EnsureGCInfoIndexPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace, //
|
|
|
|
NameTrait<T>::GetName)) //
|
|
|
|
DISPATCH(true, false, false, //
|
|
|
|
EnsureGCInfoIndexPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace)) //
|
|
|
|
DISPATCH(false, true, true, //
|
|
|
|
EnsureGCInfoIndexNonPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace, //
|
|
|
|
FinalizerTrait<T>::kCallback, //
|
|
|
|
NameTrait<T>::GetName)) //
|
|
|
|
DISPATCH(false, true, false, //
|
|
|
|
EnsureGCInfoIndexNonPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace, //
|
|
|
|
FinalizerTrait<T>::kCallback)) //
|
|
|
|
DISPATCH(false, false, true, //
|
|
|
|
EnsureGCInfoIndexNonPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace, //
|
|
|
|
NameTrait<T>::GetName)) //
|
|
|
|
DISPATCH(false, false, false, //
|
|
|
|
EnsureGCInfoIndexNonPolymorphic(registered_index, //
|
|
|
|
TraceTrait<T>::Trace)) //
|
|
|
|
|
|
|
|
#undef DISPATCH
|
2020-03-24 13:35:51 +00:00
|
|
|
|
2021-03-11 09:31:57 +00:00
|
|
|
// Fold types based on finalizer behavior. Note that finalizer characteristics
|
|
|
|
// align with trace behavior, i.e., destructors are virtual when trace methods
|
|
|
|
// are and vice versa.
|
|
|
|
template <typename T, typename ParentMostGarbageCollectedType>
|
|
|
|
struct GCInfoFolding {
|
|
|
|
static constexpr bool kHasVirtualDestructorAtBase =
|
|
|
|
std::has_virtual_destructor<ParentMostGarbageCollectedType>::value;
|
|
|
|
static constexpr bool kBothTypesAreTriviallyDestructible =
|
|
|
|
std::is_trivially_destructible<ParentMostGarbageCollectedType>::value &&
|
|
|
|
std::is_trivially_destructible<T>::value;
|
|
|
|
static constexpr bool kHasCustomFinalizerDispatchAtBase =
|
|
|
|
internal::HasFinalizeGarbageCollectedObject<
|
|
|
|
ParentMostGarbageCollectedType>::value;
|
|
|
|
#ifdef CPPGC_SUPPORTS_OBJECT_NAMES
|
|
|
|
static constexpr bool kWantsDetailedObjectNames = true;
|
|
|
|
#else // !CPPGC_SUPPORTS_OBJECT_NAMES
|
|
|
|
static constexpr bool kWantsDetailedObjectNames = false;
|
|
|
|
#endif // !CPPGC_SUPPORTS_OBJECT_NAMES
|
|
|
|
|
|
|
|
// Folding would regresses name resolution when deriving names from C++
|
|
|
|
// class names as it would just folds a name to the base class name.
|
|
|
|
using ResultType = std::conditional_t<(kHasVirtualDestructorAtBase ||
|
|
|
|
kBothTypesAreTriviallyDestructible ||
|
|
|
|
kHasCustomFinalizerDispatchAtBase) &&
|
|
|
|
!kWantsDetailedObjectNames,
|
|
|
|
ParentMostGarbageCollectedType, T>;
|
|
|
|
};
|
|
|
|
|
2020-03-24 13:35:51 +00:00
|
|
|
// Trait determines how the garbage collector treats objects wrt. to traversing,
|
|
|
|
// finalization, and naming.
|
|
|
|
template <typename T>
|
2021-03-17 12:17:42 +00:00
|
|
|
struct GCInfoTrait final {
|
cppgc: Optimize GCInfo setup
In Blink's version of Oilpan, GCInfo objects would reside in .bss and
a table would translate between an index and the .bss address. Upon
retrieving a GCInfoIndex, the slow path merely passes a .bss pointer
to a slow path setup method to create the table mapping.
In cppgc, we set up GCInfo entries directly in the table. This is
slightly faster for actually using GCInfo objects as there's no
indirection between table and .bss, and it also saves one pointer (the
indirection) per type that is set up. The downside of this approach is
that individual components of a GCInfo objects, that are all
type-dependent, need to be passed to the conditional setup method.
Since GCInfo indices must be retrieved on each allocation, this
pollutes the fast path with additional instructions.
However, GCInfo components are actually known at compile-time for many
objects. In such cases, we can use a compile-time static dispatch to
encode the known parameters in different functions. This saves around
40KiB of memory on ChromePublic.apk and also creates a more compact
fast path for allocation.
Bug: chromium:1238884, chromium:1056170
Change-Id: Iedd809a8baefcc02f131d2b2c77d341b0abe43bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094007
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76291}
2021-08-13 08:01:26 +00:00
|
|
|
V8_INLINE static GCInfoIndex Index() {
|
2020-03-24 13:35:51 +00:00
|
|
|
static_assert(sizeof(T), "T must be fully defined");
|
2021-03-17 12:17:42 +00:00
|
|
|
static std::atomic<GCInfoIndex>
|
|
|
|
registered_index; // Uses zero initialization.
|
|
|
|
const GCInfoIndex index = registered_index.load(std::memory_order_acquire);
|
|
|
|
return index ? index
|
cppgc: Optimize GCInfo setup
In Blink's version of Oilpan, GCInfo objects would reside in .bss and
a table would translate between an index and the .bss address. Upon
retrieving a GCInfoIndex, the slow path merely passes a .bss pointer
to a slow path setup method to create the table mapping.
In cppgc, we set up GCInfo entries directly in the table. This is
slightly faster for actually using GCInfo objects as there's no
indirection between table and .bss, and it also saves one pointer (the
indirection) per type that is set up. The downside of this approach is
that individual components of a GCInfo objects, that are all
type-dependent, need to be passed to the conditional setup method.
Since GCInfo indices must be retrieved on each allocation, this
pollutes the fast path with additional instructions.
However, GCInfo components are actually known at compile-time for many
objects. In such cases, we can use a compile-time static dispatch to
encode the known parameters in different functions. This saves around
40KiB of memory on ChromePublic.apk and also creates a more compact
fast path for allocation.
Bug: chromium:1238884, chromium:1056170
Change-Id: Iedd809a8baefcc02f131d2b2c77d341b0abe43bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094007
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76291}
2021-08-13 08:01:26 +00:00
|
|
|
: EnsureGCInfoIndexTrait::EnsureIndex<T>(registered_index);
|
2020-03-24 13:35:51 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace internal
|
|
|
|
} // namespace cppgc
|
|
|
|
|
2020-04-07 21:54:43 +00:00
|
|
|
#endif // INCLUDE_CPPGC_INTERNAL_GC_INFO_H_
|