waynexia commented on PR #6336: URL: https://github.com/apache/arrow-rs/pull/6336#issuecomment-2378646907
> As I understand it this mechanism would require making every codepath that allocates arrays be generic on an Allocator and take an Allocator as a parameter. IMO this is not that horrible in two aspects: - I suspect the type param on struct would only reside on `MutableBuffer` for a long time, maybe until the `Allocator` gets stable. From `Buffer` and above the type param is erased (see #6455). Like how we interact with `Vec` which may or may not belong to a customized allocator: nothing is wrong if we just ignore it, only a "feature" is missing. - We can gain great progress after the major mechanisms of constructing an array like through `Vec` or `MutableBuffer` are handled. There is still much work to do to adapt those methods. But they are not that tightly coupled together like `MutableBuffer` and `Buffer`. > Additionally the proposed use-cases appear to largely center around memory tracking, as opposed to altering the behaviour of the system allocator. As such we could potentially just store a std::sync::Weak<AtomicUsize> in thread local storage, with allocations decrementing / incrementing this as appropriate. If we don't need per-object tracking, simply replace the global allocator as @alamb mentioned before should be okay. And this is already viable in the current version as we don't need to do any change in the arrow side. And considering the arrow is a large group of libs, we don't have to take this `allocator` feature as "can or can't" for the entire project. It is acceptable from my side that this feature is only available in a few low-level APIs like `arrow-buffer` and isn't in others like `arrow-compute` in a specific period. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
