Thought on limiting scope of GC

[Paulo Pinto]

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