8 ms·

Java directly on Xen

76 points by wooby 17y ago

adatta02 17y ago
pretty neat. but what happens to OS level abstractions like the file system, sockets, ect?
- kls 17y ago
  The article says that the JVM sits on top of a micro kernel, so I would assume that that micro kernel would provide a thin layer of abstraction for hardware and IO support such as file-systems. Its an interesting concept if you couple it with something like EC2 where you could throw out a bunch of Java VMs to do massive parallel processing of a data-set.
  - jrockway 17y ago
    There are also many Java programs that do not use files or sockets; they use "the database", "the classloader", "the configuration class", etc.. With the details abstracted away, this JVM can replace those classes with custom implementations that have the same interface but are implemented without any OS support. Note: I haven't watched the video or read the source code yet.
timf 17y ago
BEA LiquidVM has been doing this for several years. Don't know what happened to it after Oracle acquired BEA...
antonovka 17y ago
What I like most about this idea is that system administration via init scripts, et al, can just go away -- presumably one will have APIs for interacting with the available hardware, necessary 'OS' services, etc. It'd make automated deployment of systems even more manageable -- turtles all the way down.
- jrockway 17y ago
  Good observation. I have to say that I find Java generally distasteful, but I feel the same way about UNIX. An "OS" for my applications that is just some OO code I interact with would be much better than random shell scripts that talk to other random shell scripts via unstructured one-way text pipes. Turtles all the way down, indeed. Of course, UNIX is trying to fix that too... so it will be interesting to see how this evolves.
- tezza 17y ago
  I'm all for this JVM re-implementation project, but the sysadmin aspect is just going to be pushed one level up the the Xen image host. You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ssh to xen master upload new xen image adjust xen master rc scripts to load new image on startup Hardly turtles-all-the-way down
  - antonovka 17y ago
    You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ... Why wouldn't the virtual machine bootstrap itself from network loaded code -- then it wouldn't be necessary to update the root Xen image. Why couldn't I write a network service (also on the VM) that runs on other Xen instances and serves up the netboot code? Why would updating the root VM require SSH? Couldn't I have a nice web management UI that I can just upload a new bootstrap JVM image to (on the rare occasions that I need to?). Perhaps systems could directly self-update the root Xen image on reboot? I don't know why I'd have turtles-all-the-way down and then require some ugly update system that involves editing RC scripts.
- viraptor 17y ago
  You can achieve that now. Just by running java as the main process. Erlang can do that (more or less). People run dedicated machines where erlang vm is the init script. With the ability to distribute code in a cluster and update a live code it's a perfect environment to manage :) Running different services is already implemented through the standard "supervisor" processes.
cinkler 17y ago
Is it simillar concept as JNode ( http://www.jnode.org http://www.jnode.org )?
- mbreese 17y ago
  It actually borrowed some code from jnode. At least it grabbed a driver for the ext2 filesystem. I'm not sure what else.
rykov 17y ago
As JVM gets closer to being the de-facto VM for running any language (Jython, jRuby, Scala, Java, etc), the possibility of higher performance by running the VM "closer to metal" is quite exciting. I commend Sun on pushing JVM beyond just Java.
- spitfire 17y ago
  We already have a bare metal VM though. It's called X86. Call me a luddite but I have never seen the point of Java and the JVM at all.
  - mbreese 17y ago
    I can think of two main benefits you can get from a VM that you can't get from bare metal: 1) (and this is also true for most if not all dynamic languages) that you can distribute your app to anyone on any machine and have it run. This does limit your access to the full capabilities if the hardware, but write once run anywhere was pretty close to being true (at least at the JVM level). 2) you can perform optimizations at runtime that you may not have known about at compile time. As I see it, those are the main theoretical benefits.
    - dkersten 17y ago
      Theres no reason you cannot get #2 in hardware.. now that'd be an interesting direction for processor manufacturers to go - architectures and instruction sets designed like that of a VM, with built in garbage collection and runtime optimisation and dynamic dispatch features. As for #1, write once run anywhere still doesn't seem to be quite there, imho.
      - rykov 17y ago
        I thought the outcome of CISC vs RISC battle has shown that best performance comes from simpler/faster CPUs with smarter software, not vice versa.
        17y ago
c00p3r 17y ago
What is the last kernel which supports Xen dom0? And the slogan is: We put outdated buzzowords together!
yason 17y ago
Just add Clojure and we're back to the future of Lisp machines.
- rbanffy 17y ago
  Nope. Unless your processor runs Lisp directly from microcode ;-)

