This is the mail archive of the
mailing list for the GCC project.
[wwwdocs] java/papers/gcc-java.html goes XHTML
- From: Gerald Pfeifer <gerald at pfeifer dot com>
- To: gcc-patches at gcc dot gnu dot org, Per Bothner <per at bothner dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: Mon, 15 Oct 2007 19:08:36 +0200 (CEST)
- Subject: [wwwdocs] java/papers/gcc-java.html goes XHTML
I happened to spot this by chance while working on a validation run
for our whole website.
Impressive to realize that this was already written eleven years ago!
Per, this has your email@example.com address. I thought I'd point
this out in case you may want to change this.
2007-10-15 Gerald Pfeifer <firstname.lastname@example.org>
* java/papers/gcc-java.html: Make markup XHTML 1.1 compliant.
RCS file: /cvs/gcc/wwwdocs/htdocs/java/papers/gcc-java.html,v
--- gcc-java.html 1 Feb 2004 20:09:21 -0000 1.4
+++ gcc-java.html 15 Oct 2007 17:02:19 -0000 1.5
@@ -1,4 +1,9 @@
+<?xml version="1.0" encoding="ASCII" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
<title>A Gcc-based Java Implementation</title>
@@ -7,11 +12,12 @@
<a href="http://www.bothner.com/">Per Bothner</a>
-While the portability of Java bytecodes is a major factor
+<p>While the portability of Java bytecodes is a major factor
in its success, we believe it cannot become a mainstream
programming language without mainstream implementation
techniques, specifically an optimizing ahead-of-time
@@ -32,11 +38,11 @@ dynamically loaded and compiled use the
conventions as pre-compiled methods. We will enhance the
GNU debugger (gdb) to understand Java, which will provide
a familiar and multi-language debugging environment (you
-can use the same interface to debug Java and native methods).
+can use the same interface to debug Java and native methods).</p>
-Java has taken off because it is a decent programming language,
+<p>Java has taken off because it is a decent programming language,
is buzzword-compliant (object-orient and web-enabled), and
because it is implemented by compiling to portable bytecodes.
However, interpreting bytecodes makes Java program many times slower
@@ -49,7 +55,7 @@ compared to conventional compilers: (1)
every time the application is executed, which increases start-up
times substantially, and (2) the JIT compiler has to run fast,
and therefore cannot do any substantial optimization.
While JIT compilers have an important place in a Java system,
for frequently used applications it is better to use a more
traditional "ahead-of-time" or batch compiler. While Java has
@@ -58,11 +64,11 @@ are interested in using Java as an alter
languages such as C++, if the performance can be made adequate.
For embedded applications it makes much more sense to pre-compile
the Java program, especially if the program is to be in ROM.
So Cygnus is building a Java programming environment that is
based on conventional a compiler, linker, and debugger, using
Java-enhanced versions of the existing GNU programming tools.
The core tool is of course the compiler. This is "cc1java,"
a gcc new front-end. This has similar structure as existing
front-ends, and shares most of the code with them.
@@ -79,7 +85,7 @@ header file); (2) it is needed so we ca
from other tools that produce Java bytecodes (such as the Kawa
Scheme-to-Java-bytecode compiler); and (3) some libraries are
(unfortunately) distributed as Java bytecodes without source.
To "parse" a Java bytecode file involves first parsing the
meta-data in the file. Each bytecode file defines one Java
class, and defines the superclass, fields, and methods of
@@ -90,7 +96,7 @@ run-time meta-information (such as the C
The compiler generates initialized static data that have the
same layout as the run-time data structures used by the Java VM.
Thus startup is fast, and does not require allocating any data.
The executable content of a bytecode file contains a vector
of bytecode instructions for each (non-native) method.
Code generation means converting the stack-oriented
@@ -103,10 +109,10 @@ postfix stack operations to expression n
a compile-time stack of expression nodes. When necessary,
we also map stack locals and local varaibles into gcc
Generating machine code from the expression nodes uses
existing code (instruction generator, optimizer, and assembler).
Linking a set of compiled Java binaries into a library or executable
will use the standard linker (GNU ld). However, some enhancements
are necessary or at least desirable. The linker must provide a way
@@ -114,7 +120,7 @@ to build a table mapping class names to
be done using the same mechanism used for running C++ static
initializer. Linker help is also desirable to combine multiple
copies of the same literal.
Running a compiled Java program will need a suitable Java run-time
environment. This contains support for threads, garbage collection,
and all the primitive Java methods. Complete Java support also means
@@ -126,11 +132,12 @@ code. (For example, we are simplifying
Kaffe include a JIT compiler, which solves the problem of calling
between pre-compiled and dynamically loaded methods (since both use
the same calling convention).
We plan to enhance gdb (the GNU debugger) so it can understand
Java-compiled code. This may involve accessing Java meta-data
from the Java executable. We may also enhance gdb to understand
dynamically-loaded bytecodes, but the need for that is reduced
if we instead provide a hook so gdb knows about JIT-compiled code.