Re: On to APR 2.0.0? Beyond 9x/ME

[Branko Čibej <br...@xbc.nu>]

Justin Erenkrantz wrote:
> 3. make pools runtime-configurable whether they are just a thin
> malloc()/free() wrapper or do internal reuse
>   

I think there may be some interest in this ... we've learned the hard
way that pools as they stand today, while moderately nice for stateless
server implementations, are less than moderately horrible for anything else.

-- Brane

Re: On to APR 2.0.0? Beyond 9x/ME

[Branko Čibej <br...@xbc.nu>]

Mladen Turk wrote:
> Branko Čibej wrote:
>> Graham Leggett wrote:
>>> Branko Čibej wrote:
>>>
>>>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>>>> remember once ... well, to make a long story short, control over pool
>>>> lifetime wasn't, and we ended up jumping through several Klein bottles
>>>> to get there.
>>> Unless I am not following something, you control the pool lifetime.
>>
>> Not if you have no control of pool cleanup order, which is exactly what
>> happens when you try to allocate long-lived structure in a DSO; the way
>> we do pool cleanup guarantees that the DSO gets unloaded before any
>> global pools are cleaned up.
>>
>> You could say that the answer is "don't do that", but sometimes there's
>> no other option.
>>
>
> There is a new apr_poll_pre_cleanup_register API, meant to
> be used exactly for that. It ensures that cleanup will run
> before subpools gets destroyed.

*Now* there is. Might be enough for the case I mentioned, dunno --
frankly I haven't looked it in a while. (Not that it would help SVN 1.x,
but that's irrelevant).

Re: On to APR 2.0.0? Beyond 9x/ME

[Mladen Turk <mt...@apache.org>]

Branko Čibej wrote:
> Graham Leggett wrote:
>> Branko Čibej wrote:
>>
>>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>>> remember once ... well, to make a long story short, control over pool
>>> lifetime wasn't, and we ended up jumping through several Klein bottles
>>> to get there.
>> Unless I am not following something, you control the pool lifetime.
> 
> Not if you have no control of pool cleanup order, which is exactly what
> happens when you try to allocate long-lived structure in a DSO; the way
> we do pool cleanup guarantees that the DSO gets unloaded before any
> global pools are cleaned up.
> 
> You could say that the answer is "don't do that", but sometimes there's
> no other option.
> 

There is a new apr_poll_pre_cleanup_register API, meant to
be used exactly for that. It ensures that cleanup will run
before subpools gets destroyed.

Regards
-- 
^(TM)

Re: On to APR 2.0.0? Beyond 9x/ME

[Branko Čibej <br...@xbc.nu>]

Graham Leggett wrote:
> Branko Čibej wrote:
>
>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>> remember once ... well, to make a long story short, control over pool
>> lifetime wasn't, and we ended up jumping through several Klein bottles
>> to get there.
>
> Unless I am not following something, you control the pool lifetime.

Not if you have no control of pool cleanup order, which is exactly what
happens when you try to allocate long-lived structure in a DSO; the way
we do pool cleanup guarantees that the DSO gets unloaded before any
global pools are cleaned up.

You could say that the answer is "don't do that", but sometimes there's
no other option.

-- Brane

Re: On to APR 2.0.0? Beyond 9x/ME

[Graham Leggett <mi...@sharp.fm>]

Branko Čibej wrote:

> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
> remember once ... well, to make a long story short, control over pool
> lifetime wasn't, and we ended up jumping through several Klein bottles
> to get there.

Unless I am not following something, you control the pool lifetime.

