[GLASSFISH-14419] Excessive memory requirements Created: 04/Nov/10  Updated: 19/Dec/16  Resolved: 20/Dec/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: Linux
URL: http://hwellmann.blogspot.com/2010/11/cdi-major-risk-factor-in-java-ee-6.html

Issuezilla Id: 14,419
Status Whiteboard:


Tags: 3_1-fishcat


In addition to the memory leaks occurring on application redeployment (see
#12368), Weld requires excessive amounts of memory even for a moderately sized

My WAR (using Wicket+EJB+JPA) running on Glassfish 3.1-b26 requires about 400 MB
heap memory. The Eclipse Memory Analyzer reveals that almost 200 MB are occupied
by instances of org.jboss.weld.introspector.weld.jlr.WeldClassImpl.

Downgrading my application to Java EE 5 style injections with @EJB instead of
@Inject, I could cut the memory usage of my application by 50 %.

Other projects may have different priorities, but for me, this is a severe
quality issue which made me stop using CDI altogether, until this issue is solved.

Comment by Sivakumar Thyagarajan [ 10/Nov/10 ]

We have been working with the Weld team to making improvements around memory
usage of Weld. This is being addressed in their current 1.1 release. We had
integrated an initial build of 1.1 earlier in GF3.1 and had some improvements.
We plan to integrate Weld 1.1.0.Beta2 in the next couple of days and it also has
changes in the generated proxies and their classloading which should result in
lesser footprint. Your blog is also being discussed in weld-dev [1] and I see
more analysis and activity around reducing the footprint further.

[1] http://lists.jboss.org/pipermail/weld-dev/2010-November/002707.html

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Marking this as weld-int-required as we need fixes in the Weld side for this.

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Marking this as 3.1_ms08, as hopefully we would have the 1.1.RC1 by then.

Comment by Harald Wellmann [ 18/Dec/10 ]

In 3.1-b33, the heap usage of Weld has gone done down drastically. See http://hwellmann.blogspot.com/2010/12/update-on-memory-issues-in-glassfish.html.

Maybe there's still some room for improvement, but this is a big step forward.

Comment by Sivakumar Thyagarajan [ 20/Dec/10 ]

GFb33 had an older version of Weld (1.1.0.Beta2), but we did fix a couple of GF side memory leaks (GLASSFISH-14803 and GLASSFISH-14801).

However Weld 1.1.0.CR1 has made a lot of progress in the performance, memory footprint and startup time fronts. Here is a snippet from the Weld 1.1.0.CR1 release http://in.relation.to/Bloggers/Weld110CR1AndCDITCK102
– snippet from Weld 1.1.0.CR1 release notes –

  • Performance improvements (around 40% on the previous release, meaning Weld performs as well as, or better than other CDI implementations and other DI engines in our tests)
  • Startup time improvements (around 20 times faster in extreme cases)
  • More improvements in memory usage, with more planned for 1.2.0 (we're aiming at 1k per class deployed)
    • snippet from Weld 1.1.0.CR1 release notes –

A bunch of these fixes were made in https://github.com/stuartwdouglas/core/commits/memoryUsage and later merged into trunk. This is their biggest "feature" in 1.1.0.CR1. We integrated Weld 1.1.0.CR2 today into GF3.1 trunk and don't see any obvious memory leaks yet.

With your comment in GLASSFISH-15266, I also see that you don't see any major memory leak issues in the Weld/CDI integration and so I am closing this issue. Please reopen a new bug if you still see any new CDI related issues. Thanks again for filing this issue.

Generated at Sat Mar 25 13:48:38 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.