Re: Sandboxing a computation?
Russell Wallace wrote:
2. Infinite or excessively deep recursion could result in stack overflow.
I think that throws a reliably catchable exception, right?
StackOverflowError.
3. Out of memory.
This is the one I'm worried about: it throws an exception, but suppose
there's other stuff going on in the main program, say in a user
interface thread, that will also need memory. Couldn't there be a
condition where something else fails in the time between exhausting
memory and catch/cleanup? In other words, you can't reliably deal with
an out of memory exception in the same process, right?
An OutOfMemoryError is guaranteed to be thrown only after the GC has
collected as much as it possibly can. The problem is that it gives
little information as to what caused it.
It might be possible -- I have not tested this, so I can't be sure -- to
set the default exception handler on your threads to kick out as much
stuff as possible and then trying to restore the position. Trying to
restore sanity would be difficult because an OutOfMemoryError handler
shouldn't allocate resources to try and save the position.
If so, is there a reliable way to kick off a second JVM instance to
run a sandboxed subprogram? ("Reliable" includes portable, e.g. can't
use native fork() because it has to run on Windows as well as Unix.)
Or is there another way to run a subprogram in a separate memory pool?
Runtime.exec("java <className>") is Java's version of fork.
(It would be nice if there was also a way to know how much memory a
subprogram had used even in the event of successful completion, or
better yet, monitor how much it was using at any given time. I'm
guessing this is impossible because other things might also use
memory, and there's no way of knowing when garbage collection has
occurred, is this correct?)
I can't say, really. Maybe javax.management and java.lang.management.
P.S. Actually, take a hard look at the Management extension. It might be
able to handle running out of memory situations without needing to spawn
subprocesses.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth