# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #636]
# in the subject line of all future correspondence about this issue.
# <URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=636 >
Peter's latest patch also included changes to the logic in terms of what
to do when we don't have any available memory left in the pool. Patch is
below.
Results are:
before after
gc_alloc_new.pbc 4.155999 0.18
gc_alloc_reuse.pbc 16.574 10.144998
gc_generations.pbc 4.025 4.175998
gc_header_new.pbc 3.686 4.286
gc_header_reuse.pbc 5.577999 4.446001
gc_waves_headers.pbc 3.815002 3.865
gc_waves_sizeable_data.pbc 8.383002 0
gc_waves_sizeable_headers.pbc 5.668 5.768
The '0' result comes from parrot crashing. This is not due to this patch,
but rather to GC bugs in parrot that this particular patch exposes.
This also causes stacks test 29/29 to crash for the same reasons. Since
it was included as part of peter's main patch which included a 'cycles'
solution to the GC problems, I don't believe the entire patch caused
parrot to crash.
gc_alloc_new seems to have improved a *lot*. This is because
gc_alloc_new allocates a lot of memory using the same headers. It
doesn't tear through headers quickly enough to trigger any dod runs on
its own, so these headers stay live and allocate tons of memory that gets
continually copied between generations.
The logic it uses is thus: If there's enough that's reclaimable, then we
compact to reclaim it. Otherwise, if there's not enough to reclaim, then
it's a hint that perhaps we need to run a DOD to reclaim some more, and so
it does.
Other results include a gc_alloc_reuse and gc_header_reuse improvement due
to the same reasons (the dod calls we wouldn't otherwise get). We get a
performance drop on gc_header_new due to the fact that we are allocating
lots and lots of headers. Performing dod runs doesn't help here, and only
serves to slow it down.
This patch seems to improve more than it deproves, so it should probably
go in, once Parrot is fixed to remove this GC bug (or perhaps before, to
ensure it gets fixed. ;) We should revisit it at some point to see if
there is a way to dynamically determine what kind of behavior our program
is doing, and avoid dod runs when allocating if we're in a massive
allocation stage of the program's life (program startups, calculation
setup, etc).
Mike Lambert
Index: resources.c
===================================================================
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.60
diff -u -r1.60 resources.c
--- resources.c 26 May 2002 20:20:08 -0000 1.60
+++ resources.c 29 May 2002 07:40:34 -0000
@@ -1126,11 +1126,16 @@
}
if (pool->top_block->free < size) {
/* Compact the pool if allowed and worthwhile */
- if (pool->compact &&
- (pool->reclaimable >
- (size_t)(pool->total_allocated * pool->reclaim_factor)))
- {
- (*pool->compact)(interpreter, pool);
+ if (pool->compact) {
+ /* Parrot_do_dod_run(interpreter); */
+ if (pool->reclaimable >
+ (size_t)(pool->total_allocated * pool->reclaim_factor)) {
+ /* Parrot_do_dod_run(interpreter); */
+ (*pool->compact)(interpreter, pool);
+ }
+ else {
+ Parrot_do_dod_run(interpreter);
+ }
}
if (pool->top_block->free < size) {
alloc_new_block(interpreter, size, pool);
