Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Just catching up… I see no objection to the proposed patch, but the obvious concern ( that is highlighted in JEP 260 ), about the digging into the private internal details of NIO buffers. I think Alan summarized the issues around providing a public API for releasing/unmapping native memory very

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi Andrew, Andrew Haley [mailto:[email protected]] wrote: > On 23/01/16 20:01, Uwe Schindler wrote: > > > It depends how small! If the speed is still somewhere between Java 8 > > ByteBuffer performance and the recent Hotspot improvements in Java > > 9, I agree with trying it out. But some volatile

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi, Alan Bateman [mailto:[email protected]] wrote: > On 23/01/2016 19:23, Uwe Schindler wrote: > > : > > > > What is the replacement for the following code (see marked BufferCleaner > impl, which is our abstraction): https://goo.gl/DGYZZj > > > > The main reason why sun.misc.Cleaner was on t

Re: RFR:8146218: Producing streams in java.time?

Hi, Looks good. I would want to verify that it is defined such that if it later needs to be abstracted up to ChronoLocalDate and apply to compatible Chronologies and respective local dates such as JapaneseDate there is no conflict. It should not be an issue since Period implements ChronoPeriod.

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 23/01/2016 19:23, Uwe Schindler wrote: : What is the replacement for the following code (see marked BufferCleaner impl, which is our abstraction): https://goo.gl/DGYZZj The main reason why sun.misc.Cleaner was on the critical API list is NOT the case that somebody wanted to implement thei

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 23/01/16 20:01, Uwe Schindler wrote: > It depends how small! If the speed is still somewhere between Java 8 > ByteBuffer performance and the recent Hotspot improvements in Java > 9, I agree with trying it out. But some volatile memory access on > every access is a no-go. The code around ByteBuf

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Hi, > Here's a question for you: could you tolerate a closeable mapped > ByteBuffer which was somewhat slower to access? It is hard to make a > secure closeable mapped ByteBuffer: the question is how small the > overhead of closeability can be made. Lucene uses the ByteBuffer like a conventional

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Here's a question for you: could you tolerate a closeable mapped ByteBuffer which was somewhat slower to access? It is hard to make a secure closeable mapped ByteBuffer: the question is how small the overhead of closeability can be made. But if the answer is "We can't tolerate *any* additional ov

RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

(reposting with correct sender address) Hi, > Note: some popular open source libraries that hack into the internal > private cleaner field of direct buffers will have to have their code > updated, if they wish to continue to do this. I followed parts of this issue, but as representative from Apa

Re: Ephemerons

> On Jan 23, 2016, at 5:14 AM, Peter Levart wrote: > > Hi Gil, it's good to have this discussion. See comments inline... > > On 01/23/2016 05:13 AM, Gil Tene wrote: > >>> On Jan 22, 2016, at 2:49 PM, Peter Levart < >>> [email protected] >>>

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 22/01/2016 20:30, Claes Redestad wrote: : I've posted a webrev including your changes here: http://cr.openjdk.java.net/~redestad/8148044/webrev.03/ If there's a preference for this version I'll push it after the weekend. This version looks good to me too. I wonder if it's worth putting t

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 23/01/2016 16:16, Chris Hegarty wrote: : Webrev: http://cr.openjdk.java.net/~chegar/8148117/ This has to move to your patch looks okay. You might need to update the TEST.groups to ensure that the existOnThrow tests will be run by jdk_core. -Alan.

RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

sun.misc.Cleaner was previously listed as a critical internal API in JEP 260 [1], but on further investigation it has been moved to an open issue, for the following reasons: 1) its primary use in the JDK is within NIO direct buffers to release native memory. The base module cannot have a dep

Re: Ephemerons

Hi Gil, it's good to have this discussion. See comments inline... On 01/23/2016 05:13 AM, Gil Tene wrote: On Jan 22, 2016, at 2:49 PM, Peter Levart > wrote: Ephemeron always touches definitions of at least two consecutive strengths of reachabilities. The pro

Re: ClassFileTransformer does not apply to anonymous classes

I agree with Vladimir, You should not be able to transform/redefine a VM anonymous class because the transformer will certainly mess up with the order of the constant pool entries. Slightly off-topic, about ASM, when you create a ClassWriter [1], you can pass a ClassReader of an existing class,

RFR 8148115: Stream.findFirst for unordered source optimization

Hello, Paul! Thank you for review. I implemented it according to your suggestions, here's issue: https://bugs.openjdk.java.net/browse/JDK-8148115 And webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148115/r1/ This patch required some changes in existing tests as FindFirstOpTest asserted that

RFR 8147505: Clarification of BaseStream.onClose() behavior

Hello! Here's a webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8147505/r1/ I just added a check in AbstractPipeline.onClose and the corresponding unit-test. To me it seems that no documentation corrections are necessary, because "onClose" is already documented that it's an intermediate operat

RE: OpenJDK8: java.util.stream.Stream.onClose

Hi, The pipeline stages don’t really need to mutate themselves (as they can mutate the Stream if needed). So they should be shareable between Streams, alleviating some of cost of creating new copies of a Stream, right? -- Have a nice day, Timo Sent from Mail for Windows 10 From: Paul

Re: Ephemerons

> On Jan 22, 2016, at 2:49 PM, Peter Levart wrote: > > Hi Gil, > > Thanks for taking a look at the Ephemerons for Java. It's great to have a big > mind joining the discussion. > > On 01/22/2016 07:12 PM, Gil Tene wrote: >> Peter, >> >> I've been following Ephemerons in other GC'ed environmen