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

On 2/13/14, 8:41 PM, 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

Yah, it's a classic (with the manes "track" -> "mark" and "cleanup" -> "sweep"). Allocators support that already, and installing a global GC should do as well.

Andrei

On Friday, 14 February 2014 at 04:41:43 UTC, Jerry wrote:
> 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.

What if allocateStuff() writes address of some newly allocated object to a field of some old object existing before GC.track()? You can't just scan only objects created after GC.track(), this might create dangling references in the "old generation".

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

How do imagine it to work in multi-core programs? Does it only track thread local allocations?

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

Looks like DIP 46: http://wiki.dlang.org/DIP46
I like the idea.

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.

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:

> On 2/13/14, 8:41 PM, 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
>
> Yah, it's a classic (with the manes "track" -> "mark" and "cleanup" -> "sweep"). Allocators support that already, and installing a global GC should do as well.

I don't follow the global GC comment.  Let's say you're using global GC in general but want to control more tightly what it's doing at a particular region of the code.

Mark looks at all things that have been allocated and possibly live. Track says keep track of objects allocated after the track call, and cleanup only looks at those objects that were recently allocated, ignoring the rest of the heap.

If you're saying that allocators will provide the means of doing this, then that's fine.

On Friday, 14 February 2014 at 11:28:11 UTC, Jerry wrote:
> Track says keep track of objects allocated after the track call, and
> cleanup only looks at those objects that were recently allocated,
> ignoring the rest of the heap.

Track cannot make sure that no reference escapes, therefore cleaning up an object could be a huge error. This would however make sense e.g. inside pure functions.

On 2/14/14, 3:28 AM, Jerry wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:
>> Yah, it's a classic (with the manes "track" -> "mark" and "cleanup" ->
>> "sweep"). Allocators support that already, and installing a global GC should
>> do as well.
>
> I don't follow the global GC comment.  Let's say you're using global GC
> in general but want to control more tightly what it's doing at a
> particular region of the code.
>
> Mark looks at all things that have been allocated and possibly live.

Oh, I think mark/sweep in the "mark/sweep idiom" are different from "mark & sweep garbage collector". I looked for the evidence that the idiom does exist under that name, but apparently I was wrong.

Anyhow, I guess track/cleanup is less confusing.

> Track says keep track of objects allocated after the track call, and
> cleanup only looks at those objects that were recently allocated,
> ignoring the rest of the heap.
>
> If you're saying that allocators will provide the means of doing this,
> then that's fine.

I'm thinking of something like:

MyAllocator alloc = ...;
alloc.installGlobally();
...
alloc.deallocateAll();
alloc.uninstallGlobally();



Andrei

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