Bug 177131 - ppc: itext.jar -> .jar.so compilation uses too much memory
ppc: itext.jar -> .jar.so compilation uses too much memory
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-06 11:01 EST by Andrew Overholt
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-01 15:34:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Overholt 2006-01-06 11:01:39 EST
Description of problem:
While attempting to build Anthony's RSSOwl RPMs [1], I needed to first build his
itext RPM [2].  I was trying this on my iBook which is running rawhide.  The
bytecode compilation goes fine, but when aot-compile-rpm attempts to
natively-compile the jar, it does not seem to finish and uses lots of my 768 MB
memory (over half when I stopped the process after 40 minutes).

Version-Release number of selected component (if applicable):
gcc-4.1.0-0.12.ppc

How reproducible:
Always (it happens if I install itext's jar and attempt to build RSSOwl native
as well).

Steps to Reproduce:
1. grab Anthony's itext SRPM [3]
2. rpmbuild --rebuild 

OR

1. wget http://overholt.ca/itext-1.3.jar.1.jar
2. gcj -shared -O2 -g -fsigned-char -fPIC -findirect-dispatch -fjni
-Wl,-Bsymbolic itext-1.3.jar.1.jar -o itext-1.3.jar.so

Actual results:

Process seemingly hangs in jc1:
++ /usr/bin/gcj -shared -O2 -g -fsigned-char -fPIC -findirect-dispatch -fjni
-Wl,-Bsymbolic
/var/tmp/itext-1.3-1jpp_2-root-andrew/usr/lib/gcj/itext/itext-1.3.jar.1.jar -o
/var/tmp/itext-1.3-1jpp_2-root-andrew/usr/lib/gcj/itext/itext-1.3.jar.so
jc1: warning: command line option "-fsigned-char" is valid for C/C++/ObjC/ObjC++
but not for Java

Expected results:
jc1 completes in a reasonable amount of time.

Additional info:
I tried removing -fsigned-char but it didn't appear to be the problem.  I can
make my laptop available to someone if they want.  Also, I doubt this happens on
i386 or Anthony probably would not have submitted his SRPMs for Extras.  I did
not try to reproduce on i386 yet, though.

[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176982
[2]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176981
[3]
http://people.redhat.com/green/FE/devel/itext-1.3-1jpp_2.src.rpm
Comment 1 Anthony Green 2006-01-06 11:13:15 EST
(In reply to comment #0)
> Also, I doubt this happens on
> i386 or Anthony probably would not have submitted his SRPMs for Extras.  I did
> not try to reproduce on i386 yet, though.
>

Don't be so sure! :-)

I had my system RPM optimization flags set to -O0, since I've been doing so much
debugging recently.  I'm going an optimized build now and it's getting fat and
slow.  

If I modify this to be a noarch RPM, will people have problems upgrading when we
switch it over to a native RPM?  I seem to remember yum having problems with this.

Comment 2 Andrew Overholt 2006-01-06 11:18:26 EST
(In reply to comment #1)
> If I modify this to be a noarch RPM, will people have problems upgrading when we
> switch it over to a native RPM?  I seem to remember yum having problems with this.
> 

I'm pretty sure these all got fixed.  Tom Fitzsimmons would know for sure.  Tom?
Comment 3 Andrew Haley 2006-01-06 11:23:15 EST
Go to aot-compile-rpm and revise these numbers downwards:

MAX_CLASSES_PER_JAR = 1024
MAX_BYTES_PER_JAR = 2097152

Tell us what you find.
Comment 4 Anthony Green 2006-01-06 11:29:12 EST
(In reply to comment #1)
>   I'm going an optimized build now and it's getting fat and
> slow.  

It eventually finished OK (x86 w/ optimization).

Comment 5 Andrew Overholt 2006-01-07 10:42:34 EST
(In reply to comment #3)
> Go to aot-compile-rpm and revise these numbers downwards:
> 
> MAX_CLASSES_PER_JAR = 1024
> MAX_BYTES_PER_JAR = 2097152
> 
> Tell us what you find.

I forgot to post here:  I tried lower numbers ((512, 0), (1024, 512)) and it
worked in both cases.  Shall I try other combinations?
Comment 6 Andrew Haley 2006-01-26 09:25:22 EST
No.  It works, it's good enough.
Comment 7 Andrew Overholt 2006-02-01 15:34:10 EST
Cool, closing.

Note You need to log in before you can comment on or make changes to this bug.