This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj performance on Solaris 2.6
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Subject: Re: gcj performance on Solaris 2.6
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Sun, 29 Jul 2001 23:37:20 -0400 (EDT)
- cc: java at gcc dot gnu dot org
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
{