Re: gcj/74: jc1 dumps core when compiling java/lang/Object.java

[Pekka Nikander <Pekka dot Nikander at hut dot fi>]

The following reply was made to PR gcj/74; it has been noted by GNATS.

From: Pekka Nikander <Pekka.Nikander@hut.fi>
To: Tom Tromey <tromey@cygnus.com>
Cc: java-gnats@sourceware.cygnus.com, Anthony Green <green@cygnus.com>
Subject: Re: gcj/74: jc1 dumps core when compiling java/lang/Object.java
Date: Sat, 23 Oct 1999 17:19:51 +0300

 I wrote:
 >> use libgcj because it is far too big.  It seems to me that I
 >> also have to hack the compiler in other respects, too, since
 >> e.g. java.lang.Class has a huge number of internal, compiler
 >> generated fields that I won't need.
 
 Tom Tromey wrote:
 > Yeah, you're right -- you'll have to change the compiler so it doesn't
 > emit fields you don't care about.  Basically, as you surmised, the
 > compiler has a fair amount of knowledge about the runtime.  This is
 > more or less undocumented, too :-(.  For instance the compiler can
 > generate calls to various functions which the runtime must implement.
 
 I don't care that much about the various function calls the compiler
 generates -- it is pretty easy to implement them.  What is worse is
 the number of fields the compiler silently inserts to the classes
 java.lang.Object and java.lang.Class.  What is even worse, from my
 point of view, is that there is no "legal" way of accessing them
 from Java (but to "know" them).  Even worse, many of them don't 
 have any legal Java type.
 
 I have now modified the compiler so that you can (re)declare the 
 compiler generated fields in Java, and if the types are assignment 
 compatible in both ways, the compiler issues just a warning, not an 
 error.  
 
 Here is an example from my  Class.java:
 
 public final class Class {
     java.lang.Class superclass;    /* Redeclared */
     int size_in_bytes;             /* Redeclared */
     java.lang.Class interfaces[];  /* Redeclared */
     public boolean isAssignableFrom(Class clazz) {
         Class c;
         for (c = clazz; c != null; c = c.superclass) {
             if (this == c)
                 return true;
             for (int i = 0; i < c.interfaces.length; i++) {
                 if (this == c.interfaces[i])
                     return true;
             }
         }
         return false;
     }
     public Class getSuperclass() {
         return superclass;
     }
     public Class[] getInterfaces() {
         return interfaces;
     }
 }
 
 Compilation warnings:
 
 gcj -fclasspath=../.. -S Class.java
 Class.java:23: warning: Redeclaration of compiler generated variable:
 `java.lang.Class superclass' was `java.lang.Class superclass' (<built-in>:0).
     java.lang.Class superclass;
                     ^
 Class.java:28: warning: Redeclaration of compiler generated variable:
 `int size_in_bytes' was `int size_in_bytes' (<built-in>:0).
     int size_in_bytes;
         ^
 Class.java:33: warning: Redeclaration of compiler generated variable:
 `java.lang.Class[] interfaces' was `java.lang.Class[] interfaces' (<built-in>:0).
     java.lang.Class interfaces[];
                     ^
 3 warnings
 
 Now I am in the process of converting the internal, compiler generated
 fields to use Java compatible types (instead of C++ types) so that I
 can access them from Java as much as possible.  Of course, that is not
 possible for some fields, but for the most important ones that can be
 accomplished quite easily.  Unfortunately that breaks compatiblity
 with the current libgcj.  However, it shouldn't be too hard to 
 modify libgcj to use Java compatible types even internally.
 
 An example of the results of this conversion is the "interfaces"
 field above.  In the original compiler, it has the type "jclass *".
 I have now converted it in my copy so that it is "java.lang.Class[]";
 unfortunately my C++ knowledge is not that good, therefore I don't know what
 it would be in C++.
 
 The next step after this conversion is to add a new paramter to
 PUSH_FIELD and PUSH_FIELD_VALUE that allows the fields to be
 inserted or not inserted depending on compiler flags.  I am planning
 to add flags like -fexcluded-object-fields=name,name,name and
 -fexcluded-class-fields=name,name,name but if you have any better
 ideas please tell me.
  
 --Pekka