Re: GC/DOD feedback & runtime tuning

[Dan Sugalski]

At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:

Ok. Here ist the rest.
- No stackwalk, as already sent by separate #19668, which is included
  if this is a problem for $architecture, please enable
  trace_system_areas in dod.c again - feedback still welcome

I think we're always going to have to walk the stack, no matter how much I'd rather not. It's an expensive walk too, alas.

- a hack to reduce DOD runs by some amount, helping for this test,
  where only allocations happen. If we keep it, it should be reworked
  to have the stats in interpreter and "skip" has to be disabled for
  explict "sweep" calls.

Twiddling the default numbers seems reasonable, though doing it for this one test is silly.

- allocation constants give good results on my systems which might
  probably not apply to yours. In the long run some sself tuning
  will be necessary, we will definitely need lower allocation
  sizes, when e.g such a big allocation is gone, and we have plenty
  of free PMCs - we currently do only increase headers_per_alloc.

Dynamic feedback on the allocation & GC system is definitely in order. We should find a victim^Wvolunteer to do this--it could be a very interesting project.

- statistics need to be reworked, they are only valid after a DOD
  run, though I update num_free_objects now immediately.

Hrm. We should get at least the allocation numbers right, though I do wonder at the impact of keeping buffer/pmc allocation counts. (Yeah, I know, I added that code, as I thought the stats would be useful for GC feedback)
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk