Naive: a new GC implementation

Hi Luca!

I appreciate the contribution, but I'm a bit curious as to what should be the reasoning for including it in Tango. What is the use case?

I understand that the naive GC is good for understanding GC mechanics, but is there a "real" program that would benefit from using it? The current GC in Tango is already considered basic, so a naive one doesn't appear to add much.

Also, with the inclusion of more GC's, there would preferably have to be a mechanism in place to easily choose one or the other.

Replying to larsivi:

Hi Luca!

Hi, Lars!

I'm sorry for the delay, I never received the e-mail notification on the reply to the bug-report, I guess my anti-spam eat it... =/

I appreciate the contribution, but I'm a bit curious as to what should be the reasoning for including it in Tango. What is the use case?

I think none.

I understand that the naive GC is good for understanding GC mechanics, but is there a "real" program that would benefit from using it?

I don't think so. I've implemented it merely as documentation. I guess including it in Tango has as much sense as including any other kind of documentation.

The current GC in Tango is already considered basic, so a naive one doesn't appear to add much.

Well, I think the current GC has a simple design, but a complicated implementation. It's really hard to figure out how to write a GC that complies with the Tango interface taking into account all the quirks to be correctly plugged into the runtime (I think the "stub" GC doesn't help with that either).

I'm planning to rewrite the basic GC too, but even if I do that, the implementation has to be optimized, so it will be harder to understand than the Naive GC. The memory layout of the basic GC is not that simple either (is not too complicated, that's true). This is not the case for the Naive GC, which can be horrible in terms of performance and have a trivial memory layout so focus can be made only in the "artifacts" needed to write a new GC implementation.

Also, with the inclusion of more GC's, there would preferably have to be a mechanism in place to easily choose one or the other.

I agree on that. The current mechanism is a little clumsy. Unfortunately I don't have much time to do that now, but who knows, maybe when I'd have to start benchmarking and have to switch frequently between implementation it can take me less time to implement a way to make easier to switch between GC implementations than recompiling all the runtime each time =)

BTW, the version in the git repo has a couple of bug fixes.

I was quite busy, but I hope to look at it soon. I thinkt that it will be really interesting when it will be multithreaded, even if naive.

This naive implementation will stay as it is now. Well, not really, I'll add code to get some interesting statistics about the GC. I plan to do this for the Basic GC too, then rewrite the Basic GC to clean it up a little and finally I will make the Basic GC concurrent (that's the plan at least =).

There is some obscure bug in this implementation that I can't find. There seems to be loosing references to live data for some reason. I've invested too many time on it without success and, since its utility is very limited, I don't think I will dig into it in a near future.

I don't think 2.0 is very near, but I think I should clarify that just in case ;)

ok, thanks for the update :)

The naive collector was abandoned so I don't think there is any use on keeping this issue open.