Issue Details (XML | Word | Printable)

Key: GLASSFISH-14419
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Sivakumar Thyagarajan
Reporter: Harald Wellmann
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Excessive memory requirements

Created: 04/Nov/10 07:58 AM   Updated: 20/Dec/10 12:44 AM   Resolved: 20/Dec/10 12:44 AM
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_ms08

Time Tracking:
Not Specified

Environment:

Issuezilla Id: 14,419
Status Whiteboard:

weld-int-required

Tags: 3_1-fishcat
Participants: Harald Wellmann and Sivakumar Thyagarajan


 Description  « Hide

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

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.



Sivakumar Thyagarajan added a comment - 10/Nov/10 05:39 AM

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


Sivakumar Thyagarajan added a comment - 19/Nov/10 07:50 AM

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


Sivakumar Thyagarajan added a comment - 19/Nov/10 08:01 AM

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


Harald Wellmann added a comment - 18/Dec/10 09:57 AM

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.


Sivakumar Thyagarajan added a comment - 20/Dec/10 12:44 AM

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.