A Gcc-based Java Implementation

From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24574 invoked by alias); 15 Oct 2007 17:08:39 -0000 Received: (qmail 24552 invoked by uid 22791); 15 Oct 2007 17:08:38 -0000 X-Spam-Check-By: sourceware.org Received: from vexpert.dbai.tuwien.ac.at (HELO vexpert.dbai.tuwien.ac.at) (128.131.111.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Oct 2007 17:08:35 +0000 Received: from acrux.dbai.tuwien.ac.at (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 20D8139164; Mon, 15 Oct 2007 19:08:31 +0200 (CEST) Date: Mon, 15 Oct 2007 17:08:00 -0000 From: Gerald Pfeifer To: gcc-patches@gcc.gnu.org, Per Bothner cc: java-patches@gcc.gnu.org Subject: [wwwdocs] java/papers/gcc-java.html goes XHTML Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2007-q4/txt/msg00008.txt.bz2 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 bothner@cygnus.com address. I thought I'd point this out in case you may want to change this. Gerald 2007-10-15 Gerald Pfeifer * java/papers/gcc-java.html: Make markup XHTML 1.1 compliant. Index: gcc-java.html =================================================================== 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 @@ - + + + + + A Gcc-based Java Implementation @@ -7,11 +12,12 @@ Per Bothner bothner@cygnus.com -December 1996 -

+ +

December 1996

Short abstract

-While the portability of Java bytecodes is a major factor +

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

Extended abstract

-Java has taken off because it is a decent programming language, +

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 pseudo-registers. -

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