RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

org; jigsaw-dev@openjdk.java.net; 'Core-Libs-Dev' > <core-libs-...@openjdk.java.net> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Hi, > > I strongly hope Paul and Cedric will be able to start the release > process next week, if

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

bs-Dev > d...@openjdk.java.net>; jigsaw-dev <jigsaw-dev@openjdk.java.net>; Uwe >> Schindler <uschind...@apache.org> >> Subject: Re: Java 9 build 148 causes trouble in Apache >> Lucene/Solr/Elasticsearch >> >> Pushed to jdk9/dev. Should make b150. >&

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

t: Friday, December 16, 2016 6:39 PM > To: Peter Levart <peter.lev...@gmail.com>; Core-Libs-Dev d...@openjdk.java.net>; jigsaw-dev <jigsaw-dev@openjdk.java.net>; Uwe > Schindler <uschind...@apache.org> > Subject: Re: Java 9 build 148 causes trouble in Apache > Luc

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

hindler <uschind...@apache.org> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Pushed to jdk9/dev. Should make b150. > > https://bugs.openjdk.java.net/browse/JDK-8171377 > > -Chris. > > > On 14 Dec 2016, at 11

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Pushed to jdk9/dev. Should make b150. https://bugs.openjdk.java.net/browse/JDK-8171377 -Chris. > On 14 Dec 2016, at 11:58, Chris Hegarty wrote: > > Webrev updated in-place. > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > -Chris. > > On 13/12/16

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

: Jochen Theodorou [mailto:blackd...@gmx.org] Sent: Saturday, December 10, 2016 9:23 AM To: Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; Core-Libs-Dev <core-libs-...@openjdk.java.net> Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch O

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

0, 2016 9:23 AM > To: Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; > Core-Libs-Dev <core-libs-...@openjdk.java.net> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > On 09.12.2016 23:32, Uwe Schindler wrote

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 13/12/2016 21:18, Peter Levart wrote: I think this is OK. Just a couple of nits in test: 1. You create a static Path bob = Paths.get("bob") field, but then you don't use it in: 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), CREATE, WRITE)) { Adding to Peter's

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Libs-Dev d...@openjdk.java.net>; jigsaw-dev <jigsaw-dev@openjdk.java.net>; Uwe > Schindler <uschind...@apache.org> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Webrev updated in-place. >http://cr.openjdk.java.net/~ch

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Webrev updated in-place. http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ -Chris. On 13/12/16 21:18, Peter Levart wrote: I think this is OK. Just a couple of nits in test: 1. You create a static Path bob = Paths.get("bob") field, but then you don't use it in: 56 try

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

I think this is OK. Just a couple of nits in test: 1. You create a static Path bob = Paths.get("bob") field, but then you don't use it in: 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), CREATE, WRITE)) { 2. badBuffers could include a duplicate and a slice of a

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

acle.com] > Sent: Tuesday, December 13, 2016 8:47 PM > To: Core-Libs-Dev <core-libs-...@openjdk.java.net>; jigsaw-dev d...@openjdk.java.net>; Uwe Schindler <uschind...@apache.org>; Peter > Levart <peter.lev...@gmail.com> > Subject: Re: Java 9 build 148 cau

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Taking into account the feedback so far, and changing the method name ( since it is an attractive nuisance ), here is where I think we ended up. http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ If this is agreeable, I’ll file an issue in JIRA to track the code changes, and update JEP

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 12/12/16 15:11, Uwe Schindler wrote: > Thanks for taking care! Your proposal is still the "volatile only > during safepoint" idea? I remember our discussions last FOSDEM and > this is why I brought it up in this mail thread (see my original > mail referring to your name). It's the same idea.

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

MC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf > Of Andrew Haley > Sent: Monday, December 12, 2016 3:00 PM > To: jigsaw-dev@openjdk.java.net > Subject: Re: Java 9

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 12/12/16 14:56, Carsten Varming wrote: > Do you have a pointer to a discussion about the changes to the JMM you > propose? I haven't written it up yet. There's a little bit more in the bug description, but not much more than I've said here. Andrew.

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Dear Andrew, Do you have a pointer to a discussion about the changes to the JMM you propose? Carsten On Mon, Dec 12, 2016 at 8:59 AM, Andrew Haley wrote: > This is JDK-4724038. It is possible to unmap a MappedByteBuffer > safely with little effect on efficiency: my basic

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 11/12/16 18:33, Peter Levart wrote: > In order for deallocation to be effective and, above all, safe, user has > to know the whole story of a buffer (s)he intends to deallocate and the > story of all possible derived buffers. I don't believe one can create a > safe program by choosing to

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Dear Alan, On Sun, Dec 11, 2016 at 6:16 AM, Alan Bateman wrote: > > The alternative is of course: > > ByteBuffer wrap(long address, int capacity) > void unmap(MappedByteBuffer) > > The wrap method allow be similar to JNI's NewDirectByteBuffer for those > that are

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 12/11/2016 09:59 PM, Peter Levart wrote: The alternative is of course: ByteBuffer wrap(long address, int capacity) void unmap(MappedByteBuffer) The wrap method allow be similar to JNI's NewDirectByteBuffer for those that are managing the underlying memory themselves. This makes it a

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi Alan, On 12/11/2016 12:16 PM, Alan Bateman wrote: On 10/12/2016 17:11, Chris Hegarty wrote: : How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ The alternative is of course: ByteBuffer wrap(long address, int capacity)

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

