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.
