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

["Boehm, Hans" <hans dot boehm at hp dot com>]

It would indeed be interesting to know why the Linux kernel kills
the application rather than returning failure.

I think there's always a bit of a risk of not being able to recover
when you run out of memory.  If the allocation barely succeeds,
and you then run out of space trying to expand the stack or to
write to a copy-on-write page with static data, the process
will probably die.

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

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.

Hans

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