>https://github.com/JCTools/JCTools) instead of Dexx HashMap?
They serve for completely different use cases. JCTool's map is for concurrent operation (like Java's ConecurrentHashMap). That is when a map needs to be accessed from multiple threads, and each thread should see updates that come from the other threads. However, JMeter needs quite the opposite. JMeter needs a map that pretends to be **non-shared**. I other words, the map should support updates, however, each thread should see **only** its own updates. What JMeter currently does it **clones** maps. So a single "FlowControlAction" is stored millions times in the Java heap since JMeter clones the test plan for each and every thread. What we need is a way to share "the common values", however, all the updates must be put to separate storage. This is exactly what Dexx collections do. Of course, Dexx is not the only implementation, however it was the best for performance-memory footprint ratio when I explored the libraries some time ago for https://github.com/vlsi/compactmap Vladimir
