

Java directly on Xen - wooby
http://research.sun.com/projects/dashboard.php?id=185

======
rykov
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
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
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
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
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.

~~~
dkersten
RISC core and microcoded CISC instructions then?

Still, what I meant was that the processor contains logic for some virtual
machine style operations, eg keeping track of objects on the heap on-chip (or
in a dedicated segment of ram/virtual address space) and having a hardware
garbage collector. The main instruction set would still be RISC, but it would
contain a small number of CISC instructions for allocating memory which the
garbage collector then manages.

As for dynamic dispatch, I guess thats not really needed, since it can be
constructed from simpler instructions, but having a Python-style method
dictionary lookup for member functions be performed in hardware could be
interesting.

Finally, if a processor had reflection and introspection features.. eg data is
annotated in memory so that the structure and state of a program can be
determined melodramatically at runtime (and modified).

Actually, while writing this, I realise that this probably doesn't really make
much sense... :-/

------
antonovka
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.

~~~
tezza
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
_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.

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

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

~~~
rbanffy
Nope.

Unless your processor runs Lisp directly from microcode ;-)

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

~~~
kls
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
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.

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

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

------
c00p3r
What is the last kernel which supports Xen dom0?

And the slogan is: We put outdated buzzowords together!

