> Results are: > before after > gc_alloc_new.pbc 4.155999 0.18 > > 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.
Okay. I guess I was a bit optimistic with that. The gc_alloc_new statistic above is false. After getting confused when applying this patch to my local safe GC and not seeing an equivalent speedup, I investigated a bit more. Normal allocation sizes are: 45 980 19600 392000 7840000 156800000 With this patch, the allocation sizes are: 980 19600 392000 7840000 0 Obviously, not allocating 156 mb of memory is quite efficient. It also makes me realize that a slower rampup here would probably be a better test. I guess it also raises some suspicion about the other test results. Ah well, we need a fix for our GC problems anyway... Mike Lambert PS: I'm currently operating under the assumption that these kinds of emails are a good thing. There will probably be a lot more in this style, so if you want to change something about how I'm doing this, please let me know.
