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] | |
Well, it seems that my application is terminated before gc even gets the chance to chance to try the second approach.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.
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.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.)
This can only be adjusted from within some C-code, right? I browsed misc.cIf 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.
Regards, Martin Egholm
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |