boost::pool 实际内存分配
boost::pool real memory allocations
我正在尝试使用来自 #include "boost/pool/pool.hpp"
的 boost::pool
内存池。
我想检查 boost::pool
分配了多少内存,所以我 运行 命令 system("ps aux | grep myProgramExe | grep -v grep | awk '{print }'");
给了我(来自 ps
手册页) VSZ - virtual memory size of the process in KiB (1024-byte units). Device mappings are currently excluded; this is subject to change. (alias vsize).
我遇到了一些奇怪的事情:
代码(代码缩进 4 个空格,再加上 4 个空格,因为它嵌入在列表中)
int main()
{
{
boost::pool<> pool(4, 1);
system("ps aux | grep boostHash | grep -v grep | awk '{print \"1. \" }'");
void *a = pool.malloc();
pool.free(a);
system("ps aux | grep boostHash | grep -v grep | awk '{print \"2. \" }'");
}
system("ps aux | grep boostHash | grep -v grep | awk '{print \"3. \" }'");
}
输出为:
1. 18908
2. 19040
3. 19040
这很奇怪,因为:
一个。我只想分配 4 个字节(next allocation
应该只有 1 个实例)。
b.当块结束并且 pool
已死时,内存不会被释放。
现在我想分配大小为128的实例,我想在下一次分配时这样分配1024:
int main()
{
{
boost::pool<> pool(128, 1024);
system("ps aux | grep boostHash | grep -v grep | awk '{print \"4. \" }'");
void *a = pool.malloc();
pool.free(a);
system("ps aux | grep boostHash | grep -v grep | awk '{print \"5. \" }'");
}
system("ps aux | grep boostHash | grep -v grep | awk '{print \"6. \" }'");
}
输出:
4. 18908
5. 19040
6. 18908
这很好,因为:
一个。我想分配 128 * 1024 = 131072
字节,得到 19040 - 18908 = 132KB = 135168
字节。 135168 - 131072 = 4096
字节(我认为这只是头顶的池)。
b.当块结束时,内存就被释放了。
析构函数
int main() {
{
boost::pool<> *pool = new boost::pool<>(128, 1024);
system("ps aux | grep boostHash | grep -v grep | awk '{print \"7. \" }'");
void *a = pool->malloc();
pool->free(a);
delete pool;
system("ps aux | grep boostHash | grep -v grep | awk '{print \"8. \" }'");
}
system("ps aux | grep boostHash | grep -v grep | awk '{print \"9. \" }'");
}
输出:
7. 19040
8. 19040
9. 19040
这很奇怪,
一个。由于某种原因,大小已经分配(在我调用 pool.malloc()
.
之前
b.在 delete
.
中未释放尺寸
这可以解释吗?
我是否需要使用其他工具而不是 ps
来查看程序使用的内存?
Is this explainable?
是的。
Do I need to use another tool instead of ps to see the memory used by the program?
您正在看到程序使用的内存。
您没有考虑到的事情:内存分配例程经过了大量优化。对于各种场景,库(如 libc)将使用各种策略使 allocation/reallocation 更快。以下是一些常见的内存管理策略:
抢占式向操作系统申请内存;这允许应用程序执行相同类型的后续内部分配,而无需从 OS;
请求更多内存
缓存释放内存;这允许应用程序为后续分配重用内存(从 OS 接收)(再次避免与 OS 讨论它的开销)
我正在尝试使用来自 #include "boost/pool/pool.hpp"
的 boost::pool
内存池。
我想检查 boost::pool
分配了多少内存,所以我 运行 命令 system("ps aux | grep myProgramExe | grep -v grep | awk '{print }'");
给了我(来自 ps
手册页) VSZ - virtual memory size of the process in KiB (1024-byte units). Device mappings are currently excluded; this is subject to change. (alias vsize).
我遇到了一些奇怪的事情:
代码(代码缩进 4 个空格,再加上 4 个空格,因为它嵌入在列表中)
int main() { { boost::pool<> pool(4, 1); system("ps aux | grep boostHash | grep -v grep | awk '{print \"1. \" }'"); void *a = pool.malloc(); pool.free(a); system("ps aux | grep boostHash | grep -v grep | awk '{print \"2. \" }'"); } system("ps aux | grep boostHash | grep -v grep | awk '{print \"3. \" }'"); }
输出为:
1. 18908
2. 19040
3. 19040
这很奇怪,因为:
一个。我只想分配 4 个字节(next allocation
应该只有 1 个实例)。
b.当块结束并且 pool
已死时,内存不会被释放。
现在我想分配大小为128的实例,我想在下一次分配时这样分配1024:
int main() { { boost::pool<> pool(128, 1024); system("ps aux | grep boostHash | grep -v grep | awk '{print \"4. \" }'"); void *a = pool.malloc(); pool.free(a); system("ps aux | grep boostHash | grep -v grep | awk '{print \"5. \" }'"); } system("ps aux | grep boostHash | grep -v grep | awk '{print \"6. \" }'"); }
输出:
4. 18908
5. 19040
6. 18908
这很好,因为:
一个。我想分配 128 * 1024 = 131072
字节,得到 19040 - 18908 = 132KB = 135168
字节。 135168 - 131072 = 4096
字节(我认为这只是头顶的池)。
b.当块结束时,内存就被释放了。
析构函数
int main() { { boost::pool<> *pool = new boost::pool<>(128, 1024); system("ps aux | grep boostHash | grep -v grep | awk '{print \"7. \" }'"); void *a = pool->malloc(); pool->free(a); delete pool; system("ps aux | grep boostHash | grep -v grep | awk '{print \"8. \" }'"); } system("ps aux | grep boostHash | grep -v grep | awk '{print \"9. \" }'"); }
输出:
7. 19040
8. 19040
9. 19040
这很奇怪,
一个。由于某种原因,大小已经分配(在我调用 pool.malloc()
.
之前
b.在 delete
.
这可以解释吗?
我是否需要使用其他工具而不是 ps
来查看程序使用的内存?
Is this explainable?
是的。
Do I need to use another tool instead of ps to see the memory used by the program?
您正在看到程序使用的内存。
您没有考虑到的事情:内存分配例程经过了大量优化。对于各种场景,库(如 libc)将使用各种策略使 allocation/reallocation 更快。以下是一些常见的内存管理策略:
抢占式向操作系统申请内存;这允许应用程序执行相同类型的后续内部分配,而无需从 OS;
请求更多内存
缓存释放内存;这允许应用程序为后续分配重用内存(从 OS 接收)(再次避免与 OS 讨论它的开销)