Re: [Drizzle-discuss] Removing Array custom vector allocation for semi-join subqueries

[Jim Starkey]

MARK CALLAGHAN wrote:
> On Thu, Feb 26, 2009 at 11:17 PM, Monty Taylor <mordred@stripped> wrote:
>
>   
>> Therefore, I'm going to say that what we _really_ want instead of
>> mem_root is what Jay and I have been pushing for for a while - resource
>> management through ownership. Pointers to allocated memory should be
>> contained in, owned by and managed by an object, such that when the
>> object goes away, so does the memory. It's almost like magic how much a
>> nice containment hierarchy can achieve the end-goal of mem_root.
>>
>> I'd post a code sample... but I'm falling asleep sitting here... I'll
>> come back to this in the morning. :)
>>
>> Monty
>>
>>     
>
> I am curious about how this will deal with the problem of memory
> allocations that have different lifetimes. The popular ones in
> non-drizzled MySQL are:
> * global -- get it from malloc() today
> * per connection -- get it from the THDs mem_root today
> * per session -- not sure if it exists today
> * custom -- not sure if it exists today
>
> Having more than one lifetime is already a problem as you need to be
> very careful when maintaining a pointer to an object that has a
> shorter lifetime (objects from the global allocation can't point to
> per-session, ...).
>
>   
An object destructor typically deletes objects that it "owns".  In cases 
where more than one object may have pointers to another, reference 
counting is generally used.  When an object is shared among threads, 
reference counting with interlocked instructions is necessary.  Objects 
that can have circular dependencies require something more sophisticated.

Many C-based database systems use memory pools for objects of the same 
lifetime.  Firebird, for example, allocates a pool for a statement to be 
compiled.  At end of compilation, the pool is released and everything 
goes away like magic.

The two models don't mix at all, which is why there are more database 
systems written in C+ (credit to Brian this time) than C++.

Having used each model extensively, the C++ destructor mechanism is 
clearly superior, but requires some getting used to.  But destructors 
must be called, and the C++ allocation mechanism doesn't provide memory 
allocators with enough information to call them.

Trying to mimic memory pools in C++ is possible, but is more work and 
overhead than making a personal accommodation to C++.


-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376