问题标签 [object-layout]

你能给我一些关于对象头中究竟存储什么的信息吗？我知道，它可能依赖于 JVM，但至少对于 HotSpot 来说可能是这样？我正在寻找专门针对第一行的确切描述。

我已经阅读了一些我无法用我找到的信息进行肯定验证的信息。也许你有一个 OpenJDK wiki 的链接可以说明一切？

I am trying to make sense of the output of Java object layout on a 64-bit HotSpot VM (v8). I do not understand how the first three bit of the mark word are used which according to the commentary in the linked class file should indicated weather a biased lock or non-biased lock is set on the instance.

When I analyze an instance of Object using JOL by

I get the following output:

From HotSpot's description of the mark word (the first 8 byte), I understand that I should interpret the above bit ranges of the output as follows:

• 00:01 - Flag for lock (00 in example.)
• 02:02 - Flag for biased lock (0 in example.)
• 03:06 - Age as number of young garbage collection iterations. (0000 in example.)
• 07:07 - Unused. (Seems to be always 1.)
• 08:39 - Identity hash code. (Only after its computation, before filled with zero.)
• 40:63 - Unused. (Seems to be filled with zeros.)

Confirming this layout for the hash code range

At least for the hash code, this can be easily confirmed by computing the identity hash code and comparing the values:

where the hash code is set as the actual bit (ignoring the fact that it is only represented by 31 bit instead of 32 as the reminder is set to zero). The flags for the locks are all set to zero as expected.

Validating the layout for biased locking

The markOops also gives a layout for when an object is subject to biased locking. Here, the last two bullet points are replaced with the following ranges:

• 08:09 - Epoch bit
• 10:63 - Pointer of the thread holding this biased lock.

When I now attempt a biased lock running the following code with -XX:BiasedLockingStartupDelay=0, I can also observe how the biased lock is set. When I run the following code:

The biased lock is visible in the mark word after the initial locking as shown below:

I can validate that this is not representing the hash code as the mark word changes (the biased lock is revoked) once I invoke object.hashCode().

What I do not understand is that the flags for the biased lock and the non-biased lock are still set to zero. How does HotSpot know that this is a biased lock and not a hash code represented in the object. I additionally wonder: What does the epoch bits indicate?

JOL工具能够计算对象的内存布局。

我注意到，静态字段不参与计算，例如：

然后，

给出以下输出：

private static final int在内存中的什么位置？

我想我对类数据成员及其在内存中的表示有一个清晰的了解：

类的成员定义了对象的布局：数据成员一个接一个地存储在内存中。使用继承时，派生类的数据成员只是添加到基类的数据成员中。

然而，当我试图弄清楚一个对象的“蓝图”是如何被它的函数成员用额外的语法元素修改的时：我遇到了困难。在下面的文本中，我试图列出所有有问题的¹函数成员语法，这些语法使我难以弄清楚对象内存大小和结构。

我无法弄清楚的类成员函数：

• 函数类型：lambda, 函数指针,修改,非修改。
• 包含额外的语法元素：（与friend非成员）virtual，，，，，，，，，，，。finaloverridestaticconstvolatilemutable

问题：

在对象内存布局的上下文中，具有不同说明符的成员函数之间有什么区别以及它们如何影响它？

笔记：

我已经读过这个和这个，它没有提供令人满意的答案²。这谈到了最接近重复的一般情况（我理解）。（但我特别关注有问题的语法列表，这是我的实际问题，并且没有在其中介绍。）

^{1.在影响对象内存布局方面。}

^{2. 第一个是关于GCC 编译器的，第二个是关于 @m@zon 的书的链接。}

如果一个类is_standard_layout，是否足以保证给定的非静态数据成员将始终具有与对象地址相同的偏移量（即跨该类的不同实例，在进程范围内相同）？

在最近的一次采访中，有人问我关于 C++ 结构字段对齐的问题，并认为 C 和 C++ 在结构打包中遵循相同的策略。

然而，这是错误的假设。面试官说，通常 C 和 C++ 以不同的方式打包结构，我们不应该期望相反。恕我直言，这是奇怪的说法。C++ 中的结构没有pack "C"用于双语 C/C++ 头文件的限定符。

因此，在实践中，这可能意味着您无法在 C++ 中创建结构并将其传递给 C 库，因为通常它的字段将以不同的方式对齐并具有不同的偏移量。但是，事实上，大多数程序员在使用一些辅助方法将指向 C POD结构的指针转换为对该结构的 C++ 包装器的引用之前，都非常依赖这种互操作性。你能澄清一下这个问题吗？

在我的第一个示例中，我有两个使用int64_t. 当我编译并获得类的大小时，我得到 8。

但是当我将第二个 bitfeild 更改为 aint32_t时，类的大小翻倍为 16：

这发生在 GCC 5.3.0 和 MSVC 2015 上。但是为什么呢？

我知道类外的常量变量可以由编译器直接优化为函数调用，但是编译器对常量类变量做同样的事情是否合法？

如果有这样声明的类：

我创建了一个 A 的实例并调用这样的函数：

是否允许编译器这样做并使类sizeof(int)更小？：

介绍：

我使用JOL（Java Object Layout）工具来分析 Java 对象的内部和外部碎片以用于研究目的。

这样做时，我偶然发现了以下内容：

问题：

在这种情况下困扰我的是每个字段都是 4 字节对齐的（参见 OFFSET 列），但仍然在偏移量 56 处添加了对齐间隙（56 8 (alignment/padding gap)）。我在 Java 9 中进行了相同的测试，对象布局发生了一些变化，对齐/填充间隙仍然存在，但甚至有 12 个字节大。

为什么会这样？为什么它有 8 个字节大，我看到的所有其他对象都是 4 个字节的内部对齐？我自己找不到解释。

我的系统：

使用默认设置（带有压缩 oops 的 ParallelOldGC）

我使用了一个名为JOL（Java Object Layout）的工具，它试图分析对象布局。它带有一个cli，我用它来分析java.lang.Integer。我看到 Integer 对象占用了 12 个额外的字节作为开销。该开销可以是对象所属类的地址的 4 个字节，另外 4 个用于垃圾收集，但是剩下的 4 个字节呢？我知道对象有一个整数 hashCode 值，但我不认为它是唯一的（即它不使用内存位置，而是使用原始值），因为：

日志：