Did some memory tweaking to try and cut down on the number of classes loaded. Couple interesting things....
# TempClassLoader TempClassLoader was full of "system" classes (and still is somewhat). We hand one of these to the JPA impl and they use it to do runtime enhancing. I cut down on the classes loaded by excluding certain packages. This falls in the category of "fixing it for us" and leaving it broken for others. Any classes added to the server will likely wind up getting pulled into the TempClassLoader and sit there for the life of the app. A handful of features come to mind. Some way to limit what the TempClassLoader will load. Fixed text or regex matching of classnames could do it. Some pluggable xbean-finder Filter could work -- it'd just be called on each load attempt. As well, since we can see the entire app we could easily figure out which packages belong to the app and which don't -- we could guess pretty well at least -- then we just only apply the TempClassLoader to the app classes. # JAXB Accessors One of the biggest polluters of the class space is JAXB as it generates accessors for all the fields. First thought is, gee, I wonder if we can do that at build time and keep the class definitions. If there's some way we could write down those classes, it could save us a lot of trouble at runtime. We'd get a great speed boost on the cold start -- which is where unit test performance lives. A while back I did some perf testing of our OpenEJB 3.0 speed and JAXB was nearly half of the time it took to boot. We have a bigger JAXB tree than we did and that can easily account for a sliver of the slightly slower embedded speed. The classes exist, so there has to be some way to write them to disk even if there is no magical flag that will make the JAXB RI do it for us. Would be great to know if such a flag did exist. If someone is looking for a research problem, this would be a great one. # Dead Classes In the case I was looking at, after deployment is finished and the app is started, we'll have loaded about 6,800 classes. Of that number 5,200 of them are classes we no longer need (no instances of them exist). Much of these are from the ConfigrationFactory stage where we use JAXB and many other classes. If we loaded the ConfigurationFactory via a TempClassLoader, used it once for deployment, then ditched the TempClassLoader, that could allow us to drop all those classes post deployment. Quite compelling for environments with small memory. Not any help if you have a few hundred MB of memory to play with. Side note, about 4,000 of those dead classes are our JAXB classes and the generated accessors. -David
