[Issue 3463] Integrate Precise Heap Scanning Into the GC

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #48 from Leandro Lucarella <llucax at gmail.com> 2010-07-25 17:04:56 PDT ---
Well timings for dil are much worse :(

This is dil generating the Tango docs, without precise scanning (dmd with the
last patch, Tango unpatched):
52.01
53.73
52.21
51.79
50.58
52.62
53.01
48.49
51.51
49.68

min  = 48.49
mean = 51.563, std = 1.58236847795
max  = 53.73

And this is with precise scanning:
79.47
69.81
72.27
67.12
68.34
83.85
65.28
75.17
77.76
74.73

min  = 65.28
mean = 73.38, std = 5.91698309013
max  = 83.85

I can't explain why is even less stable with precise scanning, maybe is
something to do with it being less cache-friendly. I don't know either why is
so stable without precise scanning, when in other tests I've done it wasn't
like that. Maybe the majority of false positives are from the static memory and
the binary was placed in an address that make them less probable (the binary
address doesn't change between runs).

It would be nice if other people give this patches a try, specially with
programs that have problems with false positives...

Here are the profiling results (using perf[1]):
Non-precise scanning: http://pastebin.com/zRKyc9mW
Precise scanning:     http://pastebin.com/jPJZLL8p

It looks like findPool() might be used much more often than before? For
example, I noticed the mixin code calls findPool() very early, so maybe it's
being called in some situations where it's not necessary. Also, with the patch
sizeOf() needs to call findPool(), but I don't think that should make a lot of
difference (unless is used by the runtime very often for array manipulation).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------