For example, selectorCache in EntityValue is never cleared, meaning that with enough unique selectors the game will run out of memory.

While it's true that many times entity selectors will be constant, there's apps (source: support request in carpetcord) that use entity selectors with multiple, variable selectors, usually depending on a position. Those could fill the allocated memory and make the game run out of memory.

In singleplayer, this problem is aggravated because the cache isn't cleared even when switching worlds, since the cache is static in EntityValue.

This problem could be made less bad by at least moving it to somewhere that is discarded on world change, like CarpetScriptServer, but original problem is still present given enough time and executions.

Other caches that may be affected, but likely to a smaller degree, are:

• particleCache in ParticleDisplay (also in ShapeDispatcher)
• itemCache in NBTSerializableValue
• bvCache in BlockValue.

all caches should have some limit and be cleared when reaching it. I (or someone else) can go over these and make sure they have a limited capacity

Would it be a good idea to use a WeakHashMap for those that use the String in the StringValue directly? Would ensure that the constant ones are kept around for the lifetime of the app, but the rest would be garbage collected at the gc's discretion.

Or would that be too expensive/too short lived?