On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
As it stands, it's impossible to have thread-local memory pools. It's quite legal to construct an object as shared or thread-local and cast it to the other. In fact, it's _highly_ likely that that's how any shared object of any complexity is going to be constructed. Similarly, it's extremely common to allocate an object as mutable and then cast it to immutable (either using assumeUnique or by using a pure function where the compiler does the cast implicitly for you if it can guarantee that the return value is unique), and immutable objects are implicitly shared. At minimum, there would have to be runtime hooks to do something like move an object between pools when it is cast to shared or immutable (or back) in order to ensure that an object was in the right pool, but if that requires copying the object rather than just moving the memory block, then it can't be done, because every pointer or reference pointing to that object would have to be rewritten (which isn't supported by the language).


It's a bit easier than that. When you cast something to shared or immutable, or allocate it as shared or immutable, you pin the object on the local heap. When the thread-local collector runs, it won't collect that object, since another thread might know about it. Then, when you run the global collector, it will determine which shared objects are still reachable and unpin things as appropriate.

That unpinning process requires a way to look up the owning thread for a piece of memory, which can be done in logarithmic time relative to the number of contiguous segments of address space.

Casting away from shared would not call any runtime functions; even if it were guaranteed that the cast were done on the allocating thread, it's likely that there exists another reference to the item in another thread.

This would discourage the use of immutable, since it wouldn't benefit from thread-local heaps.

Reply via email to