This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Controlling the garbage collector (GC) at RT?
You also need to touch the resulting memory. Try something like
char *v = sbrk( 1000000 );
for (char *p = v; p < p + 1000000; ++p) *p = 42;
in the loop.
I'll try something similar tomorrow, thanks alot - although I will need
modify the ever true statement "p < p + 1M" to "p < v + 1M"...
So, now I tried this:
#include <unistd.h>
int main( int i )
{
while ( 1 ) {
char *v = sbrk( 1000000 );
char *p;
for (*p = v; p < v + 1000000; ++p) {
*p = 42;
} // for
printf( "%x\n\n", v );
} // while
} // main
And still nothing happens with the memory consumption, although the
pointer ends up at 0xffffffff...
Weird?!
// Martin
I'll return in the morrow...
// Martin
-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On
Behalf Of Martin Egholm Nielsen
Sent: Wednesday, February 23, 2005 12:04 AM
To: java@gcc.gnu.org
Subject: Re: Controlling the garbage collector (GC) at RT?
It seems to me that the only problem here is that this
still seems to
happen with overcommit-accounting set to 2.
I would expect that you can reproduce this problem with a
program that
alternately allocates a few MB with sbrk, and then touches the
allocated memory. If you can't, there's something really
weird going
on here. If you can, it'll give you a test case for the kernel people.
I tried the following:
#include <unistd.h>
int main( int i )
{
while ( 1 ) {
void *v = sbrk( 100000 );
// sleep( 1 );
} // while
} // main
But that doesn't result in anything - the memory usage for the
application does not grow...
Are there anything else I should do to allocate the memory?
BR,
Martin
Hans
On Wed, 16 Feb 2005, Martin Egholm Nielsen wrote:
Hi Hans,
It would indeed be interesting to know why the Linux kernel
kills the application rather than returning failure.
Sure, but how to do that? Any guidelines?
What do you see on the console? Anything in the system log? Does
strace tell you anything?
Below is the last part of "strace -f -F -i -v". It doesn't
really look
like there's anything of value?
// Martin
[pid 75] [0f833558] write(1, "*** MEM CHUNK TAKEN:
8388608\n", 29***
MEM CHUNK TAKEN: 8388608
) = 29
[pid 75] [0f839834] brk(0x12d15000) = 0x12d15000
[pid 75] [0f839834] brk(0x12d25000) = 0x12d25000
[pid 75] [0f81126c] getpid() = 75
[pid 75] [0f799444] kill(77, SIGPWR <unfinished ...>
[pid 76] [0f840e2c] <... poll resumed> [{fd=3, events=POLLIN,
revents=POLLIN}
], 1, 2000) = 1
[pid 75] [0f799444] <... kill resumed> ) = 0
[pid 76] [0f81127c] getppid() = 75
[pid 76] [0f833548] read(3,
"\20\7/\234\0\0\0\4\17\374$0\20\7/\240$\0\0B\17\3
72j(\177"..., 148) = 148
[pid 76] [0f840e2c] poll( <unfinished ...>
[pid 75] [0f799444] kill(77, SIGXCPU) = 0
[pid 75] [0f839834] brk(0x13525000) = 0x13525000
[pid 75] [0f833558] write(1, "*** MEM CHUNK TAKEN:
8388608\n", 29***
MEM CHUNK TAKEN: 8388608
) = 29
[pid 75] [0f839834] brk(0x13535000) = 0x13535000
[pid 75] [0f839834] brk(0x13545000) = 0x13545000
[pid 75] [0f839834] brk(0x13d45000) = 0x13d45000
[pid 75] [0f833558] write(1, "*** MEM CHUNK TAKEN:
8388608\n", 29***
MEM CHUNK TAKEN: 8388608
) = 29
[pid 76] [0f840e2c] <... poll resumed> [{fd=3,
events=POLLIN}], 1,
2000) = 0
[pid 76] [0f840e2c] --- SIGTERM (Terminated) ---
#