What does certain JVM do after loading ByteCode into memory?

喜夏-厌秋 提交于 2019-12-02 00:41:05

You can get some hints by looking at the documentation of an API that forces the JVM to transform the internal representation back into the official class file format:

http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#retransformClasses(java.lang.Class...)

The initial class file bytes represent the bytes passed to ClassLoader.defineClass or redefineClasses (before any transformations were applied), however they might not exactly match them. The constant pool might not have the same layout or contents. The constant pool may have more or fewer entries. Constant pool entries may be in a different order; however, constant pool indices in the bytecodes of methods will correspond. Some attributes may not be present. Where order is not meaningful, for example the order of methods, order might not be preserved

From this documentation you can draw the conclusion that you can expect instructions accessing the constant pool to look different, at least they may have different indices, and that you cannot assume that methods are placed into a contiguous memory space. This does not imply that these are the only transformations, but all others can be reversed if needed— at least in a JVM that supports Instrumentation.


While running the code the JVM might replace instructions by specialized VM-internal instructions to optimize further execution. If you are curious what kind of instruction a JVM might have you can run Oracle’s HotSpot-Engine with the arguments

-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter

Then it will print the table of all instructions and their associated native code as used by the interpreter. This table will necessarily contain these specialized instructions. E.g. on my machine and jdk 1.7 I see about 30 non-standard bytecode instructions in the range 203 to 231.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!