Description of problem: During our profiling of SPECjEnterprise2010, we discovered a very large number of sun.reflect.GeneratedSerializedConstructor* objects being creating, taking the vast majority of the heap space, and they are end up in the old generation, causing large garbage collection spikes. This causes scalability problems with EAP. Version-Release number of selected component (if applicable): JBoss Marshalling 1.3.x How reproducible: Always, with any EJB remote calls. Steps to Reproduce: 1.Run SPECjEnterprise2010 at tx1400 rate. 2. 3. Actual results: Over 2.5 GB's of memory in the old generation will be seen (JProfiler) just for two of these constructor objects, and more than 3GB's of memory consumption when you count all constructor object references. Expected results: Should be very few instances, with a very small memory footprint. Additional info: The 1.4.0 version that David Lloyd has tagged as Final today, contains the fix for this problem. The EJB client library will have to be rebuilt along with JBoss Marshalling in order for this to work properly.
Also, I forgot to add that this issue is in JIRA as: https://issues.jboss.org/browse/JBMAR-153
Changed the component to remoting, since JBoss Marshalling is a part of Remoting.
Initialized flags.
Please be sure to also ack https://bugzilla.redhat.com/show_bug.cgi?id=1003990 if you ack this issue.
Verified with EAP 6.2.0.ER1.
Brad Maxwell <bmaxwell> made a comment on jira JBMAR-153 Background info: Originally JBoss Marshalling used a weak map so that it would not leak memory when a deployment was undeployed. This had a side effect, if a weak reference was cleared, JBoss Marshalling would generate a new constructor, except the JDK still kept the reference to the old one. So they would pile up over time, especially if you GC a lot in between invocations for whatever reason. The fix is to never regenerate them, by replacing the weak map with a strong map. Since a strong map is used the API had to be changed so that on undeploy the map could be released and avoid a memory leak, which the JBoss EAP code calls when an application is undeployed.