Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Flavia Rainone
Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/543946#543946
--------------------------------------------------------------
> Kabir Khan wrote:
>
> Once I am done with caching things as much as possible, we'll see if the classpools are still a bottleneck since there will be a lot less calls. If they are, I have an idea for how to change them into something simpler, but just want to jot it down so Flavia can take a look and see if she thinks it is a good idea or if I have missed something.
>
> The idea is quite simple, rather than managing the domains and pools and essentially recreating what the classloaders do, it might make sense to delegate everything to the classloaders. If we had a method like this, as I discussed with Ales (let's say it goes in the ClassLoading class, although where is up to Ales):
>
> ClassLoader getClassLoaderForClass(ClassLoader initiating, String classname);
>
>
>
>
> And we have a map of classpools by classloader in the classpool registry.
>
>
>
> Then I think our "dumb" class pool would not need much more than this - it has a null parent
>
>
>
>
>
> *class* DumbClassPool *extends* ClassPool{
>
> WeakReference<ClassLoader> cl;
> ClassPoolRepository repo;
>
> DumbClassPool(ClassLoader cl, ClassPoolRepository repo){
> this.cl = *new* WeakReference<ClassLoader>(cl);
> this.repo = repo;
> }
>
>
> CtClass get(String classname){
> //Check cache first, if not found then do the rest
>
> CtClass clazz = super.get0(classname);
> *if* (clazz != *null*)
> *return* clazz;
>
> String real = adjustForArraysAndPrimitives(classname);
> ClassLoader loader = ClassLoading.getClassLoaderForClass(cl.get(), real);
>
> ClassPool pool = repo.registerClassLoader(loader);
> *if* (pool != *null*)
> {
> clazz = pool.getOrNull(classname); //new method from Chiba that does not throw NFE, but behaves like get()
> }
>
> *if* (clazz != *null*)
> //cache class
> *else*
> *throw* *new* NotFoundException
> }
> }
>
>
>
>
> I'd obviously be extending ScopedClassPool or whatever is needed in AOP and other places. It would also have some knowledge of the domain and get notified when loaders get added/removed to the domain so the caches in the pools can be invalidated. There will probably be a bit more to it than this, but this is the basic idea.
>
>
>
I only see pros at implementing the classpools this way:
- it is fast to do it. I know that there is a lot of detail that needs to be filled in, but nobody is talking about reimplementing them with the same level of complexity of before
- it is so clean that we will be able of seeing the real impact of classpools in the performance
Regarding the last sentence, as has already been discussed on our team calls, it is not a piece of cake to outperform reflection:
- it is good that we don't force classes to be loaded... but what if the class has already been loaded? Do we want to use an extra loading level in that case? We can of course try to create a clever mechanism for working around this, but this is more complexity to a code that is already complex.
- we are doing with Java and Javassist (one more layer of indirection) something that the JDK already does (apart from bytecodes manipulation, of course). After years of JDK improvements, we can expect that they do this natively and fast. The JDK can use its own internal structures (the ones it uses to load and run code) for answering reflection invocations.
Thus, if we have the cleanest possible implementation of the ClassPools, we have less overhead and we will finally be able to see if it is possible to improve the performance with Javassist/Classpools and to beat our reflection-based implementation.
This is the main question we've been trying to answer all this time.
Using the ClassLoaders SPI to find the appropriate ClassLoader/ClassPool is definitely a plus in this regard, as we are using the same ClassLoader structure that the reflection implementation uses.
The only drawback is that we won't be able of getting rid of the old structure for AS 4 (ie, erasing all classpool code for as 4), unless we use an older version of the project for JBoss AOP. Which is not really a drawback, it is more like a constraint that we have to face for being backwards compatible with an older version of AS.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543946#543946]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/543921#543921
--------------------------------------------------------------
Although too early to say yet, it looks like the classpools are a bottleneck. I have started caching things a bit more and that is speeding things up somewhat. For example calling CtBehavior.getParameterTypes() is slow since it does not cache the parameter types, instead for every call to this it parses the method signature and then hits the classpools for every class. I am attempting to avoid that as much as possible.
Another observation is that quite a few calls to JavassistMethodInfo.getParameterTypes() are only interested in the length of the parameters and the names of the parameter types, so it might be an idea to return an array of "lazy" type infos which only know the name and the declaring typeinfo. I can be found out easily from the raw method signature (I am already passing the SignatureKey into JavassistMethodInfo and using that in its equals() method to avoid having to load parameters there). Once something more advanced is called, then that could obtain the real typeinfo and delegate to that. I'm not 100% sure yet if this is what I want to do.
Once I am done with caching things as much as possible, we'll see if the classpools are still a bottleneck since there will be a lot less calls. If they are, I have an idea for how to change them into something simpler, but just want to jot it down so Flavia can take a look and see if she thinks it is a good idea or if I have missed something.
The idea is quite simple, rather than managing the domains and pools and essentially recreating what the classloaders do, it might make sense to delegate everything to the classloaders. If we had a method like this, as I discussed with Ales (let's say it goes in the ClassLoading class, although where is up to Ales):
ClassLoader getClassLoaderForClass(ClassLoader initiating, String classname);
And we have a map of classpools by classloader in the classpool registry.
Then I think our "dumb" class pool would not need much more than this - it has a null parent
class DumbClassPool extends ClassPool{
WeakReference<ClassLoader> cl;
ClassPoolRepository repo;
DumbClassPool(ClassLoader cl, ClassPoolRepository repo){
this.cl = new WeakReference<ClassLoader>(cl);
this.repo = repo;
}
CtClass get(String classname){
//Check cache first, if not found then do the rest
CtClass clazz = super.get0(classname);
if (clazz != null)
return clazz;
String real = adjustForArraysAndPrimitives(classname);
ClassLoader loader = ClassLoading.getClassLoaderForClass(cl.get(), real);
ClassPool pool = repo.registerClassLoader(loader);
if (pool != null)
{
clazz = pool.getOrNull(classname); //new method from Chiba that does not throw NFE, but behaves like get()
}
if (clazz != null)
//cache class
else
throw new NotFoundException
}
}
I'd obviously be extending ScopedClassPool or whatever is needed in AOP and other places. It would also have some knowledge of the domain and get notified when loaders get added/removed to the domain so the caches in the pools can be invalidated. There will probably be a bit more to it than this, but this is the basic idea.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543921#543921]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months