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编写.不要忘记有多个分配路径:

    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图.顺便说一下，用于分配类实例和数组的图是不同的.如果您仍想使用它，请查看

    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屋！