`run` and `runresult` caching of compiled strings breaks down somewhere beyond a handful

@qiemem writes:

Cach[ing] the compiled procedure[s] [...] doesn't really solve the problem in my experience. When things get performance heavy, the JVM is going to be gcing everything it can, thus clearing the cache. But that's exactly the circumstance under which caching helps [...] my experience with the caching of compiled code in NetLogo as been pretty bad.

The underlying caching technology is WeakReferences. @qiemem notes:

WeakReferences are cleaned up on any GC, not just full GCs. This is easily demonstrated by throwing a println in the cache failure code and running run "ca crt 1" over and over while watching GC behavior. I've been running it for a few minutes, haven't had any full GCs, yet have a dozen or so recompiles. [...] SoftReferencess, on the other hand, are only GCed after a full GC fails to recover much memory. They come with many problems of their own however.

see also http://stackoverflow.com/q/16974776/86485

"a dozen or so recompiles" in a few minutes may sound not so bad, so that would seem to indicate why the caching does work well in practice at least some of the time. @qiemem adds:

It gets bad when you have ~100 different such strings that are each run every tick. Not a big deal though because you can do the runresult "task [ do stuff ]" trick. That's what I resorted to when dealing with that issue.

No file or test is named. Start by locating the run and runresult compiled-string cache and reproduce the behavior with many distinct strings running every tick while observing GC and recompilation messages. Done means the caching behavior is characterized and a decided approach prevents the reported recompilation breakdown.