Andrew Fedoniouk wrote:
> 
> Speaking about server side.
> In fact it should be no GC in common sense there.
> Memory allocation in execution of some request shall be done in
> memory pool. Such pool (raw memory chunk) can be dropped at the end
> of request in the whole - without any dtors and the like.
> Sort of Apache memory pools.

I think we're stuck with using the GC for built-in features, ie. dynamic arrays and AAs.  But this shouldn't amount to a tremendous percentage of allocated space in server apps.


Sean

Don Clugston wrote:
> Frank Benoit wrote:
>> MicroWizard schrieb:
>>> As far as I know the D GC can be replaced.
>>> There are many GC theories and I think most of them can not be corrupted with
>>> garbage. (They handle with working sets, aging and so on.)
>>>
>>> The problem is not a problem IMHO
>>
>> Yes, you can exchange the gc. But at the moment we have this
>> implementation, a conservative one. And as non-compiler-implementor I
>> cannot change the gc from conservative to precise, because the interface
>> lacks of the reference information.
>>
>> In serveral papers i red that it is not possible to make a gc, that is
>> optimal for all applications.
>>
>> This said, it would be a good thing to have an open standard to
>> integrate own GC implementations. This can help D in various ways.
>> - Multiple implementations can show the advantages of each way
>> - Each application can tune the used GC.
>> - Special solutions for special cases are possible (e.g. realtime,
>> gaming, secure applications)
>> - The D community can contribute to the GC implementation work
>> - D can become a GC laboratory :)
>>
>> The current interface serves only for a stop-the-world conservative GC
>> implementations. Other implementations require some kind of compiler
>> assistance. e.g. read/write barrier, information about position of
>> references, sychronisation points,  etc.
>>
>> For an interface which should serve for many possible GCs, it should support
>> - stop-the-world, incremental, concurrent
>> - copying, mark-sweep
>> - moving, non-moving
>> - generational GC
>> - ??? Building Objects out of blocks => no fragmentation ???
> 
> Have you had a look at Sean's work in Ares? He's been addressing this very issue.

The big missing piece at this point is a way to tell the GC what portions of allocated memory may contain pointers.  Some of this will require improved RAII, but some could be done now.  I've been considering adding an additional parameter or two to gc.malloc, gc.calloc, and gc.realloc to pass this information.  But since it would also require modifications to the GC (with which I'm not entirely familiar) I haven't done so yet.


Sean

Andrew Fedoniouk wrote:
> "Frank Benoit" <frank@nix.de> wrote in message news:dvhkut$541$1@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?

Georg Wrede wrote:
> 
> 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.

I think someone actually wrote a GC patch a while back that did this, so it's definitely possible with D as-is.  I would like to see this done in Phobos before 1.0, and it's on my mental to-do list for Ares as well.


Sean