# 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