On Sun, Aug 3, 2014 at 3:20 PM, Nick Wellnhofer <[email protected]> wrote:
> But I never understood exactly why the refcount hack is needed at all.
These days, the custom refcounting methods on Class, HashTombStone and
RawPosting faciliate two objectives: compatibility with threads, and speed.
For the sake of compatibility with threads, we made two changes a while back:
* Eliminate refcounting of Class ("VTable" at the time).
* Use LockFreeRegistry instead of Hash for the Clownfish class registry.
After those changes, you still couldn't share Clownfish-based objects across
threads, but basic object creation and destruction were now possible without
refcount race conditions on elements of the global OO infrastructure.
Eliminating refcounting on Class objects also had the side effect of saving a
handful of CPU cycles. Similarly, we save a small amount of time and effort
by not refcounting the HashTombStone singleton.
Lastly, RawPosting instances are allocated using a MemoryPool rather than
malloc(), which allows us to bulk-deallocate groups of them in a single call
to MemPool_Release(). (This is possible only because we use RawPostings in a
closed environment and do not allow any references to escape.) Deallocating
lots of small objects can be expensive because of the bookkeeping involved in
a heap memory allocator. However, there are alternative techniques we could
use to achieve similar optimizations, and the MemPool approach has saved less
time than I would have hoped anyway.
Marvin Humphrey
