dart-sdk/runtime/vm/class_table.cc

698 lines
22 KiB
C++
Raw Normal View History

// Copyright (c) 2012, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
#include "vm/class_table.h"
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
#include <limits>
#include <memory>
#include "platform/atomic.h"
#include "vm/flags.h"
#include "vm/growable_array.h"
#include "vm/heap/heap.h"
#include "vm/object.h"
#include "vm/object_graph.h"
#include "vm/raw_object.h"
#include "vm/visitor.h"
namespace dart {
DEFINE_FLAG(bool, print_class_table, false, "Print initial class table.");
SharedClassTable::SharedClassTable()
: top_(kNumPredefinedCids),
capacity_(0),
old_tables_(new MallocGrowableArray<void*>()) {
if (Dart::vm_isolate() == NULL) {
ASSERT(kInitialCapacity >= kNumPredefinedCids);
capacity_ = kInitialCapacity;
// Note that [calloc] will zero-initialize the memory.
table_.store(reinterpret_cast<RelaxedAtomic<intptr_t>*>(
calloc(capacity_, sizeof(RelaxedAtomic<intptr_t>))));
} else {
// Duplicate the class table from the VM isolate.
auto vm_shared_class_table = Dart::vm_isolate_group()->shared_class_table();
capacity_ = vm_shared_class_table->capacity_;
// Note that [calloc] will zero-initialize the memory.
RelaxedAtomic<intptr_t>* table = reinterpret_cast<RelaxedAtomic<intptr_t>*>(
calloc(capacity_, sizeof(RelaxedAtomic<intptr_t>)));
// The following cids don't have a corresponding class object in Dart code.
// We therefore need to initialize them eagerly.
COMPILE_ASSERT(kFirstInternalOnlyCid == kObjectCid + 1);
for (intptr_t i = kObjectCid; i <= kLastInternalOnlyCid; i++) {
table[i] = vm_shared_class_table->SizeAt(i);
}
table[kTypeArgumentsCid] = vm_shared_class_table->SizeAt(kTypeArgumentsCid);
table[kFreeListElement] = vm_shared_class_table->SizeAt(kFreeListElement);
table[kForwardingCorpse] = vm_shared_class_table->SizeAt(kForwardingCorpse);
table[kDynamicCid] = vm_shared_class_table->SizeAt(kDynamicCid);
table[kVoidCid] = vm_shared_class_table->SizeAt(kVoidCid);
table_.store(table);
}
#if defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
// Note that [calloc] will zero-initialize the memory.
unboxed_fields_map_ = static_cast<UnboxedFieldBitmap*>(
calloc(capacity_, sizeof(UnboxedFieldBitmap)));
#endif // defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
#ifndef PRODUCT
// Note that [calloc] will zero-initialize the memory.
trace_allocation_table_.store(
static_cast<uint8_t*>(calloc(capacity_, sizeof(uint8_t))));
#endif // !PRODUCT
}
SharedClassTable::~SharedClassTable() {
if (old_tables_ != NULL) {
FreeOldTables();
delete old_tables_;
}
free(table_.load());
free(unboxed_fields_map_);
NOT_IN_PRODUCT(free(trace_allocation_table_.load()));
}
void ClassTable::set_table(ClassPtr* table) {
// We don't have to stop mutators, since the old table is the prefix of the
// new table. But we should ensure that all writes to the current table are
// visible once the new table is visible.
table_.store(table);
IsolateGroup::Current()->set_cached_class_table_table(table);
}
ClassTable::ClassTable(SharedClassTable* shared_class_table)
: top_(kNumPredefinedCids),
capacity_(0),
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
tlc_top_(0),
tlc_capacity_(0),
table_(nullptr),
tlc_table_(nullptr),
old_class_tables_(new MallocGrowableArray<ClassPtr*>()),
shared_class_table_(shared_class_table) {
if (Dart::vm_isolate() == NULL) {
ASSERT(kInitialCapacity >= kNumPredefinedCids);
capacity_ = kInitialCapacity;
// Note that [calloc] will zero-initialize the memory.
// Don't use set_table because caller is supposed to set up isolates
// cached copy when constructing ClassTable. Isolate::Current might not
// be available at this point yet.
table_.store(static_cast<ClassPtr*>(calloc(capacity_, sizeof(ClassPtr))));
} else {
// Duplicate the class table from the VM isolate.
ClassTable* vm_class_table = Dart::vm_isolate_group()->class_table();
capacity_ = vm_class_table->capacity_;
// Note that [calloc] will zero-initialize the memory.
ClassPtr* table =
static_cast<ClassPtr*>(calloc(capacity_, sizeof(ClassPtr)));
// The following cids don't have a corresponding class object in Dart code.
// We therefore need to initialize them eagerly.
COMPILE_ASSERT(kFirstInternalOnlyCid == kObjectCid + 1);
for (intptr_t i = kObjectCid; i <= kLastInternalOnlyCid; i++) {
table[i] = vm_class_table->At(i);
}
table[kTypeArgumentsCid] = vm_class_table->At(kTypeArgumentsCid);
table[kFreeListElement] = vm_class_table->At(kFreeListElement);
table[kForwardingCorpse] = vm_class_table->At(kForwardingCorpse);
table[kDynamicCid] = vm_class_table->At(kDynamicCid);
table[kVoidCid] = vm_class_table->At(kVoidCid);
// Don't use set_table because caller is supposed to set up isolates
// cached copy when constructing ClassTable. Isolate::Current might not
// be available at this point yet.
table_.store(table);
}
}
ClassTable::~ClassTable() {
[vm/concurrency] Split up IsolateReloadContext into IsolateReloadContext/IsolateGroupReloadContext Similar to the split of ClassTable into ClassTable/SharedClassTable, this CL splits up the IsolateReloadContext into: * IsolateGroupReloadContext: Consists of reload-related information across all isolates. The [Reload()] method is split up in phases that are performed on all isolates before the next phase is started. => This allows each isolate to add reasons for rolling back, if no reasons are found the reload will be accepted atomically. * IsolateReloadContext: Constists of reload-related information for a particular isolate (e.g. mappings of old to new classes) The assumption is that all isolates have the same source (and therefore the same libraries). For certain things, e.g. discovering which libraries changed, it is necessary to examine the object store. We use the first isolate in a group (but could use any of them) to do so, since the isolate group does not have this information atm. This is a preparation CL for supporting hot-reloading multiple isolates within one isolate group. Though the support in this CL stays at having only a single isolate in a group. => This CL turns off FLAG_enable_isolate_groups in JIT mode. Issue https://github.com/dart-lang/sdk/issues/36097 Change-Id: I7f4d536d4f5ab4a2a73fb0c7618ba967c9b77234 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123254 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com> Reviewed-by: Alexander Aprelev <aam@google.com>
2019-11-15 14:08:45 +00:00
if (old_class_tables_ != nullptr) {
FreeOldTables();
delete old_class_tables_;
}
free(table_.load());
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
free(tlc_table_.load());
}
void ClassTable::AddOldTable(ClassPtr* old_class_table) {
ASSERT(Thread::Current()->IsMutatorThread());
[vm/concurrency] Split up IsolateReloadContext into IsolateReloadContext/IsolateGroupReloadContext Similar to the split of ClassTable into ClassTable/SharedClassTable, this CL splits up the IsolateReloadContext into: * IsolateGroupReloadContext: Consists of reload-related information across all isolates. The [Reload()] method is split up in phases that are performed on all isolates before the next phase is started. => This allows each isolate to add reasons for rolling back, if no reasons are found the reload will be accepted atomically. * IsolateReloadContext: Constists of reload-related information for a particular isolate (e.g. mappings of old to new classes) The assumption is that all isolates have the same source (and therefore the same libraries). For certain things, e.g. discovering which libraries changed, it is necessary to examine the object store. We use the first isolate in a group (but could use any of them) to do so, since the isolate group does not have this information atm. This is a preparation CL for supporting hot-reloading multiple isolates within one isolate group. Though the support in this CL stays at having only a single isolate in a group. => This CL turns off FLAG_enable_isolate_groups in JIT mode. Issue https://github.com/dart-lang/sdk/issues/36097 Change-Id: I7f4d536d4f5ab4a2a73fb0c7618ba967c9b77234 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123254 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com> Reviewed-by: Alexander Aprelev <aam@google.com>
2019-11-15 14:08:45 +00:00
old_class_tables_->Add(old_class_table);
}
void ClassTable::FreeOldTables() {
while (old_class_tables_->length() > 0) {
free(old_class_tables_->RemoveLast());
}
}
[vm/concurrency] Split up IsolateReloadContext into IsolateReloadContext/IsolateGroupReloadContext Similar to the split of ClassTable into ClassTable/SharedClassTable, this CL splits up the IsolateReloadContext into: * IsolateGroupReloadContext: Consists of reload-related information across all isolates. The [Reload()] method is split up in phases that are performed on all isolates before the next phase is started. => This allows each isolate to add reasons for rolling back, if no reasons are found the reload will be accepted atomically. * IsolateReloadContext: Constists of reload-related information for a particular isolate (e.g. mappings of old to new classes) The assumption is that all isolates have the same source (and therefore the same libraries). For certain things, e.g. discovering which libraries changed, it is necessary to examine the object store. We use the first isolate in a group (but could use any of them) to do so, since the isolate group does not have this information atm. This is a preparation CL for supporting hot-reloading multiple isolates within one isolate group. Though the support in this CL stays at having only a single isolate in a group. => This CL turns off FLAG_enable_isolate_groups in JIT mode. Issue https://github.com/dart-lang/sdk/issues/36097 Change-Id: I7f4d536d4f5ab4a2a73fb0c7618ba967c9b77234 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123254 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com> Reviewed-by: Alexander Aprelev <aam@google.com>
2019-11-15 14:08:45 +00:00
void SharedClassTable::AddOldTable(intptr_t* old_table) {
ASSERT(Thread::Current()->IsMutatorThread());
old_tables_->Add(old_table);
}
void SharedClassTable::FreeOldTables() {
while (old_tables_->length() > 0) {
free(old_tables_->RemoveLast());
}
}
void ClassTable::Register(const Class& cls) {
ASSERT(Thread::Current()->IsMutatorThread());
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
const classid_t cid = cls.id();
ASSERT(!IsTopLevelCid(cid));
// During the transition period we would like [SharedClassTable] to operate in
// parallel to [ClassTable].
const intptr_t instance_size =
cls.is_abstract() ? 0 : Class::host_instance_size(cls.ptr());
const intptr_t expected_cid =
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
shared_class_table_->Register(cid, instance_size);
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
if (cid != kIllegalCid) {
ASSERT(cid > 0 && cid < kNumPredefinedCids && cid < top_);
ASSERT(table_.load()[cid] == nullptr);
table_.load()[cid] = cls.ptr();
} else {
if (top_ == capacity_) {
const intptr_t new_capacity = capacity_ + kCapacityIncrement;
Grow(new_capacity);
}
ASSERT(top_ < capacity_);
cls.set_id(top_);
table_.load()[top_] = cls.ptr();
top_++; // Increment next index.
}
ASSERT(expected_cid == cls.id());
}
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
void ClassTable::RegisterTopLevel(const Class& cls) {
if (top_ >= std::numeric_limits<classid_t>::max()) {
FATAL1("Fatal error in ClassTable::RegisterTopLevel: invalid index %" Pd
"\n",
top_);
}
ASSERT(Thread::Current()->IsMutatorThread());
const intptr_t index = cls.id();
ASSERT(index == kIllegalCid);
if (tlc_top_ == tlc_capacity_) {
const intptr_t new_capacity = tlc_capacity_ + kCapacityIncrement;
GrowTopLevel(new_capacity);
}
ASSERT(tlc_top_ < tlc_capacity_);
cls.set_id(ClassTable::CidFromTopLevelIndex(tlc_top_));
tlc_table_.load()[tlc_top_] = cls.ptr();
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
tlc_top_++; // Increment next index.
}
intptr_t SharedClassTable::Register(intptr_t index, intptr_t size) {
if (!Class::is_valid_id(top_)) {
FATAL1("Fatal error in SharedClassTable::Register: invalid index %" Pd "\n",
top_);
}
ASSERT(Thread::Current()->IsMutatorThread());
if (index != kIllegalCid) {
// We are registring the size of a predefined class.
ASSERT(index > 0 && index < kNumPredefinedCids);
SetSizeAt(index, size);
return index;
} else {
ASSERT(size == 0);
if (top_ == capacity_) {
const intptr_t new_capacity = capacity_ + kCapacityIncrement;
Grow(new_capacity);
}
ASSERT(top_ < capacity_);
table_.load()[top_] = size;
return top_++; // Increment next index.
}
}
void ClassTable::AllocateIndex(intptr_t index) {
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
if (IsTopLevelCid(index)) {
AllocateTopLevelIndex(index);
return;
}
// This is called by a snapshot reader.
shared_class_table_->AllocateIndex(index);
ASSERT(Class::is_valid_id(index));
if (index >= capacity_) {
const intptr_t new_capacity = index + kCapacityIncrement;
Grow(new_capacity);
}
ASSERT(table_.load()[index] == nullptr);
if (index >= top_) {
top_ = index + 1;
}
ASSERT(top_ == shared_class_table_->top_);
ASSERT(capacity_ == shared_class_table_->capacity_);
}
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
void ClassTable::AllocateTopLevelIndex(intptr_t cid) {
ASSERT(IsTopLevelCid(cid));
const intptr_t tlc_index = IndexFromTopLevelCid(cid);
if (tlc_index >= tlc_capacity_) {
const intptr_t new_capacity = tlc_index + kCapacityIncrement;
GrowTopLevel(new_capacity);
}
ASSERT(tlc_table_.load()[tlc_index] == nullptr);
if (tlc_index >= tlc_top_) {
tlc_top_ = tlc_index + 1;
}
}
void ClassTable::Grow(intptr_t new_capacity) {
ASSERT(new_capacity > capacity_);
auto old_table = table_.load();
auto new_table = static_cast<ClassPtr*>(
malloc(new_capacity * sizeof(ClassPtr))); // NOLINT
intptr_t i;
for (i = 0; i < capacity_; i++) {
// Don't use memmove, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_table[i] = old_table[i];
}
for (; i < new_capacity; i++) {
// Don't use memset, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_table[i] = 0;
}
old_class_tables_->Add(old_table);
set_table(new_table);
capacity_ = new_capacity;
}
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
void ClassTable::GrowTopLevel(intptr_t new_capacity) {
ASSERT(new_capacity > tlc_capacity_);
auto old_table = tlc_table_.load();
auto new_table = static_cast<ClassPtr*>(
malloc(new_capacity * sizeof(ClassPtr))); // NOLINT
intptr_t i;
for (i = 0; i < tlc_capacity_; i++) {
// Don't use memmove, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_table[i] = old_table[i];
}
for (; i < new_capacity; i++) {
// Don't use memset, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_table[i] = 0;
}
old_class_tables_->Add(old_table);
tlc_table_.store(new_table);
tlc_capacity_ = new_capacity;
}
void SharedClassTable::AllocateIndex(intptr_t index) {
// This is called by a snapshot reader.
ASSERT(Class::is_valid_id(index));
if (index >= capacity_) {
const intptr_t new_capacity = index + kCapacityIncrement;
Grow(new_capacity);
}
ASSERT(table_.load()[index] == 0);
if (index >= top_) {
top_ = index + 1;
}
}
void SharedClassTable::Grow(intptr_t new_capacity) {
ASSERT(new_capacity >= capacity_);
RelaxedAtomic<intptr_t>* old_table = table_.load();
RelaxedAtomic<intptr_t>* new_table =
reinterpret_cast<RelaxedAtomic<intptr_t>*>(
malloc(new_capacity * sizeof(RelaxedAtomic<intptr_t>))); // NOLINT
intptr_t i;
for (i = 0; i < capacity_; i++) {
// Don't use memmove, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_table[i] = old_table[i];
}
for (; i < new_capacity; i++) {
// Don't use memset, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_table[i] = 0;
}
#if !defined(PRODUCT)
auto old_trace_table = trace_allocation_table_.load();
auto new_trace_table =
static_cast<uint8_t*>(malloc(new_capacity * sizeof(uint8_t))); // NOLINT
for (i = 0; i < capacity_; i++) {
// Don't use memmove, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_trace_table[i] = old_trace_table[i];
}
for (; i < new_capacity; i++) {
// Don't use memset, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_trace_table[i] = 0;
}
#endif
old_tables_->Add(old_table);
table_.store(new_table);
NOT_IN_PRODUCT(old_tables_->Add(old_trace_table));
NOT_IN_PRODUCT(trace_allocation_table_.store(new_trace_table));
#if defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
auto old_unboxed_fields_map = unboxed_fields_map_;
auto new_unboxed_fields_map = static_cast<UnboxedFieldBitmap*>(
malloc(new_capacity * sizeof(UnboxedFieldBitmap)));
for (i = 0; i < capacity_; i++) {
// Don't use memmove, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_unboxed_fields_map[i] = old_unboxed_fields_map[i];
}
for (; i < new_capacity; i++) {
// Don't use memset, which changes this from a relaxed atomic operation
// to a non-atomic operation.
new_unboxed_fields_map[i] = UnboxedFieldBitmap(0);
}
old_tables_->Add(old_unboxed_fields_map);
unboxed_fields_map_ = new_unboxed_fields_map;
#endif // defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
capacity_ = new_capacity;
}
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
void ClassTable::Unregister(intptr_t cid) {
ASSERT(!IsTopLevelCid(cid));
shared_class_table_->Unregister(cid);
table_.load()[cid] = nullptr;
}
void ClassTable::UnregisterTopLevel(intptr_t cid) {
ASSERT(IsTopLevelCid(cid));
const intptr_t tlc_index = IndexFromTopLevelCid(cid);
tlc_table_.load()[tlc_index] = nullptr;
}
void SharedClassTable::Unregister(intptr_t index) {
table_.load()[index] = 0;
#if defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
unboxed_fields_map_[index].Reset();
#endif // defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
}
void ClassTable::Remap(intptr_t* old_to_new_cid) {
[vm/concurrency] Distinguish "gc safepoint operations" from "deopt safepoint operations" This extends the existing safepoint operation mechanism by allowing to perform two different operations: * "gc safepoint operations": All mutators are stopped at places where it's safe to GC. It therefore requires stackmaps to be available for all optimized mutator frames. * "deopt safepoint operations": All mutators are stopped at places where it's safe to GC, but also safe to lazy-deopt mutator frames. It therefore requires deopt-id/deopt-info to be available for all optimized mutator frames. Mutators can be asked to block for any of those two safepoint operations. If a mutator is at a place where its safe to GC it will respond to "gc safepoint operations" requests, if a mutator is additionally at a place where it's also safe to lazy-deopt it will respond to "deopt safepoint operation" requests. Depending on how the runtime was entered (which is tracked via the [Thread::runtime_call_deopt_ability_] value) - the mutator might participate in both or only in gc safepoint operations. During the start of a "deopt safepoint operation", the safepoint handler will request all threads to stop at a "deopt safepoint". Some threads might first want to initiate their own "gc safepoint operation" (e.g. due to allocation failure) before they reach a "deopt safepoint". We do allow this by letting the safepoint handler own a "deopt safepoint operation" but still participate in other thread's "gc safepoint operation" requests until all mutators are checked into places where it's safe to lazy-deopt at which point the "deopt safepoint operation" also owns a "gc safepoint operation". In order to facilitate this, the Thread's safepoint_state will be extended to consist of the following bits: * AtSafepoint * SafepointRequested * AtDeoptSafepoint * DeoptSafepointRequested * BlockedForSafepoint Issue https://github.com/dart-lang/sdk/issues/45213 TEST=vm/cc/SafepointOperation_* Change-Id: Icdc2827718f6780818f99b829a5e806d6bb5b130 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196927 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2021-05-10 09:13:09 +00:00
ASSERT(Thread::Current()->IsAtSafepoint(SafepointLevel::kGCAndDeopt));
const intptr_t num_cids = NumCids();
std::unique_ptr<ClassPtr[]> cls_by_old_cid(new ClassPtr[num_cids]);
auto* table = table_.load();
memmove(cls_by_old_cid.get(), table, sizeof(ClassPtr) * num_cids);
for (intptr_t i = 0; i < num_cids; i++) {
table[old_to_new_cid[i]] = cls_by_old_cid[i];
}
}
void SharedClassTable::Remap(intptr_t* old_to_new_cid) {
[vm/concurrency] Distinguish "gc safepoint operations" from "deopt safepoint operations" This extends the existing safepoint operation mechanism by allowing to perform two different operations: * "gc safepoint operations": All mutators are stopped at places where it's safe to GC. It therefore requires stackmaps to be available for all optimized mutator frames. * "deopt safepoint operations": All mutators are stopped at places where it's safe to GC, but also safe to lazy-deopt mutator frames. It therefore requires deopt-id/deopt-info to be available for all optimized mutator frames. Mutators can be asked to block for any of those two safepoint operations. If a mutator is at a place where its safe to GC it will respond to "gc safepoint operations" requests, if a mutator is additionally at a place where it's also safe to lazy-deopt it will respond to "deopt safepoint operation" requests. Depending on how the runtime was entered (which is tracked via the [Thread::runtime_call_deopt_ability_] value) - the mutator might participate in both or only in gc safepoint operations. During the start of a "deopt safepoint operation", the safepoint handler will request all threads to stop at a "deopt safepoint". Some threads might first want to initiate their own "gc safepoint operation" (e.g. due to allocation failure) before they reach a "deopt safepoint". We do allow this by letting the safepoint handler own a "deopt safepoint operation" but still participate in other thread's "gc safepoint operation" requests until all mutators are checked into places where it's safe to lazy-deopt at which point the "deopt safepoint operation" also owns a "gc safepoint operation". In order to facilitate this, the Thread's safepoint_state will be extended to consist of the following bits: * AtSafepoint * SafepointRequested * AtDeoptSafepoint * DeoptSafepointRequested * BlockedForSafepoint Issue https://github.com/dart-lang/sdk/issues/45213 TEST=vm/cc/SafepointOperation_* Change-Id: Icdc2827718f6780818f99b829a5e806d6bb5b130 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196927 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2021-05-10 09:13:09 +00:00
ASSERT(Thread::Current()->IsAtSafepoint(SafepointLevel::kGCAndDeopt));
const intptr_t num_cids = NumCids();
std::unique_ptr<intptr_t[]> size_by_old_cid(new intptr_t[num_cids]);
auto* table = table_.load();
for (intptr_t i = 0; i < num_cids; i++) {
size_by_old_cid[i] = table[i];
}
for (intptr_t i = 0; i < num_cids; i++) {
table[old_to_new_cid[i]] = size_by_old_cid[i];
}
#if defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
std::unique_ptr<UnboxedFieldBitmap[]> unboxed_fields_by_old_cid(
new UnboxedFieldBitmap[num_cids]);
for (intptr_t i = 0; i < num_cids; i++) {
unboxed_fields_by_old_cid[i] = unboxed_fields_map_[i];
}
for (intptr_t i = 0; i < num_cids; i++) {
unboxed_fields_map_[old_to_new_cid[i]] = unboxed_fields_by_old_cid[i];
}
#endif // defined(SUPPORT_UNBOXED_INSTANCE_FIELDS)
}
void ClassTable::VisitObjectPointers(ObjectPointerVisitor* visitor) {
ASSERT(visitor != NULL);
visitor->set_gc_root_type("class table");
if (top_ != 0) {
auto* table = table_.load();
ObjectPtr* from = reinterpret_cast<ObjectPtr*>(&table[0]);
ObjectPtr* to = reinterpret_cast<ObjectPtr*>(&table[top_ - 1]);
visitor->VisitPointers(from, to);
}
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
if (tlc_top_ != 0) {
auto* tlc_table = tlc_table_.load();
ObjectPtr* from = reinterpret_cast<ObjectPtr*>(&tlc_table[0]);
ObjectPtr* to = reinterpret_cast<ObjectPtr*>(&tlc_table[tlc_top_ - 1]);
visitor->VisitPointers(from, to);
}
visitor->clear_gc_root_type();
}
void ClassTable::CopySizesFromClassObjects() {
ASSERT(kIllegalCid == 0);
for (intptr_t i = 1; i < top_; i++) {
SetAt(i, At(i));
}
}
void ClassTable::Validate() {
Class& cls = Class::Handle();
for (intptr_t cid = kNumPredefinedCids; cid < top_; cid++) {
// Some of the class table entries maybe NULL as we create some
// top level classes but do not add them to the list of anonymous
// classes in a library if there are no top level fields or functions.
// Since there are no references to these top level classes they are
// not written into a full snapshot and will not be recreated when
// we read back the full snapshot. These class slots end up with NULL
// entries.
if (HasValidClassAt(cid)) {
cls = At(cid);
ASSERT(cls.IsClass());
#if defined(DART_PRECOMPILER)
// Precompiler can drop classes and set their id() to kIllegalCid.
// It still leaves them in the class table so dropped program
// structure could still be accessed while writing debug info.
ASSERT((cls.id() == cid) || (cls.id() == kIllegalCid));
#else
ASSERT(cls.id() == cid);
#endif // defined(DART_PRECOMPILER)
}
}
}
void ClassTable::Print() {
Class& cls = Class::Handle();
String& name = String::Handle();
for (intptr_t i = 1; i < top_; i++) {
if (!HasValidClassAt(i)) {
continue;
}
cls = At(i);
if (cls.ptr() != nullptr) {
name = cls.Name();
OS::PrintErr("%" Pd ": %s\n", i, name.ToCString());
}
}
}
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
void ClassTable::SetAt(intptr_t cid, ClassPtr raw_cls) {
if (IsTopLevelCid(cid)) {
tlc_table_.load()[IndexFromTopLevelCid(cid)] = raw_cls;
return;
}
// This is called by snapshot reader and class finalizer.
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
ASSERT(cid < capacity_);
UpdateClassSize(cid, raw_cls);
table_.load()[cid] = raw_cls;
}
void ClassTable::UpdateClassSize(intptr_t cid, ClassPtr raw_cls) {
ASSERT(IsolateGroup::Current()->program_lock()->IsCurrentThreadWriter());
ASSERT(!IsTopLevelCid(cid)); // "top-level" classes don't get instantiated
ASSERT(cid < capacity_);
const intptr_t size =
raw_cls == nullptr ? 0 : Class::host_instance_size(raw_cls);
[vm] Assign top-level classes cids outside 16-bit range Right now we assign class ids to top-level classes, abstract classes as well as concrete classes. All of them have allocated from a 16-bit pool of ids. The VM FATAL()s once it hits that limit. Customers who run very large programs (significant amount of generated code) on the Dart VM have started to hit this 16-bit class limit. Concrete classes can have instances in the heap. Our current heap layout only allows 16-bit class ids to be encoded in the header word. To avoid increasing the size of heap objects or shrinking the size of the identity hash code to 16-bit we keep class ids in object headers to be 16-bit. Abstract classes cannot have instances in the heap. Though their class ids are encoded in type objects. Furthermore we sort classes in AOT/AppJIT mode to perform fast class-id range checks. To avoid impacting this optimization we treat abstract classes the same way as concrete classes. Top-level classes cannot have instances in the heap. Their class ids are only used in the runtime code, for example for hot-reload as well as part of the service protocol. => We can allocate class ids outside the 16-bit range for top-level classes, thereby freeing a significant amount of space in the 16-bit range. This CL does exactly that: We change classid_t to be int32_t. The ClassLayout::id_ can now be assigned ids outside 16-bit range for top-level classes. To do this we keep dart classes and top level classes as separate arrays in the ClassTable. Issue https://github.com/dart-lang/sdk/issues/42533 See also b/160229360 Change-Id: I6710a644e7b0ab2d4f4c792bef8e1f91cb117421 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153607 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
2020-07-09 18:33:32 +00:00
shared_class_table_->SetSizeAt(cid, size);
}
#if defined(DART_PRECOMPILER)
void ClassTable::PrintObjectLayout(const char* filename) {
Class& cls = Class::Handle();
Array& fields = Array::Handle();
Field& field = Field::Handle();
JSONWriter js;
js.OpenArray();
for (intptr_t i = ClassId::kObjectCid; i < top_; i++) {
if (!HasValidClassAt(i)) {
continue;
}
cls = At(i);
ASSERT(!cls.IsNull());
ASSERT(cls.id() != kIllegalCid);
ASSERT(cls.is_finalized()); // Precompiler already finalized all classes.
ASSERT(!cls.IsTopLevel());
js.OpenObject();
js.PrintProperty("class", cls.UserVisibleNameCString());
js.PrintProperty("size", cls.target_instance_size());
js.OpenArray("fields");
fields = cls.fields();
if (!fields.IsNull()) {
for (intptr_t i = 0, n = fields.Length(); i < n; ++i) {
field ^= fields.At(i);
js.OpenObject();
js.PrintProperty("field", field.UserVisibleNameCString());
if (field.is_static()) {
js.PrintPropertyBool("static", true);
} else {
js.PrintProperty("offset", field.TargetOffset());
}
js.CloseObject();
}
}
js.CloseArray();
js.CloseObject();
}
js.CloseArray();
auto file_open = Dart::file_open_callback();
auto file_write = Dart::file_write_callback();
auto file_close = Dart::file_close_callback();
if ((file_open == nullptr) || (file_write == nullptr) ||
(file_close == nullptr)) {
OS::PrintErr("warning: Could not access file callbacks.");
return;
}
void* file = file_open(filename, /*write=*/true);
if (file == nullptr) {
OS::PrintErr("warning: Failed to write object layout: %s\n", filename);
return;
}
char* output = nullptr;
intptr_t output_length = 0;
js.Steal(&output, &output_length);
file_write(output, output_length, file);
free(output);
file_close(file);
}
#endif // defined(DART_PRECOMPILER)
#ifndef PRODUCT
void ClassTable::PrintToJSONObject(JSONObject* object) {
Class& cls = Class::Handle();
object->AddProperty("type", "ClassList");
{
JSONArray members(object, "classes");
for (intptr_t i = ClassId::kObjectCid; i < top_; i++) {
if (HasValidClassAt(i)) {
cls = At(i);
members.AddValue(cls);
}
}
}
}
intptr_t SharedClassTable::ClassOffsetFor(intptr_t cid) {
return cid * sizeof(uint8_t); // NOLINT
}
void ClassTable::AllocationProfilePrintJSON(JSONStream* stream, bool internal) {
Isolate* isolate = Isolate::Current();
ASSERT(isolate != NULL);
auto isolate_group = isolate->group();
Heap* heap = isolate_group->heap();
ASSERT(heap != NULL);
JSONObject obj(stream);
obj.AddProperty("type", "AllocationProfile");
if (isolate_group->last_allocationprofile_accumulator_reset_timestamp() !=
0) {
obj.AddPropertyF(
"dateLastAccumulatorReset", "%" Pd64 "",
isolate_group->last_allocationprofile_accumulator_reset_timestamp());
}
if (isolate_group->last_allocationprofile_gc_timestamp() != 0) {
obj.AddPropertyF("dateLastServiceGC", "%" Pd64 "",
isolate_group->last_allocationprofile_gc_timestamp());
}
if (internal) {
JSONObject heaps(&obj, "_heaps");
{ heap->PrintToJSONObject(Heap::kNew, &heaps); }
{ heap->PrintToJSONObject(Heap::kOld, &heaps); }
}
{
JSONObject memory(&obj, "memoryUsage");
{ heap->PrintMemoryUsageJSON(&memory); }
}
Thread* thread = Thread::Current();
CountObjectsVisitor visitor(thread, NumCids());
{
HeapIterationScope iter(thread);
iter.IterateObjects(&visitor);
isolate->group()->VisitWeakPersistentHandles(&visitor);
}
{
JSONArray arr(&obj, "members");
Class& cls = Class::Handle();
for (intptr_t i = 3; i < top_; i++) {
if (!HasValidClassAt(i)) continue;
cls = At(i);
if (cls.IsNull()) continue;
JSONObject obj(&arr);
obj.AddProperty("type", "ClassHeapStats");
obj.AddProperty("class", cls);
intptr_t count = visitor.new_count_[i] + visitor.old_count_[i];
intptr_t size = visitor.new_size_[i] + visitor.old_size_[i];
obj.AddProperty64("instancesAccumulated", count);
obj.AddProperty64("accumulatedSize", size);
obj.AddProperty64("instancesCurrent", count);
obj.AddProperty64("bytesCurrent", size);
if (internal) {
{
JSONArray new_stats(&obj, "_new");
new_stats.AddValue(visitor.new_count_[i]);
new_stats.AddValue(visitor.new_size_[i]);
new_stats.AddValue(visitor.new_external_size_[i]);
}
{
JSONArray old_stats(&obj, "_old");
old_stats.AddValue(visitor.old_count_[i]);
old_stats.AddValue(visitor.old_size_[i]);
old_stats.AddValue(visitor.old_external_size_[i]);
}
}
}
}
}
#endif // !PRODUCT
} // namespace dart