Responsibilities/Functionality of MemoryRegion

[SanJSp]

Edited by phoenix

Background

We've discussed extracting certain responsibilities for concrete storage access mechanisms (e.g. mmap) from the StorageManager. The idea was to create e.g. a MemoryRegion Object that could encapsulate the concrete mmap and also madvise calls.

Possible benefits of a MemoryRegion would be that we have an easy abstraction for including other memory access methods - e.g. self-managed storage or DRAM-based storage.

Open questions:

1. What would be the responsibility separation between StorageManager and MemoryRegion?
2. Which interface to offer?
3. How can we make information about which Segment is stored in which way (MMAP, DRAM, Self-Managed Memory) accessible?
   • First idea here: Store this per Segment in an enum field (less locking issues), and create MemoryLocationStatistics analogous to current use of statistics. This however is decided to be out of scope of this project currently.

Current Status:

Implement TPC-H (aka basic functionality) with everything in StorageManager to get better overview of what needs to be done. Later refactor into sensible class structure.

[Bouncner]

@mweisgut

[mweisgut]

Implement TPC-H (aka basic functionality) with everything in StorageManager to get better overview of what needs to be done.

This sounds totally valid to me.

1. Let's exclude the possibility of having different memory regions with different characteristics. Instead, let's assume file-mapped memory regions (via mmap), represented by instances of a class FileMappedMemoryRegion. The responsibility of this class could be:

• create a new mapping in the virtual address space (call mmap), for example, in the constructor. Optionally, further mmap hints can be used (and passed to the constructor/function).
• delete the mappings (call munmap), for example, in the deconstructor
• provide the start address of the address range
• provide the size of the memory region

The StorageManager could be responsible for

• owning the FileMappedMemoryRegions
• storing a mapping from table to memory regions or from chunks of tables to memory regions: If certain chunks/tables are to be deleted, we can also destroy the corresponding FileMappedMemoryRegions.

2. No specific requirements. I think this can be derived from (1.):

• access to the start address (either via public member or a getter function)
• access to the region's size (either via public member or a getter function)
  Again, I would exclude the possibility of having different memory regions with different characteristics for designing the interface.
• constructor/deconstructor or explicit create/remove functions (or similar)

3. Since it's out of this project's scope, I think we can still leave this open.