I think it would be a good start. Notice that the value of the heap counter would at all times by the upper bound on the memory usage. In other words, we may a

I think it would be a good start. Notice that the value of the heap counter would at all times by the upper bound on the memory usage. In other words, we may always assume that there’s unreclaimed garbage memory that we’re still counting in. But that also means that if throw an error if and only if we detect that the limit has been exceeded, the only error we can be in is a false positive. For sandboxing scenarios, that’s at least some good news after all: what we definitely don’t want are false negatives and we won’t get these. Now, when we've detected that the limit has been exceeded, we don't have to signal an error immediately. The execution can be suspended (as with CPU accounting). We can resume the execution any time later, or terminate it with an out-of-memory error. What we actually do depends on the application: we could simply decide that getting false positives is a risk worth living with and terminate the program; we could try calling System.gc() and check the limit afterwards; we could increase the limit temporarily and check in X ticks if this was just a spike in allocations etc etc. I see the chances of getting to 0% false positive rate almost impossible (at least not on a generic JVM), but I tend to think that such a technique could go a long way. Regarding other solutions to this problem out there today: I agree! Using a programming language that evades these problems entirely would be a solution, but I'd be skeptical about the chances of persuading users that it's for their benefit.