>From owner-simulators  Tue Aug 15 13:28:45 1995
Received: from meitner.cs.washington.edu (meitner.cs.washington.edu [128.95.2.104]) by june.cs.washington.edu (8.6.12/7.2ju) with ESMTP id NAA18557; Tue, 15 Aug 1995 13:28:45 -0700
Received: from localhost (localhost [127.0.0.1]) by meitner.cs.washington.edu (8.6.12/7.2ws+) with SMTP id NAA24458; Tue, 15 Aug 1995 13:28:45 -0700
Message-Id: <199508152028.NAA24458@meitner.cs.washington.edu>
To: rtcg@cs
To: simulators@cs
Subject: Oak Intermediate Bytecodes
Date: Tue, 15 Aug 1995 13:28:44 PDT
From: "		    pardo@cs.washington.edu" <pardo@meitner.cs.washington.edu>
X-Message-Id: simulators@cs.washington.edu, message #1995-08-006
X-Unsubscribe: e-mail `majordomo@cs.washington.edu', body `unsubscribe rtcg'

%A James Gosling
%T Oak Intermediate Bytecodes
%J Proceedings of IR '95
%D January 1995
%C San Francisco, California, USA
%P 111-118
%W jag@eng.sun.com
%X Oak is the predecessor of Java.  Compiled to a bytecode that is
like other bytecodes but (pg 112) has more type information (though
perhaps less than OpenVM), there are restrictions on stack usage, and 
references are initially symbolic but are link-snapped by rewriting
the bytecodes.
  RTCG interest: bytecodes are self-modifying; suggests implementing
the VM with dynamic compilation.
  (pg 112-3) _Type state_ is the type of each accessible variable and
stack frame.  Operations are type so type state after an instruction
is executed can be deduced statically given the type state before an
instruction.   Two paths to one code point must arrive with the same
type state.  Precludes e.g. rolled loop copies that push a value onto
the stack on each iteration.  (Pardo: I deduce that heap-allocated
storage must be cleared in a typesafe way before user access, so
copying does not change a heap element type state from undefined to
defined.)
  (pg 115) All external references are symbolic; efficiency is
achieved by link-snapping them once the implementation is known.  Link
snapping is implemented by rewriting the bytecodes to use offsets
instead of symbolic names.  (Pardo: hurts sharing, complicates
caching).
  (pg 115) ``[S]tatically-determinable type state enables ... on the
fly translation of bytecodes into ... machine code.''  (Pardo: can do
it w/o static type state, but static typestate does improve
efficiency.)  ``Because [types are static] no dynamic type checks or
sophisticated inferences have to be done.  translation is just [a]
matter of reading the ``iadd'' bytecode and emitting an
"add ra, rb, rc" instruction.''  [Discussion of managing the stack for
compilation.]
  (pg 117) Using v-code allows a program to run on a wide variety of
machines yet use an implementation to be tailored the machine at hand
(forwards compatability of programs).
  (pg 117) Empty for loop on a SparcStation 10: ~1M iterations/sec.
Add a null procedure call to the loop: ~300K iterations/sec.  Call the
machine code translator: improves by ~10X, which is similar to the
performance of C.