[jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection

[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&containerType=14&container=2115]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100519/3d81724a/attachment-0001.html