org>; Chris Hegarty <chris.hega...@oracle.com> *Cc:* jigsaw-dev@openjdk.java.net; Core-Libs-Dev <core-libs-...@openjdk.java.net> *Subject:* Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch On 12/10/2016 09:00 PM, Uwe Schindler wrote: Hi, We no

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi Chris, On 12/11/2016 10:26 AM, Chris Hegarty wrote: >"Deallocates the underlying memory associated with given directBuffer if the buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In any other case (when the buffer is not a direct buffer

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

jdk.java.net; Core-Libs-Dev <core-libs-...@openjdk.java.net> Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch On 12/10/2016 09:00 PM, Uwe Schindler wrote: Hi, We noticed that buffers with zero length also have no cleaner. This is why we also have the

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 10/12/2016 17:11, Chris Hegarty wrote: : How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ The alternative is of course: ByteBuffer wrap(long address, int capacity) void unmap(MappedByteBuffer) The wrap method allow be

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

> On 10 Dec 2016, at 19:47, Peter Levart wrote: > > Hi Chris, > > On 12/10/2016 06:11 PM, Chris Hegarty wrote: >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? >> >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > > Apart from the fact that Unsafe

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 12/10/2016 09:00 PM, Uwe Schindler wrote: Hi, We noticed that buffers with zero length also have no cleaner. This is why we also have the null check in our code (see Github) and the guardWithTest in the MethodHandle, although we never free duplicates. So a noop is better imho. Oh yes,

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, We noticed that buffers with zero length also have no cleaner. This is why we also have the null check in our code (see Github) and the guardWithTest in the MethodHandle, although we never free duplicates. So a noop is better imho. I like the Unsafe approach. To me both variants are fine.

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi Chris, On 12/10/2016 06:11 PM, Chris Hegarty wrote: How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ Apart from the fact that Unsafe is (was?) reserved for low-level stuff, I think this approach is reasonable. Is the method

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

l from Oracle to see what they have in mind... > > Regards, Peter > >> Uwe >> >> - >> >> Uwe Schindler >> >> uschind...@apache.org >> >> ASF Member, Apache Lucene PMC / Committer >> >> Bremen, Germany >> >>

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

et> *Subject:* Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch Hi, On 12/10/2016 06:14 AM, Alan Bateman wrote: On 09/12/2016 22:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Pre

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

:10 PM To: Alan Bateman <alan.bate...@oracle.com>; Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; Core-Libs-Dev <core-libs-...@openjdk.java.net> Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch Hi, On 12/10/2016 06:1

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 10/12/2016 11:09, Peter Levart wrote: : Something like the following? http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/ Sort of although I think the proposal will be more specific, as in unmap(MappedByteBuffer) on an existing class. The other update to JEP

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, On 12/10/2016 06:14 AM, Alan Bateman wrote: On 09/12/2016 22:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

6 6:14 AM > To: Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; > Core-Libs-Dev <core-libs-...@openjdk.java.net> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > On 09/12/2016 22:32, Uwe Schindler wrote: > >

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 09.12.2016 23:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 12/9/16 3:21 PM, Uwe Schindler wrote: > The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, > but it does not solve the underlying issue. Apache Solr/Lucene and > Elasticsearch will no longer work with Java 9 unless you require users to add > those strange options.

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 09/12/2016 23:06, Stephen Felts wrote: I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true It will tell you what add-options are required. One minor downside is that it will produce the warning in cases where the software is already correctly

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 09/12/2016 22:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Message- From: Kevin Rushforth Sent: Friday, December 09, 2016 6:33 PM To: Stephen Felts Cc: Uwe Schindler; jigsaw-dev@openjdk.java.net; Core-Libs-Dev Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch I second the recommendation of using

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

k.java.net; Core-Libs-Dev Subject: RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch Hi, Thanks for the hints to fix Groovy, although this is hard to do with ANT (which is our build system). The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, b

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

I second the recommendation of using "-Dsun.reflect.debugModuleAccessChecks=true". We use gradle to build JavaFX and I ended up needing the following to allow our build to run with jdk-9+148: export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

e.com] > Sent: Saturday, December 10, 2016 12:07 AM > To: Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; > Core-Libs-Dev <core-libs-...@openjdk.java.net> > Subject: RE: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elastic

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true It will tell you what add-options are required. One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Message- From: Uwe Schindler [mailto:uschind...@apache.org] Sent: Friday, December 09, 2016 5:33 PM To: jigsaw-dev@openjdk.java.net; Core-Libs-Dev Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch   Hi,   I updated our Jenkins server for the JDK 9 preview testing

Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no longer works, although this API was marked