GC implementation

[Georg Wrede]

Andrew Fedoniouk wrote:
> "Frank Benoit" <frank at nix.de> wrote in message 
> news:dvhkut$541$1 at digitaldaemon.com...
> 
>>The intention of the GC is, to disburden the programmer from the whole
>>memory management. He only has to care about setting unused references
>>to null. And he can rely on the collector to find unused memory chunks.
>>But now it turns out, that this is not true.
>>
>>So, If I want to rely on the GC, this is a show stopper for me.
>>
>>A large piece of audio data in GC heap can completly currupt the GC.
>>If i only have a few integer variable this risk is extremly low, but it
>>is not gone.
>>So, how many variable are allowed, until we have to call it a show 
>>stopper?
> 
> Well said, Frank.
> And very good point.

Yes.

There are two problems with this "audio data". First, it takes quite 
long in the mark phase to scan such a vast data stretch. Second, as 
noted, it contains enough "pointers" to shoot down Air Force One.

>>Sorry, for being so pedantic.
> 
> I think D need some pedantic league around. Thomas is the only one
> gentleman so far who are trying to bring some "ordnung" here.
> Joke. Well, sort of.

Ja, Fritz, Ordnung, aber nur _fast_ überalles.

---

Would it be too hard to have the compiler automatically mark "obvious 
data" as non-scannable?

I mean, stuff gotten from streams or files should never contain pointers 
anyhow. Likewise, the compiler _should_ know whether a large array 
contains pointers or not. If not, then the entire array might be marked 
as non-scannable.

Doing this non-pedantically might gain much speed in GC, without making 
the program itself much slower. In other words, the compiler should not 
bother with _every_ item known not to contain pointers, because this 
would result in a long list of scan/no-scan areas for the GC. But if 
there was a "lower size" or something like it, then this might actually 
work as intended.

Opinions?