Thought on limiting scope of GC

[Paulo Pinto]

On Friday, 14 February 2014 at 09:01:09 UTC, tcak wrote:
> On Friday, 14 February 2014 at 04:41:43 UTC, Jerry wrote:
>> Hi all,
>>
>> I just had the following thought on limiting the gc in regions.
>> I don't
>> know if this would address some of Manu's concerns, but here 
>> goes:
>>
>> My thought is to have something like the following:
>>
>> GC.track();
>> auto obj = allocateStuff();
>> GC.cleanup(obj);
>>
>> The idea here is that track() tells GC to explicitly track all 
>> objects
>> created from that point until the cleanup call.  The cleanup() 
>> call
>> tells gc to limit its collection to those objects allocated 
>> since the
>> track() call.  The obj parameter tells gc to consider obj live.
>>
>> This way, you can avoid tracking everything that may get 
>> created, but
>> you can limit how much work gets done.
>>
>> Comments? Slams?
>>
>> Jerry
>
> A programmer's aim is to tell computer what to do. Purpose of 
> GC is to help him to prevent problems. In default, AFAIK, GC 
> considers every part of memory in case there are references in 
> them. Well, if the time taking process is scanning all memory, 
> programmer could tell to GC, if he/she trusts about 
> correctness, not to scan some parts of memory to limit scanning 
> area. Example, if I create a char array of 10,000 items, why 
> would I want GC to scan it. I won't put any object references 
> in it for sure.

This only works when you are the only guy on the team and have a 
small codebase to visualize on your head.

The moment a middle size team comes into play, it is chaos.

There is a reason why manual memory managed languages have lost 
their place on the enterprise.

--
Paulo