Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a heap memory allocator #110

Open
Dawoodoz opened this issue Dec 19, 2024 · 1 comment
Open

Create a heap memory allocator #110

Dawoodoz opened this issue Dec 19, 2024 · 1 comment
Assignees
Labels
Performance portability Related to working on a certain operating system Usability

Comments

@Dawoodoz
Copy link
Owner

Dawoodoz commented Dec 19, 2024

The old memory allocator was removed, because some compilers don't like overriding the new and delete operators. The new memory allocator should use the same safety features as the virtual stack allocator, so that accessing the memory using a SafePointer in debug mode will check that it is the same allocation by keeping a pointer to the allocation header. When defining a custom interface for allocating memory, one can also add settings for additional memory alignment, clearing the data, thread ownership, ranges of accepted element counts, if the memory should be possible to recycle, and which memory pool to allocate within for cache locality. An allocation header extended for reference counted allocations can contain a reference counter, but then each reference counted object will be allocated with a combined alignment including the header's padded size, so that the header can be found at a constant memory offset from the object's address.

The memory disowned from canvas images in the X11 backend should send a function pointer to X11 for freeing the data using the same allocation system as the image was allocated with.

@Dawoodoz Dawoodoz added portability Related to working on a certain operating system Performance Usability labels Dec 19, 2024
@Dawoodoz Dawoodoz self-assigned this Dec 19, 2024
@Dawoodoz
Copy link
Owner Author

Dawoodoz commented Dec 20, 2024

The biggest problem is that there is no way to implement thread safe memory allocation in standard C++, because there is no way to ask the system for the largest possible size of cache lines through the standard library. If one core reads a cache line to modify one side of it and another core reads it before the change has been written, there will be potential memory corruption. Even if you ask the current core for the size of cache lines using a system specific API, the task can be moved to a different core with larger cache lines. Assuming cache lines of 64 bytes would not be future proof.

The maximum size of cache lines might have to be provided as an argument from the build system or requested by iterating over all cores on the system. Then it should be applied to the alignment of pixel data and affect stride for fully thread-safe multi-threaded rendering.

A header dedicated to hardware settings can be created, so that all hard-coded assumptions about the target system are easy to change in one location.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Performance portability Related to working on a certain operating system Usability
Projects
None yet
Development

No branches or pull requests

1 participant