June 2018 - core-libs-dev

RFR JDK-8205540: hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 <cont> commands
by Peter Levart 25 Jun '18

25 Jun '18

Please review the following tiny change that delays TerminatingThreadLocal class initialization until the 1st thread that actually uses thread locals, exits: http://cr.openjdk.java.net/~plevart/jdk-dev/8205540_TerminatingThreadLocal.… Since JDK-8202788 has been pushed, a hotspot/jdb test started failing: https://bugs.openjdk.java.net/browse/JDK-8205540 ...presumably because it is not expecting so many instructions to be executed at thread exit. This patch might help silence the test. Even if it doesn't silence the test, it is a change that delays one class initialization until it is needed and this is good. Regards, Peter

3 3

RE: RFR JDK-8205540: hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 <cont> commands
by Chris Plummer 24 Jun '18

24 Jun '18

Hi Peter, The changes looks good and also the test passes now. Thanks for fixing this. Chris > Please review the following tiny change that delays > TerminatingThreadLocal class initialization until the 1st thread that > actually uses thread locals, exits: > > http://cr.openjdk.java.net/~plevart/jdk-dev/8205540_TerminatingThreadLocal.… > <http://cr.openjdk.java.net/%7Eplevart/jdk-dev/8205540_TerminatingThreadLoca…> > > Since JDK-8202788 has been pushed, a hotspot/jdb test started failing: > > https://bugs.openjdk.java.net/browse/JDK-8205540 > > ...presumably because it is not expecting so many instructions to be > executed at thread exit. This patch might help silence the test. Even if > it doesn't silence the test, it is a change that delays one class > initialization until it is needed and this is good. > > Regards, Peter

1 0

RE: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.
by Deshpande, Vivek R 22 Jun '18

22 Jun '18

Thanks David. Sending it to core-libs-dev. I would like to contribute a patch which improves the array comparison when there is a mismatch for the first element. This avoids call to vectorizedMismatch method and gives ~80x speed up. Could you please review and sponsor the patch. Link to bug: https://bugs.openjdk.java.net/browse/JDK-8205194 webrev: http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.00/ Regards, Vivek -----Original Message----- From: David Holmes [mailto:david.holmes@oracle.com] Sent: Monday, June 18, 2018 10:32 PM To: Deshpande, Vivek R <vivek.r.deshpande(a)intel.com>; jdk-dev(a)openjdk.java.net Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element. Hi Vivek, Reviews should take place on the appropriate mailing list for the code being changed, not on the jdk-dev list. Please takes this to core-libs-dev. Thanks, David On 19/06/2018 9:52 AM, Deshpande, Vivek R wrote: > Hi All > > Forgot to add the links: > https://bugs.openjdk.java.net/browse/JDK-8205194 > webrev: > http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.0 > 0/ > > Regards. > Vivek > > From: Deshpande, Vivek R > Sent: Monday, June 18, 2018 4:50 PM > To: 'jdk-dev(a)openjdk.java.net' <jdk-dev(a)openjdk.java.net> > Cc: 'Paul Sandoz' <paul.sandoz(a)oracle.com>; Viswanathan, Sandhya > <sandhya.viswanathan(a)intel.com> > Subject: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element. > > Hi All > > I would like to contribute a patch which improves the array comparison when there is a mismatch for the first element. > This avoids call to vectorizedMismatch method and gives ~80x speed up. > Please review and sponsor the patch. > > Regards, > Vivek >

3 13

Re: RFC: Experiment in accessing/managing persistent memory from Java
by Viswanathan, Sandhya 22 Jun '18

22 Jun '18

Hi Andrew/Jonathan, Thanks a lot for sharing this work. Copying hotspot-compiler-dev to get their feedback as well. Couple of thoughts/observations below: * Supporting ByteBuffer on persistent memory using existing FileChannel and MappedByteBuffer mechanism sounds like a very good idea. * Extending FileChannel.map to take additional parameter to indicate that the ByteBuffer is backed by persistent memory is a small API change. * Adding MappedByteBuffer.force(int from, int to) method on smaller range is very useful in addition to the force() on entire ByteBuffer. * The underlying force0_mapsync() could be implemented in terms of new unsafe APIs which in turn could be intrinsified. The advantage of this is that the unsafe APIs could then be used for other future persistent memory APIs in the JRE. Specifically the following two unsafe APIs would be useful: a) public native void flush(long address, long size); b) public native void storeFence(); storeFence() exists today but doesn't generate any instruction for x86. Wondering if we could have additional boolean parameter to force the sfence generation. * DEFAULT_CACHE_LINE_SIZE is 128 in src/hotspot/cpu/x86/globalDefinitions_x86.hpp whereas actual cache line on the hardware is 64 bytes. This could be the cause for some of performance that you saw with compiler intrinsic vs pure C native. Best Regards, Sandhya RFC: Experiment in accessing/managing persistent memory from Java Andrew Dinn adinn at redhat.com Mon May 21 09:47:46 UTC 2018 I have been helping one of my Red Hat colleagues, Jonathan Halliday, to investigate provision of a Java equivalent to Intel's libpmem suite of C libraries [1]. This approach avoids the significant cost of using the Intel libraries from Java via JNI (or, worse, as a virtual driver for a persistent memory device). Jonathan has modified the JVM/JDK to allow a MappedByteBuffer to be mapped over persistent memory, providing equivalent function to libpmem itself. On top of this he implemented a Java journaled log class providing equivalent functionality to one of the Intel client libs, libpmemlog, built over libpmem. The modified MappedByteBuffer can be configured to use either i) a registered native method or ii) a JIT intrinsic to perform the critical task of cache line writeback i.e. the persistence step (the intrinsic is my contribution). Jonathan's tests compare use of JNI, registered native and intrinsic with an equivalent C program to write a large swathe of records to a journaled log file stored in persistent memory. Performance is worse than C when relying on JNI and significantly better with JVM/JDK support. Indeed, as one might reasonably expect, use of the JIT intrinsic almost completely eliminates writeback costs. The journaled log code, jdk dev tree patch, build instructions, test code plus C equivalent and test results are all available from Jonathan's git repo [2]. For those who do not want to look at the actual code, the README file [3] provides background to use of persistent memory, an overview of the design, and summary details of the test process and results. [1] https://pmem.io/pmdk/ [2] https://github.com/jhalliday/pmem [3] http://github.com://jhalliday/pmem/README.md<http://github.com/jhalliday/pmem/README.md> n.b. Jonathan has experimented with using this same prototype to replace the journaled log used in the Red Hat Narayana transaction manager. It provides a significant improvement on the current disk file based log, both for throughput and latency (the code is not yet available as getting it to work involved some horrible hacking of the build to migrate up to jdk11). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ________________________________

