Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Speaking of counters, that brings me to another issue: Mr Click very conveniently avoids the problem with the free of the old table after resize since he leaves it to the java gc. It's not that simple for us. I guess we'll have to keep similar concurrent access counters for the references to the hash table blocks. Even so, it's still not trivial to free it in a safe way.
I don't think it's that complicated. After the copy has completed, the old table doesn't contain any references anymore, and can be freed without actually traversing it.
An array of counters is allocated for every thread, and there is a function that allocates a counter by returning a free index in those arrays. So every thread has its own counter array in the local cache in r/w mode, while the others only need (more or less) occasional read access. The allocation and freeing of counters should also be lock-free, although that's not strictly necessary.
Sounds good.