I see your point, but we're talking about allocating and copying up to 30000 X 64 bytes every time any sector changes. And changes would include update timestamps, so it would reallocate at least once every time any sector is viewed. I'm thinking java.util.concurrent.atomic.AtomicReferenceArray might be useful...

Yes, good idea, that'd fit nicely for sectors. Outside a ztm script, I doubt you'd have very many writes, especially as the parser determines if the value changed first, but if you know the size ahead of time, that class would do nicely. The point is any of those optimization should be behind a service layer, so it shouldn't matter for the clients and you can optimize later as you find bottlenecks.