If you wanted pure emulation of malloc and free, with no pool hierarchy, 
just create one global pool, and then create a subpool every time you 
want to do malloc, and destroy that subpool every time you want to do 
free. Because all of your subpools have no relationship with one another 
(apart from being created from the global pool, which would last the 
applications' lifetime), lifetime is no longer an issue.

Regards,
Graham
--

Re: On to APR 2.0.0? Beyond 9x/ME

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Paul Querna wrote:
> Branko Čibej wrote:
>>
>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>> remember once ... well, to make a long story short, control over pool
>> lifetime wasn't, and we ended up jumping through several Klein bottles
>> to get there.
> 
> I think a proposal to make them optional would be very interesting, I
> know some people (Garrett Rooney?) had some ideas on this.

I've seen a proposal to replace pool_clear/_destroy to call free() instead
of returning the pool to the allocator.

And we've tried implementing apr_sms for pluggable memory in the past,
see the svn history.  The performance was unacceptable.

Bill

Re: On to APR 2.0.0? Beyond 9x/ME

[Paul Querna <ch...@force-elite.com>]

Branko Čibej wrote:
> William A. Rowe, Jr. wrote:
>> Branko Čibej wrote:
>>   
>>> Justin Erenkrantz wrote:
>>>     
>>>> 3. make pools runtime-configurable whether they are just a thin
>>>> malloc()/free() wrapper or do internal reuse
>>>>   
>>>>       
>>> I think there may be some interest in this ... we've learned the hard
>>> way that pools as they stand today, while moderately nice for stateless
>>> server implementations, are less than moderately horrible for anything else.
>>>     
>> Nonsense ;-)  It's just a matter of applying the right scope to the right
>> objects, and this is far simpler than anticipating when individual byte
>> allocations are free()ed.
>>   
> 
> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
> remember once ... well, to make a long story short, control over pool
> lifetime wasn't, and we ended up jumping through several Klein bottles
> to get there.

I think a proposal to make them optional would be very interesting, I 
know some people (Garrett Rooney?) had some ideas on this.

Thanks,

Paul

Re: On to APR 2.0.0? Beyond 9x/ME

[Branko Čibej <br...@xbc.nu>]

William A. Rowe, Jr. wrote:
> Branko Čibej wrote:
>   
>> Justin Erenkrantz wrote:
>>     
>>> 3. make pools runtime-configurable whether they are just a thin
>>> malloc()/free() wrapper or do internal reuse
>>>   
>>>       
>> I think there may be some interest in this ... we've learned the hard
>> way that pools as they stand today, while moderately nice for stateless
>> server implementations, are less than moderately horrible for anything else.
>>     
>
> Nonsense ;-)  It's just a matter of applying the right scope to the right
> objects, and this is far simpler than anticipating when individual byte
> allocations are free()ed.
>   

Oh, certainly. Except that sometimes the "just" is a pretty big one. I
remember once ... well, to make a long story short, control over pool
lifetime wasn't, and we ended up jumping through several Klein bottles
to get there.

-- Brane

Re: On to APR 2.0.0? Beyond 9x/ME

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Branko Čibej wrote:
> Justin Erenkrantz wrote:
>> 3. make pools runtime-configurable whether they are just a thin
>> malloc()/free() wrapper or do internal reuse
>>   
> 
> I think there may be some interest in this ... we've learned the hard
> way that pools as they stand today, while moderately nice for stateless
> server implementations, are less than moderately horrible for anything else.

Nonsense ;-)  It's just a matter of applying the right scope to the right
objects, and this is far simpler than anticipating when individual byte
allocations are free()ed.

What just refers to is whether or not apr_pool_clear/_destroy should drop
the memory back into a pool freelist, or back to the system allocator (and
call a true free() upon their release).  With modern malloc/free, we may be
looking at very little advantage to keeping a freelist.

Re: On to APR 2.0.0? Beyond 9x/ME

[Mladen Turk <mt...@apache.org>]

Nick Kew wrote:
> On Mon, 16 Feb 2009 08:06:11 +0100
> Mladen Turk <mt...@apache.org> wrote:
> 
>> One thing I've proposed (but was vetoed) was the actual
>> malloc/free programmable replacement within the allocator.
>> Now the thing to consider is to make the allocator public
>> allowing to implement what ever system memory allocation
>> there is (eg, heap or virtualmemory on win32, shm, etc)
>> instead just relying on standard allocator implementation
>> which (I presume that 8K granulation was more or less
>> empirically determined) is fixed.
> 
> Can you point to that discussion?

Here was the patch
http://svn.apache.org/viewvc?view=rev&revision=647394

Browse the archive for objections ;)

> Seems to me that if it
> can be done without performance penalties, then making the
> allocator into a public API should have potential to be the
> solution to make everyone happy.
> 

I'm not saying the the proposed API was perfect.
It only changed the internal allocator malloc/free.
The best thing would be to completely abstract the
allocator so that one can completely implement it's
own allocator.
The existing implementation would then change from:
mem = allocator_alloc(allocator, size)
to
mem = (*allocator->alloc)(allocator, size)

