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

Hi, > On 26/01/2016 14:05, Uwe Schindler wrote: > > Hi, > > > > looks good to me. Once we have EA builds with that I will adapt the > ByteBufferIndexInput code in Lucene. > > > > One thing about the Runable: This should work perfectly fine, because we >

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

Hi, API changes l and security check look good to me. I don't have time to compile and test a JDK, but I trust you that it works :-) Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Mess

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

r us! Please add a new issue to either revert to have sun.misc.Cleaner available just to forcefully free mmapped files, or add an official API to allow unmapping (including Hotspot changes to prevent SIGSEGV/SIGBUS). Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / C

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

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

Hi Andrew, Andrew Haley [mailto:a...@redhat.com] 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 i

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

Hi, Alan Bateman [mailto:alan.bate...@oracle.com] 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 > > > >

RE: use of Unsafe for ASCII detection

Hi, > On 06/01/16 23:21, Martin Buchholz wrote: > > > That is, the Unsafe code is 3x faster than the simple code. The > > ByteBuffer code used to be 2x slower and is now 2x faster - well > > done - crowd goes wild! > > Why, thank you. > > > I see it uses new and well-hidden

RE: java.lang.reflect.Method.copyOf

Hi, Just as idea: Why not implement Cloneable for that purpose? Adding new methods does not look like a good idea. - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: core-li

RE: RFR: 8132541 : (process) ProcessBuilder support for redirection to discard output

Hi, + * The output is discarded by writing to the operating specific + * null file. Small Javadocs issue, it should be "... operating system specific ..." Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Ge

RE: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

Hi, > As I thought, the problem for some seems to be non-prompt unmapping of > mapped address space held by otherwise unreachable mapped byte buffers. > The mapped address space doesn't live in the Java heap and doesn't > represent a heap memory pressure, so GC doesn't kick-in automatically >

RE: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

s. We cannot force the users to calculate their index size before using it and set corresponding JVM settings. Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/

RE: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations

My intention was to say implementation removed. Uwe - Uwe Schindler uschind...@apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -Original Message- From: Joe Darcy [mailto:joe.da...@oracle.com] Sent: Monday, March 04, 2013 5:16 PM To: Uwe

RE: JDK 8 RFR: 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations

Looks good to me! Are this the only methods in the corelib that were removed in favour of a default implementation in the interface? Uwe - Uwe Schindler uschind...@apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -Original Message- From

<    1   2