Re: Projects

[Per Bothner <per at bothner dot com>]

Here are some suggested additions:

--- projects-orig.html	Thu Apr 27 13:24:21 2000
+++ projects.html	Thu Apr 27 13:23:44 2000
@@ -127,7 +127,10 @@
 href="http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/egcs/gcc/java/verify.c">verifier</a>
 to ensure the validity of natively compiled code.  What's really needed is
 a verification package that the libgcj ClassLoader can use to 
-verify dynamically loaded bytecode.
+verify dynamically loaded bytecode.  It may be possible to use
+GCJ's <code>verify.c</code> as a starting point.  It may even be possible
+(with suitable macros and typedefs) to use the same verifier both in
+GCJ and the run-time.
 <p>
 
 <br>
@@ -176,6 +179,35 @@
 href="http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/egcs/gcc/java/expr.c">gcc/java/expr.c</a>
 contains the start of this, and is currently disabled.
 
+	  <li>If an object or array is allocated in static code that is
+          executed at most once (i.e. not in a loop or in a non-private
+	  method), then we have the option of pre-allocating the object
+	  or array in the static data or bss segment.  This is most
+	  obviously the right thing to do when the expression is an array
+	  brace initializer whose elements are compile-time constants, since
+	  then we can initialize the array statically.  (This is already
+	  implemented.)  It also makes sense for array elements that
+          are initialized to link-time constants, such as references
+	  to other statically allocated objects, as you might get
+	  from a multi-dimensional array brace-initializer.
+	  <p>
+	  It may also make sense to pre-allocate a non-array object.
+	  It makes most sense when the object constructor is inlined,
+	  especially if it turns out that most or all of the fields get
+	  initialized to constants.  Even if the constructor is not inlined,
+	  it may still make sense to pre-allocate the object if it is
+	  being assigned to a static final field:  The tradeoff is that
+	  you save the space needed for the call to allocate the object, but
+	  you use more space if it turns out the class is never initialized.
+	  <p>
+	  Note that if a statically allocated object contains
+          pointer fields then the gc has to know about the object.
+          The cleanest way is to make sure the object header has
+	  appropriate flags so that the gc recognizes that the object is
+	  static but has pointer fields.  There is no need to register the
+	  static object with the gc, since if it is live, it will get
+	  traversed anyway (typically via the fields table of the declaring
+          class).
 	  <li>Write the runtime side of
 	  <tt>-fhash-synchronization</tt> and see how it affects
 	  performance.
@@ -201,6 +233,28 @@
 	    from Java source code), since gcj already represents
 	    entire functions as trees.
 
+	    <li>When compiling from bytecode, GCJ generates tree nodes
+	    as long as it is within a single "statement" - i.e. no branching
+	    or side effects.  However, any branching or other complications
+	    causes RTL to be emitted.  This is similar to the historical
+	    way the C and C++ front-ends were implemented.  Gcc now has support
+	    for representing an entire method body as a tree node, and g++
+	    has been converted to do that, because it makes certain
+	    optimizations more practical.  Gcj already represents an entire
+	    method body as a single tree structure when compiling from
+	    Java source;  we should do the same
+	    when compiling from bytecode.  To begin with, we can represent
+	    control flow using <code>GOTO_EXPR</code>.  However, if would
+	    be better if we can deduce higher-level structure.  I.e. it is
+	    easy to generate
+	    <code>(COND_EXPR TEST (GOTO_EXPR L1) (GOTO_EXPR L2))</code>, but it
+	    would be better though harder to simplify that to a
+	    <code>COND_EXPR</code> that does not use <code>GOTO_EXPR</code>.
+	    The simplification is probably best done after we have generated
+	    a correct but <code>GOTO</code>-based tree representation.
+	    For example, if a label is only used once, we can move its code
+	    to where the unique <code>GOTO</code> is.
+
 	    <li>Add hooks to gcj and g++ to generate write barriers.
 	    This would let us write a precise collector.
 
@@ -216,6 +270,16 @@
             optionally enable it for all method calls and field
             dereferences.  This will let gcj-compiled code work
             correctly on systems without an MMU.
+
+	    <li>The structure of <code>expand_byte_code</code> in
+	    <code>expr.c</code> uses macros in a way that in retrospect
+	    looks like a mistake.  It should be re-written to be a simple
+	    switch statement based on the structure of
+	    <code>verify_jvm_instructions</code> in <code>verify.c</code>.
+            (There are actually two switch statements using the magic macros
+	    in <code>expr.c</code> - look for the includes of
+	    <code>"javaop.def"</code>.  They should both be re-written, but
+	    second one is higher priority.)
 	  </ul>
 <p>
 

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/