5 6

[11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
by Dora Zhou 22 Jun '18

22 Jun '18

Hello, Please help review the fix for JDK-8194152. Thank you. The test compares output with expected error messages in English, set locale to en-US so that the output are not translated into other languages. Bug: https://bugs.openjdk.java.net/browse/JDK-8194152 Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev/> Regards, Dora

2 1

RFR: JDK-8205158: Update the .md files for 3rd party software Unicode 10.0, ICU 60.1, and CLDR v33
by Rachna Goel 22 Jun '18

22 Jun '18

Hi, Kindly review fix to update legal files for Unicode, CLDR and ICU. Issue: https://bugs.openjdk.java.net/browse/JDK-8205158 Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/ -- Thanks, Rachna

3 5

Promptly freeing the per-thread cached direct buffers when a thread exits
by Tony Printezis 22 Jun '18

22 Jun '18

Hi all, We recently hit another interesting issue with the NIO thread-local DirectByteBuffer cache. One of our services seems to create and drop threads at regular intervals. I assume this is due to a thread pool dynamically resizing itself. Let's say a thread starts, lives long enough for its Thread object to be promoted to the old gen (along with its cached direct buffer), then exits. This will result in its cached direct buffer(s) being unreachable in the old gen and will only be reclaimed after the next full GC / concurrent GC cycle. Interestingly, the service in question does concurrent GC cycles really infrequently (one every few days) as it has a really low promotion rate. This results in the JVM's total direct size constantly increasing (which is effectively a native buffer leak). Has anyone come across this issue before? There are a few obvious ways to mitigate this, e.g., cause a Full GC / concurrent GC cycle at regular intervals. However, the best solution IMHO is to explicitly free any direct buffers that are still in the cache when a thread exits. I'll be happy to implement this and test it internally at Twitter, if it's not on anyone else's radar. However, to do what I'm proposing I need some sort of thread exit hook. Unfortunately, there doesn't seem to be one. Would proposing to introduce thread exit hooks be reasonable? Or is everyone going to freak out? :-) The hooks can be either per-Thread or even per-ThreadLocal. And it's OK if the hooks can only be used within java.base. FWIW, I did a simple prototype of this (I call the hooks from Thread::exit) and it seems to work as expected. Any thoughts / feedback on this will be very appreciated. Thanks, Tony ————— Tony Printezis | @TonyPrintezis | tprintezis(a)twitter.com

7 23

COMPOUND_TEXT charset is missing on JDK11
by Ichiroh Takiguchi 22 Jun '18

22 Jun '18

Hello. JDK8 Linux build has COMPOUND_TEXT charset, but it seems it's missing on JDK11 Linux build. I checked Bug DB, I could not find out the reason why COMPOUND_TEXT charset was missing. Could you port COMPOUND_TEXT charset from JDK8 to JDK11 ? Thanks, Ichiroh Takiguchi IBM Japan, Ltd.

3 3

RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit
by Tony Printezis 22 Jun '18

22 Jun '18

Hi all, Following the discussion on this a few weeks ago, here’s the first version of the change: http://cr.openjdk.java.net/~tonyp/8202788/webrev.0/ I think the consensus was that it’d be easier if the exit hooks were only available within java.base. Is it enough that I added the functionality to the jdk.internal.misc package? (And is jdk.internal.misc the best place for this?) I’ll also add a test for the new functionality. But let’s first come up with an approach that everyone is happy with. :-) One additional question: I put the new functionality conditional on a property (jdk.nio.freeBuffersAtThreadExit) and it’s off by default. Should I make it on by default? Or just not add the property all-together? Tony ————— Tony Printezis | @TonyPrintezis | tprintezis(a)twitter.com

5 50

[PATCH] Minor optimisation for Set.copyOf(Collection)
by Andrej Golovnin 22 Jun '18

22 Jun '18

Hi all, the current implementation of Set.copyOf(Collection<? extends E> coll) creates an intermediate HashSet object to remove duplicates even when coll is already a Set. The attached patch adds an additional check whether coll is already a Set and if yes, then calls #toArray() directly on coll and passes the result to Set.of(). And when I have already your attention: the constructors of SetN and MapN may throw a NegativeArraySizeException when the length of the input is greater than Integer.MAX_VALUE / 2 + 1. Maybe this should be documented or we should throw IllegalArgumentException and explain what's went wrong. Best regards, Andrej Golovnin

2 3