May 2015 - core-libs-dev

SelectableChannels and Process API
by Peter Levart 28 Jul '15

28 Jul '15

Hi Roger, So I started new thread... On 04/14/2015 11:33 PM, Roger Riggs wrote: > > On 4/14/2015 11:47 AM, Peter Levart wrote: >> I have been thinking of another small Process API update. Some people >> find it odd how redirected in/out/err streams are exposed: >> >> http://blog.headius.com/2013/06/the-pain-of-broken-subprocess.html > yep, I've read that several times. To be fair, it's mostly, but not entirely correct. The part that says: " So when the child process exits, the any data waiting to be read from its output stream is drained into a buffer. All of it. In memory. Did you launch a process that writes a gigabyte of data to its output stream and then terminates? Well, friend, I sure hope you have a gigabyte of memory, because the JDK is going to read that sucker in and there's nothing you can do about it. And let's hope there's not more than 2GB of data, since this code basically just grows a byte[], which in Java can only grow to 2GB. If there's more than 2GB of data on that stream, this logic errors out and the data is lost forever." ...is exaggeration. This does not happen as the pipe has a bounded buffer. When subprocess exits, there is at most that much data left in the buffer (64k typically) and only that much is sucked into the Java process and the underlying handle closed. >> >> They basically don't like: >> >> - that exposed Input/Output streams are buffered >> - that underlying streams are File(Input/Output)Streams which, >> although the backing OS implementation are not files but pipes, don't >> expose selectable channels so that non-blocking event-based IO could >> be performed on them. >> - that exposed IO streams are automatically "managed" in UNIX >> variants of ProcessImpl which needs subtle "hacks" to do it in a >> perceptively transparent way (delayed close, draining input on exit >> and making it available after the underlying handle is already >> closed, ...) >> >> So I've been playing with the idea of exposing the "real" pipe >> channels in last couple of days. Here's the prototype I came up with: >> >> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/Process… >> >> >> This adds new Redirect type to the API and 3 new methods to Process >> that return Pipe channels when this new Redirect type is used. It's >> interesting that no native code changes were necessary. The behavior >> of pipes on Windows is a little different (perhaps because the Pipe >> NIO API uses sockets under the hood on Windows - why is that? Windows >> does have a pipe equivalent). What bothers me is that file handles >> opened on files (when redirecting to/from File) can be closed as soon >> as the subprocess is started and the subprocess is still able to >> read/write from the files (like with UNIX). It's not the same with >> pipe (i.e. socket) handles on Windows. They must be closed only after >> subprocess exits. >> >> If this subtle difference between file handles and socket handles on >> Windows could be dealt with (perhaps some options exist that affect >> subprocess spawning), then the extra waiting thread would not be >> needed on Windows. >> >> So what do you think of this API update? > Definitely worthy of a separate thread. It looks promising and > addresses some of the issues > raised, while moving other problems from the implementation to the > application. > Such as closing of the channels and cleanup. I worry about how the > resources are freed > if the code spawning the app doesn't do the cleanup. Will it require > hooks (like a finalizer) > to do the cleanup? > Also, it doesn't help with Martin's goal of being able to implement > emacs in Java since it doesn't provide pty control. > As you are aware the complexity in Process is to ensure a timely > cleanup and > allowing the Process to terminate and release the process resources > when it was done and not having to wait for the stdout/stderr consumer. I wonder how this automatic stream cleanup really helps in real-world programs. It doesn't help the Process to terminate and release the process resources any sooner as the process terminates on it's own (unless killed) and OS releases it's resources without the outside help anyway. Draining and closing the stream after the process has already exited just releases one file handle (the consuming side of the pipe) in a promptly manner. This could be left to the user and/or finalizer. Draining after the process has already exited does not help the process to exit any sooner as it happens after the fact. A program that doesn't consume the stream can cause the process to hang forever as the pipe's buffer is bounded (64k typically). So draining and closing after the process has exited only potentially helps for the last 64k of the stream and only to release one file handle in a potentially more timely manner. OTOH now that ProcessImpl for UNIX does that (and why does Windows implementation not do that?) sloppy programs might exist that would potentially break if the status quo is not maintained. But new functionality need not be so permissive. I'll take a look at how and if Channel(s) do any kind of automatic cleanup based on reachability and whether this can be bolted on for Process use. I doubt it is possible to drain and close a Channel without disturbing the ongoing Selector IO processing... Regards, Peter > > Thanks, Roger > >

