Slashdot Mirror


Java-Based x86 Emulator

jaavaaguru writes "Researchers at Oxford University have produced a Java-based x86 emulator that they hope will be useful in testing applications and learning about viruses without damaging the host, utilizing the robust sandboxing that Java provides. They have an online demo available that boots DOS and has some games to play. Being purely Java, this emulator should be able to run on almost anything, including cell phones." The code is not yet available outside the Oxford community; the developers are said to be working on a suitable general license. In the meantime the code can be licensed on a case-by-case basis.

12 of 263 comments (clear)

  1. How's the efficiency? by lbft · · Score: 2, Interesting

    Whilst this looks like a really interesting project, I'm failing to see how it's useful generally due to the limitations of writing it in Java and making it cross-platform. You would lose a lot of those possible (processor- or platform-specific) optimisations that make the leaders in the virtualisation market as fast as they are.

    On, say, a mobile phone (which is mentioned by the site as a possible use) would there be enough processing grunt to do anything useful? I know Java's not as slow as some people would have you believe, but virtualisation requires as much speed to be squeezed out as possible to be usable.

    On a desktop, what advantage does this have over the existing virtualisation options which don't have to deal with the Java environment?

    1. Re:How's the efficiency? by Gromius · · Score: 2, Interesting

      Actually I think it is for general purpose code. In fact I think its main purpose is for running general code on the grid and giving each process its own virtual sandbox, isolating it from the underlining hardware. This means that some random grid user wont be able to hose the machine they happen to be using which should make things easier from a grid admins point of view. Its the only reason I can possibly think of why they made it.

      Incidently when I first heard about this today, I thought it would be the comp sci dept but it turns out its particle physics, which surprised me as I'm a member of the oxford group but on a different experiment. I am still reasonably baffled why they have done this, will have to ask them on monday. This probably explains the current sad state of the ATLAS software as they are all too busy getting Commander Keen to run on their mobile phones :)

  2. Re:Interesting, but by Qwertie · · Score: 5, Interesting

    I'd have to agree. Using instruction-by-instruction emulation, a C++ based SNES emulator I wrote around 1998 used at least 150Mhz of processing power to emulate the SNES' 3Mhz processor. When I rewrote it in assembly, it was 5-10 times faster. I expect that some pretty sophisticated techniques would be required to exceed a snail's pace when using Java for emulation, eg "dynamic recompilation": translating sections of x86 machine language to Java bytecode... but getting this to work 100% correctly would be pretty tricky.

    If it's hard to get good emulation speed in C++, it's even harder in Java.

  3. Well for one by brunes69 · · Score: 5, Interesting

    For one this will let you run X86 DOS applications on a SPARC for example.

    I'd like you to point me to the support page for VMWare on SPARC... oh wait that's cause there isn't one. QEMU can't even run most applications on a SPARC.

    And forget about ARM.

    I think this is great. Java is not as slow as people seem to think it is. One thing Java 5 (and 6) have that actually benefits virtualization is dynamic recompilation... the JVM knows the instruction sdequences better than the original author, and in theory can optimize the code paths in ways writing a virtualizer in assembly or C++ can not.

    1. Re:Well for one by EvilIdler · · Score: 2, Interesting

      Java isn't all that slow, but the bad rep is because of its startup time and a really unoptimised GUI.
      It's fine for all sorts of things while running, but the two apps I use it for aren't exactly impressive.
      If I leave Azureus up for a while, it's eating 400 megs of memory. It also takes 10+ seconds to show
      its window. The other thing I regularly use Java for is my bank, which insists on using a friggin'
      control in its window. It takes about a minute to show up, even with other Java apps running. It seems
      the startup time is a per-process thing, not the entire loading of libraries and stuff.

      I recently installed Eclipse, and it's a world apart from the slowness of the bank webapp and Azureus.
      Starts up immediately, ready to rock. I may start using it once I figure out how :P

    2. Re:Well for one by jimmydevice · · Score: 2, Interesting

      I did something even slower in 1973. A Cardiac ( Bell Labs cardboard computer ) emulator written in FORTRAN, running on a FORTRAN emulator written in HP 2000 BASIC running on a HP2100 mini. Cycle time = one instruction / Sec.
      It could play tic-tac-toe, Very slowly.

  4. Molasses - 35mph! by Anonymous Coward · · Score: 3, Interesting
  5. Re:Struggling to understand... by alexj33 · · Score: 1, Interesting

    Java without emulation has been promising stuff like this for a long time and hasn't arrived. How long do you thing it'll be before Java+emulation does?

  6. can you run java in the x86? by leuk_he · · Score: 5, Interesting

    THe next question would be: can you run java in the x86 emulator that runs an other emulator that runs java, that runs an other emulator.

    Just like the old days when you ran windows real mode under a windows 386 mode windows.

  7. Java isn't slow anymore by Ranx · · Score: 1, Interesting

    The first ten reactions are about how slow Java is. Wake up! It's 2007, NOT 1997. The world has changed. Don't you keep your knowledge up to date? Are you amateurs? And no, a benchmark from 2001 doesn't count too.

    --

    Me
  8. Re:Interesting, but by Citizen+of+Earth · · Score: 2, Interesting

    Java is capable of runtime optimisations not possible with statically compiled languages like C++.

    There is a world of difference between "theoretically capable" and "reliable does". Is there some practical demonstration that compute-intensive tasks like emulation can be reliably executed with Java without sucking?

  9. Re:Struggling to understand... by Anonymous Coward · · Score: 1, Interesting

    Both have arrived, that's not the problem. The problem is that now that we can run a 1995 application as fast as it was running in 1995, no one is interested in running those applications anymore.