eclipse-ocl-bot
commented
1 month ago By Adolfo Sanchez-Barbudo Herrera on Mar 05, 2010 05:11
Ed, I think that this is an interesting bug to take into consideration. However, this needs some studies of the code and leaks discoveries are not trivial. Due to the fact that I currently have very limited time to invest on OCL, I think it's better investing time on other bugs.
I'll start with the documentation's one.
Cheers,\ Adolfo.
| --- | --- | | Bugzilla Link | 302815 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 14, 2010 07:06 EDT | | Modified | Nov 08, 2011 04:58 EDT | | Version | 3.0.0 | | Blocks | 318375 | | Reporter | Ed Willink |
Description
Bug 191689 will make the following usage much more common:
Create an OCL.\ Repeatedly invoke evaluate/createQuery/check as each new Ecore annotation is parsed and evaluated.
Bug 191689 attempts to reduce overheads by caching an OCL per package, and by caching compiled OCLExpressions for each OCL text string. I am working to improve this caching, some of which I think is misconceived but motivated by very poor OCL reuse behaviour.
Most notably: AbstractBasicEnvironment.astNodeToCSTNodeMap is positively evil for the above usage pattern. It ensures that the AST locks the CST in memory, which ensures that the Tokens are also stuck in memory. These are useful to editor applications and diagnostics but not thereafter to evaluations.
A very simple fix is to ensure that either AbstractBasicEnvironment.getASTNodeToCSTNodeMap().clear() or AbstractBasicEnvironment.setASTNodeToCSTNodeMap(null) is invoked once diagnostics associated with the parse aspect of an evaluation have been processed.
OCL has many other member variables that may contribute to leaks. My introduction of the reflective tearDown in the tests was driven by leaks caused partly by the OCL instance, but also by the test harnesses. We need to tackle the OCL instance leaks.
I think we should introduce an OCL.reinitialize() method that minimises the retained context, and ensures that the associated analyzer and parser and lexer are able to be re-used.
Adolfo: I think you were interested in ensuring that parsers were reusable; would you like to look at (and test) this?