develooper Front page | perl.perl6.internals | Postings from July 2002

[perl #809] [PATCH] Adding the system stack to the GC

From:
Mike Lambert
Date:
July 13, 2002 02:23
Subject:
[perl #809] [PATCH] Adding the system stack to the GC
Message ID:
rt-809-3798.3.09102915208271@perl
# New Ticket Created by  Mike Lambert 
# Please include the string:  [perl #809]
# in the subject line of all future correspondence about this issue. 
# <URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=809 >


Okay, patch is included below. Here are the relevant times from the gc
bench suite:
gc_alloc_reuse.pbc      12.058001       12.056999
gc_generations.pbc      3.964999        5.769
gc_header_new.pbc       3.924999        3.924999
gc_waves_headers.pbc    0.871997        0.871999
gc_waves_sizeable_data.pbc      7.059   7.140001
gc_waves_sizeable_headers.pbc   5.316999        5.358

I believe gc_generations is slower due to the many DOD calls that are
performed (and each DOD requires a stack walk). In general,
the stack-walk makes the new version a little bit slower, or perhaps the
same, in all cases.

Note that the patch implementation is a bit ugly because of the seperation
of pmc and header pools. I have another GC refactoring patch in the wings
which should remedy this situation.

Also note the problem I mentioned earlier, which may very well crop it's
head up with this patch under 'real-world' conditions. See below sig.

Mike Lambert

> Also, I think I've discovered a situation which might not be
> resolvable. How do we determine id a given buffer is alive? We walk the
> stack and check for potential pointers into buffer memory. If the stack
> contains garbage pointers, we might have bad references into buffer
> memory. I can check for alignment within the buffer pool, and so it should
> be safe to set the BUFFER_live_FLAG on them.
>
> However, when we perform a collection, that means that we could be taking
> a garbage pointer in the buffer, and attempting to copy the memory it
> pointed to, into new memory.
>
> This could give us GPFs if we access bad memory, I think. Even if we check
> to ensure the buffer points into valid collectable memory (making it
> slower), we still have the issue of buflen being set to MAX_INT or
> something, and killing the system. :|
>
> The same caveats apply to pmc headers which happen to have
> PMC_buffer_ptr_FLAG set.
>
> How should we get around this particular problem, or is it spelling the
> doom of this particular solution?
>
> Thanks,
> Mike Lambert


-- attachment  1 ------------------------------------------------------
url: http://bugs6.perl.org/rt2/attach/3798/3520/778163/diff.txt




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About