小介:去年在读<深入解析JVM>的时候写的,记得当时还想着用自己的代码解析字节码的,最后只完成了一部分.现在都不知道还有没有保留着,貌似Apache有现成的BCEL工程可以做这件事.当时也只是为了学习.这份资料主要参考<深入解析JVM>和<Java虚拟机规范>貌似是1.2版本的,整理出来的.里面包含了一些自己的理解和用实际代码的测试.有兴趣的童鞋可以研究研究.嘿嘿.要有错误也希望能为小弟指点出来,感激不尽.:) 1.总体格式 Class File format type

代码编译的结果从机器码转变为字节码,是存储格式的一小步,确实编程语言发展的一大步.正是因为有了字节码这一中间格式才有了Java语言跨平台的特性. 字节码并不能直接基于物理机执行引擎执行,因为物理机执行引擎是建立在特定的处理器,指令集以及操作系统之上的,并不具备跨平台特性.所以执行字节码的责任就交给了虚拟机中的字节码执行引擎. 1 运行时栈帧结构 栈帧是用于刻画Java程序运行时一个方法的调用.执行以及返回过程的数据结构.通过学习前面的博客我们知道Java程序运行时有一块区域叫做虚拟机栈,而虚拟机

把之前的笔记重新整理了一下,发上来供对java Class文件结构的有兴趣的同学参考一下,也算对以前知识的回顾. Java Class文件打破了C或者C++等语言所遵循的传统,用这些传统语言写的程序通常首先被编译,然后被连接成单独的.专门支持特定硬件平台和操作系统的二进制文件.通常情况下,一个平台上的二进制可执行文件不能在其他平台上工作. Java Class文件是可以运行在任何支持Java虚拟机的硬件平台和操作系统上的二进制文件,Class文件中包含了java虚拟机指令集和符号表以及若干其他辅

2.12 用dis模块检查CPython字节码 到目前为止我们已经展示了很多测量Python代码开销的方法(包括CPU和RAM的开销).不过,我们还没有看到在底层虚拟机的字节码层面发生的事情.了解"台面下"发生的事情有助于在脑海中对运行慢的函数建立一个模型,并能帮助你编译你的代码.所以现在让我们来看一些字节码. dis模块让我们能够看到基于栈的CPython虚拟机中运行的字节码.在你的Python代码运行的时候,了解虚拟机中发生了什么可以帮助你了解为什么某些编码风格会比其他的更快.同时

我最近在参与Python字节码相关的工作,想与大家分享一些这方面的经验.更准确的说,我正在参与2.6到2.7版本的CPython解释器字节码的工作. Python是一门动态语言,在命令行工具下运行时,本质上执行了下面的步骤:     当第一次执行到一段代码时,这段代码会被编译(如,作为一个模块加载,或者直接执行).根据操作系统的不同,这一步生成后缀名是pyc或者pyo的二进制文件.     解释器读取二进制文件,并依次执行指令(opcodes). Python解释器是基于栈的.要理解数据流向,我

原文出处:https://www.ibm.com/developerworks/library/it-haggar_bytecode/index.html#opcode 作者:Peter Haggar 发表时间:2001 / 07 / 01 理解字节码可以使你变成一个更好的程序员 关于字节码的信息,以及这里提供的字节码,都是基于Java 2 SDK标准版v1.2.1 javac编译器的.其他编译器生成的字节码可能略有不同. 为什么要理解字节码? 字节码就是 Java 代码的中间表示,就像是汇编代

Java二进制指令代码以以下格式紧凑排列(opcode占一个字节): opcode operand* 除了tableswitch和lookupswitch两条指令中间存在填充字节以外,其他指令都没有填充字节,即使在两条指令之间也没有.因而在读取指令的时候,要根据指令的定义读取.  通过对上面Java指令集的分析可以知道,Java指令集中很大一部分没有操作数,因而对这部分指令,只需要读取一个字节的操作码,将操作码映射成助记符即可.  而对其他带操作数的指令,则需要根据不同类型分析(由于apache

一:Java字节代码的组织形式 类文件{ OxCAFEBABE,小版本号,大版本号,常量池大小,常量池数组,访问控制标记,当前类信息,父类信息,实现的接口个数,实现的接口信息数组,域个数,域信息数组,方法个数,方法信息数组,属性个数,属性信息数组 } 二:查看方法 --- javap命令 例子:有一个Java类Demo.java public class Demo {      private String str1;      private String str2;      private

问题描述 请帮忙把字节码翻译成java代码 有人能帮忙把下面的字节码翻译成对应的java代码吗,谢谢 // Byte code: // 0: ldc 40 // 2: dup // 3: astore_2 // 4: monitorenter // 5: aconst_null // 6: astore_3 // 7: aconst_null // 8: astore 4 // 10: aconst_null // 11: astore 5 // 13: aload_1 // 14: invok