AdeptLanguage / Adept

The Adept Programming Language
GNU General Public License v3.0
120 stars 8 forks source link

What is so broken about the current memory management model? #307

Closed ghost closed 6 months ago

ghost commented 6 months ago

That you want to switch to a new model? Please elaborate.

I admit I have never mastered the current ownership based memory management model. I have never seriously learned it, though.

Related:

https://github.com/AdeptLanguage/Adept/issues/279

https://github.com/AdeptLanguage/Adept/issues/295

IsaacShelton commented 6 months ago

The current "runtime ownership-based" memory management model is "broken" in a few ways.

  1. The runtime-based ownership that most of the standard library uses is very prone to errors and mis-use (even if you know what you're doing). It's extremely easy to accidentally forget to .commit() or .clone() a value. And when you do, you might not even notice.

  2. It can (and has) led to memory vulnerabilities and heisenbugs that are very difficult to debug. There is no error message for improper use. Debugging improper use is very difficult as there is no proper debugger or address sanitization support.

  3. It's runtime based, and you might not even realize that your application has a memory bug in it because you never tested it with a particular set of inputs that cause the ownership to be transferred implicitly in unexpected ways. It might work perfectly fine when you run it on one set of inputs, but crash on another (because of improper ownership management).

  4. It's a leaky abstraction. If you create a type that contains a type that has runtime-based ownership, your new type must accommodate it by defining methods to properly interact with its ownership (if you wish to be able to transfer values of the new type to different lifetimes). There's also the issue of shallow vs deep cloning which clone() methods are not guaranteed to be consistent.

  5. It's nearly impossible to comprehend all possibilities of ownership that can exist at runtime, and failing to account for one configuration can lead to unexpected consequences (crashes, bugs, vulnerabilities, etc.).

  6. It's a pain to use. You have to always be thinking about possible ownerships a value can have and how to you to accept/pass them around. It's effectively reference counting with a limit of 1 strong reference.

  7. Referencing freed memory by accident is very easy (and you might not even notice it). It's extremely easy to reference memory through a weak ownership reference to memory that has been freed. This can lead to so many issues such as those already described (incorrect behavior, crashes, bugs, vulnerabilities, etc.).

I could go on, but I think runtime ownership-based memory management is quite possibly one of the worst models, at least without proper compile-time checks which are very hard to do, and would require very tight integration with the compiler.

ghost commented 6 months ago

Thanks for your very detailed explanation.

ghost commented 6 months ago

https://github.com/AdeptLanguage/Adept/issues/313 https://github.com/AdeptLanguage/Adept/issues/312