I don't think there will be any performance
penalties using that.


Regards
-- 
^(TM)

Re: On to APR 2.0.0? Beyond 9x/ME

[Nick Kew <ni...@webthing.com>]

On Mon, 16 Feb 2009 08:06:11 +0100
Mladen Turk <mt...@apache.org> wrote:

> One thing I've proposed (but was vetoed) was the actual
> malloc/free programmable replacement within the allocator.
> Now the thing to consider is to make the allocator public
> allowing to implement what ever system memory allocation
> there is (eg, heap or virtualmemory on win32, shm, etc)
> instead just relying on standard allocator implementation
> which (I presume that 8K granulation was more or less
> empirically determined) is fixed.

Can you point to that discussion?  Seems to me that if it
can be done without performance penalties, then making the
allocator into a public API should have potential to be the
solution to make everyone happy.

-- 
Nick Kew

Re: On to APR 2.0.0? Beyond 9x/ME

[Mladen Turk <mt...@apache.org>]

Branko Čibej wrote:
> Graham Leggett wrote:
> 
> I expect that with the new detached global pools in APR, that particular
> problem would never have arisen.
>

Right, that was the point, and that allows the pools
to behave more or less like malloc/free.

One thing I've proposed (but was vetoed) was the actual
malloc/free programmable replacement within the allocator.
Now the thing to consider is to make the allocator public
allowing to implement what ever system memory allocation
there is (eg, heap or virtualmemory on win32, shm, etc)
instead just relying on standard allocator implementation
which (I presume that 8K granulation was more or less
empirically determined) is fixed.

> The fact remains that control of pool lifetimes, whether in combination
> with DSO or long-lived memory structures, is a tricky problem not
> addressed by the current implementation.
>

Detached pools behave like malloc/free and have to be
destroyed manually (well you can always create a pool
cleanup from some standard pool).
Having custom allocators one could even create
smaller (less then default 8K) memory
footprint where system malloc has low fragmentation and
larger number of small pools is required.

Regards
-- 
^(TM)

Re: On to APR 2.0.0? Beyond 9x/ME

[Branko Čibej <br...@xbc.nu>]

Graham Leggett wrote:
> Branko Čibej wrote:
>
>> I think there may be some interest in this ... we've learned the hard
>> way that pools as they stand today, while moderately nice for stateless
>> server implementations, are less than moderately horrible for
>> anything else.
>
> I strongly disagree.
>
> malloc and free are painful in the extreme, subpools give you all the
> structure of object oriented programming, without the need to touch C++.

I'm quite mystified ... what does memory mangement have to do with OOP?
Or specifically with C++?

> Just replace malloc with apr_pool_create, and replace free with
> apr_pool_destroy, and you are done.

All right, I'll have to expand on that story it seems. But first --
using pool-create/destroy instead of malloc/free is nonsense, as the
former are quite a bit more expensive in that case, and wouldn't have
solved the problem I'm about to describe.

But I digress.

The problem I was refering to was about controlling pool lifetime in a
long-lived process-wide cache where the controlling code happened to be
in a DSO. (It's the DB_REGISTER hack in Subversion, details are in SVN
archives).

What happened was that the "global" pool that the cache was allocated
from was destroyed /after/ the DSO was unloaded, leaving cleanup
functions pointing to non-existent code. While eventually we managed to
work around that problem, it would've been a lot easier if control over
pool lifetimes were more explicit.

I expect that with the new detached global pools in APR, that particular
problem would never have arisen.

The fact remains that control of pool lifetimes, whether in combination
with DSO or long-lived memory structures, is a tricky problem not
addressed by the current implementation.

-- Brane

Re: On to APR 2.0.0? Beyond 9x/ME

[Graham Leggett <mi...@sharp.fm>]

Branko Čibej wrote:

> I think there may be some interest in this ... we've learned the hard
> way that pools as they stand today, while moderately nice for stateless
> server implementations, are less than moderately horrible for anything else.

I strongly disagree.

malloc and free are painful in the extreme, subpools give you all the 
structure of object oriented programming, without the need to touch C++.

Just replace malloc with apr_pool_create, and replace free with 
apr_pool_destroy, and you are done.

Regards,
Graham
--