RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers
Roger.Riggs at Oracle.com
Wed Nov 1 14:31:46 UTC 2017
The Supplier/Consumer allocator/deallocator version is useful and
We should be able to do better than exposing raw native pointers for
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
I'm hopeful that Panama will support that direction.
In CleanerImp:322, is there a JMM issue with the escape of the reference
to the cleaner thread before the constructor has finished and published
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
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:
>> 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:
> 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.
More information about the core-libs-dev