See https://github.com/golang/go/issues/51317#issuecomment-1905287203 Bump-pointer allocation is an interesting direction to explore. I will describe, in a bottom-up way, an idea for implementing Bump-pointer allocation. On each P or M, there is a P or M exclusive bumpPtr, and runtime.malloc prioritizes using P or M exclusive bumpPtr to allocate memory. The allocation method is to prepare memory blocks for each type to be allocated, or to prepare memory blocks for non pointer types of the same size and for each pointer type separately. An offset from 0 is used to move the pointer to allocate a go value. The cost of allocating memory in this way becomes mostly a map query (based on the https://gitee.com/qiulaidongfeng/arena Based on my experience, there is a very low Alloc cost for a map query, as well as a few if judgments and additions. No synchronization is required. If a bumpPtr exclusive to P or M requires memory blocks, the source of those blocks is determined by the implementation. This can be used to better understand the idea: https://github.com/qiulaidongfeng/go/commit/b149195ce0533834479e7a9b04a87de2bbeba0f0 Note that this submission is only for understanding the idea and does not even pass the test. I don't plan to continue researching this idea in the near future, because https://gitee.com/qiulaidongfeng/arena Try again https://github.com/golang/go/issues/51317#issuecomment-1905560437 The optimization mentioned is enough for me. I make this idea public. If anyone is interested in this idea, hopefully this will help.
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/eab8a246-c377-4011-b692-0b73ca9a39e0n%40googlegroups.com.
