== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
> I think our community will be rid of a major hurdle once we get past the
> debate on whether precise GC is necessary. Precise GC is necessary,
> there's no two ways about it. We should worry about implementing, not
> debating, it.
> Andrei

while(1) {
    vote++;
}

Needless to say, I'm quite frustrated that I implemented precise heap scanning almost two **years** ago and it's gone basically nowhere.  Admittedly there were some unresolved plumbing issues with regard to getting the relevant type info to the GC from the new operator, etc. but it actually worked for memory allocated via GC.malloc and there were tests to back it up.

There are soft realtime GCs like you describe, but I believe they're all incremental. I don't know that approach is compatible with D.

Sent from my iPhone

On Aug 31, 2011, at 10:35 PM, Josh Simmons <simmons.44@gmail.com> wrote:

> On Thu, Sep 1, 2011 at 3:23 PM, Walter Bright <newshound2@digitalmars.com> wrote:
>> 
>> And note that if you've got hard real time constraints, you cannot even use malloc/free, as they do not run in bounded time.
>> 
> 
> They're generally avoided in game code anyway because they're slow.
> 
> Games don't have hard real time constraints though in the strictest sense, but you have a fixed budget with which to work all game logic and rendering having the GC kick in at the wrong time or run a bit longer than expected can lead to very nasty frame drops. You really need to be able to say when you want the GC to run, and how long you're willing to give it to execute.

Yup. I want to revisit CDGC to see if it's up to snuff as the default GC. It already supports precise scanning, so perhaps the rest can be sorted via library code: create!T(...)

Sent from my iPhone

On Sep 1, 2011, at 7:56 AM, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
>> I think our community will be rid of a major hurdle once we get past the
>> debate on whether precise GC is necessary. Precise GC is necessary,
>> there's no two ways about it. We should worry about implementing, not
>> debating, it.
>> Andrei
> 
> while(1) {
>    vote++;
> }
> 
> Needless to say, I'm quite frustrated that I implemented precise heap scanning almost two **years** ago and it's gone basically nowhere.  Admittedly there were some unresolved plumbing issues with regard to getting the relevant type info to the GC from the new operator, etc. but it actually worked for memory allocated via GC.malloc and there were tests to back it up.

On 01-09-2011 16:42, Andrei Alexandrescu wrote:
> On 09/01/2011 12:23 AM, Walter Bright wrote:
>> On 8/31/2011 9:58 AM, Benjamin Thaut wrote:
>>> Currently there is no way to track the references or pointers on the
>>> stack
>>> because the language does not include such a feature, nor can it be
>>> build with
>>> any of the language provided mechanisms.
>>
>> The trouble with precise GC is that all the type info consumes a large
>> amount of memory.
>
> I think our community will be rid of a major hurdle once we get past the
> debate on whether precise GC is necessary. Precise GC is necessary,
> there's no two ways about it. We should worry about implementing, not
> debating, it.
>
> Andrei

And honestly, the memory footprint for the type info is negligible with the amount of memory available today, especially as D is going towards x86-64 support.

- Alex

On 8/30/2011 5:01 PM, Sean Kelly wrote:
> I'd like to say that the 'shared' attribute on member functions should just
> mean "make this member visible through a shared reference" and do away with
> the memory barriers idea entirely, except that D really does need some form
> of atomics.  I'm really not sure what the solution is here.

I'm tending to agree that shared should no longer imply memory barriers.

On Thu, 01 Sep 2011 11:46:32 -0400, Sean Kelly <sean@invisibleduck.org> wrote:
> Yup. I want to revisit CDGC to see if it's up to snuff as the default GC. It already supports precise scanning, so perhaps the rest can be sorted via library code: create!T(...)
>
> Sent from my iPhone
>

Default on *nix you mean, as CDGC sadly doesn't support windows.

On Thu, 01 Sep 2011 10:56:27 -0400, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
>> I think our community will be rid of a major hurdle once we get past the
>> debate on whether precise GC is necessary. Precise GC is necessary,
>> there's no two ways about it. We should worry about implementing, not
>> debating, it.
>> Andrei
>
> while(1) {
>     vote++;
> }
>
> Needless to say, I'm quite frustrated that I implemented precise heap scanning
> almost two **years** ago and it's gone basically nowhere.  Admittedly there were
> some unresolved plumbing issues with regard to getting the relevant type info to
> the GC from the new operator, etc. but it actually worked for memory allocated via
> GC.malloc and there were tests to back it up.
>

Make that

while(1) {
    vote +=2 ;
}

On Sep 1, 2011, at 7:57 PM, Robert Jacques wrote:

> On Thu, 01 Sep 2011 11:46:32 -0400, Sean Kelly <sean@invisibleduck.org> wrote:
>> Yup. I want to revisit CDGC to see if it's up to snuff as the default GC. It already supports precise scanning, so perhaps the rest can be sorted via library code: create!T(...)
> 
> Default on *nix you mean, as CDGC sadly doesn't support windows.

It should.  It just won't be able to use its fork-based speedup.  That should still have it run on par with the GC we use today.  If there are any actual problems running on Windows, they shouldn't be too hard to fix.

On Fri, 02 Sep 2011 13:34:12 -0400, Sean Kelly <sean@invisibleduck.org> wrote:

> On Sep 1, 2011, at 7:57 PM, Robert Jacques wrote:
>
>> On Thu, 01 Sep 2011 11:46:32 -0400, Sean Kelly <sean@invisibleduck.org> wrote:
>>> Yup. I want to revisit CDGC to see if it's up to snuff as the default GC. It already supports precise scanning, so perhaps the rest can be sorted via library code: create!T(...)
>>
>> Default on *nix you mean, as CDGC sadly doesn't support windows.
>
> It should.  It just won't be able to use its fork-based speedup.  That should still have it run on par with the GC we use today.  If there are any actual problems running on Windows, they shouldn't be too hard to fix.

Well, it would be a concurrent GC on Linux and (after patching) parallel(?) GC on Windows. So, I take your point that a lot of code could be re-used/shared between the two OSes.