Community
Participate
Working Groups
Tests show that each object consumes 180+ bytes. For a large project (1000+ classes) where an aspect is used to implement a pervasive cross-cutting concern e.g. exception logging this can lead to >1MB of additional heap space. Two possible approaches could be: 1. Break literal String used by Factory.makeXXXSig() methods into component parts e.g. package, class, method. ... names. These could then be shared automatically by the JVM as interned Strings. 2. Lazy instantiation of handler static JPs in the catch block. Any enhancements could be enabled by a compiler option similar to -XlazyTjp.
Adding Noel CC
Created attachment 10392 [details] Patch to implement option (1) I am appending the attachment from Noel Markham that implements option (1) of the two strategies proposed for addressing this problem. Noel says: --- Please find attached two patches: LazyClassGen.java and Factory.java, for reducing the footprint of JoinPoint.StaticPart objects. Currently, only the methods makeMethodSig() and makeCatchClauseSig() in Factory.java take a broken-up set of parameters. Since the generated code is enclosed in a static block, it is only run once and shoudn't affect the performance too much. Using my FFDC Simulation tests, the free heap size (on a 4Meg heap) has been increased from ~600k to ~1.6M. On the test, 1000 classes are produced, each with four catch blocks. The class names(fully qualified with package name) are approx 60 chars, and the method names are approx 40 chars. ---- My only concern with the approach is using makeClass() which calls Class.forName() - I wonder if that is necessary - but I haven't become an expert on this area of code like Noel has so I can't say yet !
Created attachment 10445 [details] New version of patch to implement (1) This patch creates overriding methods for makeMethodSig(), makeConstructorSig(), makeFieldSig(), makeAdviceSig(), makeInitializerSig() and makeCatchClauseSig() in Factory.java The code to use these methods instead of the one-String parameter methods is in the second file, a patch for LazyClassGen.java This patch supersedes the previous submission.
This could reduce memory usage in AJ programs and it is worth looking at integrating this patch in AJ5 M4. Note that tjpsp currently provides a stable and unique hashCode for use in Maps etc.. Any change to the implementation must preserve this property.
patch updated and applied.
