Running the jmap -permstat <pid> command against a process running Rule Execution Server shows many dead classloaders such as:
0x00000007abec4820 0 0 0x000000078baeac60 dead ilog/rules/util/IlrBinaryClassLoader@0x00000007736dde50
0x00000007ab8fb678 2 273192 0x00000007ab8fb6c8 dead
How can we reduce the amount of permgen space required by these classloaders?
Upon parsing of a ruleset, a classloader can be created (in particular with rulesets containing Sequential rule tasks) so that bytecode generated on the fly from the ruleset can be loaded into the JVM.
The amount of code generated depends on the number of rules (and the amount of B2X code in the BOM used by these rules) that are executed with Sequential/Fastpath mode, since bytecode is generated at runtime for the execution of the rule tasks.
When runtime rule selection is configured on a rule task that uses Sequential or Fastpath algorithm, a classloader may be generated just for the duration of each execution of that rule task, which can lead to more classloaders created and discarded than in situations with static rule selection.
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.
|Business Integration||IBM Operational Decision Manager||Platform Independent||8.0.1, 8.0, 7.5|