Community
Participate
Working Groups
Recently Caching capabilities have been added. However we believe that at a cost of some restrictions caching could be done much more efficiently. In case one unique aop.xml is present within the LTWoven JVM, the caching mechanism can be done in an upper level avoiding WeavingAdaptor to be initialized. Additionally using class name + CRC sum as cache index, at this particular level, allows the same class not to be woven several times when adding common libraries for every application. (So the weaving effort and cache efficiency would be improved by this sharing mechanism) Here you are some of the figures of this proposed cache system and the current one: (bare in mind intensive instrumentation is done including all methods and classes during this setup) ------------ jBoss startup time without AspectJ: 3 mins and 6 seconds. jBoss startup first time -caching- with the current cache system: 50 minutes approximately. jBoss startup second time -caching- with the current cache system: 30 minutes jBoss startup with aspectj and no cache at all: 22 minutes. With the proposed cache system: jBoss startup first time -caching- with the proposed cache system: 8 minutes approximately. jBoss startup second time -caching- with the proposed cache system: 3 minutes and 9 seconds. (only 3 seconds delay). ------------- We are finishing to tune tests, and tight all together, but within the next days we will be uploading the patch to include this cache system as a non default option. In order to enable it, you will require to setup the next property: aj.weaving.cache.impl=perloader - would select the existing one - this would be the 'default' if not specified so 1.7.X behaves just like 1.7.0 if this isn't specified. aj.weaving.cache.impl=shared - would select this new shared variant that is sharing the state across loaders. Thanks and regards.
Created attachment 219525 [details] shared cache Please find attach the implementation patch. Tests are still pending
Created attachment 219643 [details] Patch to extend test engine, so full LTW (invoking javaagent option) can be added
Created attachment 219644 [details] Patch that include shared cache simple unitary tests
Created attachment 219645 [details] Simple e2e test for cache system (shared and per class loader)
Added all the patches and basic tests. In order to use the new test functionality test xml definition supports usefullltw="true", when set to true, instead of testing through UrlWeavingClassLoader full agent instrumentation is used. See the next example: <ajc-test dir="features171/pr386341" title="Test Default Cache Per ClassLoader"> <compile files="A.java" options="-1.5"/> <compile files="X.aj" options="-1.5 -Xlint:ignore" /> <run class="A" ltw="aop.xml" usefullltw="true" vmargs="-Daj.weaving.cache.enabled=true -Daj.weaving.cache.dir=./" > <stdout> <line text="It Worked-before"/> <line text="It Worked-after"/> </stdout> </run> Also it is important to notice that vmargs functionality, that even present in dtd was not working, now is implemented only for usefullltw mode. The remaining tests are very basic, but fair enough as a starting point. They have been created agains our SVN image, so revision numbers will not match GitHub...
I was just applying some of these things. I made a change: I'd rather not build SimpleCache objects if they aren't being used so I adjusted the creation code and guarded the code that references them. New tests seem to still pass... but you might want to cast an eye over it. The default cache location won't work on windows, ideally it should be based on the platform (so c:\temp on win), but I'm ok with it staying as /tmp for now. What does the la in lacache stand for? last Accessed? I've pushed these changes (or at least they are committed locally and when my stupid network starts behaving, I'll push them). One peculiar thing. If I run AllTestsAspectj171 then all tests pass, but when I run 'NewFeatures' by itself, the first test fails. I'm not sure if it was always like that or it is just my initialization changes.
