gcj/freenet status 20020504

gcj/freenet status 20020504

[Goran Thyni]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

My sparetime effort to get freenet compiling and running
with upcoming gcj 3.1 made some progress. There seems to 
be some important bugfixes going into gcc-CVS recently.

Environmnet:	Debiain GNU/Linux sid/unstable on AMD K6
		256 MB DRAM, 512 MB swap
		
GCJ:

Configured with: ./configure --prefix=/usr/local/gcc --enable-languages=java --disable-static --enable-threads : (reconfigured)  : (reconfigured)  : (reconfigured) 
Thread model: posix
gcc version 3.1 20020430 (prerelease)

Freenet is CVS of today.

A Freenet node (fred) is a complex servernode,
quiet large (29MB unstripped) and use threads and I/O
heavily, so it should be a good testbed for gcj.

All tests is with services set to "no" to just exercise
the core node and no servlets code etc.

First I ran as a transistent node and tested with frost,
it ran OK for 15 minutes.
I stopped and reconfigured as a permenent node, announcing and all.
I run OK, but after about 30-40 minutes all memory 256+512 MB was
used up and the node was killed.

I though it was leakage in the node itself, but after a little investigation
I saw some very large processes - a few each of "addr2line" and "c++filt" -
which must have been started by fred. Those processes also remained after
to node where killed and had to be shut down manually.
I think it has something to do with exception handling in libgcj.
Will investigate further and post gccbug(s) when I got some more time
if someone does beat me to it.

happy hacking,
-- 
Göran Thyni
Luleå / Kiruna

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: gcj/freenet status 20020504

[Bryce McKinlay]

Goran Thyni wrote:

>I though it was leakage in the node itself, but after a little investigation
>I saw some very large processes - a few each of "addr2line" and "c++filt" -
>which must have been started by fred.
>

Yes, these are used for stack trace printing - see name-finder.cc and 
java/lang/natThrowable.cc. Is something in freenet calling 
Throwable.printStackTrace() a lot?

> Those processes also remained after
>to node where killed and had to be shut down manually.
>

Thats very odd. Child processes should get killed when the parent dies 
no matter what.

regards

Bryce.

Re: gcj/freenet status 20020504

[Andrew Haley]

Bryce McKinlay writes:
 > Goran Thyni wrote:
 > 
 > >I though it was leakage in the node itself, but after a little investigation
 > >I saw some very large processes - a few each of "addr2line" and "c++filt" -
 > >which must have been started by fred.
 > >
 > 
 > Yes, these are used for stack trace printing - see name-finder.cc and 
 > java/lang/natThrowable.cc. Is something in freenet calling 
 > Throwable.printStackTrace() a lot?
 > 
 > > Those processes also remained after
 > >to node where killed and had to be shut down manually.
 > >
 > 
 > Thats very odd. Child processes should get killed when the parent dies 
 > no matter what.

What will cause that to happen?  If the child process blocks on
output, when eventually its parent exits it will be owned by exec
which will patiently wait for it to terminate.

It sounds to me like "addr2line" and "c++filt" are buggy.  There's no
reason they should be large.

Andrew.

Re: gcj/freenet status 20020504

[Göran Thyni]

I'm out of town so I can just speculated until I have an oppotunity
to investigate things closer

On Tue, May 07, 2002 at 01:28:48PM +0100, Andrew Haley wrote:
> What will cause that to happen?  If the child process blocks on
> output, when eventually its parent exits it will be owned by exec
> which will patiently wait for it to terminate.

More patient than me, :-)
I killed them manually.
They propabably waits for something from their dead father,
I would guess that an "out of memory" exception kills fred
and leaves his children orphaned.

> It sounds to me like "addr2line" and "c++filt" are buggy.  There's no
> reason they should be large.

At least addr2line is working against fred's pid file the /proc file system.
If it maps the process, addr2line itself will be very large since
fred is large himself.
And fred is multithreaded too so if he throws exceptions in several
threads and there will be a large addr2line (and c++filt) for each
thread hanging around til the particular thread dies, mucho memory
will be eaten by fred and his friends.


regards,
-- 
Göran Thyni
 Kiruna/Luleå, Sweden

Re: gcj/freenet status 20020504

[Andrew Haley]

=?iso-8859-1?Q?G=F6ran?= Thyni writes:
 > I'm out of town so I can just speculated until I have an oppotunity
 > to investigate things closer
 > 
 > On Tue, May 07, 2002 at 01:28:48PM +0100, Andrew Haley wrote:
 > > What will cause that to happen?  If the child process blocks on
 > > output, when eventually its parent exits it will be owned by exec
 > > which will patiently wait for it to terminate.
 > 
 > More patient than me, :-)
 > I killed them manually.
 > They propabably waits for something from their dead father,
 > I would guess that an "out of memory" exception kills fred
 > and leaves his children orphaned.

That's possible.  Once the system runs out of memory it's hard to
terminate cleanly.

 > > It sounds to me like "addr2line" and "c++filt" are buggy.  There's no
 > > reason they should be large.
 > 
 > At least addr2line is working against fred's pid file the /proc file system.
 > If it maps the process, addr2line itself will be very large since
 > fred is large himself.

addr2line doesn't map the process, just the executable file.  But
indeed, that could be large.

Andrew.