Timeline for Why don't compilers automatically insert deallocations?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 16, 2017 at 10:26 | comment | added | Graham | @Raphael I've explained a well-recognised problem with the principle of garbage collection, which is (or should be) taught in CS as one of its basic disadvantages. I've even given my personal experience of having seen this in practise, to show that it is not a purely theoretical problem. If you failed to understand something about this, I'm happy to talk to you to improve your knowledge of the subject. | |
| Jan 14, 2017 at 12:59 | comment | added | Raphael | I fail to see how this attempts to answer the (CS part of the) question. | |
| Jan 13, 2017 at 23:17 | comment | added | supercat | The "delay" in when memory gets freed up is more of a problem in a virtual-memory system than in a system with limited resources. In the former case, it may be better for a program to use 100MB than 200MB even if the system has 200MB available, but in the latter case there will be no benefit to running the GC earlier than needed unless delays would be more acceptable during some parts of the code than during others. | |
| Jan 13, 2017 at 12:22 | comment | added | Konrad Rudolph | @adrianN But in practice this isn’t done because it would be mental. Graham’s point still stands: GCs always incur a substantial overhead, either in terms of runtime or in terms of required surplus memory. You can tweak this balance towards either extreme but you fundamentally cannot remove the overhead. | |
| Jan 13, 2017 at 12:15 | review | First posts | |||
| Jan 13, 2017 at 15:50 | |||||
| Jan 13, 2017 at 12:14 | comment | added | adrianN | You could in theory run a GC before every allocation. | |
| Jan 13, 2017 at 12:11 | history | answered | Graham | CC BY-SA 3.0 |