字节码以无证方式随时间变化 [英] Bytecode changes over time in undocumented manner

问题描述

今天我在openjdk 7上使用javaagent和instrumentation来探索大型应用程序（如带有应用程序的jboss服务器）的类。我每隔10秒就调用所有类的重新转换，因此它们的字节码在我的ClassFileTransformer实现中得到了。

Today I was exploring classes of huge applications (like jboss server with apps) with javaagent and instrumentation on my openjdk 7. I called retransform on all classes every 10 seconds, so their bytecode got in my ClassFileTransformer implementation.

我的实现只是跟踪类的字节码如何随时间变化。首先，我很惊讶，字段和方法的顺序，方法访问修饰符，常量池的内容和其他类似的东西因检查而异。但是，它仍然是记录。

My implementation simply keeps track of how bytecode of classes changes over time. First of all, I was surprised, that order of fields and methods, method access modifiers, contents of constant pool and other such things vary from one check to the other. But, still, it is documented.

未记录的内容 - 某些项目可以在类中创建常量池并注入方法。现在我注意到数字值（Longs，Doubles，Floats等）会发生。

What is not documented - that some items may be created in class'es constant pool and injected into methods. For now I noticed that to happen with numeric values (Longs, Doubles, Floats and such).

这是它在javap中的样子;之前：

This is how it looks in javap; before:

pool:
...
#17 Float NaNf
method:
#1 fload #17 //NaNf
...

更改后的内容运行期间的类：

After something changed class during runtime:

pool:
...
#17 Float NaNf
#18 Float NaNf
method:
#1 fload #18 //NaNf <- look, it loads #18 now

我仔细检查过，没有附加任何其他变换器或代理。

I double checked, that no other transformers or agents are attached.

为什么JVM不能让我的字节码保持不变？我在哪里可以阅读有关此类优化/转换（或其他什么）？我读了JVM源代码，但这些只让我更加困惑。

Why can't JVM just leave my bytecode the same? Where can I read about such optimisations/transformations (or what else is it)? I read JVM sources, but these only confused me more.

我只是想创建一种实时字节码验证器 - 一种安全工具。

I'm just trying to create some kind of realtime bytecode verificator - a security tool.

推荐答案

未记录的内容 - 某些项目可以在类中创建常量池并注入方法。

What is not documented - that some items may be created in class'es constant pool and injected into methods.

嗯，您自己链接的文章清楚地说：

Well, the article you have linked yourself clearly says:

常量池可能有更多或更少的条目。常量池条目的顺序可以不同;但是，方法的字节码中的常量池索引将对应。

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.

所以实际 记录了。原因是完全记住每个类的字节码是没有用的，因此重复所有在很多类中相同的常量池条目。 JVM通常具有与普通类文件不同的内部格式，并且一旦需要就生成类文件，例如，在呼叫变压器时。

So it actually is documented. The reason is that it is not useful to remember each classes’ bytecode exactly thus repeating all the constant pool entries which are the same over lots of classes. The JVMs typically have an internal format which differs from ordinary class files and generate a class file once needed, e.g. when calling a transformer.

这篇关于字节码以无证方式随时间变化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！