[MUD-Dev] Why not compile java into object code?

Cynbe ru Taren cynbe at muq.org
Thu Feb 26 22:57:56 CET 1998


| What would it take to compile java down into object code (.o files)?
| It's not being done...but I wonder why?  I don't care if I have to compile
| for each platform...if I compile just for win95 80% of my users will enjoy
| a tremendous speedup....

Actually, this isn't that unusual: SuperCede does it, for example.  We
tested one of our products compiled this way recently.

There are some obvious problems:  If a program uses classForName()
calls load unpredictable classes at runtime, either a complete
interpretive environment must be included, or the compiler must
refuse to compile it. (Not sure which SuperCede does offhand.)

| On a similar level, is this what JIT compilers do?  If so, could not
| someone write a JIT that produces an ordinary exe?

Well, JIT compilers are ordinarily going to compile individual classes
on the fly, while maintaining the complete interpretation environment.

This means that they probably can't optimize as heavily as a
conventional optimizing compiler (partly because they don't have the
time, partly because they can't do interprocedural analsis and move
code between classes and such) but on the other hand means that they
can offer nearly total compatibility with the standard bytecode
environment, since they still include (normally) a complete bytecoded
environment.

| I must be missing something here....
|
| Looking for enlightenment...

Just that Java is very young, the standard bytecoded systems are still
not working decently (trust me, I rassle them for a living), so it is a
bit early to expect production-quality incremental compilers (the old
word for JITs before Sun marketing took over) to be making any real
splash.

However, Java is very carefully engineered to simplify the job of
JITs / incremental compilers, so you can expect them to progress much
faster and produce much higher quality results with a much higher level
of compatibility than has been the case with older interpreted languages.

 Cynbe




More information about the mud-dev-archive mailing list