Re: [PATCH] Restore mempools functionality for MemBlob

From: Kinkie <gkinkie_at_gmail.com>
Date: Thu, 31 Mar 2011 01:58:49 +0200

>> I could not find the exact reference quickly, but the following FAQ
>> describes the same "static initialization order fiasco" problem, albeit
>> indirectly:
>> http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14
>>
>
> The fiasco is a peculiarity of methods. Which need valid *this.
>
> We are dealing with static constant array. I would be surprised if the
> compiler did not optimize that down to a hard-coded piece of pre-initialized
> memory on the heap.
>
> Hmm, is the a real dependable guarantee of it being zero?
>  or do we actually have to deal with the random values situation?

To the best of my knowledge (confirmed by some quick googling), that
is a basic guarantee back from C, even though it was always
recommended to explicitly intialize them.

> If it *is* guaranteed zero we are safe, any size will be <=
> StrPoolAttrs[0].obj_size.
> And also the i < count iterator abort will cut in preventing any further
> array checks quite optimally.
>
> Problems remain if the array count global is initialized but not the array,
> or if either is set to random values before initialization.

array count is a preprocessor macro.

> We could avoid the counter/array disconnect problem by terminating the array
> with an entry of zeros, avoiding the need for an array counter entirely.

I don't like this much, it would likely require special handling as
pool searching right now assumes that the pools array is sorted.

>>> In any case, I failed to convince you of the viability of this
>>> approach. As promised, I'll then implement your suggestion of
>>> assigning max(pool_size)+1 to early allocations;
>>
>> I do not insist on the M+1 hack. If others think that the check is not
>> worth the extra KBs for early allocations, it can go. I am just
>> presenting what I consider is a viable option so that we can make an
>> informed decision rather than just removing a useful check as "not
>> needed".
>>
>> Thank you,

Attached you can find a second iteration of the patch.
Changes:
- explicit flag to mark "pools are initialized" state
- implemented Alex' size suggestion
- SMP cachemgr-friendly stats
- no-op'ed MemBlob size estimator
- big and huge strings

-- 
    /kinkie

Received on Wed Mar 30 2011 - 23:58:56 MDT

This archive was generated by hypermail 2.2.0 : Thu Mar 31 2011 - 12:00:04 MDT