February 2016 - core-libs-dev

Spin Loop Hint support: Draft JEP proposal
by Gil Tene 24 Feb '16

24 Feb '16

I would like to circulate this draft JEP proposal for initial review and consensus building purposes. I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). Draft JEP follows inline... — Gil. JEP XYZ: Spin Loop Hint (suggested content for some JEP fields): Authors Gil Tene Owner Gil Tene Type Feature Status Draft Component core-libs Scope JDK Discussion core dash libs dash dev at openjdk dot java dot net Effort S Duration S Summary Add an API that would allow Java code to hint that a spin loop is being executed. Goals Provide an API that would allow Java code to hint to the runtime that it is in a spin loop. The API would be a pure hint, and will carry no semantic behavior requirements (i.e. a no-op is a valid implementation). Allow the JVM to benefit from spin loop specific behaviors that may be useful on certain hardware platforms. Provide both a no-op implementation and an intrinsic implementation in the JDK, and demonstrate an execution benefit on at least one major hardware platform. Non-Goals It is NOT a goal to look at performance hints beyond spin loops. Other performance hints, such as prefetch hints, are outside the scope of this JEP. Motivation Some hardware platforms benefit from software indication that a spin loop is in progress. Some common execution benefits may be observed: A) The reaction time of a spin loop may be improved when a spin hint is used due to various factors, reducing thread-to-thread latencies in spinning wait situations. and B) The power consumed by the core or hardware thread involved in the spin loop may be reduced, benefitting overall power consumption of a program, and possibly allowing other cores or hardware threads to execute at faster speeds within the same power consumption envelope. While long term spinning is often discouraged as a general user-mode programming practice, short term spinning prior to blocking is a common practice (both inside and outside of the JDK). Furthermore, as core-rich computing platforms are commonly available, many performance and/or latency sensitive applications use a pattern that dedicates a spinning thread to a latency critical function [1], and may involve long term spinning as well. As a practical example and use case, current x86 processors support a PAUSE instruction that can be used to indicate spinning behavior. Using a PAUSE instruction demonstrably reduces thread-to-thread round trips. Due to it's benefits and commonly recommended use, the x86 PAUSE instruction is commonly used in kernel spinlocks, in POSIX libraries that perform heuristic spins prior to blocking, and even by the JVM itself. However, due to the inability to hint that a Java loop is spinning, it's benefits are not available to regular Java code. We include specific supporting evidence: In simple tests [2] performed on a E5-2697 v2, measuring the round trip latency behavior between two threads that communicate by spinning on a volatile field, round-trip latencies were demonstrably reduced by 18-20nsec across a wide percentile spectrum (from the 10%'ile to the 99.9%'ile). This reduction can represent an improvement as high as 35%-50% in best-case thread-to-thread communication latency. E.g. when two spinning threads execute on two hardware threads that share a physical CPU core and an L1 data cache. See example latency measurement results comparing the reaction latency of a spin loop that includes an intrinsified spinLoopHint() call [intrinsified as a PAUSE instruction] to the same loop executed without using a PAUSE instruction [3], along with the measurements of the it takes to perform an actual System.nantoTime() call to measure time. Description We propose to add a method to the JDK which would be hint that a spin loop is being performed. E.g. jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The specific name space location, class name, and method name will be determined as part of development of this JEP. An empty method would be a valid implementation of the spinLoopHint() method, but intrisic implementation is the obvious goal for hardware platforms that can benefit from it. We intend to produce an intrinsic x86 implementation for OpenJDK as part of developing this JEP. A prototype implementation already exists [4] [5] [6] [7] and results from initial testing show promise. Alternatives JNI can be used to spin loop with a spin-loop-hinting CPU instruction, but the JNI-boundary crossing overhead tends to be larger than the benefit provided by the instruction, at least where latency is concerned. We could attempt to have the JIT compilers deduce spin-loop situations and code and choose to automatically include a spin-loop-hinting CPU instructions with no Java code hints required. We expect that the complexity of automatically and reliably detecting spinning situations, coupled with questions about potential tradeoffs in using the hints on some platform to delay the availability of viable implementations significantly. Testing Testing of a "vanilla" no-op implementation will obviously be fairly simple. We believe that given the vey small footprint of this API, testing of an intrinsified x86 implementation in OpenJDK will also be straightforward. We expect testing to focus on confirming both the code generation correctness and latency benefits of using the spin loop hint with an intrinsic implementation. Should this API be proposed as a Java SE API (e.g. for inclusion in the java.* namespace in a future Java SE 9 or Java SE 10), we expect to develop an associated TCK tests for the API for potential inclusion in the Java SE TCK. Risks and Assumptions The "vanilla" no-op implementation is obviously fairly low risk. An intrinsic x86 implementation will involve modifications to multiple JVM components and as such they carry some risks, but no more than other simple intrinsics added to the JDK. [1] The LMAX Disruptor https://lmax-exchange.github.io/disruptor/ <https://lmax-exchange.github.io/disruptor/> [2] https://github.com/giltene/GilExamples/tree/master/SpinHintTest <https://github.com/giltene/GilExamples/tree/master/SpinHintTest> [3] Chart depicting SpinLoopHint intrinsification impact https://github.com/giltene/GilExamples/blob/master/SpinHintTest/SpinLoopLat… <https://github.com/giltene/GilExamples/blob/master/SpinHintTest/SpinLoopLat…> [4] HotSpot WebRevs for prototype implementation which intrinsifies org.performancehintsSpinHint.spinLoopHint() http://ivankrylov.github.io/spinloophint/webrev/ <http://ivankrylov.github.io/spinloophint/webrev/> [5] JDK WebRevs for prototype intrinsifying implementation: http://ivankrylov.github.io/spinloophint/webrev.jdk/ <http://ivankrylov.github.io/spinloophint/webrev.jdk/> [6] Build environment WebRevs for prototype intrinsifying implementation: http://ivankrylov.github.io/spinloophint/webrev.main/ <http://ivankrylov.github.io/spinloophint/webrev.main/> [7] Link to a working Linux protoype OpenJDK9-based JDK (accepts optional -XX:+UseSpinLoopHintIntrinsic) https://www.dropbox.com/s/r2w1s1jykr2qs01/slh-openjdk-9-b70-bin-linux-x64.t… <https://www.dropbox.com/s/r2w1s1jykr2qs01/slh-openjdk-9-b70-bin-linux-x64.t…>

