gcj performance on Solaris 2.6

[Jeff Sturm]

On Mon, 30 Jul 2001, Bryce McKinlay wrote:
> 
> > I built one application library at -O0, -O2 and -O3 with the patch below,
> > and at -O2 unpatched for comparison.
> >
> >    text    data     bss     dec     hex filename
> > 1659369  247180     704 1907253  1d1a35 libjacl-O0.so
> > 2474525  243612     704 2718841  297c79 libjacl-O2-unpatched.so
> > 1354881  237836     704 1593421  18504d libjacl-O2.so
> > 1418826  236272     704 1655802  1943fa libjacl-O3.so
> 
> I applied this patch and found it made no difference to the size of a libgcj
> built with -O2. Any ideas why?

I forgot to mention I compiled the entire app in one pass, i.e.:

gcj -O2 -fPIC -shared $(srcs) -o libjacl.so

otherwise inlining across classes does not yet work.  I'd like to try
building libgcj this way, perhaps into one object per package.

BTW, I find the backend tends to ICE when inlining large packages like
this.  Below is a possible fix to duplicate_eh_regions():

Index: except.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/except.c,v
retrieving revision 1.143.2.13
diff -u -r1.143.2.13 except.c
--- except.c	2001/06/08 22:55:33	1.143.2.13
+++ except.c	2001/07/30 03:30:56
@@ -1448,8 +1448,10 @@
 	cur->inner = root;
 
       for (i = 1; i <= ifun_last_region_number; ++i)
-	if (n_array[i]->outer == NULL)
-	  n_array[i]->outer = cur;
+	{
+	  if (n_array[i] && n_array[i]->outer == NULL)
+	    n_array[i]->outer = cur;
+	}
     }
   else
     {