Community
Participate
Working Groups
In a heap dump of an OTDT that has been working for quite some time I can see that almost 50% of the memory are consumed by class org.eclipse.objectteams.otre.RepositoryAccess via static field repositories. This hashmap keeps instances of JavaClass for further lookup, but most clients of this lookup are only interested in superclass/ifc linkage. Only one location uses the JavaClass for searching a method signature. This is during ObjectTeamsTransformation.addTeamInitializations() while evaluating a team-config for standalone OT/J app. It should be possible to store this information in a much more compact form.
Created attachment 201992 [details] Implementation of diet class loading This patch implements diet versions of ClassLoaderRepository, ClassParser and JavaClass, which only read structural information and dispose the constant pool after reading. Only one client needs to lookup a method signature: ObjectTeamsTransformation.addTeamInitializations(), which is now handled by a new method lookupClassFully(). When running the OTDT (SDK based install) with OT perspective and a team class open, I could observe (using MAT) the following improvement: Old: class RepositoryAccess retains 239 MBytes on the heap! New: class RepositoryAccess retains 2.3 MBytes on the heap!
Patch has been released for 2.1 M2 (r1959).
Verified: using 2.2 M5 RepositoryAccess is no longer relevant in terms of retained memory.
