87
• Lines 61-64: If pmemobj_create() fails, we will exit the program and
return an error.
• Line 66: Using the pop acquired from line 58, we use the pmemobj_
root() function to locate the root object.
• Line 69: We use the pmemobj_direct() function to get a pointer to the
root object we found in line 66.
• Line 71: We set the string/buffer to “Hello PMEM World.”
• Lines 73-78. After determining the length of the buffer, we first write
the len and then the buf member of our root object to persistent
memory.
• Line 80: We close the persistent memory pool by unmapping it.
Pool Object Pointer (POP) and the Root Object
Due to the address space layout randomization (ASLR) feature used by most operating
systems, the location of the pool – once memory mapped into the application address
space – can differ between executions and system reboots. Without a way to access
the data within the pool, you would find it challenging to locate the data within a pool.
PMDK-based pools have a small amount of metadata to solve this problem.
Every pmemobj (obj) type pool has a root object. This root object is necessary
because it is used as an entry point from which to find all the other objects created in a
pool, that is, user data. An application will locate the root object using a special object
called pool object pointer (POP). The POP object resides in volatile memory and is
created with every program invocation. It keeps track of metadata related to the pool,
such as the offset to the root object inside the pool. Figure 7-1 depicts the POP and
memory pool layout.
Chapter 7 libpmemobj: a Native traNsaCtioNal objeCt store
• Lines 61-64: If pmemobj_create() fails, we will exit the program and
return an error.
• Line 66: Using the pop acquired from line 58, we use the pmemobj_
root() function to locate the root object.
• Line 69: We use the pmemobj_direct() function to get a pointer to the
root object we found in line 66.
• Line 71: We set the string/buffer to “Hello PMEM World.”
• Lines 73-78. After determining the length of the buffer, we first write
the len and then the buf member of our root object to persistent
memory.
• Line 80: We close the persistent memory pool by unmapping it.
Pool Object Pointer (POP) and the Root Object
Due to the address space layout randomization (ASLR) feature used by most operating
systems, the location of the pool – once memory mapped into the application address
space – can differ between executions and system reboots. Without a way to access
the data within the pool, you would find it challenging to locate the data within a pool.
PMDK-based pools have a small amount of metadata to solve this problem.
Every pmemobj (obj) type pool has a root object. This root object is necessary
because it is used as an entry point from which to find all the other objects created in a
pool, that is, user data. An application will locate the root object using a special object
called pool object pointer (POP). The POP object resides in volatile memory and is
created with every program invocation. It keeps track of metadata related to the pool,
such as the offset to the root object inside the pool. Figure 7-1 depicts the POP and
memory pool layout.
Chapter 7 libpmemobj: a Native traNsaCtioNal objeCt store