First things first:
1. This is not a real production quality patch. It contains some ideas and major design changes that I tried when trying to make Velocity 1.6 new macro implementation perform better. I have done some functional, performance and load testing but not nearly enough.
2. Although tests pass, I have most probably broken some functionality especially regarding error messages and namespaces.
3. I have tested these changes with several hundred concurrent threads which does not mean that they are free from race conditions, locking issues etc. nasty stuff.
4. Even after this patch Velocity 1.6 svn head is around 10-20% slower than 1.5. I didn't investigate 1.5 code that much but I suspect that Velocity 1.5 fully preconstructs templates by duplicating macro AST and precalculates values for constant macro arguments. This patch however uses shared macro ASTs which should reduce memory usage but introduces a bunch of new problems.
5. There are public interface changes (yep, bad).
Main ideas of this patch:
1. When a macro is parsed and thrown into Macro.processAndRegister, it is not transformed and stored as String but as AST.
2. VelocimacroManager does not create new VelocimacroProxy for each request but creates one per macro / namespace. Thus threads share the macro AST.
3. VMContext and VMProxyArg have been replaced with ProxyVMContext. This allows us to skip parsing of macro arguments when macro is invoked and it reduces memory allocation overhead.
4. "Render literal if null for references" is tricky to implement with shared macro AST. Velocity 1.5 implements this by preprocessing the AST tree with visitor.VMReferenceMungeVisitor. As far as I understand, this is not possible with shared macro AST. Therefore there's a rather ugly hack which puts macro argument references to the macro rendering context. ASTReference can then construct the literal format of arguments on-demand.
1. ExtendedProperties class is synchronized and very slow overall (it even says so in the JavaDocs). There are quite many runtime calls to this class throughout the Velocity code.
2. I haven't really investigated yet if this version even uses less memory than 1.5. If the memory usage isn't significantly lower, I don't see much point in using 1.6 if one doesn't need the new macro functionality.
3. I probably made some catastrophic design mistakes but it takes time to understand velocity functionality and design. Please forgive me.