rust 的内存管理
来源:互联网 发布:软件体系结构风格 编辑:程序博客网 时间:2024/05/16 00:47
在RUST的文档说明中可以看到:
RUST认为引用计数以及其它的收回堆内存在方式存在效率低下及功耗过大方面的问题。因此它默认采用LIFO,即采用栈空间的方式来管理内存。以下为文档原文。
What do other languages do?
Most languages with a garbage collector heap-allocate by default. This means that every value is boxed. There are a number of reasons why this is done, but they’re out of scope for this tutorial. There are some possible optimizations that don’t make it true 100% of the time, too. Rather than relying on the stack andDrop
to clean up memory, the garbage collector deals with the heap instead.
Which to use?
So if the stack is faster and easier to manage, why do we need the heap? A big reason is that Stack-allocation alone means you only have LIFO semantics for reclaiming storage. Heap-allocation is strictly more general, allowing storage to be taken from and returned to the pool in arbitrary order, but at a complexity cost.
Generally, you should prefer stack allocation, and so, Rust stack-allocates by default. The LIFO model of the stack is simpler, at a fundamental level. This has two big impacts: runtime efficiency and semantic impact.
Runtime Efficiency
Managing the memory for the stack is trivial: The machine just increments or decrements a single value, the so-called “stack pointer”. Managing memory for the heap is non-trivial: heap-allocated memory is freed at arbitrary points, and each block of heap-allocated memory can be of arbitrary size, the memory manager must generally work much harder to identify memory for reuse.
If you’d like to dive into this topic in greater detail, this paper is a great introduction.
Semantic impact
Stack-allocation impacts the Rust language itself, and thus the developer’s mental model. The LIFO semantics is what drives how the Rust language handles automatic memory management. Even the deallocation of a uniquely-owned heap-allocated box can be driven by the stack-based LIFO semantics, as discussed throughout this chapter. The flexibility (i.e. expressiveness) of non LIFO-semantics means that in general the compiler cannot automatically infer at compile-time where memory should be freed; it has to rely on dynamic protocols, potentially from outside the language itself, to drive deallocation (reference counting, as used by Rc<T>
and Arc<T>
, is one example of this).
When taken to the extreme, the increased expressive power of heap allocation comes at the cost of either significant runtime support (e.g. in the form of a garbage collector) or significant programmer effort (in the form of explicit memory management calls that require verification not provided by the Rust compiler).
We can make the memory live longer by transferring ownership, sometimes called ‘moving out of the box’. More complex examples will be covered later. ↩
- rust 的内存管理
- rust内存管理
- (转)Rust: Rust的 Deref 运算符
- rust的一些细节
- 调试rust的宏
- 1. rust的优点
- rust的Iterator
- Rust的注释
- Rust 的功能函数
- Rust : 独一无二的Some
- Rust : 高富帅的match
- rust
- (转)Rust:Vec、String 内存布局
- 内存管理--内存的简介
- Rust与D 的PK
- Rust的包管理器Cargo
- rust默认赋值的方法
- rust compile plugin的使用方法
- Java_开源框架_JPinyin汉字转拼音的Java开源库
- GDB技巧整理
- PHPExcel读取excel并导入数据库
- 安卓开发中Theme.AppCompat.Light的解决方法
- Linux TCP服务端接收连接数量突破65535的方法
- rust 的内存管理
- A hard puzzle—1097
- Android Eclipse集成NDK
- arcgis二次开发无法引用 ESRI.ArcGIS.DataSourcesFile解决方法
- SVN上实现代码风格自动检查
- Java中的HashMap和HashTable的不同点
- Android KeyCode列表
- 比较简单的图论最短路+搜索 CF The Two Routes
- fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'