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

[Roger Riggs]

Hi Peter,

The Supplier/Consumer allocator/deallocator version is useful and 
interesting encapsulation.

We should be able to do better than exposing raw native pointers for 
other resources.
They should have better more complete encapsulation including their cleanup.
For example, the recent work on FileDescriptor.
The current state with direct memory pointers floating freely is quite 
sensitive.

I'm hopeful that Panama will support that direction.

In CleanerImp:322, is there a JMM issue with the escape of the reference 
to PhantomCleanableResource
to the cleaner thread before the constructor has finished and published 
the instance?
True, the constructor holds this until the very end of the method but 
what makes sure
the new valuewritten to the resource field will be read by the cleanable 
thread?

Thanks, Roger


On 10/31/2017 11:17 PM, mandy chung wrote:
>
>
> On 10/31/17 4:07 PM, Peter Levart wrote:
>> Hi Mandy, Sherman, Roger,
>>
>> On 10/31/17 00:25, mandy chung wrote:
>>>
>> I played a little with an idea of how such additional Cleaner API 
>> might look like. Here's what I came up with, together with how this 
>> would apply to ZipFile/Inflater/Deflater:
>>
>> http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.02/
>>
>> So, what do you think of this new Cleaner API extension?
>
> This serves as a good starting point.  I converted the 
> ClassLoader.NativeLibrary to use it:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev-cleanable/
>
> Looks reasonably well and probably some other improvement I could do.  
> I use createResource rather than createLongResource which is 
> specialized for an address. We should check out panama how this plays out.
>
> I think it would be useful to iterate on several more use cases and it 
> would be better to separate this RFE from JDK-8185582 so that we can 
> explore with its own pace.
>
> Mandy