February 2015 - core-libs-dev

RFR: 8062518: AIOBE occurs when accessing to document function in extended function in JAXP
by Aleksej Efimov 07 May '15

07 May '15

Please, review the fix for the failure observed while accessing external document during xsl transformation: https://bugs.openjdk.java.net/browse/JDK-8062518 The jaxp code limits the access to external documents, but there is a possibility to access such documents from the xsl code - new regression test checks this functionality. The fix removes this restriction and AIOBE: http://cr.openjdk.java.net/~aefimov/8062518/9/webrev.00/ Testing: xml related regression tests (with new test) - no failures (from jdk and jaxp repos). JCK xml related tests - no failures. With Best Regards, Aleksej

2 4

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
by Andrew Haley 16 Apr '15

16 Apr '15

On 02/18/2015 09:15 AM, Andrew Haley wrote: > On 18/02/15 09:14, Florian Weimer wrote: >> Wow, looks nice. What OpenJDK build did you use? I want to see if this >> happens on x86_64, too. > > I'm working on JDK9. You don't have this code yet. I'll do an x86 > build. 0x00007f2948acbf8c: mov 0xc(%rdx),%r10d ;*synchronization entry ; - java.nio.HeapByteBuffer::<init>@-1 (line 84) ; - java.nio.ByteBuffer::wrap@7 (line 373) ; - java.nio.ByteBuffer::wrap@4 (line 396) ; - bytebuffertests.ByteBufferTests3::getLong@1 (line 23) ; implicit exception: dispatches to 0x00007f2948acbff5 ;; B2: # B5 B3 <- B1 Freq: 0.999999 ;; MEMBAR-release ! (empty encoding) 0x00007f2948acbf90: test %ecx,%ecx 0x00007f2948acbf92: jl 0x00007f2948acbfb5 ;*iflt ; - java.nio.Buffer::checkIndex@1 (line 545) ; - java.nio.HeapByteBuffer::getLong@18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong@5 (line 23) ;; B3: # B6 B4 <- B2 Freq: 0.999999 0x00007f2948acbf94: mov %r10d,%ebp 0x00007f2948acbf97: sub %ecx,%ebp ;*isub ; - java.nio.Buffer::checkIndex@10 (line 545) ; - java.nio.HeapByteBuffer::getLong@18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong@5 (line 23) 0x00007f2948acbf99: cmp $0x8,%ebp 0x00007f2948acbf9c: jl 0x00007f2948acbfd5 ;*if_icmple ; - java.nio.Buffer::checkIndex@11 (line 545) ; - java.nio.HeapByteBuffer::getLong@18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong@5 (line 23) ;; B4: # N95 <- B3 Freq: 0.999998 0x00007f2948acbf9e: movslq %ecx,%r10 0x00007f2948acbfa1: mov 0x10(%rdx,%r10,1),%rax 0x00007f2948acbfa6: bswap %rax ;*invokestatic reverseBytes ; - java.nio.Bits::swap@1 (line 61) ; - java.nio.HeapByteBuffer::getLong@41 (line 466) ; - bytebuffertests.ByteBufferTests3::getLong@5 (line 23) So, just the same except that there is no explicit fence instruction to remove. It's a shame for AArch64 because that fence really kills performance but it's bad for x86 too. Even on machines that don't emit fence instructions the fence still acts as a compiler barrier. Andrew.

3 6

JEP 238: Multi-Version JAR Files
by mark.reinhold＠oracle.com 15 Apr '15

15 Apr '15

New JEP Candidate: http://openjdk.java.net/jeps/238 - Mark

13 43

Re: jsr 305
by Sergey Bylokhov 02 Apr '15

02 Apr '15

Hi, Joe. There are no news about this jsr in jdk9? I guess it will be useful in jdk development also. On 20.09.2011 23:00, Joe Darcy wrote: > Hello. > > First, a procedural point, the party responsible for making progress on > a JSR is the spec lead, which in the case of JSR 305 is Bill Pugh. > > When I last spoke to Bill about 18 months ago, he said he felt the > annotations needed more use on real-world code before they could be > fully standardized. I assume that the JSR has remained in that state > since then. > > JSR 308 is primarily about allowing annotations in more locations in a > source file and *not* about defining more annotations. > > -Joe > > Ben Evans wrote: >> Hi Sergey, >> >> I am not an expert in what happened to JSR 305, but from a quick look >> at it, it seems to have a big overlap with JSR 308 (Type Annotations), >> which is still an active JSR. >> >> So you may want to approach the Spec Lead / EG for JSR 308 and see >> what their current status is - the last I heard they were interested >> in trying to make the cut for JDK 8. >> >> Does anyone have more information? >> >> Thanks, >> >> Ben >> >> On Tue, Sep 20, 2011 at 3:13 AM, Sergey Bylokhov >> <sergey.bylokhov(a)oracle.com> wrote: >> >>> Hello, all. >>> >>> Does anybody know what happens with jsr305? >>> http://jcp.org/en/jsr/detail?id=305 >>> >>> Probably it is replaced by another jsr? Can it be integrated as part of >>> coin project? >>> >>> >>> Thanks. >>> >>> -- >>> Best regards, Sergey. >>> >>> >>> >>> >> > > -- Best regards, Sergey.

