KB and CDI model use data from jars, so that they are loaded at first request. If there are dependencies between projects in workspace then a request from one project loads all related projects. There should be only one JarAccess object for a jar. If several projects use the same Maven dependencies and/or Runtime, they should use same JarAccess object for each jar. Now, a new Java EE Web project created from JBoss Central has in Maven Dependences and JBoss AS 7.1 Runtime 170 jars. So, it is probable that your workspace does reference 900 or more distinct jars. Could you please check that. If the number of distinct jars in your workspace is much less, than there is a memory leak with JarAccess. Instances of JarSystemImpl are created for each jar in each project, but they are sharing data if they reference the same jar, so that if there are 6.044
Instances of JarSystemImpl but only 900 distinct jar files, then only 900 of JarSystemImpl instances will be loaded, the other will be lightweight references to them. These objects are lazy-loaded that is they load only as much data as requested. However, KB builder now searches through the entire jar for files myfaces-metadata.xml and facelet taglib files; and in this way results in complete loading of data which cannot be easily released being shared between projects. So, I think that we have to check if we can avoid scanning through the entire jar.