5 added 639 characters in body
source | link

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

Just speaking very theoretically and disregarding issues like some GC implementations slowing things down during their collection cycles, the biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Another case I can think of where it might be preferable to force GC on a team is for a very short-lived program, like just something executed from the command line which does one task and then shuts down. In that case the program's lifetime is too short to make any sort of logical leak non-trivial. Logical leaks, even for big resources, usually only become problematic hours or minutes after running the software, so a software that is only intended to be executed for 3 seconds is unlikely to ever have problems with logical leaks, and it could make things a lot simpler to write such short-lived programs if the team just used GC.

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

Just speaking very theoretically and disregarding issues like some GC implementations slowing things down during their collection cycles, the biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

Just speaking very theoretically and disregarding issues like some GC implementations slowing things down during their collection cycles, the biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Another case I can think of where it might be preferable to force GC on a team is for a very short-lived program, like just something executed from the command line which does one task and then shuts down. In that case the program's lifetime is too short to make any sort of logical leak non-trivial. Logical leaks, even for big resources, usually only become problematic hours or minutes after running the software, so a software that is only intended to be executed for 3 seconds is unlikely to ever have problems with logical leaks, and it could make things a lot simpler to write such short-lived programs if the team just used GC.

4 added 129 characters in body
source | link

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

TheJust speaking very theoretically and disregarding issues like some GC implementations slowing things down during their collection cycles, the biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

The biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

Just speaking very theoretically and disregarding issues like some GC implementations slowing things down during their collection cycles, the biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

3 added 192 characters in body
source | link

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

The biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they have that effectleak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection?

The biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they have that effect. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

Can you tell me in what sort of scenario it is actually a good or reasonable idea to force garbage collection? I'm not asking for C# specific cases but rather, all programing languages that have a garbage collector. I know that you can't force GC on all languages, like Java, but let's suppose you can.

The biggest scenario I can think of to force garbage collection is a mission-critical software where logical leaks are preferable to dangling pointer crashes, e.g., because crashing at unexpected times might cost human lives or something of this sort.

If you look at some of the shoddier indie games written using GC languages like Flash games, they leak like crazy but they don't crash. They might take ten times the memory 20 minutes into playing the game because some part of the game's codebase forgot to set a reference to null or remove it from a list, and the frame rates might start to suffer, but the game still works. A similar game written using shoddy C or C++ coding might crash as a result of accessing dangling pointers as a result of the same type of resource management mistake, but it wouldn't leak so much.

For games the crash might be preferable in the sense that it can be quickly detected and fixed, but for a mission-critical program, crashing at totally unexpected times might kill somebody. So the main cases I think would be scenarios where not crashing or some other forms are security are absolutely critical, and a logical leak is a relatively trivial thing in comparison.

The main scenario where I think it's bad to force GC is for things where the logical leak is actually less preferable than a crash. With games, for example, the crash won't necessarily kill anyone and it might be easily caught and fixed during internal testing, whereas a logical leak might go unnoticed even after the product ships unless it's so severe that it makes the game unplayable within minutes. In some domains an easily-reproducible crash that occurs in testing is sometimes preferable to a leak that no one notices immediately.

2 added 135 characters in body
source | link
1
source | link