issue 34046 velocity memory & sync issues

[wezell]

Complete Session Summary - All Optimizations

Area	File	Optimization	Impact
String Pools	StringifyObject.java	ThreadLocal StringBuilder + SimpleDateFormat	~5-7 allocations/stringify
String Pools	PageRenderUtil.java	ThreadLocal StringBuilder	~1 StringWriter/page
Buffer Management	VelocityLiveMode.java	Capacity-limited buffer with trim	Memory cap per thread
Singletons	VelocityUtil.java	Singleton viewtools	~3-7 allocations/context
Cache Keys	PageCacheParameters.java	ThreadLocal TreeSet + StringBuilder	~2 allocations/page
Content Rendering	ContentMap.java	ThreadLocal StringBuilder + StringWriter	~2 allocations/contentlet
Page Cache	StaticPageCache.java	byte[] instead of String	Eliminates String↔bytes roundtrip
Page Cache	VelocityLiveMode.java	Use byte[] cache methods	Zero-copy cache serving
Resource Loading	DotResourceLoader.java	Striped lock with 15s timeout	Prevents thundering herd
Velocity Parsing	ASTMethod.java	ThreadLocal array pools	~2 arrays/method call → 0

Additional Velocity Optimizations Implemented

1. ASTStringLiteral.java - Interpolated String Pool

Problem: Every interpolated string like "Hello $name" created a new StringWriter.

Solution: ThreadLocal StringWriter pool

  private static final ThreadLocal<StringWriter> STRING_WRITER_POOL =
          ThreadLocal.withInitial(() -> new StringWriter(256));

Impact: Pages with 50+ interpolated strings save 50+ allocations per render.

2. Block.java - Block Reference Pool

Problem: Block references (used with #define and #block) created new StringWriter on toString().

Solution: ThreadLocal StringWriter pool for the inner Reference class.

Impact: Eliminates StringWriter allocation per block reference conversion.

3. ASTMethod.java - Array Pools (from earlier)

Problem: Every method call $foo.bar(arg) allocated 2 arrays.

Solution: ThreadLocal Object[] and Class[] pools for 0-8 parameters.

Impact: Eliminates ~2 allocations per method call.

---

Complete Velocity Optimization Summary

File	Optimization	Hot Path	Impact
ASTMethod.java	ThreadLocal Object[]/Class[] pools	Every $foo.method()	~2 allocs/call → 0
ASTStringLiteral.java	ThreadLocal StringWriter	Every "text $var"	~1 alloc/string → 0
Block.java	ThreadLocal StringWriter	Block toString()	~1 alloc/block → 0

What Was NOT Changed (Already Optimized or Not Hot Paths):

• PropertyExecutor/BooleanPropertyExecutor - StringBuilder in discover() is cached, not hot
• ASTObjectArray - Must allocate new ArrayList (semantic requirement)
• Info objects - Created during init(), cached
• SimpleNode.literal() - Already caches result

---

Full Session Summary - All Memory Optimizations

Area	Files Changed	Key Optimization
String Buffers	StringifyObject, PageRenderUtil, ContentMap, PageCacheParameters	ThreadLocal StringBuilder/StringWriter
Page Cache	VelocityLiveMode, StaticPageCache	byte[] instead of String, capacity limits
Viewtools	VelocityUtil	Singleton instances
Resource Loading	DotResourceLoader	Striped lock with timeout
Velocity Parsing	ASTMethod, ASTStringLiteral, Block	ThreadLocal array/writer pools

Estimated Total Impact

For a typical page with 30 contentlets, 100 method calls, and 50 interpolated strings:

• Before: ~300-500 temporary object allocations per render
• After: ~30-50 allocations (mostly final toString() calls)

~90% reduction in allocation rate for typical page renders.

[wezell]

Sped up DotConcurrentFactoryTest

Key Optimizations

1. Reduced sleep in PrintTask: 500ms → 20ms
2. Reduced sleep in ConditionalSubmitter test: 8 seconds → 200ms
3. Reduced iteration counts: Only as many as needed to verify behavior
4. Eliminated busy-wait polling loops: Replaced with Future.get() awaits
5. Used proper assertions: assertSame/assertNotSame instead of assertTrue/assertFalse
6. Added proper shutdown: ExecutorService cleanup

Estimated Time Savings

Before	After
~60-90 seconds	~2-3 seconds