3 ms·

> Caml uses non-deterministic garbage collection, whereas python mostly uses reference counting (in CPython). This is another case where the first system was sa

by copx 12y ago

> Caml uses non-deterministic garbage collection, whereas python mostly uses reference counting (in CPython). This is another case where the first system was safer in one aspect. I certainly would not call CPython's memory management approach "safer" [1]. As you can see, CPython has a nice accidental memory leak trap door there, OCaml does not. Also I see little value in partially deterministic memory management like in the case of CPython's ref-counting + GC combo. [1] http://stackoverflow.com/questions/8025888/does-python-gc-deal-with-reference-cycles-like-this http://stackoverflow.com/questions/8025888/does-python-gc-de...

illumen 12y ago
That is not even a problem in python. You've pointed out One strange case with cyclic references, that can be garbage collected by the optional garbage collector that is enabled by default. You can even test to see if there are cycles with the garbage collector and remove the cycles if you want (making it more sane, and deterministic in the process). The linked page even shows how you can detect the cycle with python, and then remove it. So by default this wouldn't be a problem in python. Also, in a production system which actually tests their code for cycles, this would not be a problem in python with the GC turned off. In practice I've found it useful to avoid many types of weird behaviour that GC systems have. Where you often need to tweak the GC so it behaves nicely with your system. These pathological non-deterministic behaviours are often just not there with ref counting. How many java or rails articles have you seen where they talk about adjusting the GC so the apps don't blow up? GC is also the enemy of fast. But not in the throughput way that many people measure it. Instead in the latency way. Where if you have GC it can take longer to process a request, due to the non-deterministic behaviour. This is noticeable in many Java systems that stop for a second to collect occasionally. If you're in a real-ish time system, then using GC or allocating memory is slow. If every 100th web request takes 1 second, or you get janky animations, or occasionally take too long to respond to user input, then that is a broken program in those domains. The linux kernel, QT, and Objective C automatic reference counting are much better forms of reference counting. The CPython one isn't the best, but still does give you some of the benefits. CPython does have memory pools and reference counting, which means if you are very careful you can avoid pathological cases of memory allocation in a deterministic way. You can also more easily manage memory manually if you need to. Since once you remove all references to an object it is free'd immediately. With GC, how do you know the 3GB object is freed now, or in 1 second? Will that cause swapping to happen? What about with the next version of INSERT_GC_LANG that changes the GC behaviour?

by copx 12y ago

illumen 12y ago

That is not even a problem in python. You've pointed out One strange case with cyclic references, that can be garbage collected by the optional garbage collector that is enabled by default. You can even test to see if there are cycles with the garbage collector and remove the cycles if you want (making it more sane, and deterministic in the process). The linked page even shows how you can detect the cycle with python, and then remove it. So by default this wouldn't be a problem in python. Also, in a production system which actually tests their code for cycles, this would not be a problem in python with the GC turned off. In practice I've found it useful to avoid many types of weird behaviour that GC systems have. Where you often need to tweak the GC so it behaves nicely with your system. These pathological non-deterministic behaviours are often just not there with ref counting. How many java or rails articles have you seen where they talk about adjusting the GC so the apps don't blow up? GC is also the enemy of fast. But not in the throughput way that many people measure it. Instead in the latency way. Where if you have GC it can take longer to process a request, due to the non-deterministic behaviour. This is noticeable in many Java systems that stop for a second to collect occasionally. If you're in a real-ish time system, then using GC or allocating memory is slow. If every 100th web request takes 1 second, or you get janky animations, or occasionally take too long to respond to user input, then that is a broken program in those domains. The linux kernel, QT, and Objective C automatic reference counting are much better forms of reference counting. The CPython one isn't the best, but still does give you some of the benefits. CPython does have memory pools and reference counting, which means if you are very careful you can avoid pathological cases of memory allocation in a deterministic way. You can also more easily manage memory manually if you need to. Since once you remove all references to an object it is free'd immediately. With GC, how do you know the 3GB object is freed now, or in 1 second? Will that cause swapping to happen? What about with the next version of INSERT_GC_LANG that changes the GC behaviour?