JVM

在JVM中，call_stub（调用存根）的设计动机是为了提供一个统一的、低层级的入口点，用于处理Java方法调用（包括解释执行和JIT编译代码）的底层细节，同时解决跨语言调用、参数传递约定、执行上下

静态注册 JNI 示例（Windows） 1. Java 代码 (StaticDemo.java) 2. 生成头文件 生成头文件 StaticDemo.h，内容如下： 3. C++ 实现 (Stati

经过上一篇JVM启动流程文章中，知道创建虚拟机并初始化的逻辑是在Thread::create_vm方法中,那么本文就朱分析其实现的主流程. is_supported_jni_version检查是否支持

紧接着上一篇JVM启动中通过JNIEnv的CallStaticVoidMethod实现对java中main函数的调用。 JNIEnv->CallStaticVoidMethod的方法实现 这里需要首先

JVM是由C++和C混合开发,C++中类是定义模板,实际对象是按照class分配内存空间产生的class的对象实例，内存是没有class自身对象，这也解释了为什么C++没有反射能力的原因,当然java

由于dispatch_next中执行需要用到解释器的分派表DispatchTable,它里面究竟存的是什么呢?那么本文本文就是模板解释器的模板解释器的分派表初始化过程\ TemplateInterpr

JNI规范定义了从Java本机方法名到C本地库实现函数名如下： 1.前缀Java_ 2.给定声明本机方法的类的内部形式的二进制名称：转义名称的结果。 3.下划线（"_"）。 4.转义的方法名称. 5.

紧接着上一篇文章介绍generate_fixed_frame是生成java方法的栈帧固定栈帧部分,也即是JVM定义的动态链接的部分,在此之前JVM规范的本地变量表已经初始化完成了. 将栈上的返回地址保

接着前面文章，介绍了generate_fixed_frame生成固定的栈帧,那么接下来就是执行字节码, InterpreterMacroAssembler的dispatch_next执行指令字节码 之

JVM虚拟机的执行入口是main.c中main的函数入口,其中window和Liunx平台函数头是不一样，JVM中是通过宏定义去区分走不通分支，下面是我去掉window，只保留了Liunx的部分，该函

java对象布局一般通过jol或者HSDB等工具查看，本文就以HSDB为例: 使用HSDB工具查看Main线程的堆栈 利用HSDB - HotSpot Debugger -> Tools -> Fin

JVM解析方法的代码如下: JVM的字节码的方法访问标识和名称 1。首先创建ResourceMark记录当前Thread的resouceArea的资源使用，以便在析构函数时候释放资源空间. 对解析的方

接着前面文章介绍了JVM通过JavaCalls::call方法,接着调用call_helper,然后调用CallStub调用java的方法的,CallStub结构体中entry_pointJava得方

在java中, 首先javac将.java文件编译成.class的字节码文件后，再由JVM去完成字节码的进行解析，首先可以参考JVM的的规范(参考连接看下一个字节码文件的构成部分如下图 类文件重要以下

JVM解析Clss类的属性是在ClassFileParser的parse_fields方法，如下 下面就parse_fields方法体的逻辑注拆解分析 从字节码文件流中获取2个字节，表示是字段的长度,

在前面介绍JVM的类加载中比如Field和Method的解析之前，都时要县创建一个ResourceMark对象，那么我们今天介绍下ResourceMark这个类。 ResourceMark类的主要成员

首先来看下面的代码输出的结果是什么? 详细分析 1. 类加载阶段（静态初始化） 加载 Z 类：发现 Z 继承自 X，需先加载父类 X。 加载 X 类： 执行 X 的静态块： → 输出 static x

基于前面介绍的JVM经过Rewriter字节码重写，在ConstantPool中创建了常量池缓存ConstantPoolCache对象, ConstantPoolCache不是常量池缓存，它其实是实例

JMV对类的链接时，会对字节码进行重写，主要作用是实现常量池缓存，以及对方法的字节码重写，提高JVM字节码执行的性能。 重新写类中所有方法的字节码，重写的时机发生在验证字节码之后，但是在第一个方法执行