Randall R Schulz wrote:
> Hi,
>
> My application has highly variable running times and memory demands
> based on the problems submitted to it. Some hard-to-solve (or
> insoluble) problems will run it out of memory.
>
> When memory is exhausted in the inner loop of the program (the only
> place it's going to happen), I catch the OutOfMemoryError, release the
> storage, trigger a GC (forcing it would seem desirable,
"Forcing" Gc is impossible.  By the definition of the language.  When
and how much to GC is always the VMS call.

Its also unnecessary.  By the definition of the language you will
*never* get a OOM exception until a best effort
has been made to reclaim the needed memory.  Trying to GC again will
simply return the same result.
>  but I'm not
> sure how to do that) and report the failure back up the call chain.
> The vast majority of the RAM is used in the search tree, which is
> linked only upwardly from the leaves and the leaves are all in a
> priority queue, so relinquishing the priority queue is enough to make
> all the objects in the tree unreferenceable.
>
> This technique sometimes works and sometimes does not. I.e., when it
> doesn't work the program gets another OOM very shortly after or during
> the my OOM handling and dies.
>
Then there is not enough collectable memory available. period.  Or the
VM is broken.  Given the state of
development of the common VMs, unless you are using a weird VM, this
second is unlikely.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com