* Peter Levart: > Simply saying that "vm is in a more critical status than a inflater is > getting leaked out" is, in my opinion, covering the problem under the > rug. The VM is not in critical state - the program is. VM is robust > enough to recover from OOMEs. The program might be in critical status > (i.e. in inconsistent state) partly because of not accounting for such > OOME situations. By taking care of them, the program has a better chance > of recovering from such situation(s).
On the other hand, memory leaks on OOM are extremely common, and for the Inflater/ZStreamRef case, it might not be that critical to get this absolutely airtight (particularly if the fix has non-trivial concurrency implications). > Handling native resources is one place where I think it is beneficial to > complicate things in order to make native resource leaks (im/less > )possible. The other such place is synchronization primitives. We must > admit that finalization does have this benefit that it makes it hard to > construct code that would allocate the native resource before cleanup > registration (which is performed as part of Object.<init>, while logic > to allocate native resource is usually invoked from subclass > constructor). To achieve the same robustness with Cleaner API, one has > to be careful to either perform registration upfront and then allocate > native resource or arrange for back-out in case of trouble. If you allocate multiple resources, you probably need to apply the same level of care with finalizers. And the difficulty there lies in implementing a close() operating which releases resources and inhibits the effect of finalization.
