RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

[Florian Weimer]

* 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.