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: Setting memory-chunk-size claimed when free-memory approacheszero?


When GC_collect_or_expand decides to expand the heap, it first
tries to expand the heap by it's desired amount.  If that fails,
it tries to expand by what it things it needs to satisfy the
current allocation request.  If both of those fail, it tries
to garbage collect GC_max_retries times and then gives up.
Well, it seems that my application is terminated before gc even gets the chance to chance to try the second approach.

The current default behavior is to set GC_max_retries to zero,
unless GC_MAXIMUM_HEAP_SIZE is set, in which case it's two by
default.  This makes a bit of sense, since if GC_MAXIMUM_HEAP_SIZE
is set, presumably it's set to avoid paging disasters.  (On an
embedded platform, paging is probably not an issue, but you do
want to set GC_MAXIMUM_HEAP_SIZE anyway, which should
give you reasonable behavior.)
That did work, yes... But I think it's only the second-best solution :-) It would be better if I didn't have to specify the amount of memory available. But ok, it's an embedded system, so I know more or less how much is available for my application. But I still have to be rather conservative, for otherwise I may shoot above the target.
So, I guess the "correct" way of doing it is to specify GC_INITIAL_HEAP_SIZE to be the same as GC_MAXIMUM_HEAP_SIZE, as well. Hence, then I'm sure that amount of memory is available all the time...


If you are really trying to adjust how aggressively the GC grows the
heap, then setting GC_free_space_divisor instead or in addition
is a good idea.
This can only be adjusted from within some C-code, right? I browsed misc.c
(http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/misc.c?rev=1.30), and didn't find any environment-variable that suited...


Regards,
 Martin Egholm


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