OOPSLA Java VM panel notes

[Nelson Minar]

I was at OOPSLA '98, the big yearly American object oriented
programming conference. It's mostly an industry conference, not
academic. This year there was a whole lot of Java stuff at the
conference, including a panel session headed by David Ungar on the
"new crop" of Java VMs.

These are my notes from that panel. It might be useful as pointers for
what some well known Java developers think is the way to go with the VM.
There's a note at the end about the lack of interest in a free Java VM..

The panel consisted of:
  David Ungar - Sun, Self project, now JVM development
  Lars Bak - Sun, Hotspot tech lead
  John Duimovich - IBM, VisualAge for Java
  Jesse Fang - Intel, working on Intel specific VM
  Scott Meyer - Oracle, working on Aurora (Java in Oracle DB)


The panel started out with short (15 minute) talks. I mostly just
copied stuff down from their slides. I put a (*) next to issues that
seemed particularly interesting.


Lars Bak - HotSpot architecture
  Adaptive Optimization
    the standard HotSpot story - analyze running code, compile active stuff
  GC - generational collector. Exact.
    first generation - copying collector
    train generations - also copying
    permanent generation - mark & collect
    <10ms pauses for GC, at least up to 60-80MB cores
  (*) Fast Synchronization - minimize space & speed
    Observation: all Java synchronization is block structured
    Solution: put monitors in the activation.
    Move object header word into monitor structure,
        put forwarding pointer in obj
    Advantage: stack allocated monitors, implict lock count, fast common case
  (From questions)
    HotSpot footprint in JDK 1.2 is close to Symantic JIT's
    HotSpot should support interactive development, but not in process now.

John Duimovich - VM in VisualAge for Java
  (From questions) - this VM is really for development only, not production.
      so it's a little slow. Can't be *too* slow though.
  (*) VM issues for advanced IDE Features (incremental development stuff)
    Hot Method/Class replacement (semantic issues)
    Multiple VMs in IDE address space (size/sharing issues)
    Class File Sharing (no bytecode rewrite, per-VM optimization)
    Code snippet execution - run and test bits of code live
    Modify system on the fly.
    In process debugging support
    Metamodel underneath the IDE VM (???)
  32 bit object pointers, untagged primitive types
  Objects contain accurate GC type info (ie: where pointers are)
  12 byte headers for objects (wasteful, he says)
    class, size, flags: writeable, hash, "shape", age, misc
  objects can be read-only and shared (critical to share between VMs)
  Two GCs: exact GC - all pointer locations are known
    Global Garbage Collector (mark, sweep, compact)
    Local Garbage Collector (generation scavenger)
  Mixed interpreted / JIT
  Green Threads - better control for debugging (??!!)
  JIT code de-optimizable
  VisualAge's JIT
    "polymorphic inline caches"
    optimized stack frame build
    top of stack data flow / optimization
    Don't inline stuff - not good for an IDE

Jesse Fang - Intel MicroComputer Research Lab
  (*) Big lesson: synchronization, JIT, GC are *all* important 
    for Java performance
  Performance of implementation of JVM is hardware platform dependent
    How do we make Java run bets on Intel hardware?
  (Specific note - floating point requirements of Java are a hassle)
  Different JITs and GCs for different applications
  Maybe different JVM implementations for different applications
    server, small client, etc.
  Interested in OS independent systems.
  Needs better benchmarks for Java
    Caffeine too small, SPECs not big enough for GC testing
    too much emphasis on java.io and java.net

Scott Meyer - Oracle's Aurora JavaVM
  (*) They want to run 10,000 sessions, each with a Java VM
  JDK is a medium sized program - 3MB of text, 6MB of data
    That'd be 60GB of data for 10,000 VMs. That's no good.
  10,000 threads.. (doesn't work)
  SQL integration, same address space
  Inside their server
    a pool of worker threads (processes) that share everthing
    memory durations
      call (lifespan of a pointer)
      session (possibly shared, data you have to keep around)
      global (shared, indefinite, often read-only)
  Implications of sharing
    separate namespaces per session
    Abstract references
      simple pointers don't work with shared memory
      so do some sort of relative offsets
      different representatios for the same class
    Activation - support mostly immutable objects
    No modifications to byte-codes after class load
      no quick-style optimization, dynamic optimization
      debugger uses "parallel interpreter"
  Memory management
    Java heap is in call-duration memory
    Classes, methods, etc are shared (activation to store static variables)
    Static variables are stored in session space
    "Standard" generational GC
  Implemented with MOSS, a Metaobject System
    Closed universe of classes for the VM
    Some sort of Scheme wrapper with C-like programming, lots of nice
        abstraction to give you encapsulated access to things
  Make it fast by compiling code to C
    No data overhead, portable, simple static optimization
    Works if your Java codebase isn't changing too quickly
  One VM/user, nonpreemptive threads, deadlock and stack overflow detection
  Results:
    good news - 50k minimal session overhead, medium size program (ORB) 200K
                10,000 sessions in 2GB.
    bad news - performance is roughly like JDK 1.1.3


There was also a brief question section, a smattering of random
things. I put a few of the bits of information into the outline above.


One question was whether people would be writing their JIT compilers
and VMs in Java itself, bootstrapping. Someone at Sun said a bit about
OpenJIT, a self-compiling Java JIT written in Java. They're hoping to
release it to the public, if Sun's lawyers will allow them.

David Ungar made a comment that processors are getting faster for
math, but not really for OO programming. He says contemporary
architectures are not agile enough, comparing them to dragsters that
are super fast but can't turn.

I asked a question to the panel about open source JVMs. I commented
that the lack of an open source JavaVM was hindering research and
wondering whether anyone on the panel thought that an open source VM
was important. David Ungar said that no one on the panel could help,
"because we've all sold out". Much laughter. David Ungar didn't sound
terribly sympathetic to the open source issue, although folks in the
crowd seemed to be.