[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Zone allocator (KHTML)
From:       Robert_Schöftner <robert () whisker ! rmu>
Date:       1999-06-11 18:31:10
[Download RAW message or body]

hi,

On Thu, Jun 10, 1999 at 09:16:22AM +0200, Waldo Bastian wrote:
> [Robert: Your reply-to address seems to be incorrect <robert@whisker.rmu>]
hmm. thx, mutt's screwing something up... there shouldn't be one...

> Robert Schöftner wrote:
> > 
> > > *) The blocks are (at least under Linux 2.2.x) returned to the OS
> > > when the page is destructed. This is unfortunately not the case with
> > > traditional memory allocation.
> > 
> >         this does not depend on the kernel but on the malloc used. iirc
> > glibc-malloc uses mmap/munmap for blocks bigger than some value...
> > munmap of course will release all mem.
> 
> Yes, true. I could mmap myself but I don't know how portable that is.
> This will work for all platforms. I don't know if all malloc implementations
> start using mmap for larger blocks... do you know?

	hmm. don't know mallocs on other platforms than linux/i386. but mmap
is POSIX and BSD4.4 and SVr4, so should be available on every platform kde
runs... i have not tested my allocator on any other system than linux,
but it should run at least on solaris and *bsds...

[stuff about alignment]

> >         it works for me :), comes with configure (that was/is a pain), a
> > new QLayout-decendant (motif-like geometry management) and much more...
> > the allocator uses mmap/munmap, thus should return memory on all systems
> > that can do anonymous mmaps.
> 
> What has QLayout todo with memory management?

	nothing :) (i hate autoconf)

> >         most important: it comes with delete :)
> 
> Well, delete is not my biggest problem:
> 
> There are some cases where it would be beneficial to use a zone allocator
> because (possibly) a large number of objects get generated and then they
> all get destructed again. The problem is that these are compound objects,
> e.g. like:
> 
> class myObject {
>   ...
>   QString myString;
>   KURL muURL;
> }

	iirc (and according to egcs-sources) new/delete can be overloaded/replaced ->
you can trick new into allocating space from a zone thats indicated in a global
variable...

// example (lacking nomem-conditions and proper nothrow etc... decls)
//
extern Zone global_zone;

void* operator new(size_t sz)
{
  if (global_zone)
	return global_zone->alloc(sz);
  else
	return malloc(sz);
}

void operator delete(void* p)
{
  Zone::free(p); // this has to do some magic, e.g. find out where from p has been alloc'ed
}
//--:)--

delete needs to be reimplemented then, too... 
(see my zone allocator :)

if this gets linked in "the right way" it replaces the default new operator.

servas,
  robert


-- 
In Root we Trust!
   [STOP ENFOPOL:  http://www.quintessenz.at]
   [   campaign mailto:nobody@quintessenz.at]
   [   contact:      mailto:k@quintessenz.at]

[prev in list] [next in list] [prev in thread] [next in thread]