On Sep 26, 2011, at 12:43 AM, David Blevins wrote: > 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.
Note on this part. I did hardcode an experimental version of "just load the app classes with the TempClassLoader" and things seemed quite efficient. Only trouble in trimming at all was the more you trimmed the more you risked getting a LinkageError later. Those are pretty much harmless and a second attempt to load the class usually does the trick. Unfortunately the LinkageErrors all came from the Tomcat StandardClassLoader which we don't control. Tempting to send a patch for a LinkageError retry ... and perhaps create an 'endorsed' version of the class in the meantime. With this out of the way we could really cut down the perm gen and guarantee that any resulting harmless LinkageErrors are not fatal. -David
