Controlling the garbage collector (GC) at RT?
Martin Egholm Nielsen
martin@egholm-nielsen.dk
Sat Feb 26 19:44:00 GMT 2005
> 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"...
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) ---
>>>>#
>>>>
>>>>
>>>
>>>
>>
>
More information about the Java
mailing list