问题标签 [memory-layout]

以下是 a.out 上 size 的输出

当我对所有使用的单个 obj 和库的大小输出进行总计时

我可以理解实际可执行文件中的文本大小小于总大小（库 + main.o），因为实际可执行文件不包含库中未使用函数的文本部分。

我的问题是为什么最终可执行文件中的 bss 部分很大（~9MB），当我总计库和 main.o 的 bss 部分的总和时，它是~23k。

如何找到，where(files) 是在可执行文件中分配的这个巨大的 bss 部分。

我正在使用 ubuntu 13.04，gcc。

任何帮助表示赞赏。

我试图理解 C 中的堆栈帧，所以我编写了一个简单的 C 代码来分析堆栈帧。

• 首先，fun1() 返回一个局部变量的地址，该变量初始化为 10 到 ptr，这会导致警告，但没关系......如果我现在打印 *ptr 的值，它会打印 10，即使这样也没关系.. .

• 接下来 fun2() 返回一个甚至没有初始化的局部变量的地址，如果我现在尝试打印 *ptr 的值，无论我返回的是 a 还是 b 的地址，它都会打印 10 ...

• 为了了解这里实际发生了什么，我使用了 gdb。使用 gdb，我开始逐步调试，当我到达 fun2() 中的“ return &a ”行时，我尝试打印 b 的地址，打印 &b但它打印了 Can't take address of “b” which is not一个左值。

我不明白当我尝试打印 a 的地址时，打印 &a它打印得非常好，那么为什么不打印 b 的地址。* 为什么当 a 是左值时 b 不是左值？

在使用旧式投影仪时，我遇到了以下模式：POD 结构用于通过网络传输数据。

在接收方，数据被接收到 POD 类型的对象中。稍后，从 PODType 派生一个类，并将接收到的对象以 C 风格的类型转换为派生类，以使用某些方法访问数据。

派生类具有公共和受保护的方法，因此它不再是 POD。我知道这是对继承的滥用，但它在代码库中已经存在很长时间了。

我想知道这是否可以保证从标准的角度（C++03 或 C++98）工作。派生类没有任何自己的数据成员或虚函数，但我不确定它是否保证内存布局是相同的，因为一个是 POD 而另一个不是。编译器是否被迫安排 DerivedFromPOD 使得d.data' 的地址与 DerivedFromPOD 类型的对象 d 的地址相同，就像 POD 基类一样？

我研究过在linux系统中堆栈从高内存地址增长到低内存地址。为了测试这一点，我写了一个小代码：

当我在 ideone 中运行它时，我得到以下输出：

根据教科书，Func 应该存储在比 Main 更低的内存地址中，但这里发生的情况完全相反。有人可以向我解释这种行为。这是ideone 的链接。

谢谢你。

来自 C/C++ 的背景，关于减少缓存未命中的对象的内存布局是至关重要的，尤其是在控制台上工作时。面向数据的设计通常比面向对象的设计更受青睐，以帮助保持相关对象在内存中彼此靠近（尤其是在性能关键区域）。

最近，我一直在做一些 Javascript 开发，我想知道 Javascript 社区内的普遍共识是什么。

由于我在 Javascript 方面的经验有限，在进行分析时，我经常会惊讶地看到完全出乎意料的结果。Javascript对象/结构的内部内存布局和实现因浏览器而异，我想知道是否值得尝试优化。

我在 jsPerf 上创建了一个简单的测试用例 ( http://jsperf.com/object-vs-data ) 来比较两种方法的性能，虽然它在 Chrome 上显示了性能提升，但在 Safari 上没有明显的加速。

在 Javascript 中，我是否应该关注对象的内存布局？还是更像是“以一种方式实现，然后在需要时进行优化”类型的东西？

第二个选项似乎有点浪费（就开发时间而言），特别是如果有一些好的指导方针可以遵循。

谢谢~

补充信息：这基本上是我在 Javascript 中实现这两种方法的方式。上面的 jsPerf 测试用例是这样实现的。

我知道标准没有指定如何打包数据。我只是想了解类的内存布局（尤其是如何dynamic_cast<void*>保证返回指向最派生类开头的指针）。我想不出关于以下代码输出的任何解释：

打印指针的值表明 , ,a始终具有相同的值，只是添加了 4 个字节作为偏移量。是偶然的吗？或者背后有什么逻辑？cdb

编辑： 从概念上讲，布局应该像图像，但不知何故，点 A、C 和 D 合并为一个。

这是在 Java 6 内存模型之后。在 32 位 JVM 中，对象的 Shallow size 为

如果前 2 个术语加起来不是 8 的倍数，则会有填充。

在 64 位 JVM 中，Shallow 大小为

我的理解是这个 Object 标头由 2 个单词组成（oracle 热点 VM）

• 一个经典的词
• 一个标记词

在 32 位 JVM 上，对象标头 = 2 * 32 位 = 64 位 = 8 字节
在 64 位 JVM 上，对象标头 = 2 * 64 位 = 128 位 = 16 字节

但是使用 CompressedOops，3 个低位被截断，因此对于小于 32 gigs 的堆，它应该在 64 位 JVM 上恢复为 8 个字节

但是当我使用 JOL（Java 对象布局）测试对象布局时，它显示了 12 个字节的对象头。

测试代码

输出

我在这里缺少什么会增加额外的 4 个字节？

从参考手册中可以清楚地看出，s的内存布局struct是未指定的（当repr不使用该属性时）。此规则使编译器可以通过重新排序字段来更紧密地打包结构。

元组和元组结构的内存布局如何？它是如何（未）指定的，为什么？

我写了一个简单的c代码，如下所示。在此代码片段中，我想验证 const 字符串的abcd存储位置。我首先猜测它应该存储在.data只读部分中。然而，在 Debian 中进行测试后，事情与我最初的猜测不同。通过检查 gcc 生成的汇编代码，我发现它被放置在 function 的堆栈框架中p。但是当我稍后在 OSX 中尝试时，该字符串.data再次存储在部分中。现在我对此感到困惑。有没有存储 const 字符串的标准？

更新：rici 的回答唤醒了我。在 OSX 中，初始文字被存储在.data之后，然后移动到函数的堆栈帧中。因此，它成为此函数的局部变量。但是，Debian 中的 gcc 处理这种情况与 OSX 不同。在 Debian 中，gcc 直接将文字存储在堆栈中，而不是从.data. 我很抱歉我的粗心。

据我所知，Rust 编译器允许对结构的每个字段进行打包、重新排序和添加填充。如果需要，如何指定精确的内存布局？

在 C# 中，我有StructLayout属性，而在 C/C++ 中，我可以使用各种编译器扩展。我可以通过检查预期值位置的字节偏移来验证内存布局。

我想编写使用自定义着色器的 OpenGL 代码，这需要精确的内存布局。有没有办法在不牺牲性能的情况下做到这一点？