W3C | OOP

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 spaces.

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 object system@@.

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 FFI.

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:

Related Ideas

Issues

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++.
Hmmm... 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 negligible.
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 on comp.lang.modula3).

Platforms

Win95/NT
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.
Unix/X
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 SEGVs.
Win 3.1
Hmmm... not straightforward at all

Work Products

W3C
Connolly
$Date: 1995/12/21 09:34:42 $