Just want to clarify, would there be any *.mar file, as a module archive? On Dec 12, 2016 2:33 AM, <[email protected]> wrote:
> Send core-libs-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > 2. Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch (Peter Levart) > 3. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > 4. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > 5. Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch (Peter Levart) > 6. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 11 Dec 2016 23:26:04 +0300 > From: Ivan Gerasimov <[email protected]> > To: Paul Sandoz <[email protected]> > Cc: [email protected] > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > Thank you Paul for the comments and suggestions! > > > > Add a fix version of 10, then it?s clear on the intent. Once tests are > > added :-) we can review for that release. > > Yes, right. I've set the fix version to 10 and also added the @since 10 > tag. > I've added a couple of test cases to > `test/java/lang/Appendable/Basic.java`, or do you think the appendN() > method worth more testing? > > > Personally i would use Arrays.fill, i gather the pattern is already > recognised: > > > > https://bugs.openjdk.java.net/browse/JDK-4809552 > > http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5 > > > > The advantage of using Arrays.fill is we know that the pattern will be > recognized (if not it?s a bug, and i suppose it could be made intrinsic to > wire up faster). (see -XX:+TraceOptimizeFill). I suspect we should review > the filling optimization to see if it can be enhanced with newer SIMD > instructions, as i gather the current implementation writes a max of 8 > bytes at a time (with an explicit unrolled loop for 32 bytes at a time, > containing 4 separate stores). > > Okay, I replaced the first loop with a call to Arrays.fill(). > Benchmark shows that for size == 1 the overhead is bigger then for > adding exactly one char in a loop. > For anything longer it appears to be faster. > > Benchmark (size) Mode Cnt Score Error Units > MyBenchmark.test_0_New 0 avgt 85 0.004 ? 0.001 us/op > MyBenchmark.test_0_New 1 avgt 85 0.016 ? 0.003 us/op > MyBenchmark.test_0_New 5 avgt 85 0.017 ? 0.003 us/op > MyBenchmark.test_0_New 10 avgt 85 0.020 ? 0.004 us/op > MyBenchmark.test_0_New 20 avgt 85 0.021 ? 0.004 us/op > MyBenchmark.test_1_Old 0 avgt 85 0.004 ? 0.001 us/op > MyBenchmark.test_1_Old 1 avgt 85 0.007 ? 0.001 us/op > MyBenchmark.test_1_Old 5 avgt 85 0.029 ? 0.006 us/op > MyBenchmark.test_1_Old 10 avgt 85 0.048 ? 0.010 us/op > MyBenchmark.test_1_Old 20 avgt 85 0.099 ? 0.019 us/op > MyBenchmark.test_2_Solid 0 avgt 85 0.008 ? 0.001 us/op > MyBenchmark.test_2_Solid 1 avgt 85 0.015 ? 0.002 us/op > MyBenchmark.test_2_Solid 5 avgt 85 0.026 ? 0.005 us/op > MyBenchmark.test_2_Solid 10 avgt 85 0.031 ? 0.004 us/op > MyBenchmark.test_2_Solid 20 avgt 85 0.028 ? 0.005 us/op > > > > > It?s good that you found places in the JDK, that adds justification for > such methods, especially for BigInteger and that static array of strings > full of ?0? characters. > > > > The updates to MethodHandleImpl are not perf sensitive, i question the > usage here but it does reduce stuff in the constant pool i suppose. > I think it also improves readability, as it's clear now the amount of > spaces added. > > > With kind regards, > Ivan > > > > ------------------------------ > > Message: 2 > Date: Sun, 11 Dec 2016 21:31:45 +0100 > From: Peter Levart <[email protected]> > To: Uwe Schindler <[email protected]>, 'Chris Hegarty' > <[email protected]>, Alan Bateman < > [email protected]> > Cc: [email protected], 'Core-Libs-Dev' > <[email protected]> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Uwe, > > > On 12/11/2016 01:57 PM, Uwe Schindler wrote: > > > > Hi, > > > > How about the following: > > > > -Check that the buffer is direct, if not throw IAE(?not direct buffer?) > > > > -Check that buffer has attachment==null (this tells you that it?s not > > a slice/dup), if not throw IAE(?not allowed to free duplicates/slices?) > > > > -Finally do the standard if (cleaner!=null) cleaner.clean(), but don?t > > throw any exceptions if cleaner is null (as this is implementation > detail) > > > > This allows for empty buffers without cleaner that are still marked as > > direct. But it disallows all slices or duplicates. > > > > Yes, this would be the right logic I agree. It would silently ignore the > requests to free memory for buffers constructed via JNI's > NewDirectByteBuffer calls, but I suppose this would not be a problem in > practice. > > > I am fine with Alan?s proposal to restrict to MappedByteBuffer but > > that?s out of my interest ? I am happy to unmap mapped byte buffers. I > > would also place the method in the legacy sun.misc.Unsafe only, the > > JDK-internal private one is not accessible to the outside. Of course > > for consistency it could be in both, but primarily it must be in > > sun.misc.Unsafe ? that?s also what most code is using anyways. > > > > Yes, internally, at least in java.base, the code can always directly > invoke the DirectBuffer's and Cleaner's methods... > > Regards, Peter > > > > Uwe > > > > *From:*Peter Levart [mailto:[email protected]] > > *Sent:* Saturday, December 10, 2016 10:23 PM > > *To:* Uwe Schindler <[email protected]>; Chris Hegarty > > <[email protected]> > > *Cc:* [email protected]; Core-Libs-Dev > > <[email protected]> > > *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 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, good catch. Then what about being noop just for zero length? I > > don't know, maybe I'm just being paranoid and those who would use this > > API know perfectly well what they are doing. I'm just imagining a > > situation where one would create and keep just a duplicate of a direct > > buffer and afterwards use it to try to deallocate the native memory. > > This would be a noop, but the developer would think it works as GC > > would finally do it for him. I think it's better to throw an exception > > to prevent such situations... > > > > Regards, Peter > > > > > > > > I like the Unsafe approach. To me both variants are fine. > > > > Uwe > > > > Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart > > <[email protected]> <mailto:[email protected]>: > > > > 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/ > > <http://cr.openjdk.java.net/%7Echegar/Unsafe_deallocate/> > > > > > > Apart from the fact that Unsafe is (was?) reserved for > > low-level stuff, I think this approach is reasonable. Is the > > method in jdk.internal.misc.Unsafe needed? You could add the > > method just to the sun.misc.Unsafe (to keep internal Unsafe > > free from hacks) and export the two packages selectively to > > jdk.unsupported. > > > > > > We could attempt to limit this to the direct buffer that > "owns" the > > > > memory, i.e. not a duplicate or a slice, but I'm not sure it > is worth > > > > it. > > > > > > What you have here *is* limited to direct ByteBuffer(s) that > > "own" the memory. Derived buffer(s) (duplicated or sliced) do > > not have a Cleaner instance (they have an 'attachment' to keep > > the 1st-level buffer reachable while they are reachable). I > > would even make it more unforgiving by throwing an IAE if the > > passed-in buffer didn't have a Cleaner. In addition I would > > specify this behavior. For example: > > > > "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 or > > was obtained by {@link ByteBuffer#duplicate() duplicating} or > > {@link ByteBuffer#slice(int, int) slicing} a direct buffer), > > the method throws {@code IllegalArgumentException}. > > > > Regards, Peter > > > > > > ------------------------------ > > Message: 3 > Date: Sun, 11 Dec 2016 23:35:26 +0300 > From: Ivan Gerasimov <[email protected]> > To: Roger Riggs <[email protected]>, > [email protected] > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > Thank you Roger for the comments! > > > On 08.12.2016 1:28, Roger Riggs wrote: > > Hi Ivan, > > > > A few comments... > > > > Appendable.appendN default method: > > I'd expect many time n is small so allocating a new StringBuilder > > every time seems > > not optimal. A simple loop with append(c) would have fewer > > (memory) side effects. > > And in particular for n=0, it could avoid doing anything. > > > The rationale here was to implement `all or nothing` approach. > If we add chars one by one in a loop and hit OOM, then the Appendable > would be partially modified, which is not good. > A special case for the size of zero can be added, of course. > > > AbstractStringBuilder: > > I agree with Claes' comment suggesting that IAE for negative > > lengths is a pain > > and defining it to append 0 would be natural in many use cases. > > > I see that most votes are for throwing the exception if n is negative. > Let's leave it this way! > > > MethodHandleImpl.toString(): > > You could beneficially replace StringBuffer with StringBuilder > > while you are there. > > (and maybe pre-size the builder). > > > Sure, let's use StringBuilder. > I wasn't sure how to easily calculate the required capacity of the > builder here though. > > Please find the updated webrev here: > http://cr.openjdk.java.net/~igerasim/8170348/01/webrev/ > > With kind regards, > Ivan > > > ------------------------------ > > Message: 4 > Date: Sun, 11 Dec 2016 23:50:21 +0300 > From: Ivan Gerasimov <[email protected]> > To: Jason Mehrens <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Thank you Jason for the comments! > > > On 06.12.2016 20:09, Jason Mehrens wrote: > > Ivan, > > > > Will java.util.StringJoiner be modified too? I assume a nCopies char > sequence object doesn't pan out performance wise? > I don't think I've seen many such uses of StringJoiner as adding the > same sequence several times. > I would hesitate to propose an addition to the API without being sure > it's going to be used. > > With kind regards, > Ivan > > > > ------------------------------ > > Message: 5 > Date: Sun, 11 Dec 2016 21:59:03 +0100 > From: Peter Levart <[email protected]> > To: Alan Bateman <[email protected]>, Chris Hegarty > <[email protected]> > Cc: [email protected], Core-Libs-Dev > <[email protected]> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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) > > 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 more advanced method to avoid too much temptation to free the > > memory underlying a buffer created with ByteBuffer.allocateDirect. We > > can't do much with unmap but that at least won't be widely used. > > > > -Alan. > > So, If I understand correctly, you are proposing users to do their own > memory allocation/management/deallocation with Unsafe and use wrap() > just to create a view of the allocated memory in the form of ByteBuffer. > Wouldn't this force them to use a different approach to managing > ByteBuffer(s) from what they do now - they would have to keep the > allocated memory's address somewhere outside the buffer in order to free > the memory later... It is doable, but I think Uwe will not like it very > much. > > About unmap()... Is it just the name and signature that would discourage > freeing memory underlying a buffer created with > ByteBuffer.allocateDirect() or do you propose to disallow such use and > only allow actual unmapping? > > Regards, Peter > > > > ------------------------------ > > Message: 6 > Date: Mon, 12 Dec 2016 00:03:02 +0300 > From: Ivan Gerasimov <[email protected]> > To: Peter Levart <[email protected]>, > [email protected] > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > Thank you Peter for the suggestion! > > > > An alternative to a new virtual method on Appendable (or maybe a > > complement to it) could be a special internal CharSequence > > implementation (CharRepetitions) with a static factory method on > > CharSequence like the following: > > > > I think it's a clever idea! > > Though it might be harder to implement the special optimized handling of > such sequences by Appendable implementations outside java.lang. > > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_ > Appendable.appendN.alt/webrev.01/ > > > > > > Together with special-case optimization in > > AbstractStringBuilder.append(CharSequence) it can perform equally well > > when JITed. I took your benchmark and modified it a bit: > > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_ > Appendable.appendN.alt/AppendNTest.java > > > > > > ...I moved sb.setLength(0) into a special @Setup method so that it > > doesn't cause the remaining tested code to be over-optimized. You can > > try just this change in your benchmark and you'll notice a difference. > Actually, in the benchmark I tried to follow the suggestions found here: > http://hg.openjdk.java.net/code-tools/jmh/file/ > ef24f1b5de08/jmh-samples/src/main/java/org/openjdk/jmh/ > samples/JMHSample_38_PerInvokeSetup.java > Note, how the Level.Invocation setup is avoided in the measureRight > benchmark. > > With kind regards, > Ivan > > > > End of core-libs-dev Digest, Vol 116, Issue 47 > ********************************************** >
