Summary: | [plan] Compiler/LookupEnvironment reset too frequently | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Andrew Clement <aclement> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P2 | ||
Version: | DEVELOPMENT | ||
Target Milestone: | 1.6.6 | ||
Hardware: | PC | ||
OS: | Windows NT | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 269605 |
Description
Andrew Clement
2009-03-20 14:40:40 EDT
this is as tricky as I imagined it would be. it appears the entire lifecycle of the compiler isn't managed correctly by AspectJ really - we constantly create new ones when we should be reusing one over and over. This hurts performance (as we continually discover information we previously knew) and causes problems like the one here where package bindings are forgotten due to a new LookupEnvironment (actually AjLookupEnvironment) being constructed for each build. Fixed!!! The problem is actually our StatefulNameEnvironment - a subtype of NameEnvironment that knows about stuff in the State instance maintained for a project. Some changes earlier this year to avoid rebuilding the StatefulNameEnvironment unless necessary failed to take into account that it still needed prodding about what the state object knew from the previous build. The fix here is to prod it even if we don't rebuild it. In this way on the incremental build we know about f.AClass and the method StatefulNameEnvironment.isPackage() can find it. This could well be the source of endless wierdness in Roo incremental builds. I don't know if this fix will address bugs dependent on this one as this one turned out to be something I didn't expect. This fix *may* affect incremental build times, hmmm. It isn't a delta update to the nameenvironment, it is a complete update from the state object. Ok, changed the fix - it is now delta processing so incremental builds won't be affected (I assert). |