Gerald Butler <[EMAIL PROTECTED]> wrote: [ message history rearranged - please don toppost - I hope that got the right levels of indentation ]
> From: Piers Cawley [mailto:[EMAIL PROTECTED] >> Leopold Toetsch <[EMAIL PROTECTED]> writes: >>> PMCs are passed on to (external) C code. When inmidst of C code the >>> PMC moves around things break horribly--as they now break with the >>> copying collector when you do: >> I know it's extra indirection, but maybe we should be passing pointers >> to pointers rather than plain pointers to C functions. It could be a >> win if that gets us faster GC... That *if* is the problem. And it depends on the number of active and dead objects and possibly multiple other factors. "Normally" mark and sweep collection is faster, there is no overhead like write barriers, but you can of course construct benchmarks that reverse the result. You can construct benchmarks for everything :) And please note that all these GC papers (at least these what I have read) are focused on JVM, which is a stack machine. I don't know, if there is much difference, when it comes to GC, but anyway we don't have any numbers that indicate a generational (or incremental or refcounting or combined) scheme could be faster. Translating some of these JVM spec benchs to PIR could show some numbers but I didn't have a look at these programs and I don't know, how complex they are. > How do you make the copy/move of the object from one location in > memory and the update of the pointer to the pointer ATOMIC? If you > don't, it doesn't matter how many layers of indirection you have, it > will still be a problem.... This is only relevant for incremetal collectors running in the background. The double indirection could look like (AFAIK) pmc->pool_pointer->pmc_memory All code only sees the pmc pointer. During generational GC the pool_pointer and its memory is moved into an area where the pool of old generation isn't scanned for dead objects during each DOD run. The win is, that you are only going through the short lived objects pool mosts of the time. This would of course mean that each PMC operation has it's indirection penalty: pmc->pool_pointer->vtable->do_something(interp, pmc->pool_pointer->cache.int_val, ... Incremental and/or background collectors additionally have to track each object's pointer changes (e.g. a PMC reference now points to a different PMC, or all changes to aggregate members) This all imposes a considerable overhead, which isn't faster "normally". leo [ and please hide that mess behind a signature if possible ] > The information contained
