apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Memory Renaming (try 2)
Date Sat, 12 May 2001 17:23:44 GMT
On Sat, May 12, 2001 at 01:41:37PM +0200, Sander Striker wrote:
> > 2) From the performance standpoint, we need to make this malloc stuff as
> >    fast as the plain malloc call or this isn't going to be worth much.
> >    Checks such as "if !size return 0" probably isn't needed in
> >    apr_sms_malloc() code.
> 
> Probably not. What does malloc() return when passed a size of 0?
> Btw, sms _always_ adds some overhead, but what you get back for it is
> (a bit of) flexibility.

Doesn't ANSI C define this?  Hmm, I just looked at FreeBSD's kernel malloc 
code, no.  My understanding is that you guys are going to be adding
kernel memory allocation support, right?  So you won't necessarily be
talking to ANSI compliant malloc()s.  Maybe this particular check 
isn't a bad idea then.  

> > 3) There is some logic that you are attempting to duplicate in
> >    apr_sms_realloc() that I believe the realloc system call handles for
> you
> >    (at least on Solaris).  More generally, you are *probably* better off
> >    letting the system calls handle this type of redirection rather than
> >    yourself, but I might be wrong.  Dean may have a better idea
> >    whether we should try to outsmart the system calls or not - my gut
> >    feeling would be to avoid this "cleverness."
> 
> The same goes for realloc() as goes for malloc(), however, this 'cleverness'
> is minor overhead and lessens the work for a sms implementor. For
> performance
> I have to agree, you move the 'cleverness' to the specific sms
> implementation,
> or you don't implement it at all. IMHO the only sms that doesn't need the
> 'cleverness' is the standard sms.

The issue I see is that since this code is in the critical path for
almost everything APR will be built upon, so this code should be extremely
fast.  That's my take on it.  I know that if all of this redirection ends
up slowing everything down, there won't be some happy campers somewhere.
Pools will make it a little faster (lessen the calls to apr_sms), but still, 
on a heavily loaded server, malloc and free get called a lot.

> >    (You also try to be "safe" about a memset call - if memset is bogus,
> >    we have lots of other problems...)
> 
> Ok, so we ditch the memset and set all members of apr_sms_t to NULL by hand.

I think you and David misunderstood me (or I didn't make myself suitably
clear)  - if you do a memset to NULL, you sure shouldn't have to set
all members of apr_sms_t to NULL.  If memset is broken, we are going to
have lots of problems.  Unless, of course, there is a platform out there
that doesn't have memset.  Ouch.

> > 5) What do you plan apr_sms_threadsafe_lock to do (maybe you talked about
> >    this, but I missed it)?  Is this something similar to apr_lock? Why are
> >    we concerned about an apr_sms_t being shared across threads?  (Please
> >    don't tell me shared memory segments...)
> 
> *grin* It was meant as the start of support for the thing I shouldn't tell
> you.
> The name is confusing as I stated in earlier postings.

What are going to be the advantages of doing shared memory segments?
Isn't this a horribly bad idea?  No platform has decent shared memory
support - and it is certainly too chaotic (IMHO) to try to actually
build something into APR that attempts to create shared memory segments
of arbirtrary size (i.e. go past insanely small limit of some OSes).

On a previous project I worked on, someone suggested using SysV SHM -
we looked into SHM of all sorts in detail and figured out that SHM is 
incredibly slow and can't scale.  We ended up using doors (local RPC)
which are incredibly fast, but isn't yet supported on all platforms.
I'm just curious to see how you see shared memory working...  I
remember some posts that Dean had with Luke about this - I'll search
the archives...

Oh, here is in an incredibly useful suggestion that I'd love to see
added into the sms stuff while you are at it - add a calloc function that
tries to use calloc if available, or use malloc/memset.  There are
a lots of places in the apr/apr-util/httpd code (SDBM comes to mind) that 
use malloc/memset because there is some incredibly non-ANSI C compiler 
that we support that doesn't have calloc (anyone know exactly which 
compiler this is?  I'd like to shoot it.).  It'd be nice if we could help 
those lame platforms out.  This redirection would be incredibly useful.  
-- justin


Mime
View raw message