Bug 177131 - ppc: itext.jar -> .jar.so compilation uses too much memory
Summary: ppc: itext.jar -> .jar.so compilation uses too much memory
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: powerpc Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-06 16:01 UTC by Andrew Overholt
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

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


Attachments (Terms of Use)

Description Andrew Overholt 2006-01-06 16:01:39 UTC
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 16:13:15 UTC
(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 16:18:26 UTC
(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 16:23:15 UTC
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 16:29:12 UTC
(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 15:42:34 UTC
(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 14:25:22 UTC
No.  It works, it's good enough.

Comment 7 Andrew Overholt 2006-02-01 20:34:10 UTC
Cool, closing.


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