OpenJDK源代码内部如何解释在何处分配堆内存? [英] How and where does allocating a heap memory interpreted inside OpenJDK source code?
问题描述
我正在尝试为我的研究项目更改OpenJDK的源代码.我想在Java程序中调用新运算符时知道代码流.
I'm trying to alter OpenJDK source for my research project. I want to know the code flow when I invoke a new operator inside a Java program.
class MyFirstProgram {
public static void main(String args[]) throws Exception{
System.out.println("Hello World!");
int i[] = new int[50];
}
}
在OpenJDK源代码中,我在新的操作员实现中放入了一些打印件. (路径: OpenJDKDev/src/hotspot/share/memory/allocation.cpp )
In the OpenJDK source code, I put several prints inside new operator implementation. (Path: OpenJDKDev/src/hotspot/share/memory/allocation.cpp)
我不确定是否要检查正确的文件以进行内存分配. 看起来,即使我调用java -version,它也会打印出我多次输入的消息.
I'm not sure if I'm checking the right file for memory allocation. It seems like even when I call java -version, it prints the messages I put many times.
当我在用户Java程序中调用新的内存时,我找不到执行内存分配调用的准确程度(以及确切位置).
I'm not able to find how exactly (and where exactly) the memory allocation calls are made when I call a new inside a user Java program.
->使用JDK11.
--> Using JDK11.
推荐答案
我对您有个坏消息. HotSpot源代码中没有一个地方可以处理所有Java分配.
I have a bad news for you. There is no a single place in HotSpot sources that handles all Java allocations.
可能会发生分配:
- 在VM运行时中;
- 在字节码解释器中;
- 在JIT编译的代码中:
- 由C1编译;
- 由C2编译;
- 由Graal等编译
- In the VM runtime;
- In the bytecode interpreter;
- In the JIT-compiled code:
- compiled by C1;
- compiled by C2;
- compiled by Graal etc.
每种情况下的方法都大不相同.例如.最简单的部分是VM运行时-它只是易于修改的普通C ++代码,请参见
The approach in each case is quite different. E.g. the simplest part is the VM runtime - it's just a plain C++ code which is easy to modify, see
MemAllocator::mem_allocate
.To modify the interpreter, you'll have to dig into some assembly code, see
TemplateTable::_new
.C1分配也用ASM编写.不要忘记有多个分配路径:在Eden中,或者回退到VM运行时的缓慢路径分配.
C1 allocation is also written in ASM. Don't forget there are multiple allocation paths: in TLAB, in Eden or a slow path allocation that falls back to the VM runtime.
将所有汇编代码乘以以下架构数量:x86,ARM,AArch64,PPC等.
Multiply all the assembly code by the number of architectures: x86, ARM, AArch64, PPC etc.
C2仍然是另一个挑战,因为它需要生成一些令人难以置信的IR图.顺便说一下,用于分配类实例和数组的图是不同的.如果您仍想使用它,请查看 GraphKit :: new_array .
C2 is yet another challenge, as it requires generating some mind-blowing IR graphs. By the way, the graphs for allocating class instances and arrays are different. If you still want to play with it, have a look at GraphKit::new_instance and GraphKit::new_array.
我并不是说稍微改变分配策略" 是绝对不可能的,但是我要说这是大量的工作,需要对JVM有深入的了解.
I don't mean "changing allocation strategy a bit" is absolutely impossible, but I'd say it's a huge amount of work which requires in-depth knowledge of the JVM.
P.S. src/hotspot/share /memory/allocation.cpp 与Java Heap无关.这部分负责内部JVM的本机"C"分配.
P.S. src/hotspot/share/memory/allocation.cpp has nothing to do with Java Heap. This part is responsible for native "C" allocations for internal JVM purposes.
这篇关于OpenJDK源代码内部如何解释在何处分配堆内存?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!