21 71

RFR 8124977 cmdline encoding challenges on Windows
by Kirk Shoop (MS OPEN TECH) 24 Feb '16

24 Feb '16

Hi, Issue: https://bugs.openjdk.java.net/browse/JDK-8124977 Webrev: http://cr.openjdk.java.net/~kshoop/8124977/ This webrev intends to address interaction between Windows console and java apps. Two switches were added that change the behavior of the launcher. The defaults do not change the launcher behavior. -Dwindows.UnicodeConsole=true - switches on Unicode support in the Windows console. This optional switch causes the launcher to call GetCommandLineW() and parse the arguments in unicode. It also modifies how the codepage for console output is selected. -Dfile.encoding.unicode="UTF-8" - identifies Unicode charset to use; If not specified, UTF-8 is used by default. Ignored when windows.UnicodeConsole is not set to true. When the first switch is used, this optional switch allows the codepage for console output to be controlled. I would like to get feedback on the approach here and any additional work that is required solve these particular Unicode issues on Windows. Kirk

10 32

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE
by Langer, Christoph 24 Feb '16

24 Feb '16

Sorry, this one is the right webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150470.1/ From: Langer, Christoph Sent: Dienstag, 23. Februar 2016 21:13 To: 'Aleksej Efimov' <aleksej.efimov(a)oracle.com>; huizhe wang <huizhe.wang(a)oracle.com> Subject: RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE Hi Aleksej, Joe, sorry, I already had a bad feeling with that line... Here is a bug: https://bugs.openjdk.java.net/browse/JDK-8150470 And here is a webrev for fix: http://cr.openjdk.java.net/~clanger/webrevs/8150470.0/ Feel free to add more data to the bug and do more tests. I only had the jtreg tests at hand. Shall I post this in the mailing list? Best regards Christoph From: Aleksej Efimov [mailto:aleksej.efimov@oracle.com] Sent: Dienstag, 23. Februar 2016 18:26 To: huizhe wang <huizhe.wang(a)oracle.com<mailto:huizhe.wang@oracle.com>> Cc: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>> Subject: Re: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE Sure! Will do it tomorrow. Best Regards, Aleksej On 02/23/2016 07:50 PM, huizhe wang wrote: Hi Aleksej, Thanks for catching the issue and identifying the fix! Once you come back from the holiday, could you submit a review of the fix? Best, Joe On 2/23/2016 8:15 AM, Aleksej Efimov wrote: Hi again, Got an update on this issue: The fix introduced back this one issue: https://bugs.openjdk.java.net/browse/JDK-8021366 The root cause is that Entity.DEFAULT_XMLDECL_BUFFER_SIZE and XMLEntityManager.DEFAULT_XMLDECL_BUFFER_SIZE have different values: 32 and 64. This change erased the JDK-8021366 change (64->32) and introduced back the issue: - len = fCurrentEntity.DEFAULT_XMLDECL_BUFFER_SIZE; + len = DEFAULT_XMLDECL_BUFFER_SIZE; Tested the reversion of the fix for only this line and JCK test passes now: - len = DEFAULT_XMLDECL_BUFFER_SIZE; + len = fCurrentEntity.DEFAULT_XMLDECL_BUFFER_SIZE; With Best Regards, Aleksej On 02/23/2016 06:46 PM, Aleksej Efimov wrote: Hi Christoph, Joe, I think we may have a problem with this fix. I'm observing one new JCK test failure with the fix. If the fix is stripped from JDK9 repo - no failure observed. Failed test is api/xsl/conf/copy/copy19.html#copy19 The failure message is: MultiJVM group agent ID: 1 java version "9-internal" OpenJDK Runtime Environment (build 9-internal+0-2016-02-23-012828.aefimov.9) OpenJDK 64-Bit Server VM (build 9-internal+0-2016-02-23-012828.aefimov.9, mixed mode) Failed to parse as XML. Cause: warning;org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 10; XML document structures must start and end within the same entity. Parsing as text. Failed to parse as XML. Cause: warning;org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 53; XML document structures must start and end within the same entity. Parsing as text. mismatch-value;TEXT()len=43;TEXT()len=62;lengths do not match mismatch-value-gold;TEXT(); <?xml version="1.0" encoding="ISO-8859-1"?> mismatch-value-text;TEXT(); <?xml version="1.0" encoding="ISO-8859-1"?><out>abcd\u00e8fgh</out> XHTFileCheckService results were not equal. Expected result: <?xml version="1.0" encoding="ISO-8859-1"?> <out>abcd\u00e8fgh</out> Actual result: <?xml version="1.0" encoding="ISO-8859-1"?><out>abcd\u00e8fgh</out> result: Failed. test cases: 1; all failed; first test case failure: testTransformation test result: Failed. test cases: 1; all failed; first test case failure: testTransformation Today is a holiday in SPb. Tomorrow I can log a bug to track this failure (new line is missing in actual result output). Best Regards, Aleksej On 02/23/2016 02:27 PM, Langer, Christoph wrote: Hi Aleksej, that's great, please go ahead. Sooner or later I would have started this effort, too. But right now I'm working on another fix for the XALAN which I'll post soon :-) Best regards Christoph PS: @Joe: I noticed that in the commit I was not the author of the change but only mentioned in the "Contributed-by" tag. Couldn't you push the change on my behalf but with maintaining me as the author? -----Original Message----- From: Aleksej Efimov [mailto:aleksej.efimov@oracle.com] Sent: Dienstag, 23. Februar 2016 12:21 To: Langer, Christoph <christoph.langer(a)sap.com><mailto:christoph.langer@sap.com> Cc: Joe Wang <huizhe.wang(a)oracle.com><mailto:huizhe.wang@oracle.com> Subject: Re: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE Hi Christoph, I would like to backport your fix to JDK8. Just wanted to get your confirmation that you're not working on that and we are not doing the same task =) With Best Regards, Aleksej On 02/18/2016 10:33 PM, Langer, Christoph wrote: Hi Joe, I fixed the copyright in http://cr.openjdk.java.net/~clanger/webrevs/8149915.3/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8149915.3/>. So I think I'm done. Can you review and push the change then? Thanks Christoph -----Original Message----- From: huizhe wang [mailto:huizhe.wang@oracle.com] Sent: Donnerstag, 18. Februar 2016 19:19 To: Langer, Christoph <christoph.langer(a)sap.com><mailto:christoph.langer@sap.com> Cc: core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> Subject: Re: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE On 2/18/2016 5:15 AM, Langer, Christoph wrote: Hi Joe, here is the next version: http://cr.openjdk.java.net/~clanger/webrevs/8149915.2/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8149915.2/> Looks good! Thanks. Copyright year in XSAttributeChecker.java is still incorrect. I meant to say the year "2016" needs to have a comma, so in this case, it needs to be "2015, 2016, " rather than "2015, 2016". Best, Joe Hopefully the final one :-) Yes, it's good to have some cleanups. For the generic initialization, it's preferable to have no redundant type arguments, for example, instead of: protected Stack<Entity> fEntityStack = new Stack<Entity>(); do: protected Stack<Entity> fEntityStack = new Stack<>(); Some of the "cleanup" in the webrev were reversing <> with added type argument(s), that would be unnecessary. I think I did that on all the places that I touched now. For the obsolete Vector, it would be good to replace it with ArrayList. There are so many Vector instances in this code that it's out of scope for me now to touch them all... Copyright year "2016" in XSAttributeChecker needs to be "2016," or else the script would complain. For that one I thought that it would look like "2015,2016" if the initial copyright was done in 2015. But I changed it as you suggested. In XSDHandler, note that there's another call to get SECURITY_MANAGER towards the end of the reset method (at 3572 in your new version) that may be removed. You may also consolidate most of those setFeature/Property statements in one try-catch block if you want. OK, I did some further refacturing here. However, I've left the try/catch blocks as I think it's the intention to silently catch some exceptions but then try to go on with the next property. For the test, the @bug tag is still desirable in the general comment section. For now, it's @bug 8149915. As we add more test to the class in the future, we'd then append more bug ids, @bug 8149915, xxxxxxx. Done. I also left the @bug in the comments for the test method. I'm also wondering why some files have a copyright header like this, e.g. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11D TDScannerImpl.java: /* * reserved comment block * DO NOT REMOVE OR ALTER! */ Shouldn't there be the standard copyright header or is there some reason behind it? The block is used by the licensing script to swap with license information required by licensees. For code that came from Xerces, we should keep the block as is with the Apache License. But when we make changes, we're required to put in the copyright header. Since the changes you made are cleanup / removing unused fields, it's okay to keep the block as is. OK :) Thanks again for reviewing. All the Best Christoph

