On 2013-06-01 02:02:53 +0000, Manu <turkeyman@gmail.com> said:

>   * find a solution for deterministic embedded garbage collection

I think reference counting while still continuing to use the current GC to release cycles is the way to go. It wouldn't be too hard to implement.

This could make it realistic to disable the GC entirely in a program if you need everything to be deterministic. The GC could still be of assistance as a debug tool to help find those rogue cycles that shouldn't be there by configuring it to emit logs about what it deallocates.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

In my eyes there is just one reason there is no better GC yet: It requires compiler support.

And thats a huge problem. The number of people who would actually be ablte to make the modifications on the compiler in this community is very small and they tend to not have much time doing it. A really good concurrent GC which properly deals with short lived allocations would need the following compiler support.

1) Callback on pointer write (if the pointer is on the heap)
2) Support for percisley scanning the stack
3) Callback on assignment of __shared or static shared variables
4) Callback on cast to shared
5) Callback on new of a shared object

The only thing the compiler already does support is the RTInfo template which can be used to percisely scan the heap, but thats not enough for a really good GC.

Kind Regards
Benjamin Thaut

On Saturday, June 01, 2013 09:43:49 bearophile wrote:
> >  - GC runs at unpredictable moments
> 
> Is this true? I think the D GC runs only when you allocate something.

Sure, but which of these calls to new is going to cause the GC to run?

auto a = new Foo;
...
auto b = new Bar;
...
auto c = new Baz;

It could be that all or none of them do. It all depends on what memory is available at the time and what exactly they're trying to allocate. So, while you may be able to know that the GC will only run when new is called, you don't know which new will trigger it, and it can (and probably will) vary on each run of the program. Pretty much the only way to control it is to disable the GC and then explicitly do a collection when you can afford a collection to run (though in a program like those Manu typically writes, where you're generating something like 60 frames per second, the GC is pretty much never fast enough to be run - not with anything even vaguely like it's current implementation).

- Jonathan M Davis

On Sat, 01 Jun 2013 07:10:07 -0400, Michel Fortin <michel.fortin@michelf.ca> wrote:

> On 2013-06-01 02:02:53 +0000, Manu <turkeyman@gmail.com> said:
>
>>   * find a solution for deterministic embedded garbage collection
>
> I think reference counting while still continuing to use the current GC to release cycles is the way to go. It wouldn't be too hard to implement.
>

+1

I was going to write this exact post, but you already did :)

-Steve