Slashdot Mirror


Notes from JVM Symposium

prostoalex writes "Steve Anglin, author of such O'Reilly books as "C# in a Nutshell" and "VB.NET Core Classes in a Nutshell" from recent Java Virtual Machine Symposium. Among the questions discussed are intelligent garbage collection, faster implementations of Java bytecode, getting JVM's for even smaller and lighter devices and stopping thinking outside the box."

3 of 11 comments (clear)

  1. How 'bout that link?!? by bay43270 · · Score: 2

    Long enough for you?

  2. JPM (Java Physical Machine) vs JVM by knorthern+knight · · Score: 3, Funny

    The Intel i686 is a RISC core, with a legacy X86 emulation layer on top. Transmeta is another CPU that can morph its instruction set to emulate other CPUs. Why not scrap the emulation under an OS, and simply execute Java bytecode directly by the CPU ?

    And if we really want to get fancy, maybe Transmeta could be set up to directly run the Emacs OS, from which you could run vim when you wanted to do serious editing.

    --

    I'm not repeating myself
    I'm an X window user; I'm an ex-Windows user
  3. Transmeta has done this by alienmole · · Score: 2
    Transmeta had a demo which executed Java bytecode directly on a Crusoe CPU, I'm too lazy to look for a link right now. It didn't go anywhere commercially, afaik.

    Also, Sun has made chips that run Java bytecode, iirc "picoJava" was one such effort.

    Right now, though, if you're an OEM designer, there's more support for traditional architectures, in terms of development tools and the functionality provided by traditional embedded operating environments. Performance is not usually such an issue that a JPM would be a necessity to the success of a project. In short, there just isn't a good enough reason to make the leap. It might become more viable in future, as tool support and the capabilities of the Java "platform" converge to provide everything that's needed.