It's actually partly inspired by how old security kernels work mixed with SFI. The first, secure kernels used a combination of rings, segments, tiny stuff in kernel space, limited manipulation of pointers, and a ton of verification. Here's original ones:
http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf
A Burroughs guy who worked with Schell et al on GEMSOS and other projects was the Intel guy who added the hardware isolation mechanisms. They were originally uninterested in that. Imagine the world if we were stuck on legacy code doing the tricks no isolation allows. Glad it didn't happen. :)
Eventually, that crowd went with separation kernels to run VM's and such that market was demanding. They run security-critical components directly on the tiny kernel.
https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
The SFI people continued doing their thing. The brighter ones realized it wasn't working. They started trying to make compiler or hardware assisted safety checking cost less with clever designs. One, like NaCl and older kernels, used segments to augment SFI. Others started looking at data flow more. So, here's some good work from that crowd:
http://dslab.epfl.ch/pubs/cpi.pdf
https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/
https://www.microsoft.com/en-us/research/wp-content/uploads/...
So, have fun with those. :)
...this is extremely relevant to what you're saying. A talk worth watching.
They mark the turning point I stopped worrying about UNIX deployments.
An application server has all the features I care about from a container, including fine grain control over which apis are accessible to the hosted applications.
It doesn't matter if the application server is running on the OS, an hypervisor, container or even bare metal.
Back in 2011 we were already using AWS Beanstalk for production deployments.
Also OS/400 is like that, user space is bytecode based. For writing kernel space native code, or privileged binaries you need the appropriately called Metal C compiler.
I think moving isolation out of hardware is really important (both to make it recursive and portable). NaCl is an interesting step in that direction. If you could use something like it to protect kernelspace (instead of ring 0), syscalls could be much, much faster.
There's another problem with language-based isolation: it makes your language/compiler/runtime security-critical. Conversely, NaCl has a tiny, formally proven verifier that works regardless of how the code was actually generated, which seems like a much saner approach.
I'll also say that I don't think it's reasonable to expect every object/module/whatever within a complex program to be fully isolated (in mainstream languages at least). There's no need for it, and it will have too much overhead (in a world where objects in many languages already have too much overhead). Better to start relatively coarse-grained (today the state of the art is basically QubesOS), and gradually improve.