What is the closest you can get to true (resource constrained) isolates in the JVM today?

Question

Posit the following situation:

• You have a large and complex system (distributed, concurrent, huge dataset) which supports many users. The code is sent to the data.
• You want to allow mobile code in the system - ie untrusted code that will run within the same JVMs as the rest of the system, to take advantage of the locality of the data, avoid deserialization etc.

You can put the code in a funny classloader, and use a customised security policy like the applet runner does. But there are still problems:

The system as a whole should be protected from malicious code - eg spawning loads of threads, eating all the cpu up, allocating too much memory.

The mooted idea at the beginning of the millenium was JSR-121. Isolates were meant to bring most of the benefits of process isolation - limits on cpu usage, thread spawning, heap usage : resource allocation in general.

Given that this effort was seemingly abandoned by Sun, what is the closest we can currently get?

So far, my ideas are:

• Bytecode translate the code to insert allocation tracking. Google seem to have done something similar to this : http://code.google.com/p/java-allocation-instrumenter/ . It needs a bit of work as Google have (Joshua) Bloch-ed themselves into a corner and made all kinds of things package private...
• Also ban calls to things the security manager can't, eg Thread creation.
• Insert (rare) interruption checks into loops and recursive functions so a monitor thread can watch (using ThreadMXBean), and if it takes too long, interrupt the offending thread. It might be simpler just to put limits on reentrancy - in any call into the user code, a basic block may only be entered n times before aborting.

Are there any better or existing ways to do this?

Answer 1

This is a complex question. My first thought was to create a domain-specific language that does what the 'mobile' users need. The DSL would have no capability to perform a dangerous operation.

Who are the people that would be uploading untrusted code? This sounds like a dubious idea to begin with. We spend a lot of effort making sure people can't run untrusted code ;-)

Answer 2

The problem is that the only real way to isolate a process is to have a dedicated machine/hardware. Anything else you do, you will have to make compromises. Depending on what those compromises are acceptable, depends on whether it is practice to share a JVM with that code.

This is not a problem you can solve for the general case in a trivial manner because you want to protect against things you haven't thought (which others might think of one day)