2 1

RFR 9: 8150337 : sun/misc/SunMiscSignalTest.java failed intermittently
by Roger Riggs 23 Feb '16

23 Feb '16

Please review a test update to skip tests using SIGINT, SIGTERM, and SIGHUP when run with those signals are ignored. For example, using nohup or trap in a shell. It also includes a small enhancement adding sun.misc.Signal.toString ease debugging. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-nohup-8150337/index.html Thanks, Roger

2 1

RFR (S) 8150180: String.value contents should be trusted
by Aleksey Shipilev 23 Feb '16

23 Feb '16

Hi, Please review a simple performance improvement in Strings: https://bugs.openjdk.java.net/browse/JDK-8150180 In short, we want VM to trust constant String contents, so that "Foo".charAt(0) is folded. As far as current Hotspot goes, this is only achievable with @Stable -- we need to trust the array contents: http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/ This, however, steps into the compiler bug caused by StringUTF16.getChar intrinsic producing a mismatched load, that is then folded incorrectly. So we instead rely on Java level folding in cases like these: http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/ ...and it works: http://cr.openjdk.java.net/~shade/8150180/notes.txt While VM change looks like a workaround, Vladimir I. and me concluded that @Stable folding code should just reject folding mismatched loads to begin with. So, getChar intrinsic change is the actual fix. Vladimir I. ought to add more assertions in @Stable folding code separately: https://bugs.openjdk.java.net/browse/JDK-8150186 Since this issue might trigger compiler bugs, I would like to push through hs-comp to pass compiler nightlies. Cheers, -Aleksey

