Controlling the garbage collector (GC) at RT?

[Martin Egholm Nielsen]

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