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
