Rule Execution Server and dead classloaders in permgen space of JVM

Resolving The Problem

If a ruleset is no longer used and is evicted from the RES ruleset cache, then references to that classloader and its loaded classes are dropped and the JVM is free to reclaim that space. The JVM implementation determines how long the dead class loaders remain in permgen. The fact that a classloader remains listed as dead does not mean that some reference is preventing it from being garbage collected, but mainly that it is up to the JVM implementation to eventually discard the classloader as part of garbage collection.

To reduce the number of classloaders needed for Rule Execution Server, either use RetePlus execution algorithm, or eliminate runtime rule selection if possible on Sequential rule tasks. Still, the generation and discard of classloaders to support runtime code generation is expected behavior.

Although doing frequent calls to "System.gc()" could help reduce the number of dead classloaders in permgen, it is not good practice to perform explicit garbage collection calls, and it is generally better to let the JVM determine a good time for it.

Note: with on the fly code generation ( as with JSPs and bytecode generated to support rulesets for example) the permgen space typically needs to be larger than applications with a more static codebase. The maximum size of the permgen space may need to be set correctly on the JVM (in particular with Sun/Oracle JVM implementations). There is no hard rule to configure it, the best is to perform load testing of the application with realistic load setup, including a few hot deployments, and monitor heap and permgen usage.