I don't know much about the other Runtimes that you mention, but correct me where I'm wrong: In the case of the JVM, green threads were dropped a long time ago

I don't know much about the other Runtimes that you mention, but correct me where I'm wrong: In the case of the JVM, green threads were dropped a long time ago, and under the current paradigm, native threads are used (on all platforms?). So doesn't this need to be written into the JVM? Not impossible of course (or provided by the unikernel wrapper as it is in OSv). Similarly with Databases, Oracle and Postgres both use a process per connection client/server model. So a unikernel for these would be impractical without rearchitecting those to run in that kind of environment. I was initially very excited for Unikernels, but because of this question (and others), I've really started becoming less enamored by them. I'm sure there are many places where they can be put to use, but for most of the software that I'm familiar with, there are still a bunch of kernel services that are quite handy. At what point of building these services into your unikernel/userspace application do you cross-over to basically building a new kernel. It really feels like the micro-kernel architecture would be a better fit in many of these cases. And yes, I understand that we can think of unikernels as VMs based micro-kernel services, but they have more isolation than traditional variations specifically allowing them to be used in AWS, etc. But still...