quality@glassfish.java.net

Re: Reducing Memory Footprint

From: Richard Kolb <rjdkolb_at_gmail.com>
Date: Wed, 8 Jun 2011 07:32:43 +0200

Hi Tim

On 3 June 2011 16:40, Tim Quinn <tim.quinn_at_oracle.com> wrote:

> As for the non-Weld aspects of this, there are some small changes with what
> we hope will be major impact we're testing. They are not yet in the builds
> but should be soon if the testing goes well.
>

Great, I will be more than happy to test.
I assume the issue will fix a lot of perm Gen issues ?

I have a bunch of issues logged here with maven samples :
http://java.net/jira/browse/GLASSFISH-16604

Also for 230 deploy of ScrumToys PS Old gen and PS Eden looks exhausted
(bottom of this issue http://java.net/jira/browse/GLASSFISH-16656)

regards
Richard



>
> - Tim
>
>
> On Jun 3, 2011, at 7:50 AM, Richard Kolb wrote:
>
> Hi Harald
>
> Great to see you still working with the WELD issue.
>
> I have another issue with weld in Glassfish 3.1 , maybe related ?
> Perhaps you can put in some of your input.
> http://java.net/jira/browse/GLASSFISH-16655
>
> thanks
> Richard.
>
> On 3 June 2011 13:37, Harald Wellmann <harald.wellmann_at_gmx.de> wrote:
>
>> Glassfish pre-3.1 used to have severe memory issues, mainly due to Weld
>> which I'm glad to say are gone since integrating Weld 1.1.1.Final.
>>
>> On the other hand, Glassfish still uses excessive amounts of memory, now
>> due to its own internal structures.
>>
>> Deploying the same WAR to two different servers, triggering GC and taking
>> a heap dump with Eclipse Memory Analyzer, I get the following measurements:
>>
>> Glassfish 3.1.1-b06 ~250M
>> Resin 4.0.pre19 ~ 60M
>>
>> A slightly different version of the same app running on Tomcat 6 and
>> Spring 3 has a footprint of ~ 50M.
>>
>> As long as these figures don't change, it will be next to impossible to
>> convince people to move from custom Tomcat-based solutions to Glassfish.
>>
>> The Memory Analyzer clearly identifies the culprit, please see
>> http://java.net/jira/browse/GLASSFISH-16747 for details.
>>
>> It seems the root cause is still the same as reported in GLASSFISH-15266
>> during the 3.1 stabilization phase.
>>
>> I do hope someone can look into this issue and fix it before the 3.1.1
>> release.
>>
>> Best regards,
>> Harald
>>
>
>
>