>> 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
This archive was generated by hypermail 2.2.0 : Thu Mar 31 2011 - 12:00:04 MDT