Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Martin, As I have been studying the CleanerTest too recently, let me comment on some questions... On 05/09/2016 06:34 PM, Martin Buchholz wrote: --- Assert.assertEquals(map.get(k2), data, "value should be found in the map"); key = null; System.gc(); Ass

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On Mon, May 9, 2016 at 11:10 AM, Roger Riggs wrote: > I'm not sure I understand what > > "a CompletableFuture-based API for cleanup actions." > > would look like or how it would be used. I'm fuzzy myself, but the idea is that any asynchronous action that will be completed in the future should be

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Martin, I added a link to these notes to the JDK-8144531 Cleanup of Cleaner implementation. I'm not sure I understand what "a CompletableFuture-based API for cleanup actions." would look like or how it would be used. Thanks, Roger On

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

I haven't been following along with the long review thread, but I took a look at the new Cleaner stuff and have some belated comments: --- Please add missing semicolon: *private final Cleaner.Cleanable cleanable --- The below looks non-sensical; maybe should return EV_CLEAR if some cle

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Since the current implementation of the old Cleaner and DirectByteBuffer works well and there is a lot of work piling up against the FC date, I'm in favor of keeping it as it is until the possibilities with Panama settle out. It would best if reclamation was not GC based, except as

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 04/05/2016 04:41 PM, Peter Levart wrote: On 04/04/2016 11:50 PM, Roger Riggs wrote: I don't see the need to change Cleaner to an interface to be able to provide an additional method on CleanerImpl or a subclass and a factory method could provide for a clean and very targeted inte

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, > On Apr 5, 2016, at 7:41 AM, Peter Levart wrote: > > The bottom line is that we need a mechanism that: > > - triggers reference discovery when native memory limit is approached or > reached > - retires native memory reservation at appropriate time slots until > succeeding or until

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 04/04/2016 11:50 PM, Roger Riggs wrote: Hi Peter, Stepping back just a bit. Right, let's clear up. The old Cleaner running on the Reference processing thread had a few (2) very well controlled functions, reference processing and deallocating DirectByteBuffers. Maybe we can'

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Stepping back just a bit. The old Cleaner running on the Reference processing thread had a few (2) very well controlled functions, reference processing and deallocating DirectByteBuffers. Maybe we can't do too much better than that. The old worst case performance/latency wise was t

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, Thanks for looking at the patch. On 04/02/2016 01:31 AM, Roger Riggs wrote: Hi Peter, I overlooked the introduction of another nested class (Task) to handle the cleanup. But there are too many changes to see which ones solve a single problem. Sorry to make more work, but I think w

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Apr 1, 2016, at 4:31 PM, Roger Riggs wrote: > > Hi Peter, > > I overlooked the introduction of another nested class (Task) to handle the > cleanup. > But there are too many changes to see which ones solve a single problem. > > Sorry to make more work, but I think we need to go back to th

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, I overlooked the introduction of another nested class (Task) to handle the cleanup. But there are too many changes to see which ones solve a single problem. Sorry to make more work, but I think we need to go back to the minimum necessary change to make progress on this. Omit all of

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Thanks for the diffs to look at. Two observations on the changes. - The Cleaner instance was intentionally and necessarily different than the CleanerImpl to enable the CleanerImpl and its thread to terminate if the Cleaner is not longer referenced. Folding them into a single object

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 04/01/2016 06:08 PM, Peter Levart wrote: On 04/01/2016 05:18 PM, Peter Levart wrote: @Roger: ... About entanglement between nio Bits and ExtendedCleaner.retryWhileHelpingClean(). It is the same level of entanglement as between the DirectByteBuffer constructor and Cleaner.register().

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 04/01/2016 05:18 PM, Peter Levart wrote: So I'm going to propose a solution for #1 while still keeping the rest of webrev unchanged for now and will try to address other issuer later. Here's new webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.12.part2/ .

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 04/01/2016 05:18 PM, Peter Levart wrote: @Roger: ... About entanglement between nio Bits and ExtendedCleaner.retryWhileHelpingClean(). It is the same level of entanglement as between the DirectByteBuffer constructor and Cleaner.register(). In both occasions an action is provided to the

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, Roger, On 04/01/2016 06:07 AM, Mandy Chung wrote: Hi Peter, I found this thread has grown to discuss several relevant issues that can be separated. 1. Assist cleaner to deallocate direct byte buffer (JDK-6857566) 2. Replace direct byte buffer with java.lang.ref.Cleaner 3. java.lang.r

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, I found this thread has grown to discuss several relevant issues that can be separated. 1. Assist cleaner to deallocate direct byte buffer (JDK-6857566) 2. Replace direct byte buffer with java.lang.ref.Cleaner 3. java.lang.ref.Cleaner be an interface vs final class 4. Pending reference

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 03/31/2016 09:12 PM, Roger Riggs wrote: Hi Peter, It would be simpler to understand the changes if we solve the problems one at a time, at least for review purposes. Right. We can focus on one aspect at a time, but I'm still trying to keep the whole thing in a working conditio

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, It would be simpler to understand the changes if we solve the problems one at a time, at least for review purposes. To your question in the 2nd part about the Cleaner. (webrev.11.part2) I don't think the communication between the memory reserving thread and the unreserving thread s

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Per, On 03/29/2016 04:03 PM, Per Liden wrote: Hi Peter, On 2016-03-28 19:18, Peter Levart wrote: [...] And now a few words about ReferenceHandler thread and synchronization with it (for Kim and Per mostly). I think it should not be a problem to move the following two java.lang.ref.Reference

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, On 2016-03-28 19:18, Peter Levart wrote: [...] And now a few words about ReferenceHandler thread and synchronization with it (for Kim and Per mostly). I think it should not be a problem to move the following two java.lang.ref.Reference methods to native code if desired: static Re

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, Kim, Per and Roger I'd like to continue the discussion about the 2nd part of removing jdk.internal.ref.Cleaner in this discussion thread. There was some discussion about whether to synchronize with ReferenceHandler thread and wait for it to enqueue the Reference(s) or simply detect

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Mar 19, 2016, at 7:00 AM, Peter Levart wrote: > > Here's the webrev: > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.08.part2/ > >> >> On 03/07/2016 07:35 PM, Mandy Chung wrote: >>> >>> I studied webrev.06priv and the history of JDK-6857566. >>> >>

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy and others, After jake integration into jdk9-dev and a fix for NativeBuffer/InnocuousThread bootstrap issue that arose after part1 of this patch was pushed, which is planned for next week, we can continue with discussion about part2 of this patch - the DirectByteBuffer part. I have

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, Chris, Kim, Roger and others, Hearing no objections for a day, two Reviewers saying it looks ok and successfully re-running the tests, I pushed webrev.07.part1 to jdk9-dev. Thanks for reviews and comments. Now to the 2nd part... On 03/07/2016 07:35 PM, Mandy Chung wrote: ... And

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Mar 6, 2016, at 8:00 AM, Peter Levart wrote: > > Hi, > > I have been asked to split the changes needed to remove > jdk.internal.ref.Cleaner into two changesets. The first one is to contain the > straightforward non-controversial changes that remove the references to > jdk.internal.ref.Cl

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Mar 6, 2016, at 5:00 AM, Peter Levart wrote: > > Hi, > > I have been asked to split the changes needed to remove > jdk.internal.ref.Cleaner into two changesets. The first one is to contain the > straightforward non-controversial changes that remove the references to > jdk.internal.ref.C

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 06/03/16 13:00, Peter Levart wrote: Hi, I have been asked to split the changes needed to remove jdk.internal.ref.Cleaner into two changesets. The first one is to contain the straightforward non-controversial changes that remove the references to jdk.internal.ref.Cleaner and swaps them with ja

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi, I have been asked to split the changes needed to remove jdk.internal.ref.Cleaner into two changesets. The first one is to contain the straightforward non-controversial changes that remove the references to jdk.internal.ref.Cleaner and swaps them with java.lang.ref.Cleaner in all places bu

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, I think this cleans up all the points raised earlier. The optimization for enqueuing from the reference queue seems ok to me and should be more efficient than the previous implementation but I think Mandy or Alan should look at it also. Thanks, Roger On 2/25/2016 4:17 AM, Peter Le

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Alan, On 02/25/2016 09:00 AM, Alan Bateman wrote: On 25/02/2016 07:24, Peter Levart wrote: : I kept the public boolean Cleaner.cleanNextPending() method which now only deals with enqueued Cleanable(s). I think this method might still be beneficial for public use in situations where clea

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 25/02/2016 07:24, Peter Levart wrote: : I kept the public boolean Cleaner.cleanNextPending() method which now only deals with enqueued Cleanable(s). I think this method might still be beneficial for public use in situations where cleanup actions take relatively long time to execute so th

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Kim, Roger, Mandy, Resending with correct From: field to reach the list too... On 02/24/2016 12:22 AM, Kim Barrett wrote: On Feb 23, 2016, at 11:35 AM, Peter Levart wrote: Hi Roger, Mandy, Here's another webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.05

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi, Moving cleanNextPending to the CleanerImpl is ok but exposes more of the CleanerImpl to the rest of java.base internals; loosing a bit of encapsulation. As for the calls to Reference.tryHandlePending(false), the existing code in Bits to reserveMemory is called on arbitrary threads (whoev

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 23, 2016, at 3:22 PM, Kim Barrett wrote: > > I'm not sure what to do about any of this; I'm just feeling like maybe > the proposed API / implementation isn't quite right yet. I suggest restore the JavaLangRefAccess used by direct byte buffer code and revisit such explicit mechanism un

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 23, 2016, at 11:35 AM, Peter Levart wrote: > > Hi Roger, Mandy, > > Here's another webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.05/ > > I renamed the method and reworded the specification. Is this better now? > > > On 02/22/2016 10:56 PM, Rog

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Alan, On 02/23/2016 04:33 PM, Alan Bateman wrote: On 22/02/2016 21:41, Mandy Chung wrote: : I added new method to Cleaner: public boolean helpClean() { } I’m in two minds of making this a public method. An explicit way to enqueue pending references as well as invoke Cleanable::clea

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, Mandy, Here's another webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.05/ I renamed the method and reworded the specification. Is this better now? On 02/22/2016 10:56 PM, Roger Riggs wrote: Hi Mandy, On 2/22/2016 4:41 PM, Mandy Chung wrote: The

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 22/02/2016 21:41, Mandy Chung wrote: : I added new method to Cleaner: public boolean helpClean() { } I’m in two minds of making this a public method. An explicit way to enqueue pending references as well as invoke Cleanable::clean. If it goes in, the method name needs to be rename

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 22, 2016, at 1:56 PM, Roger Riggs wrote: > > Hi Mandy, > > On 2/22/2016 4:41 PM, Mandy Chung wrote: >>> On Feb 21, 2016, at 10:55 AM, Peter Levart wrote: >>> > >>> I added new method to Cleaner: >>> >>>public boolean helpClean() { } >>> >> I’m in two minds of making this a pub

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, On 2/22/2016 4:41 PM, Mandy Chung wrote: On Feb 21, 2016, at 10:55 AM, Peter Levart wrote: I added new method to Cleaner: public boolean helpClean() { } I’m in two minds of making this a public method. An explicit way to enqueue pending references as well as invoke Cleanab

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 21, 2016, at 10:55 AM, Peter Levart wrote: > > Hi Kim, Roger, > > I have prepared another webrev which addresses your outstanding concerns: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.04/ > MethodHandleNatives.java line 71-74 Nit: can you break t

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Kim, Roger, I have prepared another webrev which addresses your outstanding concerns: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.04/ I added new method to Cleaner: public boolean helpClean() { ... } I think this form of method that just does one quantum o

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Nice to see this improvement. I would support adding the drainQueue method to java.lang.ref.Cleaner; it provides a mechanism to share the cleanup load (as in the case of Direct buffers) that may be useful to other use cases. It is preferable to hacking in to the CleanerImpl. Makin

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 17, 2016, at 4:06 AM, Peter Levart wrote: > > Hi Kim, > > Thanks for looking into this. Answers inline… Peter, Thanks for the explanations. > On 02/17/2016 01:20 AM, Kim Barrett wrote: >>> However, I recall Roger saying there were existing tests that >> failed when certain uses of su

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 02/17/2016 10:06 AM, Peter Levart wrote: On 02/17/2016 01:20 AM, Kim Barrett wrote: src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java I don't understand why CleanerImpl needs to be changed to public in order to provide access to the new drainQueue. Wouldn't it be better to a

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 16/02/2016 16:15, Peter Levart wrote: : and the following two, which seem to not like my network config. or something like that: java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java: Unit test for DatagramChannel's multicast support java/nio/channels/DatagramChannel/Promiscuo

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Kim, Thanks for looking into this. Answers inline... On 02/17/2016 01:20 AM, Kim Barrett wrote: On Feb 16, 2016, at 11:15 AM, Peter Levart wrote: Hello everybody, Thanks for looking into this and for all your comments. Now that it seems we have a consensus that replacing internal Cleaner

Re: We don't need jdk.internal.ref.Cleaner any more

On 02/17/2016 01:17 AM, Kim Barrett wrote: On Feb 8, 2016, at 5:46 AM, Peter Levart wrote: If special-casing in ReferenceHandler is removed then an opportunity opens to get rid of ReferenceHandler thread altogether. VM/GC could enqueue Reference(s) to their respective ReferenceQueue(s) direc

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 16, 2016, at 7:20 PM, Kim Barrett wrote: > src/java.base/share/classes/java/lang/ref/Reference.java > > After removal of the special handling of removing Cleaner objects from > the pending list, do we still need to catch OOMEs from the pending > list? If not sure, feel free to defer tha

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 16, 2016, at 11:15 AM, Peter Levart wrote: > > Hello everybody, > > Thanks for looking into this and for all your comments. Now that it seems we > have a consensus that replacing internal Cleaner with public Cleaner is not a > wrong idea, I created an issue for it [1] so that we may o

Re: We don't need jdk.internal.ref.Cleaner any more

> On Feb 8, 2016, at 5:46 AM, Peter Levart wrote: > If special-casing in ReferenceHandler is removed then an opportunity opens to > get rid of ReferenceHandler thread altogether. VM/GC could enqueue > Reference(s) to their respective ReferenceQueue(s) directly, so everyone > could enjoy the ben

Re: We don't need jdk.internal.ref.Cleaner any more

> On Feb 15, 2016, at 9:24 PM, David Holmes wrote: > >> This patch looks correct to me. The innocuous thread created for common >> cleaner is of Thread.MAX_PRIORITY - 2 priority whereas the reference handler >> thread is of MAX_PRIORITY priority. I don’t know if this would impact any >> re

RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hello everybody, Thanks for looking into this and for all your comments. Now that it seems we have a consensus that replacing internal Cleaner with public Cleaner is not a wrong idea, I created an issue for it [1] so that we may officially review the implementation. I also created an updated

Re: We don't need jdk.internal.ref.Cleaner any more

On 15 Feb 2016, at 20:05, Mandy Chung wrote: > >> On Feb 15, 2016, at 9:06 AM, Uwe Schindler wrote: >> >> Hi, >> >>> On 15/02/2016 14:57, Chris Hegarty wrote: Peter, http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/ > > This patch looks corr

Re: We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, On 16/02/2016 6:05 AM, Mandy Chung wrote: On Feb 15, 2016, at 9:06 AM, Uwe Schindler wrote: Hi, On 15/02/2016 14:57, Chris Hegarty wrote: Peter, http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/ This patch looks correct to me. The innocuous threa

Re: We don't need jdk.internal.ref.Cleaner any more

> On Feb 15, 2016, at 9:06 AM, Uwe Schindler wrote: > > Hi, > >> On 15/02/2016 14:57, Chris Hegarty wrote: >>> Peter, >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/ >>> This patch looks correct to me. The innocuous thread created for common cleaner is

RE: We don't need jdk.internal.ref.Cleaner any more

Hi, > On 15/02/2016 14:57, Chris Hegarty wrote: > > Peter, > > > > > > > http://cr.openjdk.java.net/~plevart/jdk9- > dev/removeInternalCleaner/webrev.02/ > > > > Given the changes in 6857566, I think your proposal to remove > > jdk.internal.ref.Cleaner should be good. ( Note: third party libraries

Re: We don't need jdk.internal.ref.Cleaner any more

On 15/02/2016 14:57, Chris Hegarty wrote: Peter, > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/ Given the changes in 6857566, I think your proposal to remove jdk.internal.ref.Cleaner should be good. ( Note: third party libraries digging into internals of dir

Re: We don't need jdk.internal.ref.Cleaner any more

Peter, > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/ Given the changes in 6857566, I think your proposal to remove jdk.internal.ref.Cleaner should be good. ( Note: third party libraries digging into internals of direct buffers will need to change again ). -Ch

Re: We don't need jdk.internal.ref.Cleaner any more

Peter, On 08/02/16 10:58, Peter Levart wrote: On 02/08/2016 10:33 AM, Chris Hegarty wrote: On 8 Feb 2016, at 06:27, Alan Bateman wrote: On 07/02/2016 22:20, Peter Levart wrote: : If the decision to remove sun.misc.Cleaner was partly influenced by the desire to maintain just 2 instead of

Re: We don't need jdk.internal.ref.Cleaner any more

On 02/08/2016 10:33 AM, Chris Hegarty wrote: On 8 Feb 2016, at 06:27, Alan Bateman wrote: On 07/02/2016 22:20, Peter Levart wrote: : If the decision to remove sun.misc.Cleaner was partly influenced by the desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to migrate JDK

Re: We don't need jdk.internal.ref.Cleaner any more

On 02/08/2016 07:27 AM, Alan Bateman wrote: On 07/02/2016 22:20, Peter Levart wrote: : If the decision to remove sun.misc.Cleaner was partly influenced by the desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to migrate JDK code to the public API might enable Oracle to r

Re: We don't need jdk.internal.ref.Cleaner any more

On 7 Feb 2016, at 19:01, Jeremy Manson wrote: > Hadoop seems to use sun.misc.Cleaner: > > http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java There is an issue in the Hadoop JIRA tracking this: https://issues.

Re: We don't need jdk.internal.ref.Cleaner any more

On 8 Feb 2016, at 06:27, Alan Bateman wrote: > > On 07/02/2016 22:20, Peter Levart wrote: >> : >> >> If the decision to remove sun.misc.Cleaner was partly influenced by the >> desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to >> migrate JDK code to the public API might e

Re: We don't need jdk.internal.ref.Cleaner any more

On 07/02/2016 22:20, Peter Levart wrote: : If the decision to remove sun.misc.Cleaner was partly influenced by the desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to migrate JDK code to the public API might enable Oracle to reconsider keeping sun.misc.Cleaner. The main

RE: We don't need jdk.internal.ref.Cleaner any more

nday, February 07, 2016 11:57 PM > To: Jeremy Manson > Cc: Core-Libs-Dev > Subject: Re: We don't need jdk.internal.ref.Cleaner any more > > > > On 02/07/2016 11:20 PM, Peter Levart wrote: > > > > > > On 02/07/2016 08:01 PM, Jeremy Manson wrote: >

Re: We don't need jdk.internal.ref.Cleaner any more

On 02/07/2016 11:20 PM, Peter Levart wrote: On 02/07/2016 08:01 PM, Jeremy Manson wrote: Hadoop seems to use sun.misc.Cleaner: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java So you may want to keep it ar

Re: We don't need jdk.internal.ref.Cleaner any more

Hi, I 1st thought that my version of jtreg did not want to parse the new JDK 9 version strings as it kept saying: Error: cannot determine version for JDK: build/linux-x86_64-normal-server-release/images/jdk ...but the fact was that the patched JDK did not even want to boot-up. So in order

Re: We don't need jdk.internal.ref.Cleaner any more

On 02/07/2016 08:01 PM, Jeremy Manson wrote: Hadoop seems to use sun.misc.Cleaner: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java So you may want to keep it around transitionally (a la Unsafe). JEP 260 [1

We don't need jdk.internal.ref.Cleaner any more

Hi, sun.misc.Cleaner has been moved to internal package jdk.internal.ref recently [1] to clean-up sun.misc namespace. But now that: - we have comparable public API (java.lang.ref.Cleaner & Cleanable) [2] - we have an internal shared java.lang.ref.Cleaner instance (jdk.internal.ref.CleanerFact