6 16

RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API
by Michael Haupt 23 Feb '16

23 Feb '16

Dear all, please review this (doc-only) fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8143410 Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00 The change documents the type variables used in the pseudo-code in the API documentation of the following methods in MethodHandles: catchException(), collectArguments(), filterArguments(), filterReturnValue(), foldArguments(), and guardWithTest(). Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 4

RFR(S): 8150360: augment/correct MethodHandle API documentation
by Michael Haupt 23 Feb '16

23 Feb '16

Dear all, please review this (doc-only) fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150360 Webrev: http://cr.openjdk.java.net/~mhaupt/8150360/webrev.00 The fix addresses one contradiction in the API documentation of MethodHandles.tryFinally(), and adds the following note to the API documentation of the method handle combinators given below: + * <p> + * <em>Note:</em> The resulting adapter is never a {@linkplain MethodHandle#asVarargsCollector + * variable-arity method handle}, even if the original target method handle was. * MethodHandle.asCollector(), .bindTo() * MethodHandles.collectArguments(), .dropArguments(), .filterArguments(), .filterReturnValue(), .foldArguments(), .permuteArguments() Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 2

JDK 9 RFR of JDK-8149154: tools/pack200/Pack200Test.java failed with NullPointerException
by Amy Lu 22 Feb '16

22 Feb '16

