Re: Strong/weak pointers

On Sep 2, 3:32 pm, torb...@pc-003.diku.dk (Torben Fgidius Mogensen)
wrote:
> Michiel Helvensteijn <m.helvenste...@gmail.com> writes:
> > We are aware of the fact that this does not completely eliminate
> > memory leaks, since the pointers can indirectly reference
> > themselves. We're not sure what to do about this. We may leave it to
> > the programmer to avoid. Or we may actually try to find isolated
> > cycles at any pointer de/re-allocation (but only in debug mode, of
> > course).
>
> Why not use a better garbage collection method? Reference counting is
> slow and (as you say) does not handle cycles. A simple and reasonably
> fast GC is the two-space stop-and-copy. It can move objects around,
> so you should not allow comparison of pointers except for equality
> (i.e., avoid < and similar operators) and avoid casting integers to
> pointers and vice-versa.


I read this paper
http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf,
which seems to claim that a pretty efficient GC can be made that
handles cyclic dependencies.


Having only been exposed to java's different GCs, I've come to dread
the deferred collection of hundreds of Mb when a full GC finally feel
it's time to kick in. I believe that most of the time its better to
have a higher average GC cost, than having a lower _average_ time
spent in GC where the a single pause still can be long enough to cause
an animation to stutter.


Working with IntelliJ IDEA, I sometimes have it freeze for around 30
seconds while GC-ing something on the order of 400 Mb. From this and
other java apps as well as my own work it is obvious that selecting
the optimal tracing GC and GC-settings to use is not trivial. So if I
could choose between something a bit slower but more predictable
versus (on average) fast but unpredictable, I think most applications
would prefer the former.


That's why I wonder if reference counting isn't worth considering,
even with the obvious drawbacks.

Return to the comp.compilers page.
Search the comp.compilers archives again.