auto classes and finalizers

[Bruno Medeiros]

Sean Kelly wrote:
> Bruno Medeiros wrote:
>>
>> What we want is an allocator that allocates memory that is not to be 
>> claimed by the GC (but which is to be scanned by the GC). It's 
>> behavior is exactly like the allocator of 
>> http://www.digitalmars.com/d/memory.html#newdelete but it should come 
>> with the language and be available for all types. With usage like:
>>
>>   class LinkedList {
>>     ...
>>     Add(Object obj) {
>>       Node node = mnew Node(blabla);
>>       ...
>>     }
>>
>> Thus, when the destructor is called upon a LinkedList, either 
>> explicitly, or by the GC, the Node references will always be valid. 
>> One has to be careful now, as mnew'ed object are effectively under 
>> manual memory management, and so every mnew must have a corresponding 
>> delete, lest there be dangling pointer ou memory leaks. Nonetheless it 
>> seems to be only sane solution to this problem.
> 
> This does seem to be the most reasonable method.  In fact, it could be 
> done now without the addition of new keywords by adding two new GC 
> functions: release and reclaim (bad names, but they're all I could think 
> of).  'release' would tell the GC not to automatically finalize or 
> delete the memory block, as you've suggested above, and 'reclaim' would 
> transfer ownership back to the GC.  It's more error prone than I'd like, 
> but also perhaps the most reasonable.
> 

Hum, indeed.

> A possible alternative would be for the GC to peform its cleanup in two 
> stages.  The first sweep runs all finalizers on orphaned objects, and 
> the second releases the memory.  Thus in Eric's example on d.D.learn, he 
> would be able legally iterate across his AA and close all HANDLEs 
> because the memory would still be valid at that stage.
> 

By orphaned objects, do you mean all objects that are to be reclaimed by 
the GC on that cycle? Or just the subset of those objects, that are not 
referenced by anyone?

> Assuming there aren't any problems with this latter idea, I think it 
> should be implemented as standard behavior for the GC, and the former 
> idea should be provided as an option.  Thus the user would have complete 
> manual control available when needed, but more foolproof basic behavior 
> for simpler situations.
> 
>> Another interesting addition, is to extend the concept of auto to 
>> class members. Just as currently auto couples the lifecycle of a 
>> variable to the enclosing function, an auto class member would couple 
>> the lifecycle of its member to it's owner object. It would get deleted 
>> implicitly when then owner object got deleted. Here is another (made 
>> up) example:
>>
>>   class SomeUIWidget {
>>     auto Color fgcolor;
>>     auto Color bgcolor;
>>     auto Size size;
>>     auto Image image;
>>     ...
>>
>> The auto members would then have to be initialized on a constructor or 
>> something (the exact restrictions might vary, such as being final or 
>> not).
> 
> I like this idea as well, though it may require some additional 
> bookkeeping to accomplish.  For example, a GC scan may encounter the 
> members before the owner, so each member may need to contain a hidden 
> pointer to the owner object so the GC knows how to sort things out.
> 
> 
> Sean

Hum, true, it would need some additional bookkeeping, didn't realize 
that immediately. The semantics like those that I mentioned in me 
previous post would suffice:

"When a destructor is called upon an object during a GC (i.e., "as a 
finalizer"), then the member references are not valid and cannot be 
referenced, *but they can be deleted*. Each will be deleted iff it has 
not been deleted already in the reclaiming phase."

I don't think your algorithm (having a hidden pointer) would be 
necessary (or even feasible), and the one I mentioned before would suffice.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D