Okay.  From the discussion I was under the impression that each thread
had its own arena, so reinitializing would free the entire arena.  (I'm
talking about a big block of virtual memory when I say arena.)

An option would be to give each thread its own private arena, with the
size configurable at runtime - say 10MB for example.  Any allocations
that couldn't be service from the private arena would overflow to the
shared arena.  When the thread exits, the entire 10MB arena is freed.
The AS process size might be bigger, but a significant amount of that
would probably be unaccessed VM.  Combined with killing idle threads,
this might lead to a more stable memory configuration.  The only heap
that would be subject to fragmentation would be the shared heap.

Maybe there are allocators that already do something like this and I
just need to go read/benchmark more code. :) This fragmentation issue
isn't a big deal for us because of the daily restart, but in a 24-hour
period, our dynamic content server grows to 3x its initial size
because of fragmentation.

Jim

>
> In a message dated 1/11/2004 12:03:36 AM Eastern Standard Time,
> [EMAIL PROTECTED] writes:
>
> It  seems that one way to address this memory/heap problem is to force
> threads  to exit after a certain amount of time idle, freeing their
> entire heap  area.  There is code in AS to do that, but I've never
> gotten it to  work successfully because AS tends to "round-robin" the
> workload to all  threads.  So they never idle.
> Hi,
> Unfortunately this isn't possible -- all the memory used by a thread is
> simply moved over to the shared area on thread exit.  That memory is  reused by
> other threads when needed but the fragmentation remains.  To  reduce
> fragmentation the allocator would have to coalesce unused blocks, look  for large
> contiguous free zone's, and munmap those region.  This garbage  collection would
> require all memory allocation in all threads to stop while  such a scan took place
> which would defeat the free-threaded design of the  allocator.  And, the
> possibility of such a garbage collection phase would  require locking on all
> allocations to check if and when it had started.
> -Jim


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

Reply via email to