Performance - Update

[adrian.brock]

Since I started looking at this at the start of the week,
the time to boot in the default config in JBoss5 on my laptop
has dropped from 1 minute to 45 seconds (approximate wall clock timings).

Obviously this is using unreleased versions of the MC project jars
so nobody else will be seeing this at the moment. ;-)

The big things left to do now are;

* Annotation Scanning - Ales's new code

Old code:

 java.lang.Throwable.fillInStackTrace(Throwable.java:Unknown line)
 java.lang.Throwable.<init>(Throwable.java:218)
 java.lang.Exception.<init>(Exception.java:59)
 java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:65)
 org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:379)
 java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 org.jboss.deployment.AnnotatedClassFilter.accepts(AnnotatedClassFilter.java:121)
 org.jboss.deployment.AnnotatedClassFilter.visit(AnnotatedClassFilter.java:102)
 org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
 org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:264)

* Looking at the VFS, in particular the
file.getChild() -> getChildren() madness!

 org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:161)
 org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:337)
 org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:256)
 org.jboss.virtual.plugins.context.file.FileHandler.createChildHandler(FileHandler.java:224)
 org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:509)
 org.jboss.virtual.plugins.context.file.FileHandler.getChild(FileHandler.java:233)
 org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:427)
 org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findChild(VFSClassLoaderPolicy.java:450)

[mstruk]

About 'file.getChild() -> getChildren() madness' ...

getChildren() is only getting called when no handler is found in handler's childCache for the given name. But that does happen a lot (WEB-INF probing ...)

The reason getChildren() is being called is because of the specifics of how .vfslink mechanism works.

** How links mechanism works **

FileSystemContext supports a linking mechanism. You create a properties file and put it in a directory that's somewhere under a FileSystemContext root.
This properties file has to conform to a naming convention - something.vfslink.properties. The first part of the name ('something') is irrelevant - it plays no role.

An example content of this file:

vfs.link.name=extras
vfs.link.name.0=extra1.jar
vfs.link.target.0=${jboss.server.home.url}extra/extra1.jar
vfs.link.name.1=extra2.jar
vfs.link.target.1=${jboss.server.home.url}extra/extra2.jar

Let's say this file is inside 'deploy' directory. This would create a LinkHandler named 'extras' under 'deploy' FileHandler. And this LinkHandler will contain two children - 'extra1.jar' and 'extra2.jar'.

The result of placing this file are therefore the following additional virtual files:

deploy/extras
deploy/extras/extra1.jar
deploy/extras/extra2.jar

Detecting if LinkHandler (the virtual directory containing links) was removed

Link handler can be removed by a) removing .vfslink.properties file that caused its creation, b) changing vfs.link.name property of this same file.


Detecting if link was added

Link handler can be added by a) adding a new .vfslink.properties file, b) changing vfs.link.name property of existing .vfslink.properties file.


The main problem of this design is that there is no one-to-one mapping between LinkHandler name ('deploy/extras' in our example), and the properties file that created it ('something.vfslink.properties' in our example). If we want to determine the current configured state of links we _have to_ find all .vfslink.properties files in parent directory ('deploy' in our case), and process them. That's why getChildren() gets called. We could for example just check the file from which the link was created (LinkHandler contains that info) but that's not enough. This file may have disappeared due to being renamed into something else, which shouldn't affect links configuration - nothing substantial changed.

If we want to optimize this, we need to change the implementation. The simplest change would be to cancel vfs.link.name property and tie LinkHandler name to the first component of .vfslink.properties file - in our example it would have to be called extras.vfslink.properties.


This little change is enough to now be able to avoid having to call getChildren() on the parent in order to process all .vfslink.properties files in parent directory.

I've commited a fix along these lines.

- marko