Idea: A Java-VM Implementation Based on the Modula-3 Runtime
ILU promotes global collaborative
software engineering at the interface level. But due to differences in language
runtimes, modules in different languages must often reside in different address
Economies of scale motivate a common runtime system for all the VHLLs
used in web programming (perl, python, scheme, REXX, Java, etc.) The tricky
part is designing the type system, since it impacts the garbage collector
(which needs run-time type info) and Pickler (which needs RTTI, plus type
fingerprints). Ultimately, it would be nice to have fine-grain access to
objects via network virtual memory, using pointer-swizzling ala the Texas
The Java VM is an
fascinating piece of design, and the amount of support behind it makes it
easy to leverage. But there's still the issue of native methods and
Of course, all this isn't really even worth doing unless you have common
hypermedia facilities, such as a compound document
architecture. The Java applet API is undergoing extensive evaluation
all over the net, but it's clearly not the only way to do things.
The work on obliq shows how handy the M3 runtime is for this sort of thing.
The M3 runtime has extremely well designed, specified, and integrated threads,
GC, and I/O. See:
- python VM implementation in M3 (python extensions written in
M3 rathern than C!)
- Java VM impelemted using guile
- Java->C compiler (I forgot what runtime it used...)
- scheme48 VM done in prescheme
- back-end to M3 compiler to generate Java VM bytecodes
- Java bytecode front end to M3 compiler: compile Java bytecodes to native
- Python VM as netscape plug-in (Jon Smirl firstname.lastname@example.org)
- M3 image size
- current M3 linker technology creates large program/library images: every
procedure mentioned in every interface is linked in. Need a smarter linker
so that size of programs and libraries will be comparable to C/C++.
the Pickle implementation seems to need run-time access to procedure names.
Can this limitation be removed?
- Methods Indexed by Name vs. by Number
- In Java, the fact that an object's type has a given method is checked
statically, but the index of the method is not always determined statically
-- methods are looked up by name at runtime. The Modula-3 runtime has no
support for method lookup by name. This could be added in the Java-VM support
layer, but I think it's needed in the language runtime for integration with
networked objects and ILU.
- Multiple Inheritance and Mix-Ins
- Both Modula-3 and Java have single-inheritance object models. ILU has
a multiple-inheritance model, but it only applies at the interface level.
Java's interface mechanism (ala the SmallTalk/Objective-C protocol) captures
many idioms where multiple-inheritance is employed in interfaces. But experience
with CLOS, smalltalk, python, Logicware, and related systems shows that "mixins"
are a critical implementation feature. Method dispatching in multiple-inheritance
systems can be expensive, but there are run-time system mechanisms (such
as those employed in Smalltalk and CLOS systems) that make the expense
- Low-memory situations
- The M3 NEW() primitive has no documented failure conditions. In fact,
it causes the whole program to abort when system memory is exhausted. The
runtime system needs to provide some mechanism to detect/prevent this.
Integration with threads and GC turns out to be extremely tricky (see threads
- this turns out to be a fine M3 platform. Threads work great. The current
port still requires a C/C++ compiler (mostly for the linker) but that would
be easy enough to fix.
- the original M3 implementation platform. The only consideration is that
the incremental/generational garbage collector needs to be ported specially
to each platform: the collector marks VM pages inaccessable, then deals with
them at fault time. Each unix system call has to be "wrapped" to prevent
- Win 3.1
- Hmmm... not straightforward at all
- Java-VM implementation in Modula-3: straightforward
- Java class loader, bytecode validator in Modula-3 (sun patents?)
- M3 linker for unix: straightforward
- M3 linker for Win95: straightforward
- M3 runtime interface for low-memory situations: tricky, but probably
not a lot of code
- Mac Port: hard
$Date: 1995/12/21 09:34:42