Falcon Team,
In looking through the Falcon code, one can see heavy use of reference
counters; calls to an object's addRef() or release() functions. These
are manual reference counters and they always do an interlocked
increment or decrement on the reference count.
A smart pointer is an automatic way of encapsulating this kind of
reference counting, but it is automatically done every time a copy is
made of a pointer.
The advantage of targeted reference counting is performance.
The advantage of smart pointers is stability.
We have been dealing with unbalanced reference counters in the
DeferredIndex object lately, but have dealt with it before in BDBs and
Record objects, most notably. If a reference is added but not deleted,
you get a memory leak. The opposite causes a crash, when an object
disappears prematurely.
The performance advantage of targeted reference counters is real.
Today, for example, I saw a performance report from the Intel team in
China indicating that the Record::addRef is one of the top 2 functions
which increased CPU cycles as a sysbench test increased from 10 to 20 Mb.
If Record::addRef() used smart pointers, the performance drop would be
measurable and multi-core scalability would suffer even worse. Since
one of our goals is to scale well on multi-core systems. It makes sense
for us to be careful about things which would slow us down.
Instead of sweeping reforms like smart pointers which add restrictions
to performance and scalability, I think we should take the time to
understand the correct use of targeted reference counters, and use them
wisely.
Not only that, we should look for opportunities to group reference
counters into larger scopes. Granted, those opportunities are difficult
and risky.
Kevin Lewis
Falcon Team Lead
