Should isolates be given a second chance?

Why revisit application isolation?

The opening post considers the Application Isolation API as a possible way to run several related workloads under one JVM while preserving more separation than ordinary threads provide. The core interest is not a particular implementation, but the practical problems that stronger boundaries could address.

Threads are efficient, yet a failure or uncontrolled resource demand in one workload can affect neighbouring work in the same process. The discussion asks whether isolate-style execution could offer a useful middle ground between shared-memory concurrency and fully separate operating-system processes.

1. Independent web applications could benefit from limits that prevent one workload from exhausting shared memory, processor time, or application state.
2. Code loaded from outside a primary application could benefit from a model that contains faults and gives the host clearer control over resource use.

Existing Java security facilities can control many permissions, but the discussion notes that memory and CPU governance need their own practical model. The proposed direction is therefore less about changing the Java language and more about giving runtimes a clearer way to establish, monitor, and communicate across execution boundaries.

resource context: this discussion preserves a historical design question. The summaries here clarify the technical themes without treating early proposals as current platform guidance.

Implementation complexity is central

The first response distinguishes a simple process-based approach from a deeper multi-VM design that shares more runtime machinery. Starting a separate JVM per workload can provide isolation, but it may mainly formalise ordinary process launching rather than deliver the efficiency implied by a shared runtime.

A more integrated model would have to manage native libraries and resources with great care. If untrusted native code can damage shared runtime state, then the isolation layer begins to resemble an operating-system-level protection problem. The response therefore frames performance cost and implementation complexity as inseparable questions.

Separate the goals of isolation and shared runtimes

A follow-up argues that isolates and multi-VM architectures need not have identical aims. A controlled model for related applications could still be valuable even if it does not attempt to host arbitrary, unrelated programs in one runtime.

The reply highlights controlled cross-workload communication and explicit constraints as useful design goals. In applications that avoid native integration, an isolation model might reduce the scope of some runtime risks while providing better control than thread-only arrangements.

The question is narrowed to two durable concerns: how resource policy could be expressed, and how concurrent execution contexts could be prevented from accessing each other’s memory directly.

Begin with an approachable API

Another participant suggests that a process-backed implementation could be useful if paired with reliable resource observation. The practical recommendation is to establish a coherent API first, then improve the underlying implementation where evidence and demand justify it.

What would a practical first version include?

The response welcomes the incremental approach and asks for more detail about the expected interface and resource-monitoring model. The exchange keeps the focus on usable boundaries rather than a single idealised runtime architecture.

Implementation style remains open

The final note observes that the proposal did not prescribe one implementation route. An experiment using process construction had reached a compilable state, with additional work needed to complete behavioural tests. For communication, the participant moved from an initial remote-invocation idea toward simpler serialised data exchange.