Re: doZeroOnPush

On 01/24/2013 07:27 PM, Amos Jeffries wrote:
> On 24/01/2013 11:36 p.m., Kinkie wrote:
>> On Thu, Jan 24, 2013 at 11:28 AM, Amos Jeffries wrote:
>>> On 24/01/2013 5:56 a.m., Kinkie wrote:
>>>> Hi Amos,
>>>> what is the best way to signal in a mempools client that the
>>>> constructor is complete and that thus zeroing is not necessary? It's
>>>> not immediately evident from looking at the source..
>>>> It seems that this is only done in mem.cc for string pools.
>>>
>>> memDataInit() has an optional bool flag. Set it to false.
>> .. I still can't fully understand how it relates to the usual
>> MEMPROXY_CLASS/MEMPROXY_CLASS_INLINE, and I can't find any good
>> example.
>>
>>
>> --
>> /kinkie
>
> I think I found the answer. And its no good...
>
> The objects defined with MEMPROXY_CLASS() macro are all using
> MemAllocatorProxy::getAllocator() in lib/MemPools.cc to late-initialize
> their pools. There is no zero flag being passed around in any of those
> macros or their code paths.
>
> So far as I can see to make it optional we will need to make either a
> template or a new macro which accepts the flag and saves it for use when
> MemAllocatorProxy::getAllocator().create(...) is done. The doZero()
> setter needs to be called from the same if() condition right after
> MemAllocatorProxy::getAllocator().create().
>
> So:
> 1)
> - update the macro and roll it out in one step defaulting as (true)
> everywhere
> - then set it to false as things get verified.
> - then eventually remove it again when we have a fully no-zero state
> for all classes.

I think this is the best option, especially if you trust Coverity to
eventually find all initialization problems. It comes with virtually no
initial risk and results in very few code changes.

> 2)
> - add a second macro which sets it to true.
> - roll out a conversion to the new maro

OK, but I think #1 is better because #1 results in fewer code changes. I
may change my opinion if Kinkie's tests prove that fewer doZero buffers
result in significantly better performance, justifying per-class,
incremental changes.

> 3)
> - make a template which can replace MEMPROXY_CLASS() etc. with zero
> optional flag
> - rollout the template as we verify classes are constructed properly

Doable, but too complex IMO, without much added benefit that I can see.

Thank you,

Alex.
Received on Fri Jan 25 2013 - 17:57:12 MST