Personally I think memory should be managed by refcounts, and GC only when the cyclic garbage adds up. However adding refcounts is somewhat harder since every state-mutating 'set, 'sref, 'scar, 'scdr, and 'cons needs to decrement the current obj refcount and increment the new obj refcount.
I also suppose that currently the time taken by GC isn't actually very big yet, since all we've been compiling are a few dorky simply bits of Arc code.
One day a student came to Moon and said, "I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons." Moon patiently told the student the following story-
"One day a student came to Moon and said, "I understand how to make a better garbage collector...
hmm, interesting. I'm not really fond of refcounting. It makes FFI or C extensions really hard. That's what I don't like with Python's FFI. You always have to think : "do I have to increment the refcount ? decrement it ? Leace it alone ?" If you don't do it well, you have random bugs. The sad story is that Python makes C programming harder than it already is.
On the opposite, palying with mzscheme's or Lua's FFI is a real pleasure : you don't have to bother with GC. You even have (sometimes) your malloced object collected for you.
But if we can cetnralize the refcount operations in a single (or a very small number) of places, I'm OK... Their talking about stack_push / stack_pop is rather inspiring...
For information : On a GC-relativey-intensive program (mainly calculating (fib 40), which generates a lot of garbage), and with a heap of 50 million possible references, for a total time of 228000 ms, i got the following GC info :
total time : 177ms, nb cycles : 17, max time : 42ms, avg time : 10 ms
That's far from perfect, of course, but it doesn't look so bad to me.
Btw, doctstrings are a real performance killer : they are useless, but are allocated on the heap and fill it up really quick (ah, recursive functions...). We should add something in the code removing immediate values in functions.
> Btw, doctstrings are a real performance killer : they are useless, but are allocated on the heap and fill it up really quick (ah, recursive functions...). We should add something in the code removing immediate values in functions.
Really? You've tried it? Because docstrings are supposed to be removed by the unused global removal step.
> Btw, doctstrings are a real performance killer : they are useless, but are allocated on the heap and fill it up really quick (ah, recursive functions...
Are you saying that you alloc a docstring at every function call?
Well, for the moment, yes. Every object appearing in the program has to be allocated (it's not an optimizing compiler yet). Useless objects are not detected, so every time the compiler sees a string, it generates code to allocate it, and it is freed on the next GC cycle. Every time, you call the function, that code is executed. Well, that's an easy optimisation, so I'll work on it very soon I guess.
Yes, it's not difficult. You just have to find all constant values, create a global var for each constant, assign the const value to the global var and substitute the occurence of the constant with the global var name.
Refcounting performs a lot worse than a generational gc. When dealing with many deep data structures, it becomes more worse. And a simple generational gc is not very hard to implement.
