5 ms·
Which has been shown time and time again to be the source of many serious software bugs and exploits
by SmooL 7y ago
Which has been shown time and time again to be the source of many serious software bugs and exploits
- soup10 7y agooooo manual memory management scary. the absolute state of web programmers today
- aidenn0 7y agoI have over a decade of professional experience entirely in C and C++. I believe that manual memory management is the wrong choice for the vast majority of applications. It is error prone and often slower than garbage collection.
- soup10 7y agoif you have a decade of C then you know its not slower unless mistakes are made
- p_l 7y agoif you believe that then you have no idea how Garbage Collectors work, period.
- soup10 7y agoPlease explain why half of optimizing java involves statically pre-allocating memory and trying to avoid the automatic memory management then
- TGR44 7y agoThis...isn’t true. Could you give any examples of common use cases and ways that people perform these “optimisations”?
- flukus 7y agoNot necessarily common because garbage collected languages tend to not get used for high performance tasks, but a huge amount of modern optimization is in improving contiguous memory access and avoiding pointer chasing to use CPU cache more effectively, in java allocating arrays of primitives type is about the only way to do that. Similarly in c# they added spans to achieve this with better ergonomics, but both basically come down to avoiding the garbage collector for better performance. Another big one is trying to allocate as much as possible on the stack, either through the language like c/c++/c# or by using local variables and hoping the compiler will do the right thing for you with java. A lot of the work gone into java vm's over the decades have been trying to improve this. Even java sacrifices it's OO purity to make integers and floats value types on the stack, that was to get non-laughable performance. > This...isn’t true. It's not even remotely controversial, saying garbage collection is slower is like saying water is wet.
- mailslot 7y agoSure, if you’re using pre-1990’s memory management. Best practices have evolved far beyond the explicit use of malloc & free and unsafe string handling. Most popular dynamic languages don’t use garbage collection under the hood anyway. In Python and many other runtimes, it’s primarily reference counted.
- ygra 7y agoPython still uses mark and sweep occasionally to clean up structures where reference counting fails.
- mailslot 7y agoIt has optional cycle detection, yep. But... you could also just spend a couple of minutes to not have cyclic references.
- mantap 7y agoClosures are objects that can participate in cycles. And the lifetime of closures is very hard to track statically.
- mailslot 7y agoThey are and they should be used responsibly. I’d argue sparingly also.
- Dylan16807 7y ago"A couple of minutes" Just a little bit overconfident.
- kllrnohj 7y agoPython largely only gets away with ref counting because it doesn't support concurrent access. The GIL means it's basically single-threaded ref counting, which is much cheaper than an actual atomic ref count (like std::shared_ptr) Scattering atomic ref counts everywhere gets extremely expensive very quickly.
- banachtarski 7y agoI'd be willing to wager you use plenty of software, codecs, games, and more that would not function nearly half as well without carefully managed memory.
- Dylan16807 7y agoCarefully managing memory often means using a language feature that handles the bulk for you. Neither manual nor GC. And you can be careful about how you use memory even in the presence of a GC, getting the same kind of optimization without any safety risks. It's not a tradeoff between manual management and "who cares?".