3 6

Bad interaction between wildcard and functional interface conversion
by Remi Forax 05 Jul '15

05 Jul '15

Hi all, The way the conversion between a lambda (or a method reference) and a functional interface is specified doesn't take wildcard (exactly ? super) into account making the concept of contravariance of functional interface less intuitive that it should be. The following code compiles: private static void create(Consumer<Consumer<String>> consumer) { consumer.accept(s -> System.out.println(s)); } This one doesn't compile because "? super Consumer<? super String>" is not a functional interface: private static void create2(Consumer<? super Consumer<? super String>> consumer) { consumer.accept(s -> System.out.println(s)); } The workaround is to introduce a cast :( private static void create3(Consumer<? super Consumer<? super String>> consumer) { consumer.accept((Consumer<String>)s -> System.out.println(s)); } which is stupid in this case because there is no ambiguity. This cast is just here because the JLS doesn't consider that ? super Consumer<...> is a valid target type IMO, this bug is very similar to JDK-6964923 and i think the spec should be changed to allow ? super Foo to be a valid target type for a lambda conversion (obviously if Foo is a functional interface). regards, Rémi

2 3

JEP 132: More-prompt finalization
by Peter Levart 03 Jul '15

03 Jul '15

Hi, Did you know that the following simple loop: public class FinalizableBottleneck { static boolean no; @Override protected void finalize() throws Throwable { // empty finalize() method does not make the object finalizable // (it is not even registered on the finalizer's list) if (no) { throw new AssertionError(); } } public static void main(String[] args) { while (true) { new FinalizableBottleneck(); } } } ...quickly fills the entire heap with FinalizableBottleneck and internal Finalizer objects and brings the JVM to a halt? After a few seconds of running the above program, jmap -histo:live reports: num #instances #bytes class name ---------------------------------------------- 1: 50048325 2001933000 java.lang.ref.Finalizer 2: 50048278 800772448 FinalizableBottleneck There are a couple of bottlenecks that make this happen: - ReferenceHandler thread synchronizes with VM to unhook Reference(s) from the pending chain one be one and dispatches them to their respected ReferenceQueue(s) which also use synchronization for equeueing each Reference. - Enqueueing synchronizes with the finalization thread which removes the Finalizer(s) (FinalReferences) from the finalization queue and executes them. - Executing the Finalizer(s) removes them from the doubly-linked list of all Finalizer(s) which is used to retain them until they are needed and this synchronizes with the threads that link new Finalizer(s) into the doubly-linked list as new finalizable objects get registered. We see that the creation of a finalizable object only takes one synchronization (registering into the doubly-linked list) and is performed synchronously, while finalization takes 4 synchronizations among 4 different threads (in pairs) and happens when the Finalizer instance "travels" over from VM thread to ReferenceHandler thread and then to finalization thread. No wonder that finalization can not keep up with allocation in a single thread. The situation is even worse when finalize() methods do some actual work. I have experimented with various approaches to widen these bottlenecks and found out that I can not beat the ForkJoinPool when combined with some improvements to internal data structures used in reference processing. Here's a prototype I came up with: http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.01/ And this is the benchmark I use for measuring the throughput: http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/Finalizer… The benchmark shows (results inline in source) that using unpatched JDK, on my PC (i7-2700K, Linux, JDK8) I can not construct more than 1500 finalizable objects per ms in a single thread and that while doing so, finalization only manages to process approx. 100 - 120 objects at the same time. Objects "in-flight" quickly accumulate and bring the VM to a halt, where it is not doing anything but full GC cycles. When constructing in 4 threads, there's not much difference. Construction of finalizable objects simply doesn't scale. Patched JDK shows something completely different. Single thread construction achieves a rate of 3600 objects / ms. Number of "in-flight" objects is kept constant at about 5-6M instances which amounts to approx 1.5 s of allocation. I think this is about the rate of GC cycles during which VM also processes the references. The benchmark also shows the ForkJoinPool statistics which shows that the number of queued tasks is also kept low. Increasing the allocation threads to 4 increases allocation rate to about 4300 objects / ms and finalization keeps up. Increasing allocation threads to 8, further increases allocation rate to about 4600 objects / ms and finalization still keeps up. The increase in rate is not linear, but keep in mind that i7 is a 4-core CPU. About the implementation... 1st improvement I did was for the doubly-linked list of Finalizer instances that is used to keep them alive until they are needed. I ripped-off the wonderful ConcurrentLinkedDeque by Doug Lea and Martin Buchholz and just kept the internal link/unlink methods while specializing them to Finalizer entries (very straight-forward). I experimented with throughput and got some improvement, but throughput has increased much more when I used several instances of independent lists and distributed registrations among them randomly (unlinking consequently is also distributed randomly). I found out that no matter how hard I try to optimize ReferenceQueue while keeping the API unchanged, I can only do so much and that was not enough. I have been surprised by how well ForkJoinPool distributes tasks among threads, so I concluded that leveraging it is the best choice. I re-designed the pending-list unhooking loop to unhook pending references in chunks which greatly improves the throughput. Since unhooking can be performed by a single thread while holding a lock which is mandated by interface between VM and Java, I didn't employ multiple threads, but a single eternal ForkJoinTask that unhooks in chunks and forks-off other processing tasks that process chunks. When there are just a couple of References pending at one time and a not-full chunk is unhooked, then the processing is performed by the same thread that unhooked the refrences, but when there are more, worker tasks are forked off and the unhooking thread continues with full peace. This processing includes execution of Cleaners, forking the finalizer tasks and enqueue-ing other references. Finalizer(s) are always executed as separate ForkJoinTask(s). It's interesting how Runtime.runFinalizers() is implemented in this patch - it basically amounts to ForkJoinPool.awaitQuiescence() ... I also tweaked the ReferenceQueue implementation a bit (it is still used for other kinds of references) so that it avoids synchronization with a monitor lock when there are no blocking waiters and uses CAS to enqueue/dequeue. This improves throughput when the queue is not empty. Since in the prototype multiple threads can enqueue into the same queue, I thought this would improve throughput in such situations. Comments, suggestions, criticism are welcome. Regards, Peter

7 25

RFR 8080640: Reduce copying when reading JAR/ZIP entries
by Staffan Friberg 29 Jun '15

29 Jun '15

Hi, Wanted to get reviews and feedback on this performance improvement for reading from JAR/ZIP files during classloading by reducing unnecessary copying and reading the entry in one go instead of in small portions. This shows a significant improvement when reading a single entry and for a large application with 10k classes and 500+ JAR files it improved the startup time by 4%. For more details on the background and performance results please see the RFE entry. RFE - https://bugs.openjdk.java.net/browse/JDK-8080640 WEBREV - http://cr.openjdk.java.net/~sfriberg/JDK-8080640/webrev.0 Cheers, Staffan

2 15

[9] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
by Konstantin Shefov 17 Jun '15

17 Jun '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.00/ Thanks -Konstantin

3 10

RFR 8076039: Remove the unused internal API sun.reflect.misc.FieldUtil.getDeclaredFields
by Srikanth 10 Jun '15

10 Jun '15

Greetings, Please review this patch to remove the said unused internal API - this has been reviewed by a couple of engineers already and is now submitted now for wider review. I have built JDK on all platforms and ran the tests to make sure this is safe. JBS: https://bugs.openjdk.java.net/browse/JDK-8076039 Webrev: http://cr.openjdk.java.net/~sadayapalam/8076039/webrev/ Thanks! Srikanth

3 4

Re: RFR(M): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo
by Staffan Larsen 08 Jun '15

08 Jun '15

Dmitry, I think this should be reviewed on hotspot-gc and core-libs-dev as well considering the changes to Finalizer. I’m a little worried about the potentially very large String that is returned from printFinalizationQueue(). A possible different approach would be to write printFinalizationQueue() in C++ inside Hotspot. That would allow for outputting one line at a time. The output would still be saved in memory (since the stream is buffered), but at least the data is only saved once in memory, then. It would make the code a bit harder to write, so its a question of how scared we are of running out of memory. I see you are traversing the ‘unfinalized’ list in Finalizer, whereas the old SA code for ‘-finalizerinfo' traverses the ‘queue’ list. I am not sure of the difference, perhaps someone from the GC team can help out? For the output, it would be a nice touch to sort it on the number of references for each type. Perhaps outputting it more like a table (see the old code again) would also make it easier to digest. In diagnosticCommand.hpp, the new commands should override permission() and limit access: static const JavaPermission permission() { JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", NULL}; return p; } The two tests don’t validate the output in any way. Would it be possible to add validation? Perhaps hard to make sure an object is on the finalizer queue… Hmm. Thanks, /Staffan > On 5 maj 2015, at 12:01, Dmitry Samersoff <dmitry.samersoff(a)oracle.com> wrote: > > Everyone, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.01/ > > heap dcmd outputs the same information as SIGBREAK > > finalizerinfo dcmd outputs a list of all classes in finalization queue > with count > > -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.

7 59

[8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
by Konstantin Shefov 05 Jun '15

05 Jun '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9. Thanks -Konstantin

2 12

Patch to improve primitives Array.sort()
by Chan, Sunny 05 Jun '15

05 Jun '15

We are proposing a patch to improve the performance for the DualPivotQuickSort use by Array.sort to sort primitives array. We have identified two area for optimization: Firstly, we have changed the algorithm to determine what a "run" is. A "run" is how long you go through the array with it being in order. For example, an array of 1, 2, 3, 5, 4, 3 would have a run count equal to 2 (two parts that are in order). The JDK implementation stops looking for runs if it comes across two equal numbers at the beginning of a run, eg. 1, 1, 1, 1, 2, 3, 4, 4, 4, 4, 4, 4, 5 And then sorts the whole array, as seen in this part of the algorithm: } else { // equal for (int m = MAX_RUN_LENGTH; ++k <= right && a[k - 1] == a[k]; ) { if (--m == 0) { sort(a, left, right, true); return; } } } Instead, we detect and equal beginning of a run at the top of the for loop, as shown here: while (k < right && a[k] == a[++k]); //equal so the array mentioned above would instead have one run, be determined already sorted, and sort would not be called as it would in the original JDK implementation. Second optimization is in the case of an array that is descending, and then ascending. Since the algorithm does swapping in the case of descending numbers, by the end of all swapping the array is sorted. We detect this through this if statement: if (run[count] > left && a[run[count]] >= a[run[count] - 1]) { count--; } And will stop sorting, unlike the JDK. I have attached a webrev.zip containing the patch and unit test that verifies the sort is correct. We also have a couple of JMH based performance tests which is not included. If the JMH is available we can also make those performance test available as well. The patch is author by Kristen O'Leary (Kristen.o'leary(a)gs.com) and myself. Please attribute both of us when committing. You can find my OCA entry under Goldman Sachs and as we are not authors yet we can't raise a bug report in the database. Please let us know if you need further clarification or modification to the patch. Sunny Chan, Executive Director, Technology Goldman Sachs (Asia) L.L.C. | 68th Floor | Cheung Kong Center | 2 Queens Road Central | Hong Kong email: sunny.chan(a)gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication.

5 20

Lower overhead String encoding/decoding
by Richard Warburton 04 Jun '15

04 Jun '15

Hi all, A long-standing issue with Strings in Java is the ease and performance of creating a String from a ByteBuffer. People who are using nio to bring in data off the network will be receiving that data in the form of bytebuffers and converting it to some form of String. For example restful systems receiving XML or Json messages. The current workaround is to create a byte[] from the ByteBuffer - a copying action for any direct bytebuffer - and then pass that to the String. I'd like to propose that we add an additional constructor to the String class that takes a ByteBuffer as an argument, and directly create the char[] value inside the String from the ByteBuffer. Similarly if you have a String that you want to encode onto the wire then you need to call String.getBytes(), then write your byte[] into a ByteBuffer or send it over the network. This ends up allocating a byte[] to do the copy and also trimming the byte[] back down again, usually allocating another byte[]. To address this problem I've added a couple of getBytes() overloads that take byte[] and ByteBuffer arguments and write directly to those buffers. I've put together a patch that implements this to demonstrate the overall direction. http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/ I'm happy to take any feedback on direction or the patch itself or the overall idea/approach. I think there are a number of similar API situations in other places as well, for example StringBuffer/StringBuilder instances which could have similar appends directly from ByteBuffer instances instead of byte[] instances. I'll also be at Javaone next week, so if you want to talk about this, just let me know. regards, Richard Warburton http://insightfullogic.com @RichardWarburto <http://twitter.com/richardwarburto> PS: I appreciate that since I'm adding a method to the public API which consequently requires standardisation but I think that this could get incorporated into the Java 9 umbrella JSR.

7 27