Re: Controlling the garbage collector (GC) at RT?

[Martin Egholm Nielsen <martin at egholm-nielsen dot dk>]

Hi,

> 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?

> But most you should be able to recover in the 99% of cases in which
> the sbrk or mmap fails.
I have recover percentage of zero.

> re: Heap expansion
> Ideally I think the GC should use a reasonable default strategy
> based on what it knows about the platform, and you should be able
> to override that dynamically.  Currently, I think we have the first
> part of that.
Sure, this "request" was born from the lack of succes in the above 
situations...

// Martin

> > -----Original Message-----
> > From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> > On Behalf Of Martin Egholm Nielsen
> > Sent: Tuesday, February 08, 2005 1:49 AM
> > To: java@gcc.gnu.org
> > Subject: Re: Controlling the garbage collector (GC) at RT?
> >
> >
> > Hi Hans,
> >
> >
> > > > But it would also be really nice if I could, somehow, control the
> > > > heap-increase-size (factor). It seems to be 1.33 today:
> > > >
> > > > heap_last_increase_size *= 1.33;
> > > > heap_size += heap_last_increase_size;
> > > >
> > > > I would like to specify an initial "heap_last_increase_size",
> > > > and then 
> > > > an increase-factor of 1.0.
> > > > That way, I wouldn't have to specify the "GC_..._HEAP_SIZE" that 
> > > > accurately (and possibly risk overshooting if too ambitious, and 
> > > > undershooting with several megs if too carefull)...
> >
> > > That's kind of already possible, but it's currently only build-time 
> > > configurable.  (Look for MINHINCR and MAXHINCR.)  I think 
> >
> > there's no 
> >
> > > good reason for that, since it's rarely accessed.
> > > (It's currently expressed as a multiple of the minimum heap block
> > > size.  That would need to be fixed.)  If someone wants to submit a
> > > patch ...
> >
> > But don't you agree it would make sense that different targets could 
> > have different GC strategies?
> > Or perhaps I should rather dig into the reason why the Linux kernel 
> > terminates the application just because the GC tries to 
> > allocate beyond 
> > the memory boundary - and then just leave GC alone?!
> >
> > Thanks for all the help,
> >  Martin