问题标签 [jol]

我对 HotSpot 中堆上的对象布局相当熟悉，但对 Android 来说并不熟悉。

例如，在 32 位 HotSpot JVM 中，堆上的一个对象被实现为一个 8 字节的标头，然后是对象的字段（一个字节用于boolean，四个字节用于引用，以及其他所有内容）以某种特定的顺序（对超类中的字段有一些特殊规则），并填充为 8 个字节的倍数。

我已经进行了一些研究，但找不到任何特定于 Android 的信息。

（我有兴趣优化一些极其广泛使用的数据结构，以最大限度地减少 Android 上的内存消耗。）

你能给我一些关于对象头中究竟存储什么的信息吗？我知道，它可能依赖于 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在内存中的什么位置？

当使用 jol 的 GraphLayout 类打印从对象实例引用的对象图时，一些输出条目会显示“（其他）”而不是类型和引用路径。例如，考虑以下代码，它打印 20 个随机 Integer 对象的列表图：

此代码打印：

jol "something else"在 DuckDuckGo 和 Google 上搜索并没有返回任何有用的结果。

“（其他）”条目代表什么？

我正在尝试使用来自 openJDK 的 jol。

我从这里下载了 jar：http:
//central.maven.org/maven2/org/openjdk/jol/jol-cli/0.4/jol-cli-0.4.jar

但是，当我尝试运行时：
java -jar jol-cli-0.4.jar --help

我得到：
no main manifest attribute, in /home/rattias/jol-cli-0.4.jar

我究竟做错了什么？

我在多个地方读到它，使用 byte[] 而不是 string 可以节省内存。我想使用jol对其进行测试。

这是我的测试：

这是我的结果：

如您所见，StrByteMap 和 StrStrMap 之间的内存使用几乎相同。我在这里测试错了吗？

更新：请看下面@Amod Pandey 的问题，我也想知道为什么。

这是相关代码的链接 - http://hg.openjdk.java.net/code-tools/jol/file/07087260ce41/jol-samples/src/main/java/org/openjdk/jol/samples/ JOLSample_16_AL_LL.java

当我按原样运行代码时，我看到以下内容：

我不确定 [Ljava.lang.Object; 的 4952 字节在哪里；来自。如果我更新 ArrayList 创建并将初始大小设置为 1000 以便没有增长，我会得到以下信息：

谢谢。

更新

我关闭了 CompressedOops (-XX:-UseCompressedOops)。这是新的结果：

因此，当禁用 CompressedOops 时，参考大小会增加到 8 个字节。对我来说，Object 数组包含对 1000 个整数对象的引用更有意义。

我想知道是否可以通过自己设置对象标头的标记字中的一位来防止对象被 GC 移动（试图欺骗 GC）。

所以基本上我想知道这种方式是否可以确保标记的对象始终具有相同的内存地址。

使用 java-9 build 9-ea+149 和 jol 0.6。

运行这个简单的代码：

输出：

这个访问被拒绝的部分来自方法中的 FieldData.java：

实际的例外是：

无法使字段受保护的瞬态 int java.util.AbstractList.modCount 可访问：模块 java.base 不会“打开 java.util”到未命名的模块 @479d31f3。

我认为这与不安全功能被锁定有关。问题是我如何让它运行？

我查看了以下属性：

但不能真正说出它应该是什么样子。