Re: Out-of-Memory Handling in Long-Running / Server Applications

On 2008.04.14., at 2:20, Jeff Kesselman wrote:
> "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.

Allow me to disagree, here's a scenario: GC can clear a soft/weak/
phantom reference that gets enqueued into a reference queue. The
application will (supposedly soon enough) process the reference queue,
and discard some other objects related to those objects (i.e.
WeakHashMap keys when the weakly reachable values' WeakReference
objects got cleared and enqueued). Suddenly there's more garbage to
collect.

This is a quite frequent scenario -- WeakHashMap is one example,
serialization internals also cache class-specific data by binding them
with less-than-strong references, clearing them on first serialization
operation after the classes become unreachable, and so forth. I really
wish ReferenceQueue supported event/listener mechanism to have GC
invoke listeners when a reference is enqueued. (And yes, I know this
sounds similar to finalizers, and I know what the pitfalls are, but
even if it only existed for phantom references that'd be very
beneficial - they wouldn't provide a reference to the phantom object
so it should theoretically be safe, and it could be specified that the
listener must be invoked at the time of enqueue, making it tad more
deterministic.)

Attila.

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

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