>>
>> 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

Many people wants to disable GC to improve performance (if there are other reasons, it is not included here.). If after adding new codes, memory problems start, just disable the GC-disabled-code-parts (as I exampled with that 10,000 item array). This way, errors will disappear and performance may decrease a little. Then fixing can be done to increase performance again.

I think enabling GC for only some parts of code is wrong. It should be disabling it for some parts of code. This way, if programmer loses control of memory, he/she can remove GC-disabling codes, and tada everything works correctly without doing any other changes.

"Paulo Pinto" <pjmlp@progtools.org> writes:

> 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.
>>
>> This way, you can avoid tracking everything that may get created, but you can limit how much work gets done.
>
> How do imagine it to work in multi-core programs? Does it only track thread local allocations?

I think this can be handled by storing the thread that requests tracking, and then each allocation is tracked if it's done from the same thread that requested tracking.  Then cleanup just considers the objects that were tracked.

Am 14.02.2014 16:46, schrieb tcak:
>>>
>>> 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
>
> Many people wants to disable GC to improve performance (if there are
> other reasons, it is not included here.). If after adding new codes,
> memory problems start, just disable the GC-disabled-code-parts (as I
> exampled with that 10,000 item array). This way, errors will disappear
> and performance may decrease a little. Then fixing can be done to
> increase performance again.
>
> I think enabling GC for only some parts of code is wrong. It should be
> disabling it for some parts of code. This way, if programmer loses
> control of memory, he/she can remove GC-disabling codes, and tada
> everything works correctly without doing any other changes.

Again, this example only works when you are the only guy working on the code.

For example, projects of the size of Linux kernel are only viable in languages like C, because there are guys validating every single line of code that gets added to the kernel.

In most projects that is far from truth, everyone just checks whatever they feel like. Then when the thing blows up on the customer and there are high escalation meetings going over, there are a few poor souls,
usually senior developers, going over commit history and using tools like Insure++ to track down the issue.

Sometimes it takes a whole week to track down such culprits.

I don't miss those days.

--
Paulo

"tcak" <tcak@pcak.com> writes:

> Many people wants to disable GC to improve performance (if there are other reasons, it is not included here.). If after adding new codes, memory problems start, just disable the GC-disabled-code-parts (as I exampled with that 10,000 item array). This way, errors will disappear and performance may decrease a little. Then fixing can be done to increase performance again.
>
> I think enabling GC for only some parts of code is wrong. It should be disabling it for some parts of code. This way, if programmer loses control of memory, he/she can remove GC-disabling codes, and tada everything works correctly without doing any other changes.

My proposal was to leave GC enabled for the whole program.  The track and cleanup call pair is intended to narrow the scope of GC in some regions of the code.

"thedeemon" <dlang@thedeemon.com> writes:

> 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".

This is a concern.  Rather than passing a single object into the cleanup, a list of objects to consider live can be passed in.  That would cover at least some of these situations, but not all.

Would it still be useful given this limitation?  Would it give someone looking for tighter control over GC the tools they need?

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:

> On 2/14/14, 3:28 AM, 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.
>>
>> 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();

The difference is that I'd like the ability for some objects to live after the region ends.  I.e. it's reducing the scope of the GC, not temporarily replacing it with a completely separate heap.

On 2/14/14, 8:26 AM, Jerry wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:
>
>> On 2/14/14, 3:28 AM, 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.
>>>
>>> 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();
>
> The difference is that I'd like the ability for some objects to live
> after the region ends.  I.e. it's reducing the scope of the GC, not
> temporarily replacing it with a completely separate heap.

Then I guess you'd need to use two allocators.

Andrei