[Issue 3463] Integrate Precise Heap Scanning Into the GC

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Apr 14 19:53:39 PDT 2011


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



--- Comment #120 from Vladimir <thecybershadow at gmail.com> 2011-04-14 19:50:08 PDT ---
(In reply to comment #118)
> > I hope it is as you say it is, but without benchmarks it's hard to say
> > anything, and this talk of state machines etc. is disconcerting.
> 
> Why?

It "sounds" slower. This is subjective and unscientific. That's why I said only
a benchmark will show the real results.

> Also, even if the compiler emits the tables necessary for more precise gc, the
> gc implementation can ignore them and do it the old way. Emitting the tables
> makes it possible for people to experiment with various kinds of gc strategies.

I would like to avoid bloating executables any further, and giving reverse
engineers more data about my code. (I know executable size doesn't affect
performance, at least in theory, but it does matter and can't be completely
neglected either.)

> True, and it works tolerably well. To do a moving gc, however, you need more
> precise information.

I don't want a moving GC. I want a fast GC.

("I" in this context means D users with the same requirements, mainly video
game developers.)

I understand the advantages of a moving GC - heap compaction allowing for an
overall smaller managed heap etc., but I hope you understand that sacrificing
speed for these goals is not an unilateral improvement for everyone.

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


More information about the Digitalmars-d-bugs mailing list