Community
Participate
Working Groups
Moving to a pipelining architecture in AspectJ is hard. The interplay between static crosscutting constructs (ITDs, declares) makes it hard to process types one at a time - that's why we have the current model of: 1. compile everything 2. fix up the type system based on ITDs 3. weave everything At step (2) we are consuming a large amount of memory. In the ideal pipeline system we move to a model where we compile and weave one file at a time (obviously compiling the aspects first so that weaving can be done correctly). A first step towards pipelining could ignore the complexities of ITDs/declares and say that if the user is simply using pointcuts and advice (dynamic crosscutting) then we pipeline, if they are using the more complex constructs then we operate as today. This would mean that new users that always start with just pointcuts and advice would get the best initial experience using AJDT.
Changed the name of this bug as I don't need to single out dynamic crosscutting - my prototype pipeline can handle ITDs too. Current memory gains are looking quite promising. I'm making changes throughout the projects, from down in AjBCEL to up in the modified JDT that we have.
Created attachment 46806 [details] JConsole images First pictures of memory gains. Both pictures are for building shadows, which includes multiple aspects in a 1000 file project. Running with an Xmx of 256M. memory_head.bmp shows the compiler from HEAD on 26th July 06 memory_pipeline.bmp shows my prototype pipeline compiler variant. check the scale on the left hand side of the images. Oh, and the pipeline compilation is faster too.
Very impressive. When can I try it out?
Pipeline code is in. Turned ON by default, can be deactivated: -Xset:pipelineCompilation=false The other option -Xset:runMinimalMemory=true can make a further difference for batch builds, that is currently off (it is ignored in AJDT anyway). I may look at turning it on if I can reduce the processing cost of it and get it behaving under AJDT. Without runMinimalMemory, building shadows without the pipeline needs 220M, building shadows with pipeline needs 70M. With runMinimalMemory you can take another 20M off the pipeline requirements. What has gone in: - multiple compiler adapter classes - one for normal non-pipelined compilation, one for pipelined compilation - new lifecycle hook in the compiler for sorting units post diet parse to ensure aspects done first - new 'woven aspect/class' message to match the 'compiling' message - new eclipseresolvedmember for answering deeper questions about uncompiled types, may need further extension - eclipsesourcetype enhanced to do basic transformation from eclipse annotation to aj annotations, covers only minimal set of possible annotation forms, may need future extension. Right now will crash 'nicely' when it encounters an unknown form - compilation time message now comes out of main (info) - bcelobjecttype changes to store superclass/superinterfaces in signature form, not resolvedtype form - prevents unwanted anchoring of supertypes in the typemap - adviceDidNotMatch logic slightly changed, but still works in both pipeline and non-pipeline. next steps - observe operation under AJDT. May not appear to use drastically less memory when it is available but rather be much better at coping when Xmx isn't so high.
Contrasting pipelining, what a work of art: pipelining off: telecom>ajc -verbose -Xset:pipelineCompilation=false @billing.lst directory classpath entry does not exist: c:\jvms\sun150_06\jre\lib\i18n.jar directory classpath entry does not exist: c:\jvms\sun150_06\jre\lib\sunrsasign.jar zipfile classpath entry does not exist: c:\jvms\sun150_06\jre\classes compiling telecom\AbstractSimulation.java compiling telecom\BillingSimulation.java compiling telecom\Call.java compiling telecom\Connection.java compiling telecom\Local.java compiling telecom\LongDistance.java compiling telecom\Customer.java compiling telecom\Timer.java compiling telecom\Billing.java compiling telecom\Timing.java weaver operating in reweavable mode. Need to verify any required types exist. woven aspect telecom.Billing (from telecom\Billing.java) woven aspect telecom.Timing (from telecom\Timing.java) woven class telecom.AbstractSimulation (from telecom\AbstractSimulation.java) woven class telecom.BillingSimulation (from telecom\BillingSimulation.java) woven class telecom.Call (from telecom\Call.java) woven class telecom.Connection (from telecom\Connection.java) woven class telecom.Local (from telecom\Local.java) woven class telecom.LongDistance (from telecom\LongDistance.java) woven class telecom.Customer (from telecom\Customer.java) woven class telecom.Timer (from telecom\Timer.java) pipelining on: telecom>ajc -verbose @billing.lst directory classpath entry does not exist: c:\jvms\sun150_05\jre\lib\i18n.jar directory classpath entry does not exist: c:\jvms\sun150_05\jre\lib\sunrsasign.jar zipfile classpath entry does not exist: c:\jvms\sun150_05\jre\classes Pipelining compilation compiling telecom\Billing.java compiling telecom\Timing.java weaver operating in reweavable mode. Need to verify any required types exist. woven aspect telecom.Billing (from telecom\Billing.java) woven aspect telecom.Timing (from telecom\Timing.java) compiling telecom\AbstractSimulation.java woven class telecom.AbstractSimulation (from telecom\AbstractSimulation.java) compiling telecom\BillingSimulation.java woven class telecom.BillingSimulation (from telecom\BillingSimulation.java) compiling telecom\Call.java woven class telecom.Call (from telecom\Call.java) compiling telecom\Connection.java woven class telecom.Connection (from telecom\Connection.java) compiling telecom\Local.java woven class telecom.Local (from telecom\Local.java) compiling telecom\LongDistance.java woven class telecom.LongDistance (from telecom\LongDistance.java) compiling telecom\Customer.java woven class telecom.Customer (from telecom\Customer.java) compiling telecom\Timer.java woven class telecom.Timer (from telecom\Timer.java) it shows: - the switch from compile/compile/compile/weave/weave/weave to compile/weave/compile/weave - the stalling of the weave pipeline until the aspects have been compiled
delivered in AJ and AJDT now... possible follow on work could do the same for binary weaving but that isn't as trivial as you might think.
