In highly parallel environments running on multiple cores, profiling shows that the JCas map has performance issues due to volatile and atomic operations that are unneeded, but happen due to the use of the built-in Java Random function (which uses volatile and atomic operations, internally). This map doesn't need to support multi-threading operations - it is always used in a single-thread manner. Other optimizations are possible, due to the limited way this table is used. One of the common cases is an iterator fetching an existing FS from the CAS, and needing to supply the corresponding JCas object (if it exists). This operation first looks up in the Map using the address as the key, and if not found, then makes the JCas object, and then adds it to the map - an operation which repeats the same lookup in order to find the "empty slot" where it can store the item. This extra lookup can be eliminated.