Zen of class loading, Jason Green

JBossWorld Boston, Jason T Greene, Zen of class loading

What is the Class class
– represents a class
– allocates memory on heap and permgen
– is referenced by every object instance of that class
– Unique (by name) only to a ClassLoader
– holds a reference to the ClassLoader

What is a ClassLoader
– responsible for loading classes
– holds strong reference to all classes it loads
– optional parent for delegation

Problem #1 – OutOfMemory:PermGen
– too many classes loaded
– sizing could be wrong, big application with many classes
– possible classloader leak
— hot deployment causes new classloader
— one instance to an object prevents garbage collection of all classes loaded by the classloader

Common leak sources
– static field on a class with a long lifecycle (on another classloader)
– caching frameworks
– persistent thread locals (automatic cleaning is *very* important)
– framework bugs (logging frameworks, third-party frameworks)

JDK class loading delegation
– parent-first prevents overriding a parent
– custom classloaders can do this (and they do!)
– bootstrap is searched even if parent==null
– bootstrap classes often return null for getClassLoader()

JDK has default hierarchy
– boot classpath (including lib/endorsed)
– application/system loader (defined class path)
– user loader

Problem #2 – ClassNotFoundException
– classes are not visible to the loader
– unintentional ref/dep
– solution: audit cross jar references (Tattletale)

EE class loading model
– child-first allows deployments to override parent classes and jars
— support bundling a diffrent version of a framework than in the ear
– EJB jars share classes with the EAR
– WARs do not share classes, but do see classes in the EAR
– RARs and global EJB-Jars visible to everyone

Problem #3 – ClassCastException on the same name
– duplicate class in isolated loaders
– usually a packaging problem
– common scenario – bundling ejb local interfaces in a WAR

Domain based models (default class loader)
– hot deploy requires classloader per deployment
– normal classloader isolations disallows pass-by-reference
– domains allow class sharing between class loaders
– duplicate classes are resolved using fist-come-first-server
– allows big ball-of-mud
– shared class cache
– default : one domain (defaultDomain) for all, plus one for each WAR
– fix : isolate ears in deployers/ear.deployer

Evolution to module class loaders
– applications don’t always fit hierarchical models
– declare specific dependencies, each jar is a module
— each jar declares dependencies on a name and version
– module system responsible for mapping to class loader (delegation map)
– module has imports and exports

OSGi bundle = module mentioned here, require-bundle, import-package, export-package

AS5 support package and module import/export, jboss-classloading.xml (import=requirements, export-capabilities)
domain style model is also possible

future :
– JDK7 is probably going modular (project jigsaw – JSR-294)
– EE7 will probably follow
– AS7 will be modular

Tattletale can produce module descriptors using a plug-in

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen