Controlling the garbage collector (GC) at RT?

Thu Feb 10 21:50:00 GMT 2005

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