java - 关于 Java 和 C++ 中的内存管理

Question

好吧，我接到了一项任务，要基本上弄清楚内存分配对于我将使用的任何语言是如何工作的。经过一些研究，我有一些问题和疑惑，我想深入了解一下。例如:

我读了here Java 明确指定了堆栈内容的组织方式。看着 JVM spec structure ，它基本上说堆栈包含帧，并且通过正确分配变量和函数，帧包含类内部的任何内容。也许我在这里遗漏了一些东西，但我不明白这与 C++ 所做的有什么不同。我问是因为第一个链接说 Java 的堆栈内容规范避免了编译器不兼容。

此外，我还没有找到内存段是如何准确地相互重叠组织的。例如，我知道内存分为全局变量、调用堆栈、堆和 C++ 代码，但我不知道堆的地址是否高于堆栈的地址，或者这取决于实现。我还想知道 Java 程序是否有更多内容，以及它的布局方式。我想有一个标准，因为 JVM 必须知道它在哪里使用它，尽管我想它可以只拥有指针并将其余的留给操作系统。我也想，至少必须有一个事实上的标准。

我不明白的另一件事是运行时常量池。它应该是“类文件中 constant_pool 表的每个类或每个接口(interface)的运行时表示”，但我不认为我理解它的作用。它似乎有一个标签来指示所讨论的结构是什么类型？然后是结构的名称(由程序员给出或由底层系统分配？)然后它的其余部分似乎随标记描述的内容(线程、数组等)而变化。

如果我对运行时常量池的解释是正确的，那么为什么它们和堆栈帧一样必要？是不是栈帧只管栈段，运行时常量池也必须有堆分配内存的指针？

Answer 1

Looking at the JVM spec structure, it basically says the stack contains frames, and that the frames contain whatever is inside the class by properly allocating the variables and functions. Maybe I am missing something here, but I don't understand how this is any different than what C++ does. I ask because the first link says Java's specification of stack contents avoid compiler incompatibilities.

在实践中，C++ 编译器遵循相同的基本策略。但是，标准委员会不认为它是语言问题。相反，C++ 编译器遵循这个系统，因为大多数 CPU 和操作系统都是这样设计的。不同的平台不同意数据是通过堆栈还是通过寄存器(RISC 机器)传递给函数，堆栈是增长还是下降，是否有不同的调用约定允许“正常”调用使用堆栈而其他调用使用某些东西else(例如 __fastcall 和 naked )，是否有像 nested functions 这样的东西, tail call support等

事实上，符合标准的 C++ 编译器有可能编译成类似于 Scheme VM 的东西，其中“堆栈”有很大不同，因为 Scheme 要求实现同时支持尾调用和延续。我从未见过这样的事情，但这是合法的。

The "compiler incompatibilities" are most obvious if you try to write a garbage collector :

all local variables, both for the current function and all its callers, are in ["the" stack, but consider ucontext.h and Windows Fibers]. For each platform (meaning, OS + CPU + compiler) there's a way to find out where ["the" stack] is. Tamarin does that, then it scans all that memory during GC to see where the locals point to. ...

This magic lives in a macro, MMGC_GET_STACK_EXTENTS, defined in the header MMgc/GC.h. ... [T]here’s a separate implementation for each platform.

At any given moment, some locals might be in CPU registers and not on the stack. To cope with this, the macro uses a few lines of assembly code to dump the contents of all the registers onto the stack. That way MMgc can just scan the stack and it’ll see all local variables.

---

此外，Java 中的对象 通常不会分配在堆栈上。相反，对它们的引用是。整数、 double 、 boolean 值和其他基本类型确实在堆栈上分配。在 C++ 中，任何东西都可以在堆栈上分配，堆栈有其自身的优点和缺点列表。

Another the thing I don't understand is the runtime constant pool. It's supposed to be "a per-class or per-interface runtime representation of the constant_pool table in a class file", but I don't think I understand what it does.

考虑:

String s = "Hello World";
int i = "Hello World".length();
int j = 5;

s、i 和 j 都是变量，每个都可以在程序稍后的某个时间点更改。然而，“Hello World”是一个String类型的对象，不能改变，5是一个int，不能改变，而“Hello World”.length()可以在编译时确定总是返回11。这些常量是有效的对象，并且可以在它们上调用方法(好吧，至少在 String 上)，因此需要将它们分配到某个地方。但它们永远无法改变。如果这些常量属于一个类，那么它们将分配在每个类的常量池中。其他不属于类的常量数据(如 main() 线程的 ID)分配在每个运行时常量池中(“运行时”在本例中表示“JVM 的实例”)。

C++ 标准有一些关于类似技术的语言，但实现取决于二进制格式(ELF、a.out、COFF、PE 等)。标准期望整数数据类型(bool、int、long 等)或 c 风格字符串的常量实际保存在二进制的常量部分，而其他常量数据( double 、 float 、类)可能存储作为一个变量和一个标志，表示“变量”不可修改(用整数和 c 风格的字符串常量存储它们也是可以接受的，但许多二进制格式不支持此选项)。

一般来说，当程序的多个拷贝同时打开时，二进制文件的“常量数据部分”可以共享(因为常量数据在程序的每个拷贝中都是相同的)。 On ELF this section is called the .rodata section .