startup and footprint of larger size application deployment to 3.x

[glassfishrobot]

Refer to this blog for description of the problem: http://ktschmidt.blogspot.com/2011/04/is-glassfish-v3-slower-and-bigger.html

Scott Oaks confirmed that the startup time issue is valid.

Also refer to this forum thread: http://forums.java.net/node/798503

Affected Versions

[3.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/16355
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: Assign the umbrella issue to Tom. The deployment could have a sub issue of the umbrella issue.

[glassfishrobot]

@glassfishrobot Commented tmueller said: Not sure why this is an admin issue. Assigning it to performance.

[glassfishrobot]

@glassfishrobot Commented ai109478 said: Adding 3_1-next tag. We need a fix for this during 3.1.1.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Linking the apparent MQ start-up regression to this more-or-less umbrella issue.

[glassfishrobot]

@glassfishrobot Commented sdo said: Remaining different in heap usage after startup is attributable to retained gmbal-related references.

[glassfishrobot]

@glassfishrobot Commented sdo said: We are tracking a new set of tests for this in 3.1.2.

In this set of tests (which includes one large app with multiple jars and wars, including EJBs, JSPs, MDB, etc., and one smaller web app), the heap after starting with the apps deployed in 2.1.1 consumes 41.2MB; in 3.1.2 it consumes 59.7MB. This is before an ORB is started, and hence does not include the gmbal-related references. [So that earlier comment about everything being related to gmbal is in error.] There is no load generated in this test, so lazily-initialized things will benefit the test, which may or may not be a good thing (but it follows the scenario in the posting that drives this bug).

Where does that 18.5MB come from? Here is the short answer: Additional classes: 4MB HK2: 4MB Felix: 5MB Grizzly: 3MB Stats Provider: 2MB

In a scenario like this where a significant part of the EE modules are loaded, one place we lose out is in the infrastructure for modularization. In simple terms of classes loaded, 3.1.2 is loading 11% more classes (10K vs 9K), and the class objects themselves consume 50% more heap (12M vs 8M). That is a reflection of the added features as well as the added modularization, of course.

Then there is the memory consumed by instances of the classes. The single instance of org.jvnet.jk2.component.Habitat consumes 1.6MB of heap. However, there are are other habitats (subclasses) as well, and they are consuming at least another 1.2MB of heap (for their MultiMap) and a significant amount of memory for the LazyInhabitant objects. Total consumed by HK2 is in excess of 3.9MB.

Instances of Felix classes consume at least 4MB of heap (not including the classes held by the Felix ModuleClassLoader). The big amounts of memory there are held by Felix ModuleImpls (again not including the inner classloader objects); memory here is consumed by CapabilityImpl, RequirementImpl, and ResolverState. I realize there is overlap between some of those classes, but the 4MB calculation in the tool will have removed that overlap, and in particular the 1.2MB of heap consumed by ResolverState appears independent of the CapabilityImpl/RequirementImpl. So without understanding the code better, I can just say that it heap usage is between 4 and 5.2MB (or bigger).

Grizzly processorTasks consume 3.1MB more heap. In 2.1.1, the three processor tasks queues consume 2.25MB of heap In 3.1.2, the there five processor tasks queues consuming 5.3MB of heap This is a default-configured domain

Stats Provider Registry consumes 2MB of heap

[glassfishrobot]

@glassfishrobot Commented sdo said: The extra classes contribute as well to the regression in the time to restart the server: they cause a few expansions of the perm gen as it fills up with the extra classes.

In 2.1.1, a server restart with the EJB apps deployed goes through one resizing of permgen on my laptop; in 3.1.2, there are three or four. If we increase the initial size of perm gen (keeping the max size at 192m), we can improve the server restart in this scenario by 11%. But that will affect the footprint of other smaller deployments, so some discussion on the trade-offs here needs to occur.

[glassfishrobot]

@glassfishrobot Commented @barchetta said: We won't be making any more progress on this for 3.1.2 so I'm excluding from the release. We did get a gmbal fix into Metro that helps WS applications, but not EJB. The ORB fix has proven more difficult (see linked gmbal bug).

[glassfishrobot]

@glassfishrobot Commented tmueller said: Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

[glassfishrobot]

@glassfishrobot Commented Issue-Links: depends on GLASSFISH-16543 GLASSFISH-17044 GLASSFISH-16540 GLASSFISH-16460 GLASSFISH-16747 GRIZZLY-1144 GLASSFISH-17914

[glassfishrobot]

@glassfishrobot Commented Was assigned to sdo

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-16355

[glassfishrobot]

@glassfishrobot Commented Reported by ai109478

[github-actions[bot]]

This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment