[1494] in java-interest
Re: Systems Programming Oriented Java
daemon@ATHENA.MIT.EDU (Chuck McManis)
Wed Sep 6 03:50:30 1995
Date: Tue, 5 Sep 1995 21:41:33 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: sbk@netcom.com
Cc: java-interest@java.Eng.Sun.COM
> Just to play the devil's advocate here to help me understand some of
> this stuff (ie please don't flame me if I'm clueless :-)
> 1. If C is adequate to specify/implement a java VM, wouldn't Java, being
> a better systems programming language and all, be better?
No I don't think it would. The Intel Pentium executes a machine code
specified in the data book, but that machine code is written in
microcode. Is there an advantage to expressing the microcode in
intel code? The P6 is supposedly a RISC chip that implements the
x86 instruction set as an emulation on its own native set.
> 2. *Java bytecode* ought to be the portability medium, not C.
It is and it isn't. Intel machine code is half the portability
of DOS applications, DOS is the other half. Portability has two
faces, a canonical form of expression, and a universally available
engine.
> Correct me if I'm out of my depth on this, but for instance, does it
> look like the current (Alpha 3) interpreter on Solaris makes enough
> assumptions about structure alignment that I can't simply run gcc on
> the same piece of C on the same platform and get correctly working
> code?
> So I'm wondering if it is more portable to implement large portions of
> the VM in Java, and bootstrap it by translating the byte code for the
> VM into C. The assumption is that since the bytecode manipulates
> comparatively simple data types, the resultant C code is more portable
> than writing the entire VM in C.
Lets be careful here, the Java "VM" is not a whole heck of a lot of
code. The two primary source directories are ../src/share/java/runtime
and ../src/<platform>/java/runtime. On alpha3 that is about 46 files.
That is less than 20K lines of code. Sure there is another 5K lines
of C code that makes up the implementation of some of the foundation
classes, but even 25K isn't a big burden. The fact of the matter is
that there _are_ large portions of the Java environment written in
Java and no doubt more could be upcoded without changing the language.
The only addition needed to make an OS out of it is a device driver
class library.
> The second aspect to this is that it would also quickly expose any
> hooks that are required to be provided by the VM outside of what the
> specification says a VM needs to do.
> For instance, many methods require the VM to tell them the state of
> the stack (is there a class loader on it?). There is no byte code to
> accomplish this task, so it is implemented by using a hook into
> the VM data structures.
I don't believe it is "many". We do have a bunch of methods that look
at the stack to see if there is a class loader so they can change
their behaviour but that certainly isn't the only way of implementing
a security scheme for the applet classes. When one of these behaviours
manifests itself what happens is a new fundamental or base class gets
created that encapsulates the ability. This is what was done for Beta.
Again however the *language* did not need to change to support this
behaviour, but the *environment* did. (new base class) My thesis is
that if you added the necessary classes to implement a small portable
OS "in" Java the C part of it would not be a burden, whereas supporting
two "nearly compatible" languages would.
--Chuck
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
