You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: