core-libs-dev Digest, Vol 116, Issue 47
Prakhar Makhija
matcdac at gmail.com
Mon Dec 12 08:17:14 UTC 2016
Just want to clarify, would there be any *.mar file, as a module archive?
On Dec 12, 2016 2:33 AM, <core-libs-dev-request at openjdk.java.net> wrote:
> Send core-libs-dev mailing list submissions to
> core-libs-dev at openjdk.java.net
>
> 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
> core-libs-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> core-libs-dev-owner at openjdk.java.net
>
> 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 <ivan.gerasimov at oracle.com>
> To: Paul Sandoz <paul.sandoz at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to
> append multiple copies of char
> Message-ID: <3e67db3c-4ebd-1889-b22d-b7f6a29d508c at oracle.com>
> 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 <peter.levart at gmail.com>
> To: Uwe Schindler <uschindler at apache.org>, 'Chris Hegarty'
> <chris.hegarty at oracle.com>, Alan Bateman <
> Alan.Bateman at oracle.com>
> Cc: jigsaw-dev at openjdk.java.net, 'Core-Libs-Dev'
> <core-libs-dev at openjdk.java.net>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
> Message-ID: <edf60d3b-5685-aa8c-d16d-3a789c86a4e2 at gmail.com>
> 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:peter.levart at gmail.com]
> > *Sent:* Saturday, December 10, 2016 10:23 PM
> > *To:* Uwe Schindler <uschindler at apache.org>; Chris Hegarty
> > <chris.hegarty at oracle.com>
> > *Cc:* jigsaw-dev at openjdk.java.net; Core-Libs-Dev
> > <core-libs-dev at 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 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
> > <peter.levart at gmail.com> <mailto:peter.levart at gmail.com>:
> >
> > 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 <ivan.gerasimov at oracle.com>
> To: Roger Riggs <Roger.Riggs at oracle.com>,
> core-libs-dev at openjdk.java.net
> Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to
> append multiple copies of char
> Message-ID: <1d976771-e6f9-bc49-7804-0cd18686b7b8 at oracle.com>
> 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 <ivan.gerasimov at oracle.com>
> To: Jason Mehrens <jason_mehrens at hotmail.com>,
> "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to
> append multiple copies of char
> Message-ID: <055a7abc-bacc-6847-c0dd-5b1cb3d107c2 at oracle.com>
> 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 <peter.levart at gmail.com>
> To: Alan Bateman <Alan.Bateman at oracle.com>, Chris Hegarty
> <chris.hegarty at oracle.com>
> Cc: jigsaw-dev at openjdk.java.net, Core-Libs-Dev
> <core-libs-dev at openjdk.java.net>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
> Message-ID: <4f29ccda-e2db-2a61-446e-5208f3881d90 at gmail.com>
> 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 <ivan.gerasimov at oracle.com>
> To: Peter Levart <peter.levart at gmail.com>,
> core-libs-dev at openjdk.java.net
> Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to
> append multiple copies of char
> Message-ID: <c29a6177-cd84-5740-e1a9-ad5ac078eb05 at oracle.com>
> 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
> **********************************************
>
More information about the core-libs-dev
mailing list