This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Hans


> -----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) ---
> >>#
> >>
> >>
> > 
> > 
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]