Thomas Kuehne wrote:
> 
> No. The trick is that this area is collected(and updated by a moving
> GC), but isn't considered while looking for pointers into the "normal"
> area.

I made some experimental changes to add a per-block "scan through" bit to the DMD GC to indicate whether a memory block may contain pointers or not.  It works quite well, but granularity is per block, so if you had something like this:

class C {
    C strong;
    C weak;
}

There is no way to tell the GC to simply ignore the weak reference--it's all or nothing.


Sean

Walter Bright wrote:
> Yes, it is a hack, and an awful one. I think Frits and Thomas have it right in suggesting support for a 'weak pointer' that the GC updates for moves, but doesn't scan for roots.

Don't forget it should be nulled when the object is deleted[1]. Otherwise you have a pointer that's valid for the lifetime of the object but dangles around afterwards.


[1] This may be trickier than it seems.
The most only way I can think of that works for deletion by user and by any GC[2] would probably be to keep track of which weak pointers point to an object in the object itself.
Java probably has it a bit easier in this regard, since it doesn't have a 'delete' statement. If you only need to worry about the GC, it's possible to make sure the GC deletes objects only after scanning everything while keeping a list of weak pointers found. Though I'm not sure how Java implementations do this, just guessing here.

[2] Maybe a specific GC can make this easier? I don't know, but I don't think so. I think 'manual' deletions are probably the hardest to deal with.

Miles wrote:
> 
> Am I the only one who is screaming "OMG! What a hack!" while reading
> this thread?
> 
> Sincerely, my impression of D dropped 2 points after reading the
> proposed solutions on this thread.

How rude.

Perhaps you have a better solution or reasons why these solutions shouldn't be implemented.  Do share that information.  These insults, however, are not helpful.

> But how can you tell if _ptr is valid or not? If you can't, it's pretty useless, as you can never safely dereference it...

Check my other post. There, I've declared an interface IOnDelete with 1 method OnDelete. The pointer-wrapper implements the interface and sets its pointer to null. The objects pointed-to would have to keep a list of IOnDelete's, though.

L.

Georg Wrede wrote:
> Having instead an external entity to handle SS reduces drastically the number of needed connections.

Having a global entity do this has some advantages, but some significant disadvantages. The biggest is handling things in the presence of DLLs and shared libraries.

Walter Bright wrote:
> Georg Wrede wrote:
> 
>> Having instead an external entity to handle SS reduces drastically the number of needed connections.
> 
> 
> Having a global entity do this has some advantages, but some significant disadvantages. The biggest is handling things in the presence of DLLs and shared libraries.

Ehh, "does not compute: add information"!

I'm not pursuing a global entity for it's own sake, I just can't see any other way to reduce the number of interconnections.

And, especially, I wouldn't ever have expected to see it as a disadvantage with DLLs. (Or SLs.)

Please enlighten.

Georg Wrede wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>
>>> Having instead an external entity to handle SS reduces drastically the number of needed connections.
>>
>>
>> Having a global entity do this has some advantages, but some significant disadvantages. The biggest is handling things in the presence of DLLs and shared libraries.
> 
> Ehh, "does not compute: add information"!
> 
> I'm not pursuing a global entity for it's own sake, I just can't see any other way to reduce the number of interconnections.
> 
> And, especially, I wouldn't ever have expected to see it as a disadvantage with DLLs. (Or SLs.)
> 
> Please enlighten.

An external entity would be a global, singleton, entity. Since DLLs (and shared libraries) might be shared with other languages, they'll need their own global entity. But if there are multiple D DLLs, then there are multiple global entities. Who's in charge? Fixing this is not impossible, it's just added complexity and risk of bugs, and I'm not sure it will reduce interconnections anyway (because it'll need a fast reverse lookup anyway).

Sean Kelly wrote:
> Thomas Kuehne wrote:
>>
>> No. The trick is that this area is collected(and updated by a moving
>> GC), but isn't considered while looking for pointers into the "normal"
>> area.
> 
> I made some experimental changes to add a per-block "scan through" bit to the DMD GC to indicate whether a memory block may contain pointers or not.  It works quite well, but granularity is per block, so if you had something like this:
> 
> class C {
>     C strong;
>     C weak;
> }
> 
> There is no way to tell the GC to simply ignore the weak reference--it's all or nothing.
> 
> 
> Sean

Cool, I'm interested in a patch! What are you using by the way, sizeof<4? Or something smarter? Even a simple sizeof would suffice for me; at least it'll prevent the GC scanning strings and such.

L.

Lionello Lunesu wrote:
> Sean Kelly wrote:
>> Thomas Kuehne wrote:
>>>
>>> No. The trick is that this area is collected(and updated by a moving
>>> GC), but isn't considered while looking for pointers into the "normal"
>>> area.
>>
>> I made some experimental changes to add a per-block "scan through" bit to the DMD GC to indicate whether a memory block may contain pointers or not.  It works quite well, but granularity is per block, so if you had something like this:
>>
>> class C {
>>     C strong;
>>     C weak;
>> }
>>
>> There is no way to tell the GC to simply ignore the weak reference--it's all or nothing.
> 
> Cool, I'm interested in a patch! What are you using by the way, sizeof<4? Or something smarter? Even a simple sizeof would suffice for me; at least it'll prevent the GC scanning strings and such.

Less than (void*).sizeof, which equates to the same thing.  I'll try to find the time to get a patch off to Walter.


Sean