The current caching logic in the compiler leans on the fact that the superclass of a Script, AbstractScript, defines a bunch of fields to use for caching fixnums, symbols, regexps, blocks, and so on. Unfortunately this also wastes memory for ever Script instance instantiated, since regardless of whether they need 50 call site caching slots, they'll take up 4 bytes each in the object. So that's 200 bytes for call site references, 200 bytes for symbol references, and 200 bytes for fixnum references; 600 bytes of memory per instantiated Script (including jitted methods, even the tiniest ones) that might never be filled or used. The inherited cache logic was originally added to reduce the amount of permgen taken up by all those generated classes, since defining new fields adds new metadata which eats up permgen memory on at least HotSpot. But it seems this move may have traded some amount of permgen for more heap memory, and we could certainly do better to reduce them. It would be interesting to see what the actual in-memory size of Script subclasses is and whether this inefficiency has a real impact on heap usage. At any rate, it ought to be addressed.