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
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