RFC: Allocator: Track core1 allocations #46
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
I'm thinking if we should modify the allocator to track allocations made by 2 cores separately, so that we can free the blocks allocated to core1 after reset, similar to what an OS would do after a process terminates.
The problem with core1 is that we cannot guarantee to be free of memory leaks, due to possible hardware reset requested by the core0 at any time. The user code may also contain bugs or any kind of infinite loop so the kernel would never reaches the destructor.
Using mutex or something to share the reference between two cores, and ask core0 to drop those references when it request a reset for core1 is possible. However, that would be quite complicated, and if core1 is holding the mutex guard during reset/panic that would be a problem as we can no longer guarantee the struct to be in a correct state.
I suppose this is obsolete now - the current route is to have two completely separate allocators, there is never anything allocated by one core and freed by the other.