C ++ permanent Object Storage (Persistent Object Storage for C ++)

Source: Internet
Author: User

 

 

C ++ permanent Object Storage (Persistent Object Storage for C ++)

  • Introduction
  • Description object type
  • Allocate and release objects from memory
  • Permanent object protocol
  • Memory Constructor
  • Open storage
  • Post ++ Installation
  • Post ++ class library
  • Use STL class with post ++
  • Replace Standard Sub-Games
  • How to Use post ++
  • S debug post ++ application details
  • More information about post ++
Introduction

Post ++Provides simple and effective storage for application objects.Post ++Based on the memory file image mechanism and page image processing.Post ++Eliminates the overhead for permanent object access.Post ++Supports multiple storage, virtual functions, atomic data update operations, efficient memory allocation, and optional garbage collectors in the specified memory release mode.Post ++It can also work well on objects that inherit from and contain pointers.

 

Description object type

Post ++ storage management requires some information so that the permanent object type supports the Garbage Collector. During loading, the reference is relocated and the function pointer in the virtual table is initialized. Unfortunately, the C ++ language does not provide a mechanism to extract the information from the class during runtime. To avoid using special tools (pre-processors) or "dirty" channels (retrieving class information from debugging information), this information must be specified by the programmer. These are called class registrars and can be simply implemented through some macros provided by post ++.

Post ++ calls the default constructor to initialize objects when reloading objects from memory. To store object handles, programmers must include Macros in class definitions.CLASSINFO(NAME, FIELD_LIST).NAMESpecifies the object name.FIELD_LISTThe reference field of the description class. In the header file classinfo. H, three macros are defined to describe fields:

REF(x)
Describe a field.
REFS(x)
Describe a One-Dimensional Fixed Array field .. (For example, a fixed-length array ).
VREFS(x)
A variable one-dimensional array field. A mutable array can only be the last member of a class. When defining a class, you can specify an array containing only one element. The number of elements in a specific object instance can be specified during creation.

These macro lists must be separated by spaces:REF(a) REF(b) REFS(c). MacroCLASSINFODefines the default constructor (constructor without parameters) and Class descriptor. Class descriptor is a static member of the class namedself_class.fooYou can useFoo: self_class accessThe Default constructors of base classes and members are automatically called by the compiler, so you don't have to worry about calling them explicitly. However, do not forget to use the classinfo macro in the structure definition for the structure members in the serialized class. Then, register the class through the memory management to make it accessible. This process is composed of macros.REGISTER(NAME) Complete. Class names and objects are put together in the memory. When the storage is opened, the class is mirrored between the storage and the application. The class names in the memory and the class names in the program are compared. If a class is not defined by the program or the class in the application and memory has different sizes, the program asserted that it will fail.

The following example describes these rules:

struct branch {     object* obj;    int key;    CLASSINFO(branch, REF(obj));};class foo : public object {   protected:    foo*    next;    foo*    prev;    object* arr[10];    branch  branches[8];    int     x;    int     y;    object* childs[1];  public:    CLASSINFO(foo, REF(next) REF(prev) REFS(arr) VREFS(linked));    foo(int x, int y);};REGISTER(1, foo);main() {     storage my_storage("foo.odb");    if (my_storage.open()) {         my_root_class* root = (my_root_class*)my_storage.get_root_object();if (root == NULL) {     root = new_in(my_storage, my_root)("some parameters for root");}...        int n_childs = ...;size_t varying_size = (n_childs-1)*sizeof(object*);// We should subtract 1 from n_childs, because one element is already// present in fixed part of class.        foo* fp = new (foo:self_class, my_storage, varying_size) foo(x, y);...my_storage.close();    }}

 

Allocate and release objects from memory

Post ++ provides a special memory allocation sub-to manage the storage memory. This sub-allocation uses two different methods: for allocating small objects and large objects. All storage memory is divided into pages (the page size is irrelevant to the page size of the operating system, and 512 bytes are used in the current version of post ++ ). small objects are such objects whose size is smaller than or equal to 256 bytes (page size/2 ). these objects are allocated as fixed block links. Each chain contains blocks of the same size. The size of the allocated object is 8 bytes. For each object, it is recommended that the number of chains containing the block size of 256 should not be greater than 14 (different number of balanced pages ). before each object, post ++ assigns an object header, which contains the Object ID and object size. Considering that the header is exactly 8 bytes, and the total size of the object in C ++ is greater than 0, 8 chunks can be discarded. It is usually very fast to allocate and release small objects: you only need to perform one insert/delete operation from the L1 queue. if the chain is empty and we try to allocate new objects, the new page is allocated to store objects of the current size (the pages are divided into blocks and added to the linked list ). Space required for large objects (larger than 256 bytes) is allocated from the free page queue. The size of a large object is aligned with the page boundary. Post ++ uses the first feed to the random location algorithm to maintain the free page Queue (the idle segments of all pages are arranged by address and followed by a special pointer to the current position of the queue ). For the implementation of storage management, see file storage. cxx.

Whether explicit or implicit memory is used depends on the programmer. Explicit Memory release is faster (especially for small objects), but implicit memory release (garbage collection) is more reliable. Use the flag and garbage collection mechanism in post ++. There is a special object in the storage: root object. The garbage collector first marks that all objects can be accessed by the root object (that is, they can be reached from the root object and traversed through reference ). In this way, all unlabeled objects are released in the first GC phase. The garbage collector can be generated when an object is loaded from a file (if you passdo_garbage_collectionAttributestorage::open()Method ). You can also call storage::do_mark_and_sweep()Method call the garbage collector. However, be sure that the objects not pointed to by program variables cannot be accessed from the root object (these objects will be released by GC ).

The multi-inheritance C ++ class can have a non-zero offset in the object and may also be referenced in the object. This is why we need to use special technologies to access object headers. Post ++ maintains the page allocation bitmap, where each bit corresponds to the page in the memory. If some large objects are allocated on several pages, all the pages occupied by these objects are set to 1 except the first one. All other page BITs exist in the in-place graph. To find the starting address of an object, we first sort the pointer values by page size. Then, post ++ searches for the object start page from the bitmap (This page has a zero position in the bitmap ). Then, the object size information is retrieved from the object header contained at the beginning of the page. If the size is greater than half of the page size, we have found the Object Description: it is at the beginning of the page. On the contrary, we calculate the size of the fixed block used in the page and calculate the pointer offset in the page based on the block size. This head locating scheme is used by the garbage collector, Class objectDefinedoperator deleteAnd the method used to parse the object size and class information from the object header.

In post ++, a special overload is provided.newMethod is used to allocate objects in storage. This method requires the class description of the object, the storage of the object, and the variable part size of the optional object instance as an additional parameter. Macronew_in(STORAGE, CLASS)Create a "syntactic Sugar" for a permanent object ". Permanent objects can be redefinedoperator deleteDelete.

Permanent object protocol

All permanent object classes in post ++ must inherit the classes defined in object. h.object. This class does not contain any variables and provides methods to allocate/release objects and obtain class information and size during runtime. ClassMore "C ++ permanent Object Storage (Persistent Object Storage for C ++)" contents ....

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.