At 19:11 Uhr +0100 28.09.2000, David Brownlee wrote:
>On Thu, 28 Sep 2000, Hauke Fath wrote:
> > I've got IBM's Java compiler Jikes 1.0.6 set up on a 1.4.1 server
> > (PPro 200, 128 MB RAM) to do regular test builds from the current
> > repository. During compiles, the load goes up to 3.5, and Jikes eats
> > up to 50MB memory. The whole build (cvs checkout, compile, jar) takes
> > about five minutes. If anybody is doing anything on the machine at
> > the time (it's an SMB/AppleShare server, CVS server, html documents
> > server), they feel the load but can still work.
> >
> > Now, I have set up Jikes on my 1.5 workstation (2x PII/350, 256MB
> > RAM). Built from the same sources, the 1.5 ELF Jikes wants ~300MB
> > memory. The whole build takes 10..15 minutes, most of which appears
> > to be excessive swapping (cpu activity is near zero). During the
> > build, the machine is close to unusable.
>man
>	Can you test the 1.4.1 binary on the 1.5 system to confirm it
>	is a library/toolchain rather than a kernel issue (copying
>	a.out libraries across into /usr/lib/aout and using the
>	uuencode a.out ld.so from 1.5).

Wow... That makes for ~230,000 LOC Java code on the PII/350

(a.out)		top(1) 		SIZE 130MB
		time(1)		101.6 real, 48,75 user, 17,98 sys
		wallclock	2:40 min

(elf)		top(1)		SIZE 336MB
		time(1)		751.78 real, 55.88 user, 11.59 sys
		wallclock	12:31 min

That's "only" a factor of three in memory consumption (looks like our 
project has grown a bit since the ~50MB; the build takes ~125MB on 
the PPro 200).

>
>	Assuming it is userland/toolchain, could it be the new malloc
>	library - does "ln -sf R /etc/malloc.conf" have any effect?

[hf@scree] ~ > man -k malloc.conf
malloc.conf: nothing appropriate
[hf@scree] ~ >

I found it in malloc(3)... strange concept... No, makes no difference.

	hauke


-- 
Hauke Fath                        tangro software components GmbH
                                         D-69115 Heidelberg
hf@tangro.de                       Ruf +49-6221-13336-0, Fax -21