This PR provides a prerequisite for #186, by implementing a solution for a problem originally described here.
To reiterate, the problem is as follows:
For "static" tables (= tables managed my a TablePool), the TablePool manages a single mmapped memory region from which it allocates all tables. To this end, it calculates the required overall size of this region as max_number_of_allowed_tablesmax_allowed_element_count_per_tablesize_of_each_table_entry. Thus, the memory for table with index i in the pool then starts at i max_allowed_element_count_per_tablesize_of_each_table_entry.
However, all of this is based on the (hardcoded) assumption that all table entries across all table types are pointer-sized (i.e., size_of_each_table_entry is sizeof(*mut u8)). But once #186 lands, this is not the case any more.
This PR addresses this as follows:
Change the calculation of the overall size of the mmapped region to max_number_of_allowed_tablesmax_allowed_element_count_per_tablemax_size_of_each_table_entry, where max_size_of_each_table_entry will be sizeof(VMContObj) == 16 once #186 lands. This effectively doubles the amount of address space occupied by the table pool. The calculation of the start address of each table is changed accordingly.
Change the logic for allocating and deallocating tables from the pool so that we take the element size for that particular table type into account when committing and decommitting memory.
Note that the logic implemented this PR is independent from the underlying element sizes. This means that this PR itself does not change the space occupied by the tables, as max_size_of_each_table_entry is currently still the size of a pointer. The necessary changes happen implicitly once #186 lands, which changes the size of ContTableElem which in turns changes the constant MAX_TABLE_ELEM_SIZE.
In summary, these changes mean that in the future the table pool occupies more virtual address space, but the amount of actually committed pages for non-continuation tables does not change.
This PR provides a prerequisite for #186, by implementing a solution for a problem originally described here.
To reiterate, the problem is as follows: For "static" tables (= tables managed my a
TablePool), theTablePoolmanages a single mmapped memory region from which it allocates all tables. To this end, it calculates the required overall size of this region asmax_number_of_allowed_tablesmax_allowed_element_count_per_tablesize_of_each_table_entry. Thus, the memory for table with index i in the pool then starts at imax_allowed_element_count_per_tablesize_of_each_table_entry.However, all of this is based on the (hardcoded) assumption that all table entries across all table types are pointer-sized (i.e.,
size_of_each_table_entryissizeof(*mut u8)). But once #186 lands, this is not the case any more.This PR addresses this as follows:
max_number_of_allowed_tablesmax_allowed_element_count_per_tablemax_size_of_each_table_entry, wheremax_size_of_each_table_entrywill besizeof(VMContObj)== 16 once #186 lands. This effectively doubles the amount of address space occupied by the table pool. The calculation of the start address of each table is changed accordingly.Note that the logic implemented this PR is independent from the underlying element sizes. This means that this PR itself does not change the space occupied by the tables, as
max_size_of_each_table_entryis currently still the size of a pointer. The necessary changes happen implicitly once #186 lands, which changes the size ofContTableElemwhich in turns changes the constantMAX_TABLE_ELEM_SIZE.In summary, these changes mean that in the future the table pool occupies more virtual address space, but the amount of actually committed pages for non-continuation tables does not change.