shr*_*000 15 java reflection jit
我最近遇到了这个有趣的术语,并在网上搜索了解更多信息.然而,我发现的信息是粗略的.有人可以吗.给我一个详细解释这是什么,为什么这有用?
从我发现的信息来看,看起来这个机制使得反射方法的执行速度更快,代价是创建了很多动态类并占用了perm gen内存区域,但我不确定.
shr*_*000 18
是否有一些源代码挖掘和编码自己来解决这个问题,这就是我发现的:
Java的'Method'类有一个'MethodAccessor'类型的成员变量'methodAccessor',它是一个方法'invoke'的接口,类似于Method的invoke.方法调用委托给methodAccessor的调用.
如果启用了通胀(noInflation为false),则此访问器指向使用JNI运行此Java方法的实现(我认为使用api类似GetObjectClass,GetMethodID和Call*Method).这就像决斗调度一样,由于这个原因和其他原因,JNI的执行很慢.(是什么让JNI呼叫变慢?)
通过反射执行15次方法('15'是默认值并且可以更改)并且noInflation为false后,基于JNI的访问器动态创建一个类(名称是动态生成的,例如说'GeneratedMethodAccessor1'),它也有调用方法.现在,在这个'invoke'方法中,它将第一个'obj'参数强制转换为其对应的类,然后在其上调用目标方法.然后,它创建此类的实例,并更改methodAccessor设置,以便此后每次执行该方法都委托给此实例而不是JNI访问器.这被称为通货膨胀.
因为此实例是委托给Java对象的Java类,所以此后委托是普通的Java委托.它永远不会进入JNI,因此节省了开销,加上JITC可以对其进行其他优化,因为它变得高效.
缺点是,如果许多方法以这种方式膨胀,它们的类占据了permgen空间并且可能导致内存不足错误.
有关详情,请参阅:
http://java.sun.com/docs/books/jni/html/fldmeth.html
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
Java Inflation是对通过Java 反射 API进行的方法调用的优化。它将不频繁的方法调用委托给廉价、立即可用但速度较慢的Java 本机接口,并将频繁的方法调用委托给快速但昂贵的、运行时生成的方法访问器。
| 归档时间: |
|
| 查看次数: |
2770 次 |
| 最近记录: |