Please help to review this minor fix to post-test clean-up where NullPointerException should be avoided. bug: https://bugs.openjdk.java.net/browse/JDK-8149154 webrev: http://cr.openjdk.java.net/~amlu/8149154/webrev.00/ Thanks, Amy --- old/test/tools/pack200/Pack200Test.java 2016-02-20 19:12:36.000000000 +0800 +++ new/test/tools/pack200/Pack200Test.java 2016-02-20 19:12:35.000000000 +0800 @@ -81,7 +81,9 @@ System.out.println("Packing [" + in.toString() + "]"); // Call the packer Utils.pack(jarFile, packFile); + System.out.println("Done Packing [" + in.toString() + "]"); jarFile.close(); + System.out.println("Start leak check"); leakCheck(); System.out.println(" Unpacking using java unpacker"); --- old/test/tools/pack200/Utils.java 2016-02-20 19:12:38.000000000 +0800 +++ new/test/tools/pack200/Utils.java 2016-02-20 19:12:38.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -324,6 +324,9 @@ private static void findFiles0(File startDir, List<File> list, FileFilter filter) throws IOException { File[] foundFiles = startDir.listFiles(filter); + if (foundFiles == null) { + return; + } list.addAll(Arrays.asList(foundFiles)); File[] dirs = startDir.listFiles(DIR_FILTER); for (File dir : dirs) {

2 1

RFR 8144931: Assert class signatures are correct and refer to valid classes
by shilpi rastogi 22 Feb '16

22 Feb '16

Hi All, Please review fix for the following bug- https://bugs.openjdk.java.net/browse/JDK-8144931 http://cr.openjdk.java.net/~srastogi/8144931/webrev.01/ Thanks, Shilpi

6 13

JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014
by joe darcy 20 Feb '16

20 Feb '16

Hello, Right now, we are seeing some cross-platform intermittent failures of java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java as noted in bug JDK-8150014. Until that test instability is resolved, the test should be demoted from tier 1 to tier 2. Please see the patch below. (Circumstantial evidence points to the changes in JDK-8145485 being involved.) -Joe diff -r 3973fe856db2 test/TEST.groups --- a/test/TEST.groups Wed Feb 17 12:47:35 2016 -0800 +++ b/test/TEST.groups Thu Feb 18 16:44:40 2016 -0800 @@ -29,6 +29,7 @@ :jdk_lang \ -java/lang/ProcessHandle/TreeTest.java \ -java/util/zip/TestLocalTime.java \ + -java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java \ :jdk_util \ -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ @@ -39,6 +40,7 @@ :jdk_math tier2 = \ + java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java \ java/lang/ProcessHandle/TreeTest.java \ java/util/zip/TestLocalTime.java \ java/util/WeakHashMap/GCDuringIteration.java \

3 6