2 2

8072909: TimSort fails with ArrayIndexOutOfBoundsException on arrays longer than 1073741824
by Lev Priima 24 Mar '15

24 Mar '15

Hi, Stack length increased previously by JDK-8011944 was insufficient for some cases. Please review and push: webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8072909 -- Lev

5 45

String.indexOf optimization
by Zoltan Sziladi 24 Mar '15

24 Mar '15

Hi, I am new to this mailing list so please forgive me if this has been discussed before. I was looking at the implementation of String.indexOf and I see that it uses the O(n^2) naive implementation. I have been trying to find out why it does not use some kind of a modern, sophisticated O(n) algorithm but I have no clear answer as of now. My guess is that the average case should be quite good for this algorithm because in practice the partial matches are actually quite rare, so it should work well... usually. Also, I saw that this code was last touched about 6 years ago, so maybe it was just left like this? My concern is actually the worst case scenario. If we compared two long strings with lots of partial matches, then this would perform quite poorly. Wouldn't it be worth having an O(n) implementation here then? Modern O(n) pattern matching algorithms don't use much extra space either. The Collections.sort method also uses an algorithm that prepares for worst case. Maybe a highly optimized quicksort could outperform the current mergesort implementation but I suppose one of the design principles behind that was also to prepare for the worst case. (Even though a nicely implemented quicksort has an expected average case runtime of O(nlogn) regardless of the input). If anyone knows why it is implemented this way or if it were possible to change the implementation, I'd be happy to hear your opinion. Thanks! Regards, Zoltan

8 23

Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics
by Andrew Haley 16 Mar '15

16 Mar '15

I've been kicking around a few ideas for Unsafe access methods for unaligned access to byte arrays and buffers in order to provide "whatever second-best mechanism the platform offers". These would provide the base for fast lexicographic array comparisons, etc. https://bugs.openjdk.java.net/browse/JDK-8044082 If the platform supports unaligned memory accesses, the implementation of {get,put}-X-Unaligned is obvious and trivial for both C1 and C2. It gets interesting when we want to provide efficient unaligned methods on machines with no hardware support. We could provide compiler intrinsics which do when we need on such machines. However, I think this wouldn't deliver the best results. >From the experiments I've done, the best implementation is to write the access methods in Java and allow HotSpot to optimize them. While this seemed a bit counter-intuitive to me, it's best because C2 has profile data that it can work on. In many cases I suspect that data read and written from a byte array will be aligned for their type and C2 will take advantage of this, relegating the misaligned access to an out-of-line code path as appropriate. Also, these methods have the additional benefit that they are always atomic as long as the data are naturally aligned. This does result in rather a lot of code for the methods for all sizes and endiannesses, but none of it will be used on machines with unaligned hardware support except in the interpreter. (Perhaps the interpreter too could have intrinsics?) I have changed HeapByteBuffer to use these methods, with a major performance improvement. I've also provided Unsafe methods to query endianness and alignment support. Webrevs at http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/ http://cr.openjdk.java.net/~aph/unaligned.jdk.1/ Andrew.

9 94

JEP 102 Process Updates revised API draft
by Roger Riggs 13 Mar '15

13 Mar '15

Hi, After a protracted absence from working on JEP 102, the updated API draft provides access to process hierarchies and individual process information; as permitted by the OS. The relationship between Process and ProcessHandle is clarified and the security model validated. Both Processes and ProcessHandles can be monitored using CompletableFuture for termination and to trigger additional actions on Process exit. Information about processes includes the total cputime, starttime, user, executable, and arguments. Please review and comment: http://cr.openjdk.java.net/~rriggs/ph-apidraft/ Thanks, Roger

10 73

RFR(S): JDK-8073584 Native compilation warning in unpack code
by Dmitry Samersoff 12 Mar '15

12 Mar '15

Hi Everyone, It's my $0.02 to the warning cleanup work. Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/ Notes: I use an ugly trick: (void) (read() + 1) to get rid of ignored value warning because since gcc 4.6 just (void) is not enough. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

5 11

RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667
by Brent Christian 12 Mar '15

12 Mar '15

Hi, The code in bug 8071667 [1] passes a mappingFunction to computeIfAbsent() which itself put()s a sufficient number of additional entries into the HashMap to cause a resize/rehash. As a result, computeIfAbsent() doesn't add the new entry at the proper place in the HashMap. While one should not (mis)use the mappingFunction in this way, HashMap.computeIfAbsent() (and similar HashMap methods which accept Lambda expressions) could check for and throw a ConcurrentModificationException on a "best-effort" basis, similar to iterators. This is already done in bulk operations HashMap.forEach() and HashMap.replaceAll(). I think it's also worth making mention of this in the JavaDoc. Here's an example of what might be done, using computeIfAbsent() as an example: http://cr.openjdk.java.net/~bchristi/8071667/webrev.0/ I would update HashMap and Hashtable. It looks like ConcurrentHashMap.computeIfAbsent() already forbids such usage, stating that the computation "must not attempt to update any other mappings of this map." Comments on this approach? Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8071667 "HashMap.computeIfAbsent() adds entry that HashMap.get() does not find."

5 14