76 points by wooby 17y ago

adatta02 17y ago

pretty neat. but what happens to OS level abstractions like the file system, sockets, ect?

kls 17y ago
The article says that the JVM sits on top of a micro kernel, so I would assume that that micro kernel would provide a thin layer of abstraction for hardware and IO support such as file-systems. Its an interesting concept if you couple it with something like EC2 where you could throw out a bunch of Java VMs to do massive parallel processing of a data-set.
- jrockway 17y ago
  There are also many Java programs that do not use files or sockets; they use "the database", "the classloader", "the configuration class", etc.. With the details abstracted away, this JVM can replace those classes with custom implementations that have the same interface but are implemented without any OS support. Note: I haven't watched the video or read the source code yet.

timf 17y ago

BEA LiquidVM has been doing this for several years. Don't know what happened to it after Oracle acquired BEA...

antonovka 17y ago

What I like most about this idea is that system administration via init scripts, et al, can just go away -- presumably one will have APIs for interacting with the available hardware, necessary 'OS' services, etc. It'd make automated deployment of systems even more manageable -- turtles all the way down.

jrockway 17y ago
Good observation. I have to say that I find Java generally distasteful, but I feel the same way about UNIX. An "OS" for my applications that is just some OO code I interact with would be much better than random shell scripts that talk to other random shell scripts via unstructured one-way text pipes. Turtles all the way down, indeed. Of course, UNIX is trying to fix that too... so it will be interesting to see how this evolves.
tezza 17y ago
I'm all for this JVM re-implementation project, but the sysadmin aspect is just going to be pushed one level up the the Xen image host. You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ssh to xen master upload new xen image adjust xen master rc scripts to load new image on startup Hardly turtles-all-the-way down
- antonovka 17y ago
  You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ... Why wouldn't the virtual machine bootstrap itself from network loaded code -- then it wouldn't be necessary to update the root Xen image. Why couldn't I write a network service (also on the VM) that runs on other Xen instances and serves up the netboot code? Why would updating the root VM require SSH? Couldn't I have a nice web management UI that I can just upload a new bootstrap JVM image to (on the rare occasions that I need to?). Perhaps systems could directly self-update the root Xen image on reboot? I don't know why I'd have turtles-all-the-way down and then require some ugly update system that involves editing RC scripts.
viraptor 17y ago
You can achieve that now. Just by running java as the main process. Erlang can do that (more or less). People run dedicated machines where erlang vm is the init script. With the ability to distribute code in a cluster and update a live code it's a perfect environment to manage :) Running different services is already implemented through the standard "supervisor" processes.

cinkler 17y ago

Is it simillar concept as JNode ( http://www.jnode.org http://www.jnode.org )?

mbreese 17y ago
It actually borrowed some code from jnode. At least it grabbed a driver for the ext2 filesystem. I'm not sure what else.

rykov 17y ago

As JVM gets closer to being the de-facto VM for running any language (Jython, jRuby, Scala, Java, etc), the possibility of higher performance by running the VM "closer to metal" is quite exciting. I commend Sun on pushing JVM beyond just Java.

spitfire 17y ago
We already have a bare metal VM though. It's called X86. Call me a luddite but I have never seen the point of Java and the JVM at all.
- mbreese 17y ago
  I can think of two main benefits you can get from a VM that you can't get from bare metal: 1) (and this is also true for most if not all dynamic languages) that you can distribute your app to anyone on any machine and have it run. This does limit your access to the full capabilities if the hardware, but write once run anywhere was pretty close to being true (at least at the JVM level). 2) you can perform optimizations at runtime that you may not have known about at compile time. As I see it, those are the main theoretical benefits.
  - dkersten 17y ago
    Theres no reason you cannot get #2 in hardware.. now that'd be an interesting direction for processor manufacturers to go - architectures and instruction sets designed like that of a VM, with built in garbage collection and runtime optimisation and dynamic dispatch features. As for #1, write once run anywhere still doesn't seem to be quite there, imho.
    - rykov 17y ago
      I thought the outcome of CISC vs RISC battle has shown that best performance comes from simpler/faster CPUs with smarter software, not vice versa.
      - 17y ago

c00p3r 17y ago

What is the last kernel which supports Xen dom0? And the slogan is: We put outdated buzzowords together!

yason 17y ago

Just add Clojure and we're back to the future of Lisp machines.

rbanffy 17y ago
Nope. Unless your processor runs Lisp directly from microcode ;-)