From orionllmain at gmail.com Sat Dec 1 04:34:50 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Sat, 1 Dec 2018 11:34:50 +0700 Subject: Optimized version of CopiesList.hashCode() In-Reply-To: <92419515-1a9a-576a-aa49-cbf82d6bf780@oracle.com> References: <92419515-1a9a-576a-aa49-cbf82d6bf780@oracle.com> Message-ID: I think we should choose Tagir's version so you don't need my OCA. ??, 1 ???. 2018 ?. ? 06:38, Stuart Marks : > > > On 11/30/18 8:52 AM, Martin Buchholz wrote: > > On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev wrote: > > > >> I can file an issue and create a webrev, but I still need a sponsor > >> and review for such change. Martin, can you help with this? > > > > As usual, I'm only half paying attention, but I can be your shepherd. > > (I'm still digging out from my backlog. Perhaps Martin and I are competing > for > who has less time....) > > A quick process check: are the proper OCAs in place? [1] > > If Zheka is authoring, he'll need to have signed the OCA. (Or he'll need > to be > doing this work on behalf of a company or organization that has signed the > OCA.) > > If Tagir is authoring, he's good, since he's already signed the OCA. > > Zheka, even if you're not authoring this changeset, if you intend to > contribute > to OpenJDK in the future, you might want to work on an OCA. It's not a > gigantic > bit of bureaucracy, but it does take a few days, and you'll probably want > to > avoid lack of an OCA blocking a future contribution. > > Otherwise, thanks and carry on. > > s'marks > > > > > [1] https://www.oracle.com/technetwork/community/oca-486395.html > From sormuras at gmail.com Sat Dec 1 08:45:02 2018 From: sormuras at gmail.com (Christian Stein) Date: Sat, 1 Dec 2018 09:45:02 +0100 Subject: jar --verify operation mode checking mrjar validity Message-ID: Hi, jar --create (and --update) perform type API validation checks when used in combination with --release option. This detects invalid "version overlays" at package time, where the API doesn't match a previous one. Having a jar --verify mode that performs the same checks consuming an already existing jar file would be useful as most "3rd-party packaging tools" don't perform those checks. A possible work-around could be to explode an existing jar and re-create it using jar --create... Cheers, Christian From philipp.kunz at paratix.ch Sat Dec 1 11:49:15 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 01 Dec 2018 12:49:15 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes Message-ID: <1543664955.2437.5.camel@paratix.ch> Find the proposed patch attached. Some comments and explanations, here: There is a quite interesting implementation in Manifest and Attributes worth quite some explanation. The way it used to work before was: 1. put manifest header name, colon and space into a StringBuffer -> the buffer now contains a string of characters each high-byte of which is zero as explained later why this is important. the high-bytes are zero because the set of allowed characters is very limited to ":", " ", "a" - "z", "A" - "Z", "0" - "9", "_", and "-" according to Attributes.Name#hash(String) so far with only the name and the separator and yet without the values. 2. if the value is not null, encode it in UTF-8 into a byte array and instantiate a String with it using deprecated String#String(byte[],int,int,int) resulting in a String with the same length as the byte array before holding one byte in each character's low-byte. This makes a difference for characters encoded with more than one byte in UTF-8. The new String is potentially longer than the original value. 3.?if the value is not null, append value to buffer. The one UTF-8 encoded byte per character from the appended string is preserved also in the buffer along with the previous buffer contents. 3alt. if the value is null, add "null" to the buffer. See java.lang.AbstractStringBuilder#append(String). Neither of the characters of "null" has a non-zero high-byte encoded as UTF-16 chars. 4. make72Safe inserts line breaks with continuation spaces. Note that the buffer here contains only one byte per character because all high- bytes are still zero so that line.length() and line.insert(index, ...) effectively operate with byte offsets and not characters. 5. buffer.toString() 6. DataOutputStream#writeBytes(String). First of all read the JavaDoc comment for it, which explains it all: Writes out the string to the underlying output stream as a ????sequence of bytes. Each character in the string is written out, in ????sequence, by discarding its high eight bits. If no exception is ????thrown, the counter written is incremented by the ????length of s This restores the earlier UTF-8 encoding correctly. The topic has been discussed and mentioned already in http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052946.ht ml https://bugs.openjdk.java.net/browse/JDK-6202130 String(byte[],int,int,int) works "well" or "well enough" only together with DataOutputStream#writeBytes(String). When removing String(byte[],int,int,int) from Manifest and Attributes because deprecated, it makes no sense to keep using DataOutputStream#writeBytes(String) either. For the same reason as?String#String(byte[],int,int,int) has been deprecated, I suggest to also deprecate java.io.DataOutput#writeBytes(String) as a separate issue. This might relate to https://bugs.openjdk.java.net/browse/JDK-6400767 but that one came to a different conclusion some ten years ago. I preferred to stick with the DataOutputStream even though not strictly necessary any more. It is and has been in the API of Attributes (unfortunately not private) and should better not be removed by changing the parameter type. Same for Manifest#make72Safe(StringBuffer) which I deprecated rather than having removed. Someone could have extended a class from Manifest and use such a method and when changing the signature it could no longer even compile in a far-fetched case. LINE_BREAK, CONTINUATION_SPACE, LINE_BREAK_BYTES, and LINE_BREAK_WITH_CONTINUATION_SPACE_BYTES should prevent having to invoke getBytes(UTF_8) over and over again on "\r\n" and "\r\n " with the idea to slightly improve performance this way. I figured it does not need JavaDoc comments but would be happy to add them if desired. I removed "XXX Need to handle UTF8 values." from Manifest#read after adding a test for it in ValueUtf8Coding. This change and test also relate to bug 6202130 but does not solve that one completely. ValueUtf8Coding demonstrates that Manifest can read UTF-8 encoded values which is a necessary test case to cover for this patch here. ValueUtf8Coding is the same test as already submitted and suggested earlier. See http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/threa d.html#55848 Indentation in Attributes#write(DataOutputStream) was five spaces on most lines. I?fixed indentation only on the lines changed anyway. I replaced String#String(byte[],int,int,String) with String#String(byte[],int,int,java.nio.charset.StandardCharsets.UTF_8) which as a difference does not declare to throw a java.io.UnsupportedEncodingException. That also replaced "UTF8" as a charset name which I would consider not optimal regarding sun.nio.cs.UTF_8#UTF_8() and sun.nio.cs.UTF_8#historicalName(). In my opinion there is still some duplicated or at least very similar code in Manifest#write, Attributes#writeMain, and Attributes#write but I preferred to change less rather than more and not to further refactor and re-combine it. In EmptyKeysAndValues and NullKeysAndValues tests I tried to demonstrate that the changed implementation does not change behaviour also in edge cases. I would have expected not having to test all these cases but then I realized it was possible to test and is therefore possible in a real use case as well however far-fetched. At least the if (value != null) { lines (three times) most obviously demand to test the null value cases. I'm looking curiously forward to any kind of feedback or opinion. Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 8905 bytes Desc: not available URL: From Alan.Bateman at oracle.com Sat Dec 1 17:27:06 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 1 Dec 2018 17:27:06 +0000 Subject: RFR: 8212703: Remove sun.java2d.fontpath property from java launcher code In-Reply-To: <5fcbf33a-004d-8156-d917-f4652e871d4a@oracle.com> References: <270a99cf-2f95-9730-5c92-b947abd2d99c@oracle.com> <5fcbf33a-004d-8156-d917-f4652e871d4a@oracle.com> Message-ID: <7b4d4735-eae2-5a32-d6ed-5c140d50ddf4@oracle.com> On 30/11/2018 23:11, Roger Riggs wrote: > Hi Phil, > > That looks fine. > > Too bad it introduces a new shell test, we're trying to get rid of them. > The other alternative would have the test program needed to set the > environment > and launch a java program. > The implementation look good to me too and I agree with Roger that we shouldn't be introducing a shell test for this. In this case, it looks like you just need a /othervm test that checks for the env variable and property. -Alan From vladimir.kozlov at oracle.com Sun Dec 2 00:37:45 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 1 Dec 2018 16:37:45 -0800 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> Message-ID: <09a1553c-558c-fb67-9609-a544e50db43c@oracle.com> I am fine with Hotspot changes. But we need to verify changes on all platforms. I see that aarch64 also supports it in addition to SPARC. I will run compiler/codegen/aes/ test to make sure it pass on SPARC but we don't test aarch64. I let you know testing results when they are done. Thanks, Vladimir On 11/20/18 6:45 PM, Kamath, Smita wrote: > Hi Tony, > > Thanks for your comments. > > 1) This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not break the sparc intrinsic? It may work as the code is now since the sparc intrinsic will only use the first two longs in the subkeyHtbl. > Would it be possible to help with this sanity check? I don't have the required set-up to test this scenario. > > 2) I have changed the code so that subkeyH corresponds to the first two entries of subkeyHtbl. Please find the updated webrev link. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 > > Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ > > Thanks and Regards, > Smita > > > > -----Original Message----- > From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] > Sent: Tuesday, November 20, 2018 2:05 PM > To: Kamath, Smita ; 'Vladimir Kozlov' > Cc: Viswanathan, Sandhya ; core-libs-dev at openjdk.java.net; hotspot compiler > Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions > > On 11/19/18 12:50 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> I'd like to contribute an optimization for GHASH Algorithm using AVX >> Instructions. I have tested this optimization on SKX x86_64 platform >> and it shows ~20-30% performance improvement for larger message sizes >> (for example 8k). >> >> I, smita.kamath at intel.com , Shay >> Gueuron, (shay.gueron at intel.com )and >> Regev Shemy (regev.shemy at intel.com ) are >> contributors to this code. >> >> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >> >> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >> >> For testing the implementation, I have executed TestAESMain.java. I >> have executed Jtreg tests and tested this code on 64 bit Windows and >> Linux platforms. >> >> Please review and let me know if you have any comments. >> >> Thanks and Regards, >> >> Smita >> > > Hi, > > This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not break the sparc intrinsic? > It may work as the code is now since the sparc intrinsic will only use the first two longs in the subkeyHtbl. > > In that same idea, have you consider combining the subkeyH to be the first two of subkeyHtbl for the non-avx operations? It would eliminate an extra two longs per instance. > > Tony > From vladimir.kozlov at oracle.com Sun Dec 2 02:44:09 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 1 Dec 2018 18:44:09 -0800 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <09a1553c-558c-fb67-9609-a544e50db43c@oracle.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <09a1553c-558c-fb67-9609-a544e50db43c@oracle.com> Message-ID: All tests passed. Vladimir On 12/1/18 4:37 PM, Vladimir Kozlov wrote: > I am fine with Hotspot changes. > > But we need to verify changes on all platforms. > I see that aarch64 also supports it in addition to SPARC. > > I will run compiler/codegen/aes/ test to make sure it pass on SPARC but we don't test aarch64. > I let you know testing results when they are done. > > Thanks, > Vladimir > > > On 11/20/18 6:45 PM, Kamath, Smita wrote: >> Hi Tony, >> >> Thanks for your comments. >> >> 1)? This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not >> break the sparc intrinsic? It may work as the code is now since the sparc intrinsic will only use the first two longs >> in the subkeyHtbl. >> Would it be possible to help with this sanity check?? I don't have the required set-up to test this scenario. >> >> 2) I have changed the code so that subkeyH corresponds to the first two entries of subkeyHtbl.? Please find the >> updated webrev link. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >> >> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >> >> Thanks and Regards, >> Smita >> >> >> >> -----Original Message----- >> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >> Sent: Tuesday, November 20, 2018 2:05 PM >> To: Kamath, Smita ; 'Vladimir Kozlov' >> Cc: Viswanathan, Sandhya ; core-libs-dev at openjdk.java.net; hotspot compiler >> >> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions >> >> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>> Instructions. I have tested this optimization on SKX x86_64 platform >>> and it shows ~20-30% performance improvement for larger message sizes >>> (for example 8k). >>> >>> I, smita.kamath at intel.com , Shay >>> Gueuron, (shay.gueron at intel.com )and >>> Regev Shemy (regev.shemy at intel.com ) are >>> contributors to this code. >>> >>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>> >>> For testing the implementation, I have executed TestAESMain.java. I >>> have executed Jtreg tests and tested this code on 64 bit Windows and >>> Linux platforms. >>> >>> Please review and let me know if you have any comments. >>> >>> Thanks and Regards, >>> >>> Smita >>> >> >> Hi, >> >> This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not >> break the sparc intrinsic? >> It may work as the code is now since the sparc intrinsic will only use the first two longs in the subkeyHtbl. >> >> In that same idea, have you consider combining the subkeyH to be the first two of subkeyHtbl for the non-avx >> operations?? It would eliminate an extra two longs per instance. >> >> Tony >> From Alan.Bateman at oracle.com Sun Dec 2 10:13:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 2 Dec 2018 10:13:14 +0000 Subject: jar --verify operation mode checking mrjar validity In-Reply-To: References: Message-ID: <6532d778-6a41-0d7e-60f3-ffda04b44626@oracle.com> On 01/12/2018 08:45, Christian Stein wrote: > Hi, > > jar --create (and --update) perform type API validation checks when used in > combination with --release option. This detects invalid "version overlays" > at package time, where the API doesn't match a previous one. > > Having a jar --verify mode that performs the same checks consuming an > already existing jar file would be useful as most "3rd-party packaging > tools" don't perform those checks. > > A possible work-around could be to explode an existing jar and re-create it > using jar --create... > I think it would be useful to create a list of the popular tools and plugins in the eco system that create or update JAR files and see what their current capabilities are. The addition of modules and MR JARs have extended the JAR format quite a bit in recent years and it's not clear if the eco system has caught up, e.g. if I package a module as a modular JAR with the `jar` tool then it will do the right thing and add/update the ModulePackages class file attribute. It will also do check such as ensuring that the JAR files contains the service provider that the module claims to provide. MR JARs are more complicated, and modular MR JARs more complicated again. Beyond the API validation check that you are asking about, there is also checking that any module-info.class in the versioned section match (API wise) the module-info in the base section. So I agree there may be merit in a -verify like option with the benefit that it helps identify where the build tools or plugins may not be doing the right thing. There may also be merit is seeing if some of these tools or plugins should move to using the jar tool, by way of ToolProvider.findFirst("jar"), or having the jar tool introduce an API (as the exit code and stdout/stderr output might not be sufficient for tools that need fine control). -Alan. From vincent.x.ryan at oracle.com Sun Dec 2 22:54:53 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sun, 2 Dec 2018 22:54:53 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> Message-ID: <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> Thanks for the thorough review. Responses in-line. > On 26 Nov 2018, at 19:49, Roger Riggs wrote: > > Hi, > > Thanks for updating this proposal. Some comments on the javadoc/spec. > > The class name Hex isn't very evocative of its function. > HexFormat would convey a more complete idea as to its function and be similar to > to the existing DecimalFormat and NumberFormat classes though they do not share > any of the APIs or framework. OK > > - The 2nd example using Files.newInputStream is not recommended > since the stream to the file may not be closed. > The recommended form would use try-with-resources. > try (InputStream is = Files.newInputStream(Paths.get("mydata"))) { > Hex.dumpAsStream(is, 64, > (offset, chunk, fromIndex, toIndex) -> > String.format("%d %s", > offset / 64 + 1, > Hex.toPrintableString(chunk, fromIndex, toIndex))) > .forEachOrdered(System.out::println); > } catch (IOException ioe) { > ... > } > The 'forEachOrdered' should not be necessary and may raise questions about why. > if there's no good reason, use 'forEach?. OK > > > - The HEXDUMP_FORMATTER should be explicit about the format it generates. > Though it may declare itself compatible with hexdump(1) it should specify > the format it produces to avoid an external reference that might change unexpectedly. OK > > - toFormattedHexString: > References to the line-separator should be javadoc linked to System#lineSeparator. OK. And maybe shorten this method to simply: toFormattedString ? > > Alternatively, should this class follow the lead of String.align/indent and use > the normalized line terminator "\n" consistently? In which case, it should be explicit. > > Clarify exactly the behavior: > > "If the final chunk is less than 16 +bytes+ then +the result+ is padded with spaces to match the length of the preceding chunks. " > > Only the built-in formatter asserts that every result is the same length. A provided formatter > may not conform. soften "will be" -> "may be" in "the final chunk ?" OK > > - everywhere: "binary buffer" -> "byte buffer" or byte array OK > > - toPrintableString: The ASCII limitation seems quite dated, 8-bit clean is the norm and > except for control characters and 0x7f, the rest of the range is printable in most Locales. > Strict conformance to hexdump is not a requirement. I can see the benefit to including the accented letters > 0x7F but is it really useful to also display graphical and non-printable characters > 0x7F ? > > - dumpAsStream(InputStream) > It is inconsistent (and possibly wrong) that the final chunk may be shorter since the HEXDUMP_FORMATTER > uses the formatter that always pads. (Btw, the implementation appends \n and should be using lineSeparator.) > "If the input is not a multiple of 16 bytes then the final chunk will be shorter than the preceding chunks.? I?ve clarified the language. The final chunk will indeed be shorter but the output 'will be' padded by HEXDUMP_FORMATTER and 'may be' padded when a custom formatter is supplied. > > - dumpAsStream(bytes, from, to, chunk, formatter) > > Can it more explicit about the unchecked exception? > "If an error occurs in the formatter then an unchecked exception will be thrown from the underlying Stream method.? What do you suggest? The formatter may throw any exception and it doesn?t get thrown until the stream is processed. > > - Another thought about the methods returning Stream. > They require a concrete string to be created for each chunk. > There may be some efficiency and flexibility to be gained if formatters can return a CharSequence. > In many cases it would be a string, but it would allow the formatter to return a StringBuilder > that could be used directly without needing to construct a short lived string. Sounds OK but I?ll need to prototype this and get back to you. > > Thanks, Roger > > > p.s. > I wrote code for the use case of formatting bytes in the form that can be compiled with javac. > it took rather more code than I expected but I don't have any specific suggestions. > > > byte[] b = ...; > final String indent = " ".repeat(8); > final StringBuilder sb = new StringBuilder(16 * 5); > sb.append(indent); > > System.out.print(" byte[] bytes = {\n"); > try (ByteArrayInputStream is = new ByteArrayInputStream(b)) { > dumpAsStream(is, 16, (o, c, s, e) -> { > sb.setLength(indent.length()); > for (int i = s; i < e; i++) { > sb.append(c[i]); > sb.append(", "); > } > sb.append(System.lineSeparator()); > return sb.toString(); > }).forEach(s -> System.out.print(s)); > } > System.out.print(" }\n"); > > > On 11/23/2018 09:51 AM, Vincent Ryan wrote: >> Hello, >> >> Please review this proposal for a new API to conveniently generate and display binary data using hexadecimal string representation. >> It supports both bulk and stream operations and it can also generate the well-known hexdump format [1]. >> >> This latest revision addresses review comments provided earlier. >> These include adding methods to support for data supplied in a ByteBuffer, exposing the default formatter implementation as a public >> static and dropping the superfluous 'Hex' term from several method names. >> >> Thanks >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> API: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >> >> >> ____ >> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html > From david.holmes at oracle.com Sun Dec 2 23:14:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Dec 2018 09:14:07 +1000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> Message-ID: This is probably best discussed on net-dev rather than core-libs-dev. Cheers, David On 1/12/2018 2:27 am, Volker Simonis wrote: > On Fri, Nov 30, 2018 at 12:20 PM Steve Groeger wrote: >> >> Hi Goetz, >> >> I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as >> they detected that IPv6 is not enabled and then didnt try and set the IPv6 >> options. > > Not being a network expert either, I think there's two things to > consider here. It seems that IPv6 can be disabled globally (e.g. in > the Linux kernel) or IPv6 can be enabled globally, but not all network > devices supporting it. A quick search revealed that it seems to be > fairly easy to disable IPv6 on a single interface on Linux while still > having IPv6 globally enabled (see > https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux). > @Steve Groeger can you please check if the test still succeeds on > Linux if you only disable IPv6 on the specific interface used by the > test? If it still succeeds, there's probably something to fix on AIX. > If it fails on Linux as well, there may be something to fix in the > test (i.e. to detect that the corresponding interface doesn't support > IPv6) or even in the Java network implementation (i.e. to handle both, > IPv6 and IPv4-only interfaces on an IPv6 enabled system correctly). > > Thank you and best regards, > Volker > >> I am currently unable to disable IPv6 on my AIX box to test this but would >> assume it would also work as the code checks to see whether IPv6 is >> enabled and doesnt try and set the IPV6 options. >> It seems the issue with the tests failing seems to be, if IPv6 is enabled >> but the interface doesn't have an IPv6 address associated with it, as in >> your case here: >> >> bash-4.3$ ifconfig -a >> en0: >> flags=1e084863,480 >> inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx >> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >> lo0: >> flags=e08084b,c0 >> inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx >> inet6 ::1%1/0 >> tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 >> >> where you can see that the en0 interface has an inet address associated >> but doesnt have an inet6 address associated. >> I can see that IPv6 is enabled as the lo0 interface has an inet6 address >> (pointing to localhost) >> >> As I stated below, my AIX system was configured in a similar way to yours >> and the tests failed. When I was able to add an inet6 address to en0, >> everything works correctly. >> NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to >> add the inet6 address to my en0 interface. After that all tests worked. >> >> So I think the tests are working as expected, but the AIX system is not >> configured correctly, but I would like someone else to confirm this. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: "Lindenmaier, Goetz" >> To: Steve Groeger , ppc-aix-port-dev >> >> Date: 30/11/2018 10:18 >> Subject: RE: 8207404: MulticastSocket tests failing on Aix >> >> >> >> i Steve, >> >> thanks for looking at this issue. >> >>> Should these tests work without having IPV6 configured on the interface? >> In general, tests should not show errors if a system does not meet >> the requirements for the test. In such cases the test should >> be skipped somehow. Maybe only a test fix is needed. >> >> Can you check on a non-aix machine without ipv6 whether the test >> passes? >> >>> Goetz, do you have IPV6 configured on the machine you were running these >>> tests on? >> This is our test machine: >> >> bash-4.3$ ifconfig -a >> en0: >> flags=1e084863,480 >> inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx >> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >> lo0: >> flags=e08084b,c0 >> inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx >> inet6 ::1%1/0 >> tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 >> >> I think this message should be posted to core-libs-dev, too. That's also >> the list where a potential fix needs to be reviewed. >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Steve Groeger >>> Sent: Donnerstag, 29. November 2018 17:07 >>> To: ppc-aix-port-dev >>> Cc: Lindenmaier, Goetz >>> Subject: 8207404: MulticastSocket tests failing on Aix >>> >>> Hi All, >>> >>> I have been having a look at this issue: >>> >> https://bugs.openjdk.java.net/browse/JDK-8207404 >> >>> < >> https://bugs.openjdk.java.net/browse/JDK-8207404 >>> >>> which was raised by Goetz Lindenmaier. >>> >>> When I ran the tests on my AIX system I got the same results as Goetz >> listed >>> in the issue. >>> >>> Looking at the failure I noticed that it was failing on a setsockopt >> call in the >>> native code in >>> the PlainDatagramSocketImpl.c file which returned a EADDRNOTAVAIL (Can't >>> assign requested address) >>> >>> Looking at my network configuration using "ifconfig -a", I noticed that >> my >>> interface "en0" which the test >>> was trying to use did not have an inet6 address configured (see below - >> some >>> addresses have been obfuscated with x's). >>> >>> en0: >>> flags=1e084863,14c0>> CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> >>> inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx >>> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >>> >>> configuring the IPV6 on my AIX box I then had a inet6 address configured >> for >>> en0 >>> >>> en0: >>> flags=1e084863,14c0>> CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> >>> inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx >>> inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 >>> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >>> >>> with this configured the MulticastSocket tests all passed. >>> >>> Should these tests work without having IPV6 configured on the interface? >>> >>> Goetz, do you have IPV6 configured on the machine you were running these >>> tests on? >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, UK >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >> >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Mon Dec 3 00:11:06 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Dec 2018 10:11:06 +1000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> Message-ID: Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: > Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). > > Hi David, > Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. > In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David > #ifdef _MSC_VER // Windows > #define gmtime_r(t, s) gmtime(t) > #endif > > Regards > Patrick > > -----Original Message----- > From: Florian Weimer > Sent: Thursday, November 29, 2018 8:02 PM > To: David Holmes > Cc: Patrick Zhang ; jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path > > * David Holmes: > >> This should really be being discussed on core-libs-dev. > > Okay, moving the conversation. > >>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp >>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 >>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 >>> @@ -415,9 +415,7 @@ >>> ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>> } >>> -#ifdef _REENTRANT // solaris >>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>> +#if !defined(_REENTRANT) // linux >>> #define gmtime_r(t, s) gmtime(t) >>> #endif >>> /* >> >> Under the theme "two wrongs don't make a right" the use of _REENTRANT >> here is totally inappropriate AFAICS. It seems to be a misguided >> attempt at determining whether we need the thread-safe gmtime_r or not >> - and the answer to that should always be yes IMHO. >> >> We define _REENTRANT for: >> - linux >> - gcc >> - xlc >> >> So the original code will define: >> >> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >> >> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >> >> But Solaris has gmtime_r anyway. So the existing code seems a really >> convoluted hack. AFAICS we have gmtime_r everywhere but Windows (where >> gmtime is already thread-safe). So it seems to me that all we should >> need here is: >> >> -#ifdef _REENTRANT // solaris >> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >> +#ifdef _MSC_VER // Windows >> #define gmtime_r(t, s) gmtime(t) >> #endif > > That looks much cleaner. > > Thanks, > Florian > From amaembo at gmail.com Mon Dec 3 05:27:35 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 3 Dec 2018 12:27:35 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() Message-ID: Hello! Please review and sponsor the optimized implementation of Collections.nCopies().hashCode(): https://bugs.openjdk.java.net/browse/JDK-8214687 http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ Previous discussion thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056843.html Thanks to Zheka Kozlov for the original proposal. Also thanks to Ivan Gerasimov for the simplification idea: (x & 0x8000_0000) != 0 => x < 0. With best regards, Tagir Valeev From jai.forums2013 at gmail.com Mon Dec 3 06:24:33 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 3 Dec 2018 11:54:33 +0530 Subject: jar --verify operation mode checking mrjar validity In-Reply-To: <6532d778-6a41-0d7e-60f3-ffda04b44626@oracle.com> References: <6532d778-6a41-0d7e-60f3-ffda04b44626@oracle.com> Message-ID: <34d4fa40-b6fa-0b25-e66f-b6eff2ca774e@gmail.com> (resending using the email id I'm subscribed by, in this list) On 02/12/18 3:43 PM, Alan Bateman wrote: > On 01/12/2018 08:45, Christian Stein wrote: >> Hi, >> >> jar --create (and --update) perform type API validation checks when >> used in >> combination with --release option. This detects invalid "version >> overlays" >> at package time, where the API doesn't match a previous one. >> >> Having a jar --verify mode that performs the same checks consuming an >> already existing jar file would be useful as most "3rd-party packaging >> tools" don't perform those checks. >> >> A possible work-around could be to explode an existing jar and >> re-create it >> using jar --create... >> > I think it would be useful to create a list of the popular tools and > plugins in the eco system that create or update JAR files and see what > their current capabilities are. The addition of modules and MR JARs > have extended the JAR format quite a bit in recent years and it's not > clear if the eco system has caught up, FWIW - We (Apache Ant) haven't yet caught up with many of these changes/enhancements, both in what the Java tools (like jar, jmod etc...) have introduced[1][2][3], nor in runtime aspects like multi-release jars[4]. It's going to take us a while to catch up with these current new enhancements. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62789 [2] https://www.mail-archive.com/user at ant.apache.org/msg42796.html [3] https://www.mail-archive.com/dev at ant.apache.org/msg47740.html [4] https://bz.apache.org/bugzilla/show_bug.cgi?id=62952 -Jaikiran From amaembo at gmail.com Mon Dec 3 06:38:59 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 3 Dec 2018 13:38:59 +0700 Subject: Optimized version of CopiesList.hashCode() In-Reply-To: <92419515-1a9a-576a-aa49-cbf82d6bf780@oracle.com> References: <92419515-1a9a-576a-aa49-cbf82d6bf780@oracle.com> Message-ID: Thanks, Stuart, Martin. I've created an issue and posted a webrev here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057038.html > You're optimizing hashCode to be O(log(N)) instead of O(N)? Yes. On Sat, Dec 1, 2018 at 6:38 AM Stuart Marks wrote: > > > > On 11/30/18 8:52 AM, Martin Buchholz wrote: > > On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev wrote: > > > >> I can file an issue and create a webrev, but I still need a sponsor > >> and review for such change. Martin, can you help with this? > > > > As usual, I'm only half paying attention, but I can be your shepherd. > > (I'm still digging out from my backlog. Perhaps Martin and I are competing for > who has less time....) > > A quick process check: are the proper OCAs in place? [1] > > If Zheka is authoring, he'll need to have signed the OCA. (Or he'll need to be > doing this work on behalf of a company or organization that has signed the OCA.) > > If Tagir is authoring, he's good, since he's already signed the OCA. > > Zheka, even if you're not authoring this changeset, if you intend to contribute > to OpenJDK in the future, you might want to work on an OCA. It's not a gigantic > bit of bureaucracy, but it does take a few days, and you'll probably want to > avoid lack of an OCA blocking a future contribution. > > Otherwise, thanks and carry on. > > s'marks > > > > > [1] https://www.oracle.com/technetwork/community/oca-486395.html From amaembo at gmail.com Mon Dec 3 06:41:47 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 3 Dec 2018 13:41:47 +0700 Subject: Optimized version of CopiesList.hashCode() In-Reply-To: <90d487cd-e91b-1b78-e931-1ca242ed8ec5@oracle.com> References: <90d487cd-e91b-1b78-e931-1ca242ed8ec5@oracle.com> Message-ID: Hello, Ivan! > The check > if (((n << i) & 0x8000_0000) != 0) { > might be written as > if ((n << i) < 0 ) { > to save one bit-wise operation and avoid using extra constant. Nice catch, thanks! When I switch my mind to bitwise thinking mode, I forget about normal arithmetic properties like sign :-) Webrev is posted: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057038.html With best regards Tagir Valeev. From ivan.gerasimov at oracle.com Mon Dec 3 07:23:02 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 2 Dec 2018 23:23:02 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: Message-ID: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> Thank you Tagir! I think your solution is quite clever, and the fix looks good. While we are here: Would it make sense to use CopiesList only for n > 0, and make nCopies() and nCopies().subList() return Collection.emptyList() otherwise? This would allow to remove the check for n == 0 in a couple of places. Also an unnecessary reference to the `element` wouldn't be kept. With kind regards, Ivan On 12/2/18 9:27 PM, Tagir Valeev wrote: > Hello! > > Please review and sponsor the optimized implementation of > Collections.nCopies().hashCode(): > https://bugs.openjdk.java.net/browse/JDK-8214687 > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ > > Previous discussion thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056843.html > > Thanks to Zheka Kozlov for the original proposal. Also thanks to Ivan > Gerasimov for the simplification idea: (x & 0x8000_0000) != 0 => x < > 0. > > With best regards, > Tagir Valeev > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Mon Dec 3 08:11:36 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 3 Dec 2018 00:11:36 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> Message-ID: <7cf69811-c3bd-062d-aee3-a439535431d1@oracle.com> Also, I believe it makes sense to override CopiesList.equals() to at least optimize the case when the other list is a CopiesList too. With kind regards, Ivan On 12/2/18 11:23 PM, Ivan Gerasimov wrote: > Thank you Tagir! > > I think your solution is quite clever, and the fix looks good. > > While we are here: Would it make sense to use CopiesList only for n > > 0, and make nCopies() and nCopies().subList() return > Collection.emptyList() otherwise? > > This would allow to remove the check for n == 0 in a couple of places. > Also an unnecessary reference to the `element` wouldn't be kept. > > With kind regards, > Ivan > > > On 12/2/18 9:27 PM, Tagir Valeev wrote: >> Hello! >> >> Please review and sponsor the optimized implementation of >> Collections.nCopies().hashCode(): >> https://bugs.openjdk.java.net/browse/JDK-8214687 >> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ >> >> Previous discussion thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056843.html >> >> >> Thanks to Zheka Kozlov for the original proposal. Also thanks to Ivan >> Gerasimov for the simplification idea: (x & 0x8000_0000) != 0 => x < >> 0. >> >> With best regards, >> Tagir Valeev >> > -- With kind regards, Ivan Gerasimov From orionllmain at gmail.com Mon Dec 3 08:42:37 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Mon, 3 Dec 2018 15:42:37 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> Message-ID: > Would it make sense to use CopiesList only for n > 0 This can break serialization. When CopiesList(0, e) is serialized and deserialized back, it will be in an invalid state. > I believe it makes sense to override CopiesList.equals() Also: contains(), iterator(), listIterator() ??, 3 ???. 2018 ?. ? 14:19, Ivan Gerasimov : > Thank you Tagir! > > I think your solution is quite clever, and the fix looks good. > > While we are here: Would it make sense to use CopiesList only for n > > 0, and make nCopies() and nCopies().subList() return > Collection.emptyList() otherwise? > > This would allow to remove the check for n == 0 in a couple of places. > Also an unnecessary reference to the `element` wouldn't be kept. > > With kind regards, > Ivan > > > On 12/2/18 9:27 PM, Tagir Valeev wrote: > > Hello! > > > > Please review and sponsor the optimized implementation of > > Collections.nCopies().hashCode(): > > https://bugs.openjdk.java.net/browse/JDK-8214687 > > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ > > > > Previous discussion thread: > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056843.html > > > > Thanks to Zheka Kozlov for the original proposal. Also thanks to Ivan > > Gerasimov for the simplification idea: (x & 0x8000_0000) != 0 => x < > > 0. > > > > With best regards, > > Tagir Valeev > > > > -- > With kind regards, > Ivan Gerasimov > > From amaembo at gmail.com Mon Dec 3 11:32:25 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 3 Dec 2018 18:32:25 +0700 Subject: RFR - JDK-8203442 String::transform (Code Review) In-Reply-To: <411491802.1433014.1543616582400.JavaMail.zimbra@u-pem.fr> References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com> <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com> <8b3c5d6d-b7b3-d1fb-6afe-2640e0f0b23f@gmail.com> <22754DF6-855F-4DE4-BE68-14379EFD822F@oracle.com> <411491802.1433014.1543616582400.JavaMail.zimbra@u-pem.fr> Message-ID: +1 to Stephen and Remi. I personally see no reason to hurry up with this API: unlike trimming/indenting methods this one doesn't look crucial for raw string literals. I don't see that this method blocks anything else. > For info, AWS SDK v2 has chosen applyMutation() for a similar concept: Unfortunately this name serves well only for mutable objects, like builders. For String it looks confusing. With best regards, Tagir Valeev. On Sat, Dec 1, 2018 at 5:27 AM Remi Forax wrote: > > I fully agree with Stephen. > > R?mi > > ----- Mail original ----- > > De: "Stephen Colebourne" > > ?: "core-libs-dev" > > Envoy?: Vendredi 30 Novembre 2018 12:06:23 > > Objet: Re: RFR - JDK-8203442 String::transform (Code Review) > > > I see from Twitter (!!!) that this has been pushed. This appears to have > > happened without this thread coming to a clear conclusion, particularly wrt > > criticism of transform() as a suitable method name in the broader context. > > > > I also do not think that the code review was completed correctly and in > > public, which I find concerning. > > > > The two public threads are: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html > > > > The last webrev had the name map() and no further webrev was published that > > I can see. I can see no explicit public approvals of the change from > > reviewers. And plenty of concern about the method name, especially map() > > but also transform(). > > > > While I'm well aware of the danger of public bikeshedding, I also think > > that adding methods to `String` deserves more care than this has been > > shown. In my view the change should be reverted, and retargetted to Java 13 > > to allow for a proper conclusion to the discussion. > > > > For info, AWS SDK v2 has chosen applyMutation() for a similar concept: > > https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/utils/builder/SdkBuilder.html#applyMutation-java.util.function.Consumer- > > > > Stephen > > > > > > On Wed, 14 Nov 2018, 14:18 Stephen Colebourne > > >> On Tue, 13 Nov 2018 at 15:44, Brian Goetz wrote: > >> > Yes, we know :) But we don?t have any current plans to do that, nor > >> use-site extension methods, nor does it seem likely to come to the top of > >> the language priority list very soon. So its not a choice between |> and > >> .transform(); it?s a choice between transform() and nothing. Picking > >> transform() seems pretty good here. > >> > > >> > Stephen raised the issue of a ?broader context?; indeed, the intention > >> of adding a transform() method here was that it would be feasible to add to > >> other types for which it was suitable. String is an obvious candidate for > >> ?do it first?, but this is within a broader context. > >> > >> I'd be more comforted if there was a commitment to add the method to > >> Stream and Optional in Java 12 or 13. > >> > >> I also agree with Remi that `transform()` is a poor name for Stream, > >> and thus it is a poor name for String. I doubt there is a perfect > >> name, process() or apply() seem like good candidates. > >> > >> Stephen From nishit.jain at oracle.com Mon Dec 3 12:22:18 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 3 Dec 2018 17:52:18 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <6bf5dd71-471f-59b0-5ba8-5e9ce4e19dcd@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> <60acf63c-b9f8-49f2-e04d-4484a5327982@oracle.com> <6bf5dd71-471f-59b0-5ba8-5e9ce4e19dcd@oracle.com> Message-ID: <88571ad9-dd69-9d08-6a3d-e5e884a54ffe@oracle.com> Thanks Roger, Updated the webrev based on thebelow suggested changes and some clean up. http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.05/ On 01-12-2018 01:03, Roger Riggs wrote: > Hi Nishit, > > Some comments, a couple of possible bugs and several? performance > related issues > could be deferred. Both formatting and parsing seem to be quite > heavyweight > due to looping and combinatorics. > > > CompactNumberFormat.java > > > 661, 727, 1507: Is there a reason to convert the divisor to a string > and then re-parse it to create a new BigDecimal? > ??????? (IntelliJ observes that divide is called without a rounding > argument.) > ??????? Given that the divisors are all powers of 10 and the digit > list is a base 10 set of digits > ??????? it seems more efficient to just move the decimal point then to > do the math. > ??????? BTW, the divisor.toString() is preferred over concat with "".? > (looks like a hack). > > ??????? It would be more efficient to write two methods that would > pass the Number > ??????? and return a BigInteger or BigDecimal by dispatching on the > concrete type and > ??????? using the appropriate constructor. Changed concatenation with toString() and added a rounding parameter, but not getting the benefit of having two methods and returning respective concrete type using constructors. I didn't get the point of having two methods. Can you please elaborate? > > 781:? @param prefix - the parameter name is suffix > > 804: move the int start = inside the if. > > 826:? expandAffix can be more efficient if tests the pattern for the > presence of QUOTE > ??????? and returns the pattern if the QUOTE is not present.? That > would be the most common case. > > 914: Reduce the number of compares by reordering to: > ??????? if number > currentValue; multiply and continue > ??????? if number < currentValue break; > ??????? else ==; assign matched index and break; > > ??????? In the normal case, there will be only one compare in the loop > until it is to exit. > > 1109:? IntelliJ observes that within the case QUOTE, the if (ch == > QUOTE) is always true > ????? so the if is redundant. OK. > > 1205:? It looks odd to prepend two characters '- to the prefix. Is the > single quote correct? > ????? Where's the closing quote if so. It is to specify that the minus sign is a special character, which needs to be replaced with its localized equivalent at the time of formatting. Internally, there is a difference between a "minus sign prefix with a single quote" and a "minus sign" (it depends on how user specify the pattern), because the later one is considered as a literal and should be used exactly same in the formatted output, but the one prefixed with a single quote is replaced with its localized symbol using DecimalFormatSymbols.getMinusSign(). > 1394: matchedPosPrefix.length() is compared to negativePrefix.length(). > ????? That's an unusual mixing of positive and negative! Please re-check. Yes, it was a mistake. > > 1363:? Can there be an early exit from this loop if one of the > prefixes is identified? > ????? The pattern of comparing for a prefix/suffix and the length > might warrant > ????? creating a private method to reduce the repetitive parts of the > code. I had thought about it, but it was difficult unless the whole list of affixes are traversed, because there is always a chance to get longer affix later in the list. I thought to sort the lists based on the length and do the match, but in that case indexes get disordered across lists (divisor, prefix, suffix, compact patterns), and computation will become more complicated. Updated the code by moving the repetitive parts in the loop to private methods. > > 1593: extra space between "- ("; should be the same style as 1591 > > 1627, 1363: Is an early exit from this loop possible? > ?????? or a quick comparison to avoid the regionMatches. > ?????? Do the regionMatches *only if* the prefix/suffix is longer than > the suffix already compared? Yes, I think this can be done. Updated. > > 1721:? IntelliJ observes that if (gotNeg) is redundant since 1708 > rules out them being both true or both false. Updated Regards, Nishit Jain > > Thanks, Roger > >> >> On 11/28/18 3:46 AM, Nishit Jain wrote: >>> Thanks Naoto, >>> >>> Updated. >>> >>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ >>> > From claes.redestad at oracle.com Mon Dec 3 16:02:53 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 3 Dec 2018 17:02:53 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES Message-ID: Hi, initializing java.util.jar.Attributes.Name. executes ~20k bytecodes setting up and eagerly calculating case-insensitive hash codes for a slew of Name objects. By archiving the resulting set of Names and initializing public constants from the archived map, we reduce time spent starting up (Name. drops to 368 executed bytecodes) and improve the footprint sharing effect of using CDS: http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ Testing: tier1-2 running Verified a 1-2.5ms startup improvement on java -jar Hello.jar - significant and stable reduction in instruction count, branches and branch misses - only adds ~1.1Kb to the dumped CDS archive Thanks! /Claes From Alan.Bateman at oracle.com Mon Dec 3 16:06:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Dec 2018 16:06:59 +0000 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: <49f05954-fab6-3c0d-229a-37a10fb2f19f@oracle.com> On 03/12/2018 16:02, Claes Redestad wrote: > Hi, > > initializing java.util.jar.Attributes.Name. executes ~20k > bytecodes setting up and eagerly calculating case-insensitive hash > codes for a slew of Name objects. > > By archiving the resulting set of Names and initializing public > constants from the archived map, we reduce time spent starting up > (Name. drops to 368 executed bytecodes) and improve the > footprint sharing effect of using CDS: > > http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ > > Testing: tier1-2 running > > Verified a 1-2.5ms startup improvement on java -jar Hello.jar > - significant and stable reduction in instruction count, branches and > branch misses > - only adds ~1.1Kb to the dumped CDS archive This looks okay to me but the changes remind me that there are several attributes name in KNOWN_NAMES are should probably be removed as they aren't defined by Java SE or the JDK. -Alan From claes.redestad at oracle.com Mon Dec 3 16:50:29 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 3 Dec 2018 17:50:29 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: <49f05954-fab6-3c0d-229a-37a10fb2f19f@oracle.com> References: <49f05954-fab6-3c0d-229a-37a10fb2f19f@oracle.com> Message-ID: On 2018-12-03 17:06, Alan Bateman wrote: > > > On 03/12/2018 16:02, Claes Redestad wrote: >> Hi, >> >> http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ >> > This looks okay to me but the changes remind me that there are several > attributes name in KNOWN_NAMES are should probably be removed as they > aren't defined by Java SE or the JDK. Thanks, Alan! The extra Names added to KNOWN_NAMES was my doing, and it was based on commonly used attributes in Jar file manifests scanned from a set commonly used applications as an alternative to building up a Name cache dynamically (which is frought with other perils). The chose extras gave a marginal but measurable improvement in startup to a wide array of applications as a result, and their inclusion is strictly an internal implementation detail. If you insist on having them removed I won't object, but I believe it's an harmless optimization. /Claes From brian.burkhalter at oracle.com Mon Dec 3 17:03:50 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Dec 2018 09:03:50 -0800 Subject: Fwd: 6516099: InputStream.skipFully(int k) to skip exactly k bytes References: <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: <87CCE560-6F03-4657-922B-E65C12E133DF@oracle.com> ping ... > Begin forwarded message: > > From: Brian Burkhalter > Subject: Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes > Date: November 30, 2018 at 11:55:08 AM PST > To: Java Core Libs > > Loathe though I am to resurrect this thread, one problem arose after testing with assertions enabled which I had neglected previously to do. A few small changes to test/jdk/java/io/InputStream/Skip.java are required. A delta versus webrev.08 (link at bottom) is at > > http://cr.openjdk.java.net/~bpb/6516099/webrev.08-delta/ > > The changes are as follows (line numbers in the new version): > > 1. L154 > > in.setState(-1, 100); > - dotestExact(in, pos, streamLength, n, true, false); > + dotestExact(in, pos, streamLength, -1, true, false); > > Pass ?-1? as the number to skip instead of ?n.? > > 2. L159 > > in.setState(n + 1, 100); > dotestExact(in, pos, streamLength, n, true, false); > + pos += n + 1; > > Update the test-tracked position according to the number actually skipped, which is ?n + 1? although only ?n? bytes were requested. This sub-test causes the internal call to ?skip()? to be ?skip(n+1)? which will return ?n+1? which intentionally provokes an IOException and leaves the stream in an inconsistent state as documented. The call to ?skip(n+1)? does however really skip ?n+1? bytes so the test-tracked position must be updated accordingly. > > 3. L214 > > - public long position() { return readctr == endoffile ? EOF : readctr; } > + public long position() { return readctr; } > > The position should be returning the actual offset which for EOF is the length of the stream, not -1. > > With the foregoing changes the test passes. > > Thanks, > > Brian > >> On Nov 28, 2018, at 9:51 AM, Daniel Fuchs wrote: >> >> Looks good to me Brian. >> >> I never knew whether positive meant >= 0 or > 0 anyway ;-) >> >> best regards, >> >> -- daniel >> >> On 28/11/2018 17:38, Brian Burkhalter wrote: >>> >>> http://cr.openjdk.java.net/~bpb/6516099/webrev.08/ > From daniel.fuchs at oracle.com Mon Dec 3 17:27:44 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 3 Dec 2018 17:27:44 +0000 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> References: <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> <0CA96647-3B5B-41CB-A368-86F5A957C73D@oracle.com> <2864b759-b7a3-1bbc-973c-239d96340de1@oracle.com> <48FF6FE1-1E16-468C-923A-A35CC9C6E88A@oracle.com> <5A44B287-CC4F-4904-ACE2-1621658BCE81@oracle.com> <9d34f98b-9ac2-2d95-896a-3ea36c28cc6f@oracle.com> <35EE3661-242A-48DD-8A5B-10B648E854C1@oracle.com> <45fac915-2dac-bd2d-0f3a-0409e11fe947@oracle.com> <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: Hi Brian, Looks good to me, though I don't understand the change at line 214: The comment says: 152 // skip(n) returns negative value: IOE but if you pass -1 - you're no longer calling skip(n)? best regards, -- daniel On 30/11/2018 19:55, Brian Burkhalter wrote: > Loathe though I am to resurrect this thread, one problem arose after testing with assertions enabled which I had neglected previously to do. A few small changes to test/jdk/java/io/InputStream/Skip.java are required. A delta versus webrev.08 (link at bottom) is at > > http://cr.openjdk.java.net/~bpb/6516099/webrev.08-delta/ > > The changes are as follows (line numbers in the new version): > > 1. L154 > > in.setState(-1, 100); > - dotestExact(in, pos, streamLength, n, true, false); > + dotestExact(in, pos, streamLength, -1, true, false); > > Pass ?-1? as the number to skip instead of ?n.? > > 2. L159 > > in.setState(n + 1, 100); > dotestExact(in, pos, streamLength, n, true, false); > + pos += n + 1; > > Update the test-tracked position according to the number actually skipped, which is ?n + 1? although only ?n? bytes were requested. This sub-test causes the internal call to ?skip()? to be ?skip(n+1)? which will return ?n+1? which intentionally provokes an IOException and leaves the stream in an inconsistent state as documented. The call to ?skip(n+1)? does however really skip ?n+1? bytes so the test-tracked position must be updated accordingly. > > 3. L214 > > - public long position() { return readctr == endoffile ? EOF : readctr; } > + public long position() { return readctr; } > > The position should be returning the actual offset which for EOF is the length of the stream, not -1. > > With the foregoing changes the test passes. > > Thanks, > > Brian > >> On Nov 28, 2018, at 9:51 AM, Daniel Fuchs wrote: >> >> Looks good to me Brian. >> >> I never knew whether positive meant >= 0 or > 0 anyway ;-) >> >> best regards, >> >> -- daniel >> >> On 28/11/2018 17:38, Brian Burkhalter wrote: >>> >>> http://cr.openjdk.java.net/~bpb/6516099/webrev.08/ > From daniel.fuchs at oracle.com Mon Dec 3 17:34:32 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 3 Dec 2018 17:34:32 +0000 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> <0CA96647-3B5B-41CB-A368-86F5A957C73D@oracle.com> <2864b759-b7a3-1bbc-973c-239d96340de1@oracle.com> <48FF6FE1-1E16-468C-923A-A35CC9C6E88A@oracle.com> <5A44B287-CC4F-4904-ACE2-1621658BCE81@oracle.com> <9d34f98b-9ac2-2d95-896a-3ea36c28cc6f@oracle.com> <35EE3661-242A-48DD-8A5B-10B648E854C1@oracle.com> <45fac915-2dac-bd2d-0f3a-0409e11fe947@oracle.com> <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: typo in my previous mail: On 03/12/2018 17:27, Daniel Fuchs wrote: > Hi Brian, > > Looks good to me, though I don't understand the change > at line 214: ^^^ 154 sorry for the noise and confusion... -- daniel > > The comment says: > > 152???????? // skip(n) returns negative value: IOE > > but if you pass -1 - you're no longer calling skip(n)? > > best regards, > > -- daniel From brian.burkhalter at oracle.com Mon Dec 3 17:39:32 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Dec 2018 09:39:32 -0800 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> <0CA96647-3B5B-41CB-A368-86F5A957C73D@oracle.com> <2864b759-b7a3-1bbc-973c-239d96340de1@oracle.com> <48FF6FE1-1E16-468C-923A-A35CC9C6E88A@oracle.com> <5A44B287-CC4F-4904-ACE2-1621658BCE81@oracle.com> <9d34f98b-9ac2-2d95-896a-3ea36c28cc6f@oracle.com> <35EE3661-242A-48DD-8A5B-10B648E854C1@oracle.com> <45fac915-2dac-bd2d-0f3a-0409e11fe947@oracle.com> <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: HI Daniel, That does look messed up. Thanks for pointing it out. I will investigate. Thanks, Brian > On Dec 3, 2018, at 9:27 AM, Daniel Fuchs wrote: > > Looks good to me, though I don't understand the change > at line 154: > > The comment says: > > 152 // skip(n) returns negative value: IOE > > but if you pass -1 - you're no longer calling skip(n)? From t.linkowski at gmail.com Mon Dec 3 17:50:19 2018 From: t.linkowski at gmail.com (Tomasz Linkowski) Date: Mon, 3 Dec 2018 18:50:19 +0100 Subject: RFR - JDK-8203442 String::transform (Code Review) In-Reply-To: References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com> <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com> <8b3c5d6d-b7b3-d1fb-6afe-2640e0f0b23f@gmail.com> <22754DF6-855F-4DE4-BE68-14379EFD822F@oracle.com> <411491802.1433014.1543616582400.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, My 2 cents: 1) I agree that `String.map` is a really unfortunate name - Peter explained it very well! I'd rather wait than have `String.map`. 2) I absolutely agree that `String`, `Stream`, and `Optional` should share the name. 3) I prefer `Stream.transform` to `Stream.chain` but I understand it might be confusing to newbies. BTW. Stream-like `transform` has already been used by Lukas Eder in his `Seq`: https://www.jooq.org/products/jOO ?/javadoc/0.9.14/org/jooq/lambda/Seq.html#transform-java.util.function.Function- 4) I'm not convinced by `asInputTo` (too many words) nor by `applyMutation` (confusing, like Tagir said). On a side note: regardless of the name, I bet we'll see some `string.transform(String::toLowerCase)` or `stream.chain(s->s.map(mapper))` :) Regards, Tomasz Linkowski On Mon, Dec 3, 2018 at 12:32 PM Tagir Valeev wrote: > +1 to Stephen and Remi. I personally see no reason to hurry up with > this API: unlike trimming/indenting methods this one doesn't look > crucial for raw string literals. I don't see that this method blocks > anything else. > > > For info, AWS SDK v2 has chosen applyMutation() for a similar concept: > > Unfortunately this name serves well only for mutable objects, like > builders. For String it looks confusing. > > With best regards, > Tagir Valeev. > On Sat, Dec 1, 2018 at 5:27 AM Remi Forax wrote: > > > > I fully agree with Stephen. > > > > R?mi > > > > ----- Mail original ----- > > > De: "Stephen Colebourne" > > > ?: "core-libs-dev" > > > Envoy?: Vendredi 30 Novembre 2018 12:06:23 > > > Objet: Re: RFR - JDK-8203442 String::transform (Code Review) > > > > > I see from Twitter (!!!) that this has been pushed. This appears to > have > > > happened without this thread coming to a clear conclusion, > particularly wrt > > > criticism of transform() as a suitable method name in the broader > context. > > > > > > I also do not think that the code review was completed correctly and in > > > public, which I find concerning. > > > > > > The two public threads are: > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html > > > > > > The last webrev had the name map() and no further webrev was published > that > > > I can see. I can see no explicit public approvals of the change from > > > reviewers. And plenty of concern about the method name, especially > map() > > > but also transform(). > > > > > > While I'm well aware of the danger of public bikeshedding, I also think > > > that adding methods to `String` deserves more care than this has been > > > shown. In my view the change should be reverted, and retargetted to > Java 13 > > > to allow for a proper conclusion to the discussion. > > > > > > For info, AWS SDK v2 has chosen applyMutation() for a similar concept: > > > > https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/utils/builder/SdkBuilder.html#applyMutation-java.util.function.Consumer- > > > > > > Stephen > > > > > > > > > On Wed, 14 Nov 2018, 14:18 Stephen Colebourne wrote: > > > > > >> On Tue, 13 Nov 2018 at 15:44, Brian Goetz > wrote: > > >> > Yes, we know :) But we don?t have any current plans to do that, nor > > >> use-site extension methods, nor does it seem likely to come to the > top of > > >> the language priority list very soon. So its not a choice between |> > and > > >> .transform(); it?s a choice between transform() and nothing. Picking > > >> transform() seems pretty good here. > > >> > > > >> > Stephen raised the issue of a ?broader context?; indeed, the > intention > > >> of adding a transform() method here was that it would be feasible to > add to > > >> other types for which it was suitable. String is an obvious > candidate for > > >> ?do it first?, but this is within a broader context. > > >> > > >> I'd be more comforted if there was a commitment to add the method to > > >> Stream and Optional in Java 12 or 13. > > >> > > >> I also agree with Remi that `transform()` is a poor name for Stream, > > >> and thus it is a poor name for String. I doubt there is a perfect > > >> name, process() or apply() seem like good candidates. > > >> > > >> Stephen > -- Pozdrawiam, Tomasz Linkowski From jaikiran at apache.org Mon Dec 3 06:19:55 2018 From: jaikiran at apache.org (Jaikiran Pai) Date: Mon, 3 Dec 2018 11:49:55 +0530 Subject: jar --verify operation mode checking mrjar validity In-Reply-To: <6532d778-6a41-0d7e-60f3-ffda04b44626@oracle.com> References: <6532d778-6a41-0d7e-60f3-ffda04b44626@oracle.com> Message-ID: <1d809357-5597-0a29-1408-19dcab7ffe7c@apache.org> On 02/12/18 3:43 PM, Alan Bateman wrote: > On 01/12/2018 08:45, Christian Stein wrote: >> Hi, >> >> jar --create (and --update) perform type API validation checks when >> used in >> combination with --release option. This detects invalid "version >> overlays" >> at package time, where the API doesn't match a previous one. >> >> Having a jar --verify mode that performs the same checks consuming an >> already existing jar file would be useful as most "3rd-party packaging >> tools" don't perform those checks. >> >> A possible work-around could be to explode an existing jar and >> re-create it >> using jar --create... >> > I think it would be useful to create a list of the popular tools and > plugins in the eco system that create or update JAR files and see what > their current capabilities are. The addition of modules and MR JARs > have extended the JAR format quite a bit in recent years and it's not > clear if the eco system has caught up, FWIW - We (Apache Ant) haven't yet caught up with many of these changes/enhancements, both in what the Java tools (like jar, jmod etc...) have introduced[1][2][3], nor in runtime aspects like multi-release jars[4]. It's going to take us a while to catch up with these current new enhancements. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62789 [2] https://www.mail-archive.com/user at ant.apache.org/msg42796.html [3] https://www.mail-archive.com/dev at ant.apache.org/msg47740.html [4] https://bz.apache.org/bugzilla/show_bug.cgi?id=62952 -Jaikiran From andrewluotechnologies at outlook.com Mon Dec 3 19:06:21 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Mon, 3 Dec 2018 19:06:21 +0000 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> Message-ID: CopiesList is private anyways, so are you suggesting that someone might call nCopies(0) in a previous version of the JDK, serialize the return value, and then unserialize in a later version of the JRE? Is this even a supported use case (serialization/deserialization of JRE classes across versions)? It was always my understanding that you can only unserialize JRE classes of the same version, since the internal class definition can change at any time... Thanks, -Andrew -----Original Message----- From: core-libs-dev On Behalf Of Zheka Kozlov Sent: Monday, December 3, 2018 12:43 AM To: Ivan Gerasimov Cc: core-libs-dev Subject: Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() > Would it make sense to use CopiesList only for n > 0 This can break serialization. When CopiesList(0, e) is serialized and deserialized back, it will be in an invalid state. > I believe it makes sense to override CopiesList.equals() Also: contains(), iterator(), listIterator() ??, 3 ???. 2018 ?. ? 14:19, Ivan Gerasimov : > Thank you Tagir! > > I think your solution is quite clever, and the fix looks good. > > While we are here: Would it make sense to use CopiesList only for n > > 0, and make nCopies() and nCopies().subList() return > Collection.emptyList() otherwise? > > This would allow to remove the check for n == 0 in a couple of places. > Also an unnecessary reference to the `element` wouldn't be kept. > > With kind regards, > Ivan > > > On 12/2/18 9:27 PM, Tagir Valeev wrote: > > Hello! > > > > Please review and sponsor the optimized implementation of > > Collections.nCopies().hashCode(): > > https://bugs.openjdk.java.net/browse/JDK-8214687 > > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ > > > > Previous discussion thread: > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056 > 843.html > > > > Thanks to Zheka Kozlov for the original proposal. Also thanks to > > Ivan Gerasimov for the simplification idea: (x & 0x8000_0000) != 0 > > => x < 0. > > > > With best regards, > > Tagir Valeev > > > > -- > With kind regards, > Ivan Gerasimov > > From vicente.romero at oracle.com Mon Dec 3 19:12:53 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 3 Dec 2018 14:12:53 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> Hi all, Can I have the final nod to the JVM constants API, there have been some changes since the last review iteration. Thanks to the internal and external developers that have taken the time to provide feedback so far. The links to the last versions are: webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ javadoc: http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html specdiff: http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html Thanks, Vicente On 10/18/18 9:55 PM, Mandy Chung wrote: > > > On 10/15/18 11:12 AM, Vicente Romero wrote: >> >> [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 > > I reviewed java.lang.invoke change in details.? I have skimmed through > the new classes. > I will look at the new tests next. > > @since 12 is missing in the new APIs > > VarHandle.java > 1887 public final String toString() { > 1888 // @@@ defer to concrete type for additional description > 1889 // see https://bugs.openjdk.java.net/browse/JDK-8199149 You may > want to take out this comment or L1889 as we can refer back to > JDK-8199149. VarHandles.java > ?169???????? // @@@ This is a little fragile assuming the base is the > class > > Maybe FieldStaticReadOnly and FieldStaticReadWrite constructor and > getStaticFieldFromBaseAndOffset method should take Class refc > rather than Object base. FieldStaticReadXXX will do the cast when > calling getStaticFieldFromBaseAndOffset. > > java.base module-info.java > ?? It'd be good to keep the exported APIs in alphabetical order. > > java/lang/invoke/TypeDescriptor.java > ?? copyright header is missing > > Mandy From Roger.Riggs at oracle.com Mon Dec 3 19:28:02 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 14:28:02 -0500 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <88571ad9-dd69-9d08-6a3d-e5e884a54ffe@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> <60acf63c-b9f8-49f2-e04d-4484a5327982@oracle.com> <6bf5dd71-471f-59b0-5ba8-5e9ce4e19dcd@oracle.com> <88571ad9-dd69-9d08-6a3d-e5e884a54ffe@oracle.com> Message-ID: Hi Nishit, Thanks for the updates and cleanup. CompactNumberFormat.java: - 827: To locate a single character use: ??????? if (pattern.indexOf(QUOTE) < 0) { ... } - 1488:? Since infinite returns do not depend on any of the code after line 1454, ?? the 1488- 1494 could be moved to 1454. (It is correct where it is). ?- in API design, I would have put the position argument immediately after text since the position ?? is closely related to the text argument (in matchAffix and matchPrefixAndSuffix methods). ?? Its probably not worth the change in these private methods. comments below... On 12/03/2018 07:22 AM, Nishit Jain wrote: > Thanks Roger, > > Updated the webrev based on thebelow suggested changes and some clean up. > > http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.05/ > > On 01-12-2018 01:03, Roger Riggs wrote: >> Hi Nishit, >> >> Some comments, a couple of possible bugs and several performance >> related issues >> could be deferred. Both formatting and parsing seem to be quite >> heavyweight >> due to looping and combinatorics. >> >> >> CompactNumberFormat.java >> >> >> 661, 727, 1507: Is there a reason to convert the divisor to a string >> and then re-parse it to create a new BigDecimal? >> ??????? (IntelliJ observes that divide is called without a rounding >> argument.) >> ??????? Given that the divisors are all powers of 10 and the digit >> list is a base 10 set of digits >> ??????? it seems more efficient to just move the decimal point then >> to do the math. >> ??????? BTW, the divisor.toString() is preferred over concat with >> "".? (looks like a hack). >> >> ??????? It would be more efficient to write two methods that would >> pass the Number >> ??????? and return a BigInteger or BigDecimal by dispatching on the >> concrete type and >> ??????? using the appropriate constructor. > Changed concatenation with toString() and added a rounding parameter, > but not getting the benefit of having two methods and returning > respective concrete type using constructors. > I didn't get the point of having two methods. Can you please elaborate? The would the same function but different return types (BigInteger vs BigDecimal). The code is ok as is. >> >> 781:? @param prefix - the parameter name is suffix >> >> 804: move the int start = inside the if. >> >> 826:? expandAffix can be more efficient if tests the pattern for the >> presence of QUOTE >> ??????? and returns the pattern if the QUOTE is not present. That >> would be the most common case. >> >> 914: Reduce the number of compares by reordering to: >> ??????? if number > currentValue; multiply and continue >> ??????? if number < currentValue break; >> ??????? else ==; assign matched index and break; >> >> ??????? In the normal case, there will be only one compare in the >> loop until it is to exit. >> >> 1109:? IntelliJ observes that within the case QUOTE, the if (ch == >> QUOTE) is always true >> ????? so the if is redundant. > OK. >> >> 1205:? It looks odd to prepend two characters '- to the prefix. Is >> the single quote correct? >> ????? Where's the closing quote if so. > It is to specify that the minus sign is a special character, which > needs to be replaced with its localized equivalent at the time of > formatting. > > Internally, there is a difference between a "minus sign prefix with a > single quote" and a "minus sign" (it depends on how user specify the > pattern), because the later one is considered as a literal and should > be used exactly same in the formatted output, but the one prefixed > with a single quote is replaced with its localized symbol using > DecimalFormatSymbols.getMinusSign(). thanks for the explanation. > >> 1394: matchedPosPrefix.length() is compared to negativePrefix.length(). >> ????? That's an unusual mixing of positive and negative! Please >> re-check. > Yes, it was a mistake. >> >> 1363:? Can there be an early exit from this loop if one of the >> prefixes is identified? >> ????? The pattern of comparing for a prefix/suffix and the length >> might warrant >> ????? creating a private method to reduce the repetitive parts of the >> code. > I had thought about it, but it was difficult unless the whole list of > affixes are traversed, because there is always a chance to get longer > affix later in the list. I thought to sort the lists based on the > length and do the match, but in that case indexes get disordered > across lists (divisor, prefix, suffix, compact patterns), and > computation will become more complicated. > Updated the code by moving the repetitive parts in the loop to private > methods. Nice use of an private method to avoid code replication. >> >> 1593: extra space between "- ("; should be the same style as 1591 >> >> 1627, 1363: Is an early exit from this loop possible? >> ?????? or a quick comparison to avoid the regionMatches. >> ?????? Do the regionMatches *only if* the prefix/suffix is longer >> than the suffix already compared? > Yes, I think this can be done. Updated. +1 >> >> 1721:? IntelliJ observes that if (gotNeg) is redundant since 1708 >> rules out them being both true or both false. > Updated Thanks, Roger > > Regards, > Nishit Jain >> >> Thanks, Roger >> >>> >>> On 11/28/18 3:46 AM, Nishit Jain wrote: >>>> Thanks Naoto, >>>> >>>> Updated. >>>> >>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ >>>> >> > From Roger.Riggs at oracle.com Mon Dec 3 19:44:38 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 14:44:38 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> Message-ID: <7c85430f-d11b-6148-cd76-6d0bd02cd5fc@oracle.com> Hi Vincent, On 12/02/2018 05:54 PM, Vincent Ryan wrote: > Thanks for the thorough review. > Responses in-line. > >> On 26 Nov 2018, at 19:49, Roger Riggs > > wrote: >> >> Hi, >> >> Thanks for updating this proposal.? Some comments on the javadoc/spec. >> >> The class name Hex isn't very evocative of its function. >> HexFormat would convey a more complete idea as to its function and be >> similar to >> to the existing DecimalFormat and NumberFormat classes though they do >> not share >> any of the APIs or framework. > > OK > >> >> - The 2nd example using Files.newInputStream is not recommended >> since the stream to the file may not be closed. >> The recommended form would use try-with-resources. >> |try (InputStream is = |||Files.newInputStream(Paths.get("mydata"))) {| Hex.dumpAsStream(is, >> 64, (offset, chunk, fromIndex, toIndex) -> String.format("%d %s", >> offset / 64 + 1, Hex.toPrintableString(chunk, fromIndex, toIndex))) >> .forEachOrdered(System.out::println); } catch (IOException ioe) { ... } | >> The 'forEachOrdered' should not be necessary and may raise questions >> about why. >> if there's no good reason, use 'forEach?. > > OK > >> >> >> - The HEXDUMP_FORMATTER should be explicit about the format it generates. >> ? Though it may declare itself compatible with hexdump(1) it should >> specify >> ? the format it produces to avoid an external reference that might >> change unexpectedly. > > OK > >> >> - toFormattedHexString: >> References to the line-separator should be javadoc linked to >> System#lineSeparator. > > OK. And maybe shorten this method to simply: toFormattedString ? Fine with me. > >> >> Alternatively, should this class follow the lead of >> String.align/indent and use >> the normalized line terminator "\n" consistently? In which case, it >> should be explicit. >> >> Clarify exactly the behavior: >> >> "If the final chunk is less than 16 +bytes+ then +the result+ is >> padded with spaces to match the length of the preceding chunks. " >> >> Only the built-in formatter asserts that every result is the same >> length.? A provided formatter >> may not conform.? soften "will be" -> "may be" in "the final chunk ?" > > OK > >> >> - everywhere: "binary buffer" -> "byte buffer"? or byte array > > OK > >> >> - toPrintableString:? The ASCII limitation seems quite dated, 8-bit >> clean is the norm and >> except for control characters? and 0x7f, the rest of the range is >> printable in most Locales. >> Strict conformance to hexdump is not a requirement. > > I can see the benefit to including the accented letters > 0x7F but is > it really useful to also display > graphical and non-printable characters > 0x7F ? Unless the character would cause the terminal to go 'haywire' or enter a unprintable mode? I'd rather see the character than '.'. It may a bit arbitrary but if a character is ISO 8859-1, it should be printed. That omits? 0..0x1F, and 0x7F..0x9F;? I'm fine with those being '.'. > >> >> - dumpAsStream(InputStream) >> ? It is inconsistent (and possibly wrong) that the final chunk may be >> shorter since the HEXDUMP_FORMATTER >> ? uses the formatter that always pads.? (Btw, the implementation >> appends \n and should be using lineSeparator.) >> ?? "If the input is not a multiple of 16 bytes then the final chunk >> will be shorter than the preceding chunks.? > > I?ve clarified the language. The final chunk will indeed be shorter > but the output 'will be' padded by HEXDUMP_FORMATTER > and 'may be' padded when a custom formatter is supplied. ok > >> >> - dumpAsStream(bytes, from, to, chunk, formatter) >> >> ?Can it more explicit about the unchecked exception? >> ?"If an error occurs in the |formatter| then an unchecked exception >> will be thrown from the underlying |Stream| method.? > > What do you suggest? The formatter may throw any exception and it > doesn?t get thrown until the stream is processed. ok, You are right, there isn't much that can be said, exceptions from the stream can happen. > >> >> - Another thought about the methods returning Stream. >> ? They require a concrete string to be created for each chunk. >> ? There may be some efficiency and flexibility to be gained if >> formatters can return a CharSequence. >> ? In many cases it would be a string, but it would allow the >> formatter to return a StringBuilder >> ? that could be used directly without needing to construct a short >> lived string. > > Sounds OK but I?ll need to prototype this and get back to you. This may be more trouble than its worth; it makes the API a bit harder to understand. If its not quick and easy, I'm fine with it as string. Thanks, Roger > > >> >> Thanks, Roger >> >> >> p.s. >> I wrote code for the use case of formatting bytes in the form that >> can be compiled with javac. >> it took rather more code than I expected but I don't have any >> specific suggestions. >> >> >> ??????? byte[] b = ...; >> ??????? final String indent = " ".repeat(8); >> ??????? final StringBuilder sb = new StringBuilder(16 * 5); >> ??????? sb.append(indent); >> >> ??????? System.out.print("??? byte[] bytes = {\n"); >> ??????? try (ByteArrayInputStream is = new ByteArrayInputStream(b)) { >> ??????????? dumpAsStream(is, 16, (o, c, s, e) -> { >> ??????????????? sb.setLength(indent.length()); >> ??????????????? for (int i = s; i < e; i++) { >> ??????????????????? sb.append(c[i]); >> ??????????????????? sb.append(", "); >> ??????????????? } >> ??????????????? sb.append(System.lineSeparator()); >> ??????????????? return sb.toString(); >> ??????????? }).forEach(s -> System.out.print(s)); >> ??????? } >> ??????? System.out.print("??? }\n"); >> >> >> On 11/23/2018 09:51 AM, Vincent Ryan wrote: >>> Hello, >>> >>> Please review this proposal for a new API to conveniently generate >>> and display binary data using hexadecimal string representation. >>> It supports both bulk and stream operations and it can also generate >>> the well-known hexdump format [1]. >>> >>> This latest revision addresses review comments provided earlier. >>> These include adding methods to support for data supplied in a >>> ByteBuffer, exposing the default formatter implementation as a public >>> static and dropping the superfluous 'Hex' term from several method >>> names. >>> >>> Thanks >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>> API: >>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>> >>> >>> ____ >>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >> > From Roger.Riggs at oracle.com Mon Dec 3 20:50:56 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 15:50:56 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> Message-ID: <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> Hi Ichiroh, src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: ??? I think this is no longer needed since it only has imports. ??? By the way, the style is to import each specific class and avoid wild card imports. TestIBMBugs: ? - Please use a style consistent with other methods in the class. ??? In this case spaces are needed around "{" and "}, and a space after "," comma. ? - The new method bug8212794, includes a test for x-IBM33722. ??? Is that needed since there does not appear to be a change for 33722? Regards, Roger On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: > > > On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix again ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ > I think it looks good but please let someone from core-libs review it > too. > > /Magnus >> >> I just fixed only IBM964 for JDK-8212794. >> (IBM29626C fix is not included) >> >> On non AIX platform (Linux), >> ibm-euctw alias is added for IBM964. >> >> Without fix >> $ jshell >> |? Welcome to JShell -- Version 12-ea >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.ext.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> With fix >> ====== >> $ jshell >> |? Welcome to JShell -- Version 12-internal >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.ext.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm-euctw >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> On AIX platform >> IBM964 is moved to java.base module from jdk.charset module. >> >> ====== >> $ LANG=zh_TW jshell >> |? Welcome to JShell -- Version 12-internal >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.defaultCharset() >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm-euctw >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>> Hello Alan & Magnus. >>> >>> Sorry for you confusion. >>> I did many copy actions and rename actions. >>> So you may see, I added unexpected code into non AIX platform. >>> >>> I think I should not put 2 kind of modification. >>> >>> For this bug id, I'll handle IBM964 and IBM33722. >>> (also SimpleEUCEncoder.java is required) >>> >>> I'll submit code review again. >>> >>> Additionally, I'll touch >>> make/data/charsetmapping/charsets >>> make/data/charsetmapping/stdcs-aix >>> >>> I'll not touch >>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>> >>> My build machine is not so fast, after test is done. >>> I'll post new code. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>> I'm quite unsatisfied with the current handling of character sets >>>>>> in the build in general. :-( I'd really like to modernize it. I >>>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>>> a build perspective, but I'm not sure of what "external" >>>>>> requirements are coming from AIX and the general core-libs agenda >>>>>> regarding character sets in general. >>>>>> >>>>>> I think there is a good opportunity to solve many problems at the >>>>>> same time here, as long as everyone agrees on what is the >>>>>> preferred outcome. >>>>> The support in the build to configure the charsets to include in >>>>> java.base on each platform has been working well. Charsets that >>>>> aren't in java.base go into the jdk.charsets service provider >>>>> module and that has been working well too. From the result point >>>>> of view, perhaps, but definitely not from the build perspective. >>>>> ;-) But yes, I understand this is functionality that should be kept. >>>>> One thing that we lack is some way to add charsets for specific >>>>> platforms and this comes up with the IBM patches where they are >>>>> looking to adding several additional IBM charsets. One starting >>>>> point that we've touched on in several threads here is dropping >>>>> the EBCDIC charsets from the main stream builds. Going there will >>>>> need build support. >>>> So build support for trivially adding specific charsets to specific >>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>> then? >>>> >>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>> that needs build support? >>>> >>>> /Magnus >>>>> >>>>> >>>>> -Alan >> > From Roger.Riggs at oracle.com Mon Dec 3 21:45:15 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 16:45:15 -0500 Subject: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed In-Reply-To: References: Message-ID: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> Ping? On 11/27/2018 02:04 PM, Roger Riggs wrote: > Please review a test update to address an intermittent test failure. > The test is modified to accept the current implementation behavior of > the input streams > from processes that may under race conditions with close throw > IOE("Stream closed"). > > Details and analysis in the Jira: > ? https://bugs.openjdk.java.net/browse/JDK-8171426 > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426/ > > Thanks, Roger > From Roger.Riggs at oracle.com Mon Dec 3 21:43:37 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 16:43:37 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <1543664955.2437.5.camel@paratix.ch> References: <1543664955.2437.5.camel@paratix.ch> Message-ID: Hi Phillip, The amount detail obscures the general purpose. And there appears to be more than 1. The Jira issue IDs mentioned are 8066619 and 6202130. Is this functionally neutral and only fixes the deprecations? There is a mention that a test is needed for multi-byte chars, but a test is not included.? Is there an existing test for that? Its probably best to identify the main functional improvement (multi-byte) and fix the deprecation as a side effect. Thanks for digging through the issues and the explanations; it will take a bit of study to unravel and understand everything in this changeset. Regards, Roger On 12/01/2018 06:49 AM, Philipp Kunz wrote: > Find the proposed patch attached. Some comments and explanations, here: > > There is a quite interesting implementation in Manifest and Attributes > worth quite some explanation. The way it used to work before was: > > 1. put manifest header name, colon and space into a StringBuffer > -> the buffer now contains a string of characters each high-byte of > which is zero as explained later why this is important. the high-bytes > are zero because the set of allowed characters is very limited to ":", > " ", "a" - "z", "A" - "Z", "0" - "9", "_", and "-" according to > Attributes.Name#hash(String) so far with only the name and the > separator and yet without the values. > > 2. if the value is not null, encode it in UTF-8 into a byte array and > instantiate a String with it using deprecated > String#String(byte[],int,int,int) resulting in a String with the same > length as the byte array before holding one byte in each character's > low-byte. This makes a difference for characters encoded with more than > one byte in UTF-8. The new String is potentially longer than the > original value. > > 3.?if the value is not null, append value to buffer. The one UTF-8 > encoded byte per character from the appended string is preserved also > in the buffer along with the previous buffer contents. > > 3alt. if the value is null, add "null" to the buffer. See > java.lang.AbstractStringBuilder#append(String). Neither of the > characters of "null" has a non-zero high-byte encoded as UTF-16 chars. > > 4. make72Safe inserts line breaks with continuation spaces. Note that > the buffer here contains only one byte per character because all high- > bytes are still zero so that line.length() and line.insert(index, ...) > effectively operate with byte offsets and not characters. > > 5. buffer.toString() > > 6. DataOutputStream#writeBytes(String). First of all read the JavaDoc > comment for it, which explains it all: > Writes out the string to the underlying output stream as a > ????sequence of bytes. Each character in the string is written out, in > ????sequence, by discarding its high eight bits. If no exception is > ????thrown, the counter written is incremented by the > ????length of s > This restores the earlier UTF-8 encoding correctly. > > The topic has been discussed and mentioned already in > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052946.ht > ml > https://bugs.openjdk.java.net/browse/JDK-6202130 > > String(byte[],int,int,int) works "well" or "well enough" only together > with DataOutputStream#writeBytes(String). When removing > String(byte[],int,int,int) from Manifest and Attributes because > deprecated, it makes no sense to keep using > DataOutputStream#writeBytes(String) either. > > For the same reason as?String#String(byte[],int,int,int) has been > deprecated, I suggest to also deprecate > java.io.DataOutput#writeBytes(String) as a separate issue. This might > relate to https://bugs.openjdk.java.net/browse/JDK-6400767 but that one > came to a different conclusion some ten years ago. > > I preferred to stick with the DataOutputStream even though not strictly > necessary any more. It is and has been in the API of Attributes > (unfortunately not private) and should better not be removed by > changing the parameter type. Same for Manifest#make72Safe(StringBuffer) > which I deprecated rather than having removed. Someone could have > extended a class from Manifest and use such a method and when changing > the signature it could no longer even compile in a far-fetched case. > > LINE_BREAK, CONTINUATION_SPACE, LINE_BREAK_BYTES, and > LINE_BREAK_WITH_CONTINUATION_SPACE_BYTES should prevent having to > invoke getBytes(UTF_8) over and over again on "\r\n" and "\r\n " with > the idea to slightly improve performance this way. I figured it does > not need JavaDoc comments but would be happy to add them if desired. > > I removed "XXX Need to handle UTF8 values." from Manifest#read after > adding a test for it in ValueUtf8Coding. This change and test also > relate to bug 6202130 but does not solve that one completely. > ValueUtf8Coding demonstrates that Manifest can read UTF-8 encoded > values which is a necessary test case to cover for this patch here. > ValueUtf8Coding is the same test as already submitted and suggested > earlier. See > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/threa > d.html#55848 > > Indentation in Attributes#write(DataOutputStream) was five spaces on > most lines. I?fixed indentation only on the lines changed anyway. > > I replaced String#String(byte[],int,int,String) with > String#String(byte[],int,int,java.nio.charset.StandardCharsets.UTF_8) > which as a difference does not declare to throw a > java.io.UnsupportedEncodingException. That also replaced "UTF8" as a > charset name which I would consider not optimal regarding > sun.nio.cs.UTF_8#UTF_8() and sun.nio.cs.UTF_8#historicalName(). > > In my opinion there is still some duplicated or at least very similar > code in Manifest#write, Attributes#writeMain, and Attributes#write but > I preferred to change less rather than more and not to further refactor > and re-combine it. > > In EmptyKeysAndValues and NullKeysAndValues tests I tried to > demonstrate that the changed implementation does not change behaviour > also in edge cases. I would have expected not having to test all these > cases but then I realized it was possible to test and is therefore > possible in a real use case as well however far-fetched. At least the > > if (value != null) { > > lines (three times) most obviously demand to test the null value cases. > > I'm looking curiously forward to any kind of feedback or opinion. > > Philipp From brian.burkhalter at oracle.com Mon Dec 3 21:49:50 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Dec 2018 13:49:50 -0800 Subject: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed In-Reply-To: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> References: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> Message-ID: Hi Roger, L2: copyright year, of course L2119: The verbiage seems a little obtuse. Otherwise, +1. Thanks, Brian On 11/27/2018 02:04 PM, Roger Riggs wrote: > Please review a test update to address an intermittent test failure. > The test is modified to accept the current implementation behavior of the input streams > from processes that may under race conditions with close throw IOE("Stream closed"). > > Details and analysis in the Jira: > https://bugs.openjdk.java.net/browse/JDK-8171426 > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426/ > > Thanks, Roger From jonathan.gibbons at oracle.com Tue Dec 4 00:02:27 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Dec 2018 16:02:27 -0800 Subject: RFR: [XXS] 8214744: Unnecessary

tags in java.util.zip.Deflater Message-ID: Please review this small patch, given below, to remove unnecessary

reported by `tidy` as the last remaining HTML issues in the documentation for java.base build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:827:2: Warning: trimming empty

build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:850:2: Warning: trimming empty

JBS: https://bugs.openjdk.java.net/browse/JDK-8214744 -- Jon $ hg diff -R open open/src diff -r 2eb8ae0f3454 src/java.base/share/classes/java/util/zip/Deflater.java --- a/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec 03 18:48:01 2018 +0100 +++ b/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec 03 15:57:17 2018 -0800 @@ -224,7 +224,6 @@ ????? * One of the {@code setInput()} methods should be called whenever ????? * {@code needsInput()} returns true indicating that more input data ????? * is required. -???? *

????? * @param input the input data bytes ????? * @param off the start offset of the data ????? * @param len the length of the data @@ -248,7 +247,6 @@ ????? * One of the {@code setInput()} methods should be called whenever ????? * {@code needsInput()} returns true indicating that more input data ????? * is required. -???? *

????? * @param input the input data bytes ????? * @see Deflater#needsInput ????? */ From mandy.chung at oracle.com Tue Dec 4 00:08:02 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Dec 2018 16:08:02 -0800 Subject: RFR: [XXS] 8214744: Unnecessary

tags in java.util.zip.Deflater In-Reply-To: References: Message-ID: <36aa2e84-23ef-cc65-edbe-fbf832fd86d9@oracle.com> +1 Mandy On 12/3/18 4:02 PM, Jonathan Gibbons wrote: > Please review this small patch, given below, to remove unnecessary

> reported by `tidy` as the last remaining HTML issues in the > documentation for java.base > > build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:827:2: > Warning: trimming empty

> build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:850:2: > Warning: trimming empty

> > JBS: https://bugs.openjdk.java.net/browse/JDK-8214744 > > -- Jon > > > $ hg diff -R open open/src > diff -r 2eb8ae0f3454 > src/java.base/share/classes/java/util/zip/Deflater.java > --- a/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec > 03 18:48:01 2018 +0100 > +++ b/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec > 03 15:57:17 2018 -0800 > @@ -224,7 +224,6 @@ > ????? * One of the {@code setInput()} methods should be called whenever > ????? * {@code needsInput()} returns true indicating that more input data > ????? * is required. > -???? *

> ????? * @param input the input data bytes > ????? * @param off the start offset of the data > ????? * @param len the length of the data > @@ -248,7 +247,6 @@ > ????? * One of the {@code setInput()} methods should be called whenever > ????? * {@code needsInput()} returns true indicating that more input data > ????? * is required. > -???? *

> ????? * @param input the input data bytes > ????? * @see Deflater#needsInput > ????? */ > From jiangli.zhou at oracle.com Tue Dec 4 00:08:15 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 3 Dec 2018 16:08:15 -0800 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: Hi Claes, Looks good from object graph archiving perspective. Placing the KNOWN_NAMES map in the closed archive looks safe since no additional names are added after initialization. If you also agree, maybe add a comment above the KNOWN_NAMES field declaration with those information. Thanks! Jiangli On 12/3/18 8:02 AM, Claes Redestad wrote: > Hi, > > initializing java.util.jar.Attributes.Name. executes ~20k > bytecodes setting up and eagerly calculating case-insensitive hash > codes for a slew of Name objects. > > By archiving the resulting set of Names and initializing public > constants from the archived map, we reduce time spent starting up > (Name. drops to 368 executed bytecodes) and improve the > footprint sharing effect of using CDS: > > http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ > > Testing: tier1-2 running > > Verified a 1-2.5ms startup improvement on java -jar Hello.jar > - significant and stable reduction in instruction count, branches and > branch misses > - only adds ~1.1Kb to the dumped CDS archive > > Thanks! > > /Claes From lance.andersen at oracle.com Tue Dec 4 00:12:18 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 3 Dec 2018 19:12:18 -0500 Subject: RFR: [XXS] 8214744: Unnecessary

tags in java.util.zip.Deflater In-Reply-To: References: Message-ID: +1 > On Dec 3, 2018, at 7:02 PM, Jonathan Gibbons wrote: > > Please review this small patch, given below, to remove unnecessary

reported by `tidy` as the last remaining HTML issues in the documentation for java.base > > build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:827:2: Warning: trimming empty

> build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:850:2: Warning: trimming empty

> > JBS: https://bugs.openjdk.java.net/browse/JDK-8214744 > > -- Jon > > > $ hg diff -R open open/src > diff -r 2eb8ae0f3454 src/java.base/share/classes/java/util/zip/Deflater.java > --- a/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec 03 18:48:01 2018 +0100 > +++ b/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec 03 15:57:17 2018 -0800 > @@ -224,7 +224,6 @@ > * One of the {@code setInput()} methods should be called whenever > * {@code needsInput()} returns true indicating that more input data > * is required. > - *

> * @param input the input data bytes > * @param off the start offset of the data > * @param len the length of the data > @@ -248,7 +247,6 @@ > * One of the {@code setInput()} methods should be called whenever > * {@code needsInput()} returns true indicating that more input data > * is required. > - *

> * @param input the input data bytes > * @see Deflater#needsInput > */ > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Tue Dec 4 00:20:42 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Dec 2018 16:20:42 -0800 Subject: RFR: [XXS] 8214744: Unnecessary

tags in java.util.zip.Deflater In-Reply-To: References: Message-ID: LGTM On Mon, Dec 3, 2018 at 4:07 PM Jonathan Gibbons wrote: > Please review this small patch, given below, to remove unnecessary

> reported by `tidy` as the last remaining HTML issues in the > documentation for java.base > > build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:827:2: > Warning: trimming empty

> build/linux-x86_64-server-release/images/docs/api/java.base/java/util/zip/Deflater.html:850:2: > Warning: trimming empty

> > JBS: https://bugs.openjdk.java.net/browse/JDK-8214744 > > -- Jon > > > $ hg diff -R open open/src > diff -r 2eb8ae0f3454 > src/java.base/share/classes/java/util/zip/Deflater.java > --- a/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec 03 > 18:48:01 2018 +0100 > +++ b/src/java.base/share/classes/java/util/zip/Deflater.java Mon Dec 03 > 15:57:17 2018 -0800 > @@ -224,7 +224,6 @@ > * One of the {@code setInput()} methods should be called whenever > * {@code needsInput()} returns true indicating that more input data > * is required. > - *

> * @param input the input data bytes > * @param off the start offset of the data > * @param len the length of the data > @@ -248,7 +247,6 @@ > * One of the {@code setInput()} methods should be called whenever > * {@code needsInput()} returns true indicating that more input data > * is required. > - *

> * @param input the input data bytes > * @see Deflater#needsInput > */ > > From jonathan.gibbons at oracle.com Tue Dec 4 00:22:04 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Dec 2018 16:22:04 -0800 Subject: RFR: XXXS: JDK-8214745: Bad link in coll-reference.html Message-ID: <7a36c5b3-c3eb-6f4c-2699-86a506f110be@oracle.com> Please review a tiny patch, given below, to fix a broken link in coll-reference.html. The problem is bad/misplaced punctuation characters within the link. This is believed to be the last broken link in the java.base module, and one of the last in the overall documentation. JBS: https://bugs.openjdk.java.net/browse/JDK-8214745 -- Jon $ hg diff -R open open/src diff -r bbf85239e37c src/java.base/share/classes/java/util/doc-files/coll-reference.html --- a/src/java.base/share/classes/java/util/doc-files/coll-reference.html Mon Dec 03 16:14:15 2018 -0800 +++ b/src/java.base/share/classes/java/util/doc-files/coll-reference.html Mon Dec 03 16:17:11 2018 -0800 @@ -431,7 +431,7 @@ ?fill(List, Object) - Overwrites every element in a ?list with the specified value. ?

  • +"../Collections.html#copy(java.util.List,java.util.List)"> ?copy(List dest, List src) - Copies the source list ?into the destination list.
    • ?
  • References: <7a36c5b3-c3eb-6f4c-2699-86a506f110be@oracle.com> Message-ID: <89F6B0AF-D019-4A86-BC61-CD1A675107DB@oracle.com> +1 > On Dec 3, 2018, at 7:22 PM, Jonathan Gibbons wrote: > > Please review a tiny patch, given below, to fix a broken link in coll-reference.html. The problem is bad/misplaced punctuation characters within the link. This is believed to be the last broken link in the java.base module, and one of the last in the overall documentation. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8214745 > > -- Jon > > > $ hg diff -R open open/src > diff -r bbf85239e37c src/java.base/share/classes/java/util/doc-files/coll-reference.html > --- a/src/java.base/share/classes/java/util/doc-files/coll-reference.html Mon Dec 03 16:14:15 2018 -0800 > +++ b/src/java.base/share/classes/java/util/doc-files/coll-reference.html Mon Dec 03 16:17:11 2018 -0800 > @@ -431,7 +431,7 @@ > fill(List, Object) - Overwrites every element in a > list with the specified value.
    • >
  • -"../Collections.html#copy-java.util.List(java.util.List)"> > +"../Collections.html#copy(java.util.List,java.util.List)"> > copy(List dest, List src) - Copies the source list > into the destination list.
    • >
  • > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Tue Dec 4 00:30:41 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Dec 2018 16:30:41 -0800 Subject: RFR: XXXS: JDK-8214745: Bad link in coll-reference.html In-Reply-To: <7a36c5b3-c3eb-6f4c-2699-86a506f110be@oracle.com> References: <7a36c5b3-c3eb-6f4c-2699-86a506f110be@oracle.com> Message-ID: LGTM On Mon, Dec 3, 2018 at 4:27 PM Jonathan Gibbons wrote: > Please review a tiny patch, given below, to fix a broken link in > coll-reference.html. The problem is bad/misplaced punctuation characters > within the link. This is believed to be the last broken link in the > java.base module, and one of the last in the overall documentation. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8214745 > > -- Jon > > > $ hg diff -R open open/src > diff -r bbf85239e37c > src/java.base/share/classes/java/util/doc-files/coll-reference.html > --- > a/src/java.base/share/classes/java/util/doc-files/coll-reference.html > Mon Dec 03 16:14:15 2018 -0800 > +++ > b/src/java.base/share/classes/java/util/doc-files/coll-reference.html > Mon Dec 03 16:17:11 2018 -0800 > @@ -431,7 +431,7 @@ > fill(List, Object) - Overwrites every element in a > list with the specified value.
    • >
  • -"../Collections.html#copy-java.util.List(java.util.List)"> > +"../Collections.html#copy(java.util.List,java.util.List)"> > copy(List dest, List src) - Copies the source list > into the destination list.
    • >
  • > > From brian.burkhalter at oracle.com Tue Dec 4 00:31:55 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Dec 2018 16:31:55 -0800 Subject: RFR: XXXS: JDK-8214745: Bad link in coll-reference.html In-Reply-To: <7a36c5b3-c3eb-6f4c-2699-86a506f110be@oracle.com> References: <7a36c5b3-c3eb-6f4c-2699-86a506f110be@oracle.com> Message-ID: +1 Brian > On Dec 3, 2018, at 4:22 PM, Jonathan Gibbons wrote: > > --- a/src/java.base/share/classes/java/util/doc-files/coll-reference.html Mon Dec 03 16:14:15 2018 -0800 > +++ b/src/java.base/share/classes/java/util/doc-files/coll-reference.html Mon Dec 03 16:17:11 2018 -0800 > @@ -431,7 +431,7 @@ > fill(List, Object) - Overwrites every element in a > list with the specified value.
    • >
  • -"../Collections.html#copy-java.util.List(java.util.List)"> > +"../Collections.html#copy(java.util.List,java.util.List)"> > copy(List dest, List src) - Copies the source list > into the destination list.
    • >
  • References: <92419515-1a9a-576a-aa49-cbf82d6bf780@oracle.com> Message-ID: <2d87f83d-64a2-b55a-2e12-85c8031a7238@oracle.com> On 11/30/18 8:34 PM, Zheka Kozlov wrote: > I think we should choose Tagir's version so you don't need my OCA. OK, thanks. Let me know if you need any assistance with the OCA, should you decide to proceed with it. s'marks From takiguc at linux.vnet.ibm.com Tue Dec 4 03:30:04 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 12:30:04 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> Message-ID: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Hello Roger. Thank you for your suggestion. > src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: > > I think this is no longer needed since it only has imports. > By the way, the style is to import each specific class and > avoid wild card imports. "import sun.nio.cs.*;" is required because of SimpleEUCEncoder.java.template. SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. It means that, * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext package I could not determine which package has SimpleEUCEncoder. And same kind code is available on ISO2022_JP.java. Please let me know if you know another way. > TestIBMBugs: > - Please use a style consistent with other methods in the class. > In this case spaces are needed around "{" and "}, and a space > after "," comma. I'll changed. > - The new method bug8212794, includes a test for x-IBM33722. > Is that needed since there does not appear to be a change for > 33722? Yes, it's no need. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, Ichiroh Takiguchi On 2018-12-04 05:50, Roger Riggs wrote: > Hi Ichiroh, > > src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: > > ??? I think this is no longer needed since it only has imports. > ??? By the way, the style is to import each specific class and > avoid wild card imports. > > TestIBMBugs: > ? - Please use a style consistent with other methods in the class. > ??? In this case spaces are needed around "{" and "}, and a space > after "," comma. > > ? - The new method bug8212794, includes a test for x-IBM33722. > ??? Is that needed since there does not appear to be a change for > 33722? > > Regards, Roger > > > On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >> >> >> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix again ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >> I think it looks good but please let someone from core-libs review it >> too. >> >> /Magnus >>> >>> I just fixed only IBM964 for JDK-8212794. >>> (IBM29626C fix is not included) >>> >>> On non AIX platform (Linux), >>> ibm-euctw alias is added for IBM964. >>> >>> Without fix >>> $ jshell >>> |? Welcome to JShell -- Version 12-ea >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.ext.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> With fix >>> ====== >>> $ jshell >>> |? Welcome to JShell -- Version 12-internal >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.ext.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm-euctw >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> On AIX platform >>> IBM964 is moved to java.base module from jdk.charset module. >>> >>> ====== >>> $ LANG=zh_TW jshell >>> |? Welcome to JShell -- Version 12-internal >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm-euctw >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>> Hello Alan & Magnus. >>>> >>>> Sorry for you confusion. >>>> I did many copy actions and rename actions. >>>> So you may see, I added unexpected code into non AIX platform. >>>> >>>> I think I should not put 2 kind of modification. >>>> >>>> For this bug id, I'll handle IBM964 and IBM33722. >>>> (also SimpleEUCEncoder.java is required) >>>> >>>> I'll submit code review again. >>>> >>>> Additionally, I'll touch >>>> make/data/charsetmapping/charsets >>>> make/data/charsetmapping/stdcs-aix >>>> >>>> I'll not touch >>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>> >>>> My build machine is not so fast, after test is done. >>>> I'll post new code. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> >>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>> I'm quite unsatisfied with the current handling of character sets >>>>>>> in the build in general. :-( I'd really like to modernize it. I >>>>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>>>> a build perspective, but I'm not sure of what "external" >>>>>>> requirements are coming from AIX and the general core-libs agenda >>>>>>> regarding character sets in general. >>>>>>> >>>>>>> I think there is a good opportunity to solve many problems at the >>>>>>> same time here, as long as everyone agrees on what is the >>>>>>> preferred outcome. >>>>>> The support in the build to configure the charsets to include in >>>>>> java.base on each platform has been working well. Charsets that >>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>> module and that has been working well too. From the result point >>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>> ;-) But yes, I understand this is functionality that should be >>>>>> kept. >>>>>> One thing that we lack is some way to add charsets for specific >>>>>> platforms and this comes up with the IBM patches where they are >>>>>> looking to adding several additional IBM charsets. One starting >>>>>> point that we've touched on in several threads here is dropping >>>>>> the EBCDIC charsets from the main stream builds. Going there will >>>>>> need build support. >>>>> So build support for trivially adding specific charsets to specific >>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>> then? >>>>> >>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>> that needs build support? >>>>> >>>>> /Magnus >>>>>> >>>>>> >>>>>> -Alan >>> >> From stuart.marks at oracle.com Tue Dec 4 03:24:44 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 3 Dec 2018 19:24:44 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> Message-ID: <47699b67-f467-4f13-b065-214a12cdd37f@oracle.com> The general rule for JDK core classes (including collections, even private implementations) is that we try to preserve backward *and* forward serialization compatibility. This doesn't apply to all classes in the JDK, though. For example, javax.swing.JComponent is serializable, but it includes a disclaimer about potential serialization incompatibilities with future versions of itself. s'marks On 12/3/18 11:06 AM, Andrew Luo wrote: > CopiesList is private anyways, so are you suggesting that someone might call nCopies(0) in a previous version of the JDK, serialize the return value, and then unserialize in a later version of the JRE? Is this even a supported use case (serialization/deserialization of JRE classes across versions)? It was always my understanding that you can only unserialize JRE classes of the same version, since the internal class definition can change at any time... > > Thanks, > > -Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of Zheka Kozlov > Sent: Monday, December 3, 2018 12:43 AM > To: Ivan Gerasimov > Cc: core-libs-dev > Subject: Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() > >> Would it make sense to use CopiesList only for n > 0 > > This can break serialization. When CopiesList(0, e) is serialized and deserialized back, it will be in an invalid state. > >> I believe it makes sense to override CopiesList.equals() > Also: contains(), iterator(), listIterator() > > ??, 3 ???. 2018 ?. ? 14:19, Ivan Gerasimov : > >> Thank you Tagir! >> >> I think your solution is quite clever, and the fix looks good. >> >> While we are here: Would it make sense to use CopiesList only for n > >> 0, and make nCopies() and nCopies().subList() return >> Collection.emptyList() otherwise? >> >> This would allow to remove the check for n == 0 in a couple of places. >> Also an unnecessary reference to the `element` wouldn't be kept. >> >> With kind regards, >> Ivan >> >> >> On 12/2/18 9:27 PM, Tagir Valeev wrote: >>> Hello! >>> >>> Please review and sponsor the optimized implementation of >>> Collections.nCopies().hashCode(): >>> https://bugs.openjdk.java.net/browse/JDK-8214687 >>> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ >>> >>> Previous discussion thread: >>> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056 >> 843.html >>> >>> Thanks to Zheka Kozlov for the original proposal. Also thanks to >>> Ivan Gerasimov for the simplification idea: (x & 0x8000_0000) != 0 >>> => x < 0. >>> >>> With best regards, >>> Tagir Valeev >>> >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> From stuart.marks at oracle.com Tue Dec 4 03:56:37 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 3 Dec 2018 19:56:37 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> Message-ID: <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> >> I believe it makes sense to override CopiesList.equals() > Also: contains(), iterator(), listIterator() equals(): sure contains() is already overridden. Not sure there's much benefit to overriding the iterators. s'marks From david.holmes at oracle.com Tue Dec 4 05:09:52 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Dec 2018 15:09:52 +1000 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: Hi Claes, Meta-comment: are these Names candidates for the forthcoming compile-time evaluation of constants? Just wondering if these optimizations (and even the archiving itself) will be moot in the future? Thanks, David On 4/12/2018 2:02 am, Claes Redestad wrote: > Hi, > > initializing java.util.jar.Attributes.Name. executes ~20k > bytecodes setting up and eagerly calculating case-insensitive hash codes > for a slew of Name objects. > > By archiving the resulting set of Names and initializing public > constants from the archived map, we reduce time spent starting up > (Name. drops to 368 executed bytecodes) and improve the > footprint sharing effect of using CDS: > > http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ > > Testing: tier1-2 running > > Verified a 1-2.5ms startup improvement on java -jar Hello.jar > - significant and stable reduction in instruction count, branches and > branch misses > - only adds ~1.1Kb to the dumped CDS archive > > Thanks! > > /Claes From amaembo at gmail.com Tue Dec 4 05:22:46 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 4 Dec 2018 12:22:46 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> Message-ID: Hello! Thank you for your comments! Yes, deserialization will be broken if we assume that size is never 0. Also we'll introduce referential identity Collections.nCopies(0, x) == Collections.nCopies(0, y) which might introduce slight semantics change in existing programs. Once I suggested to wire Arrays.asList() (with no args) to Collections.emptyList(), but it was rejected for the same reason: no need to introduce a risk of possible semantics change. I updated webrev with equals implementation and test: http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ Comparing two CopiesList is much faster now indeed. Also we can spare an iterator in the common case and hoist the null-check out of the loop. Not sure whether we can rely that JIT will always do this for us, but if you think that it's unnecessary, I can merge the loops back. Note that now copiesList.equals(arrayList) could be faster than arrayList.equals(copiesList). I don't think it's an issue. On the other hand we could keep simpler and delegate to super-implementation if the other object is not a CopiesList (like it's implemented in java.util.RegularEnumSet::equals for example). What do you think? With best regards, Tagir Valeev. On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks wrote: > > > >> I believe it makes sense to override CopiesList.equals() > > Also: contains(), iterator(), listIterator() > > equals(): sure > > contains() is already overridden. Not sure there's much benefit to overriding > the iterators. > > s'marks From ivan.gerasimov at oracle.com Tue Dec 4 06:05:29 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 3 Dec 2018 22:05:29 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> Message-ID: <4768befa-a4a8-d245-180c-0c700de2a896@oracle.com> Hi Tagir! I think what you have in the last webrev looks good! In CopiesList.equals() please use eq() instead of Objects.equal() (see a comment at the line 5345). With kind regards, Ivan On 12/3/18 9:22 PM, Tagir Valeev wrote: > Hello! > > Thank you for your comments! > > Yes, deserialization will be broken if we assume that size is never 0. > Also we'll introduce referential identity Collections.nCopies(0, x) == > Collections.nCopies(0, y) which might introduce slight semantics > change in existing programs. Once I suggested to wire Arrays.asList() > (with no args) to Collections.emptyList(), but it was rejected for the > same reason: no need to introduce a risk of possible semantics change. > > I updated webrev with equals implementation and test: > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ > Comparing two CopiesList is much faster now indeed. Also we can spare > an iterator in the common case and hoist the null-check out of the > loop. Not sure whether we can rely that JIT will always do this for > us, but if you think that it's unnecessary, I can merge the loops > back. Note that now copiesList.equals(arrayList) could be faster than > arrayList.equals(copiesList). I don't think it's an issue. On the > other hand we could keep simpler and delegate to super-implementation > if the other object is not a CopiesList (like it's implemented in > java.util.RegularEnumSet::equals for example). What do you think? > > With best regards, > Tagir Valeev. > On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks wrote: >> >>>> I believe it makes sense to override CopiesList.equals() >>> Also: contains(), iterator(), listIterator() >> equals(): sure >> >> contains() is already overridden. Not sure there's much benefit to overriding >> the iterators. >> >> s'marks -- With kind regards, Ivan Gerasimov From orionllmain at gmail.com Tue Dec 4 06:10:17 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Tue, 4 Dec 2018 13:10:17 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> Message-ID: I think you should use iterator() instead of listIterator(). See the explanation here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html ??, 4 ???. 2018 ?. ? 12:23, Tagir Valeev : > Hello! > > Thank you for your comments! > > Yes, deserialization will be broken if we assume that size is never 0. > Also we'll introduce referential identity Collections.nCopies(0, x) == > Collections.nCopies(0, y) which might introduce slight semantics > change in existing programs. Once I suggested to wire Arrays.asList() > (with no args) to Collections.emptyList(), but it was rejected for the > same reason: no need to introduce a risk of possible semantics change. > > I updated webrev with equals implementation and test: > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ > Comparing two CopiesList is much faster now indeed. Also we can spare > an iterator in the common case and hoist the null-check out of the > loop. Not sure whether we can rely that JIT will always do this for > us, but if you think that it's unnecessary, I can merge the loops > back. Note that now copiesList.equals(arrayList) could be faster than > arrayList.equals(copiesList). I don't think it's an issue. On the > other hand we could keep simpler and delegate to super-implementation > if the other object is not a CopiesList (like it's implemented in > java.util.RegularEnumSet::equals for example). What do you think? > > With best regards, > Tagir Valeev. > On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks > wrote: > > > > > > >> I believe it makes sense to override CopiesList.equals() > > > Also: contains(), iterator(), listIterator() > > > > equals(): sure > > > > contains() is already overridden. Not sure there's much benefit to > overriding > > the iterators. > > > > s'marks > From amaembo at gmail.com Tue Dec 4 07:40:26 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 4 Dec 2018 14:40:26 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> Message-ID: Hello! > In CopiesList.equals() please use eq() instead of Objects.equal() (see a comment at the line 5345). Ok > I think you should use iterator() instead of listIterator(). See the explanation here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html Ok. I wonder why this message received no attention. Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r3/ With best regards, Tagir Valeev On Tue, Dec 4, 2018 at 1:10 PM Zheka Kozlov wrote: > > I think you should use iterator() instead of listIterator(). See the explanation here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html > > ??, 4 ???. 2018 ?. ? 12:23, Tagir Valeev : >> >> Hello! >> >> Thank you for your comments! >> >> Yes, deserialization will be broken if we assume that size is never 0. >> Also we'll introduce referential identity Collections.nCopies(0, x) == >> Collections.nCopies(0, y) which might introduce slight semantics >> change in existing programs. Once I suggested to wire Arrays.asList() >> (with no args) to Collections.emptyList(), but it was rejected for the >> same reason: no need to introduce a risk of possible semantics change. >> >> I updated webrev with equals implementation and test: >> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ >> Comparing two CopiesList is much faster now indeed. Also we can spare >> an iterator in the common case and hoist the null-check out of the >> loop. Not sure whether we can rely that JIT will always do this for >> us, but if you think that it's unnecessary, I can merge the loops >> back. Note that now copiesList.equals(arrayList) could be faster than >> arrayList.equals(copiesList). I don't think it's an issue. On the >> other hand we could keep simpler and delegate to super-implementation >> if the other object is not a CopiesList (like it's implemented in >> java.util.RegularEnumSet::equals for example). What do you think? >> >> With best regards, >> Tagir Valeev. >> On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks wrote: >> > >> > >> > >> I believe it makes sense to override CopiesList.equals() >> > > Also: contains(), iterator(), listIterator() >> > >> > equals(): sure >> > >> > contains() is already overridden. Not sure there's much benefit to overriding >> > the iterators. >> > >> > s'marks From Alan.Bateman at oracle.com Tue Dec 4 07:42:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Dec 2018 07:42:21 +0000 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: <49f05954-fab6-3c0d-229a-37a10fb2f19f@oracle.com> Message-ID: <33976421-9dd4-430e-df32-2fd80743eb60@oracle.com> On 03/12/2018 16:50, Claes Redestad wrote: > : > > The extra Names added to KNOWN_NAMES was my doing, and it was based on > commonly used attributes in Jar file manifests scanned from a set > commonly used applications as an alternative to building up a Name > cache dynamically (which is frought with other perils). The chose > extras gave a marginal but measurable improvement in startup to a wide > array of applications as a result, and their inclusion is strictly an > internal implementation detail. If you insist on having them removed I > won't object, but I believe it's an harmless optimization. There are several non-standard and tool/library specify attribute name in this list, many should not be interesting to libraries on either the class path or module path. So I think we should look at pruning that list. Ideally it would like just standard and JDK-specific attributes as they are the only attributes that the JDK knows about. -Alan From claes.redestad at oracle.com Tue Dec 4 08:08:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 4 Dec 2018 09:08:05 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: <89742fbd-e710-8266-c749-1c1f0377da4b@oracle.com> Hi David, unless my reading of JEP 334 (and JEP 303) is completely off then custom constants (say, Attributes$Name) would effectively be turned into condys, implying a bootstrap method call for them to be constructed. So would carry similar construction overhead as the current implementation. And even if I'm missing some detail of JEP 334 that would allow these Name objects to be loaded in without any runtime BSM call overhead whatsoever, we'd still need to create the KNOWN_NAMES Map of these things. So maybe create the entire map as a constant? I'm not sure we even could describe something like a Map as a loadable constant, but it'd be an interesting prospect... still, I believe the creation cost would end up similar to the status quo. So: while they may share some common goals (move computation out of runtime), I think there are some things heap archiving will keep doing better. Facilitating better sharing between JVMs is another benefit that comes from more extensive heap archiving. /Claes On 2018-12-04 06:09, David Holmes wrote:i > Hi Claes, > > Meta-comment: are these Names candidates for the forthcoming > compile-time evaluation of constants? Just wondering if these > optimizations (and even the archiving itself) will be moot in the future? > vev > Thanks, > David > > On 4/12/2018 2:02 am, Claes Redestad wrote: >> Hi, >> >> initializing java.util.jar.Attributes.Name. executes ~20k >> bytecodes setting up and eagerly calculating case-insensitive hash >> codes for a slew of Name objects. >> >> By archiving the resulting set of Names and initializing public >> constants from the archived map, we reduce time spent starting up >> (Name. drops to 368 executed bytecodes) and improve the >> footprint sharing effect of using CDS: >> >> http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ >> >> Testing: tier1-2 running >> >> Verified a 1-2.5ms startup improvement on java -jar Hello.jar >> - significant and stable reduction in instruction count, branches and >> branch misses >> - only adds ~1.1Kb to the dumped CDS archive >> >> Thanks! >> >> /Claes From claes.redestad at oracle.com Tue Dec 4 08:32:12 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 4 Dec 2018 09:32:12 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: <33976421-9dd4-430e-df32-2fd80743eb60@oracle.com> References: <49f05954-fab6-3c0d-229a-37a10fb2f19f@oracle.com> <33976421-9dd4-430e-df32-2fd80743eb60@oracle.com> Message-ID: <929e22f5-beec-b7a2-a4ec-3a68dc4c5a17@oracle.com> On 2018-12-04 08:42, Alan Bateman wrote: > On 03/12/2018 16:50, Claes Redestad wrote: >> : >> >> The extra Names added to KNOWN_NAMES was my doing, and it was based >> on commonly used attributes in Jar file manifests scanned from a set >> commonly used applications as an alternative to building up a Name >> cache dynamically (which is frought with other perils). The chose >> extras gave a marginal but measurable improvement in startup to a >> wide array of applications as a result, and their inclusion is >> strictly an internal implementation detail. If you insist on having >> them removed I won't object, but I believe it's an harmless >> optimization. > There are several non-standard and tool/library specify attribute name > in this list, many should not be interesting to libraries on either > the class path or module path. So I think we should look at pruning > that list. Ideally it would like just standard and JDK-specific > attributes as they are the only attributes that the JDK knows about. These non-standard and tool/library specific names appear in the manifest of a great many jar files, for example on maven central, and including the most common non-standard manifest attributes significantly reduce allocation churn reading such manifests. Especially true for ones that were oft repeated within the same manifest, e.g.,"Name" and "SHA1-Digest" for signed entries. Was it a crucial optimization? Probably not, a few percent on some startup applications. Ideals vs trade-offs... Hard-coding a bunch of arbitrarily chosen external values isn't exactly pretty, sure, but I do think the JDK should try to optimize for typical behavior, and the fact that many (most?) libraries on maven central have OSGi attributes ("Bundle-*") in their manifests is one such typical behavior, and this optimization was very low cost and net beneficial on most. With 8214712 the overhead cost is even less (almost zero in fact). /Claes From philipp.kunz at paratix.ch Tue Dec 4 08:34:47 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 04 Dec 2018 09:34:47 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: References: <1543664955.2437.5.camel@paratix.ch> Message-ID: <1543912487.2437.16.camel@paratix.ch> Hi Roger, I'm afraid the previous patch missed the tests, should be included this time. The intention of the patch is to solve only bug 8066619 about deprecation. I sincerely hope the changes are neutral. The new ValueUtf8Coding test heavily coincides/overlaps with 6202130 which is why I mentioned it. I'm however not satisfied that that test alone also completely solves 6202130 because 6202130 has or might have implications with breaking characters encoded in UTF-8 with more than one bytes across a line break onto a continuation line which is not part of the current patch proposed for 8066619. At some point I proposed ValueUtf8Coding with only removing the comments from the implementation in http://mail.openjdk.java.net/pipermail/core-libs-dev/ 2018-October/056166.html but I have changed my mind since then and think now 6202130 should also change the implementation not to break lines inside of multi-byte characters which is not part of the current patch and is probably easier after the current patch if necessary at all. Both 6202130 and the current patch for 8066619 here touch the UTF- 8 coding of manifests and which ever is solved first should add a corresponding test because no such test exists yet I believe. Worth to mention are test/jdk/tools/launcher/DiacriticTest.java and test/jdk/tools/launcher/UnicodeTest.java both of which test the JVM launch and have a somewhat different purpose. I haven't found any other test for the specifically changed lines of code apart from probably many tests that use manifests indirectly in some form.? Regards,Philipp On Mon, 2018-12-03 at 16:43 -0500, Roger Riggs wrote: > Hi Phillip, > > The amount detail obscures the general purpose. > And there appears to be more than 1. > The Jira issue IDs mentioned are 8066619 and 6202130. > > Is this functionally neutral and only fixes the deprecations? > > There is a mention that a test is needed for multi-byte chars, but a > test > is not included.? Is there an existing test for that? > > Its probably best to identify the main functional improvement (multi- > byte) > and fix the deprecation as a side effect. > > Thanks for digging through the issues and the explanations; > it will take a bit of study to unravel and understand everything in > this? > changeset. > > Regards, Roger > > > On 12/01/2018 06:49 AM, Philipp Kunz wrote: > > Find the proposed patch attached. Some comments and explanations, > > here: > > > > There is a quite interesting implementation in Manifest and > > Attributes > > worth quite some explanation. The way it used to work before was: > > > > 1. put manifest header name, colon and space into a StringBuffer > > -> the buffer now contains a string of characters each high-byte of > > which is zero as explained later why this is important. the high- > > bytes > > are zero because the set of allowed characters is very limited to > > ":", > > " ", "a" - "z", "A" - "Z", "0" - "9", "_", and "-" according to > > Attributes.Name#hash(String) so far with only the name and the > > separator and yet without the values. > > > > 2. if the value is not null, encode it in UTF-8 into a byte array > > and > > instantiate a String with it using deprecated > > String#String(byte[],int,int,int) resulting in a String with the > > same > > length as the byte array before holding one byte in each > > character's > > low-byte. This makes a difference for characters encoded with more > > than > > one byte in UTF-8. The new String is potentially longer than the > > original value. > > > > 3.?if the value is not null, append value to buffer. The one UTF-8 > > encoded byte per character from the appended string is preserved > > also > > in the buffer along with the previous buffer contents. > > > > 3alt. if the value is null, add "null" to the buffer. See > > java.lang.AbstractStringBuilder#append(String). Neither of the > > characters of "null" has a non-zero high-byte encoded as UTF-16 > > chars. > > > > 4. make72Safe inserts line breaks with continuation spaces. Note > > that > > the buffer here contains only one byte per character because all > > high- > > bytes are still zero so that line.length() and line.insert(index, > > ...) > > effectively operate with byte offsets and not characters. > > > > 5. buffer.toString() > > > > 6. DataOutputStream#writeBytes(String). First of all read the > > JavaDoc > > comment for it, which explains it all: > > ?????Writes out the string to the underlying output stream as a > > ?????sequence of bytes. Each character in the string is written > > out, in > > ?????sequence, by discarding its high eight bits. If no exception > > is > > ?????thrown, the counter written is incremented by the > > ?????length of s > > This restores the earlier UTF-8 encoding correctly. > > > > The topic has been discussed and mentioned already in > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/05294 > > 6.ht > > ml > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > String(byte[],int,int,int) works "well" or "well enough" only > > together > > with DataOutputStream#writeBytes(String). When removing > > String(byte[],int,int,int) from Manifest and Attributes because > > deprecated, it makes no sense to keep using > > DataOutputStream#writeBytes(String) either. > > > > For the same reason as?String#String(byte[],int,int,int) has been > > deprecated, I suggest to also deprecate > > java.io.DataOutput#writeBytes(String) as a separate issue. This > > might > > relate to https://bugs.openjdk.java.net/browse/JDK-6400767 but that > > one > > came to a different conclusion some ten years ago. > > > > I preferred to stick with the DataOutputStream even though not > > strictly > > necessary any more. It is and has been in the API of Attributes > > (unfortunately not private) and should better not be removed by > > changing the parameter type. Same for > > Manifest#make72Safe(StringBuffer) > > which I deprecated rather than having removed. Someone could have > > extended a class from Manifest and use such a method and when > > changing > > the signature it could no longer even compile in a far-fetched > > case. > > > > LINE_BREAK, CONTINUATION_SPACE, LINE_BREAK_BYTES, and > > LINE_BREAK_WITH_CONTINUATION_SPACE_BYTES should prevent having to > > invoke getBytes(UTF_8) over and over again on "\r\n" and "\r\n " > > with > > the idea to slightly improve performance this way. I figured it > > does > > not need JavaDoc comments but would be happy to add them if > > desired. > > > > I removed "XXX Need to handle UTF8 values." from Manifest#read > > after > > adding a test for it in ValueUtf8Coding. This change and test also > > relate to bug 6202130 but does not solve that one completely. > > ValueUtf8Coding demonstrates that Manifest can read UTF-8 encoded > > values which is a necessary test case to cover for this patch here. > > ValueUtf8Coding is the same test as already submitted and suggested > > earlier. See > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/t > > hrea > > d.html#55848 > > > > Indentation in Attributes#write(DataOutputStream) was five spaces > > on > > most lines. I?fixed indentation only on the lines changed anyway. > > > > I replaced String#String(byte[],int,int,String) with > > String#String(byte[],int,int,java.nio.charset.StandardCharsets.UTF_ > > 8) > > which as a difference does not declare to throw a > > java.io.UnsupportedEncodingException. That also replaced "UTF8" as > > a > > charset name which I would consider not optimal regarding > > sun.nio.cs.UTF_8#UTF_8() and sun.nio.cs.UTF_8#historicalName(). > > > > In my opinion there is still some duplicated or at least very > > similar > > code in Manifest#write, Attributes#writeMain, and Attributes#write > > but > > I preferred to change less rather than more and not to further > > refactor > > and re-combine it. > > > > In EmptyKeysAndValues and NullKeysAndValues tests I tried to > > demonstrate that the changed implementation does not change > > behaviour > > also in edge cases. I would have expected not having to test all > > these > > cases but then I realized it was possible to test and is therefore > > possible in a real use case as well however far-fetched. At least > > the > > > > ?????if (value != null) { > > > > lines (three times) most obviously demand to test the null value > > cases. > > > > I'm looking curiously forward to any kind of feedback or opinion. > > > > Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 27217 bytes Desc: not available URL: From magnus.ihse.bursie at oracle.com Tue Dec 4 10:42:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Dec 2018 11:42:30 +0100 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Message-ID: <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> On 2018-12-04 04:30, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> I think this is no longer needed since it only has imports. >> By the way, the style is to import each specific class and >> avoid wild card imports. > "import sun.nio.cs.*;" is required because of > SimpleEUCEncoder.java.template. > SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. > It means that, > * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package > * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext > package > I could not determine which package has SimpleEUCEncoder. > And same kind code is available on ISO2022_JP.java. > Please let me know if you know another way. I'm not sure I'm fully following the template intricacies here, but would this not be solved if IBM33722.java was made a template as well? Then you could do import $PACKAGE$. SimpleEUCEncoder Or so I'd think. /Magnus > >> TestIBMBugs: >> - Please use a style consistent with other methods in the class. >> In this case spaces are needed around "{" and "}, and a space >> after "," comma. > I'll changed. > >> - The new method bug8212794, includes a test for x-IBM33722. >> Is that needed since there does not appear to be a change for 33722? > Yes, it's no need. > > Could you review the fix again ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 05:50, Roger Riggs wrote: >> Hi Ichiroh, >> >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> I think this is no longer needed since it only has imports. >> By the way, the style is to import each specific class and >> avoid wild card imports. >> >> TestIBMBugs: >> - Please use a style consistent with other methods in the class. >> In this case spaces are needed around "{" and "}, and a space >> after "," comma. >> >> - The new method bug8212794, includes a test for x-IBM33722. >> Is that needed since there does not appear to be a change for 33722? >> >> Regards, Roger >> >> >> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix again ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>> I think it looks good but please let someone from core-libs review >>> it too. >>> >>> /Magnus >>>> >>>> I just fixed only IBM964 for JDK-8212794. >>>> (IBM29626C fix is not included) >>>> >>>> On non AIX platform (Linux), >>>> ibm-euctw alias is added for IBM964. >>>> >>>> Without fix >>>> $ jshell >>>> | Welcome to JShell -- Version 12-ea >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> With fix >>>> ====== >>>> $ jshell >>>> | Welcome to JShell -- Version 12-internal >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> On AIX platform >>>> IBM964 is moved to java.base module from jdk.charset module. >>>> >>>> ====== >>>> $ LANG=zh_TW jshell >>>> | Welcome to JShell -- Version 12-internal >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>> Hello Alan & Magnus. >>>>> >>>>> Sorry for you confusion. >>>>> I did many copy actions and rename actions. >>>>> So you may see, I added unexpected code into non AIX platform. >>>>> >>>>> I think I should not put 2 kind of modification. >>>>> >>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>> (also SimpleEUCEncoder.java is required) >>>>> >>>>> I'll submit code review again. >>>>> >>>>> Additionally, I'll touch >>>>> make/data/charsetmapping/charsets >>>>> make/data/charsetmapping/stdcs-aix >>>>> >>>>> I'll not touch >>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>> >>>>> My build machine is not so fast, after test is done. >>>>> I'll post new code. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>> >>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>> preferred outcome. >>>>>>> The support in the build to configure the charsets to include in >>>>>>> java.base on each platform has been working well. Charsets that >>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>> module and that has been working well too. From the result point >>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>> kept. >>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>> point that we've touched on in several threads here is dropping >>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>> will need build support. >>>>>> So build support for trivially adding specific charsets to specific >>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>>> then? >>>>>> >>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>> that needs build support? >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> -Alan >>>> >>> > From takiguc at linux.vnet.ibm.com Tue Dec 4 11:33:27 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 20:33:27 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> Message-ID: <688f9f696141dac6377b065472b79770@linux.vnet.ibm.com> Hello Magnus. IBM33722 should be in sun.nio.cs.ext package on jdk.charset module Because it's not used for default encoding on AIX platform. In case of template file, build tool checks make/data/charsetmapping/stdcs-aix file for this case. If class name is there, it will be migrated to sun.nio.cs package. About IBM33722, If IBM33722 is moved to sun.nio.cs package also, "import sun.nio.cs.*;" is no need on IBM33722.java If IBM33722 is not in stdcs-aix, "import sun.nio.cs.*;" is still required on IBM33722.java Thanks, Ichiroh Takiguchi On 2018-12-04 19:42, Magnus Ihse Bursie wrote: > On 2018-12-04 04:30, Ichiroh Takiguchi wrote: >> Hello Roger. >> >> Thank you for your suggestion. >> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> I think this is no longer needed since it only has imports. >>> By the way, the style is to import each specific class and >>> avoid wild card imports. >> "import sun.nio.cs.*;" is required because of >> SimpleEUCEncoder.java.template. >> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >> it. >> It means that, >> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >> package >> I could not determine which package has SimpleEUCEncoder. >> And same kind code is available on ISO2022_JP.java. >> Please let me know if you know another way. > I'm not sure I'm fully following the template intricacies here, but > would this not be solved if IBM33722.java was made a template as well? > Then you could do > import $PACKAGE$. SimpleEUCEncoder > Or so I'd think. > > /Magnus >> >>> TestIBMBugs: >>> - Please use a style consistent with other methods in the class. >>> In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >> I'll changed. >> >>> - The new method bug8212794, includes a test for x-IBM33722. >>> Is that needed since there does not appear to be a change for >>> 33722? >> Yes, it's no need. >> >> Could you review the fix again ? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-04 05:50, Roger Riggs wrote: >>> Hi Ichiroh, >>> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> I think this is no longer needed since it only has imports. >>> By the way, the style is to import each specific class and >>> avoid wild card imports. >>> >>> TestIBMBugs: >>> - Please use a style consistent with other methods in the class. >>> In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >>> >>> - The new method bug8212794, includes a test for x-IBM33722. >>> Is that needed since there does not appear to be a change for >>> 33722? >>> >>> Regards, Roger >>> >>> >>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix again ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>> I think it looks good but please let someone from core-libs review >>>> it too. >>>> >>>> /Magnus >>>>> >>>>> I just fixed only IBM964 for JDK-8212794. >>>>> (IBM29626C fix is not included) >>>>> >>>>> On non AIX platform (Linux), >>>>> ibm-euctw alias is added for IBM964. >>>>> >>>>> Without fix >>>>> $ jshell >>>>> | Welcome to JShell -- Version 12-ea >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> With fix >>>>> ====== >>>>> $ jshell >>>>> | Welcome to JShell -- Version 12-internal >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> On AIX platform >>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>> >>>>> ====== >>>>> $ LANG=zh_TW jshell >>>>> | Welcome to JShell -- Version 12-internal >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>> Hello Alan & Magnus. >>>>>> >>>>>> Sorry for you confusion. >>>>>> I did many copy actions and rename actions. >>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>> >>>>>> I think I should not put 2 kind of modification. >>>>>> >>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>> (also SimpleEUCEncoder.java is required) >>>>>> >>>>>> I'll submit code review again. >>>>>> >>>>>> Additionally, I'll touch >>>>>> make/data/charsetmapping/charsets >>>>>> make/data/charsetmapping/stdcs-aix >>>>>> >>>>>> I'll not touch >>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>> >>>>>> My build machine is not so fast, after test is done. >>>>>> I'll post new code. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> >>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>>> >>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>> preferred outcome. >>>>>>>> The support in the build to configure the charsets to include in >>>>>>>> java.base on each platform has been working well. Charsets that >>>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>>> module and that has been working well too. From the result point >>>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>>> kept. >>>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>>> point that we've touched on in several threads here is dropping >>>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>>> will need build support. >>>>>>> So build support for trivially adding specific charsets to >>>>>>> specific >>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>> presume, >>>>>>> then? >>>>>>> >>>>>>> Can you expand on the issue of dropping ebcdic? What's the >>>>>>> problem >>>>>>> that needs build support? >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>> >>>> >> From thomas.stuefe at gmail.com Tue Dec 4 13:07:55 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Dec 2018 14:07:55 +0100 Subject: RFR 4947890 : Minimize JNI upcalls in system-properties initialization In-Reply-To: References: Message-ID: Hi Roger, There is a difference now as to how java.specification.version is set. - PUTPROP(props, "java.specification.version", - VERSION_SPECIFICATION); + props.setProperty("java.specification.version", VERSION_NUMBER); Was that intended? It seems to cause errors in our JTreg tests because the jtreg runner is expecting only the full version number without dots. Cheers, Thomas On Thu, Nov 15, 2018 at 2:12 AM Roger Riggs wrote: > > Hi Brent, > > > On 11/14/2018 06:54 PM, Brent Christian wrote: > > Hi, Roger > > > > * I like Mandy's idea of not combining the cli/VM props and the > > well-known props into a single array. Maybe we could then avoid > > copying between arrays (System.c L166). > yes, it would avoid the copy. > > > > * The name "Raw" doesn't really speak to me. It's OK as an inner > > class, though I wonder if everything could be done in SystemProps > > directly. > Raw to make it clear that these are not system properties, just data to > be used to > create the system properties. > > In some other prototyping, there were quite a few other changes in > SystemProps > so keeping the primitive data separate was useful, possibly the class > could be unloaded > since its use-once code. > > > > A few other comments: > > > > java.base/share/native/libjava/System.c: > > > > 112 * The first FIXED_LENGTH entries are the platform defined > > property values, no names. > > 113 * The remaining array indices are alternating key/value pairs > > 114 * supplied by the VM including those defined on the command line > > 115 * using -Dkey=value that may override the platform defined value. > > > > Some of this would also be useful information SystemProps.java, maybe > > in the comment for Raw.initProps. Or refer the reader to > > Java_jdk_internal_util_SystemProps_00024Raw_getRawProperties for a > > description of the layout of the array. Or may become moot if we use > > two separate arrays. > Agreed, a more complete description would be good in the declaration of > the native method. > > > > -- > > > > file.encoding used to be set from sprops->encoding on Mac, and > > sprops->sun_jnu_encoding otherwise: > > > > 382 #ifdef MACOSX > > 383 /* > > 384 * Since sun_jnu_encoding is now hard-coded to UTF-8 on > > Mac, we don't > > 385 * want to use it to overwrite file.encoding > > 386 */ > > 387 PUTPROP(props, "file.encoding", sprops->encoding); > > 388 #else > > 389 PUTPROP(props, "file.encoding", sprops->sun_jnu_encoding); > > 390 #endif > > > > There is no longer an ifdef for this. But I guess this is OK, as > > SystemProps.initProperties() will only put a value for "file.encoding" > > if there isn't one, and only uses sun.jnu.encoding if there is no > > file.encoding: > > > > 59 putIfAbsent(props, "file.encoding", > > 60 ((raw.propDefault(Raw._file_encoding_NDX) == null) > > 61 ? raw.propDefault(Raw._sun_jnu_encoding_NDX) > > 62 : raw.propDefault(Raw._file_encoding_NDX))); > > > Yes, I spent some time ensuring that the result was the same. > Thanks for confirming the logic. > > -- > > > > 313 * Command line overrides with -D are copied above from > > JVM_getProperties. > > > > s/JVM_get/JVM_Get/ > right, fixed, Java naming conventions bleeding into native. > > > > > > java.base/share/classes/jdk/internal/util/SystemProps.java: > > > > 126 /** > > 127 * Puts the property if it is non-null > > 128 * @param props the Properties > > 129 * @param key the key > > 130 * @param value the value > > 131 */ > > 132 private static void put(Properties props, String key, String > > value) { > > > > I notice that this method is only called once. > Yes, at the moment, that is the only property that must not be > overridden on the command line. > There are others that probably should not be overridable but for > compatibility... > > > > -- > > > > 175 cmdProps.put(disp, dispValue); > > ... > > 186 cmdProps.put(fmt, fmtValue); > > ) { > > > > } else if ( > > Aren't L175 & L186 just putting the property that is already there ? > Oops, that's a carryover from a different implementation that had > separate maps. > Those can be removed since an I18N property on the command is always > retained > only defined if the platform value is supplied and different than the base. > > Thanks for the review and suggestions > > Roger > > > > > Thanks, > > -Brent > > > > On 11/13/18 7:59 AM, Roger Riggs wrote: > >> Please review a re-implementation of the initialization of System > >> properties > >> moving some functions from native to Java. > >> > >> The upcalls from native to java for each property are replaced by a > >> mechanism > >> to gather the platform, VM and command line properties and return them > >> from a single JNI call. The creation of the Properties instance and > >> applying > >> command line overrides is handled in Java instead of native. > >> > >> The JVM_initProperties interface in Hotspot is replaced by > >> JVM_getProperties. > >> > >> Webrev: > >> http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/ > >> > >> Issue: > >> https://bugs.openjdk.java.net/browse/JDK-4947890 > >> > >> Thanks, Roger > >> > From dmitry.chuyko at bell-sw.com Tue Dec 4 13:18:44 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 4 Dec 2018 16:18:44 +0300 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <09a1553c-558c-fb67-9609-a544e50db43c@oracle.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <09a1553c-558c-fb67-9609-a544e50db43c@oracle.com> Message-ID: <631d6b30-7a9d-989d-74db-f650d4f6f4e8@bell-sw.com> Hello, AArch64 aes test runs pass in -Dmode=GCM. -Dmitry On 12/2/18 3:37 AM, Vladimir Kozlov wrote: > I am fine with Hotspot changes. > > But we need to verify changes on all platforms. > I see that aarch64 also supports it in addition to SPARC. > > I will run compiler/codegen/aes/ test to make sure it pass on SPARC > but we don't test aarch64. > I let you know testing results when they are done. > > Thanks, > Vladimir > > > On 11/20/18 6:45 PM, Kamath, Smita wrote: >> Hi Tony, >> >> Thanks for your comments. >> >> 1)? This intrinsic is also used with solaris-sparc, has there been a >> sanity check by anyone to make sure this does not break the sparc >> intrinsic? It may work as the code is now since the sparc intrinsic >> will only use the first two longs in the subkeyHtbl. >> Would it be possible to help with this sanity check?? I don't have >> the required set-up to test this scenario. >> >> 2) I have changed the code so that subkeyH corresponds to the first >> two entries of subkeyHtbl.? Please find the updated webrev link. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >> >> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >> >> Thanks and Regards, >> Smita >> >> >> >> -----Original Message----- >> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >> Sent: Tuesday, November 20, 2018 2:05 PM >> To: Kamath, Smita ; 'Vladimir Kozlov' >> >> Cc: Viswanathan, Sandhya ; >> core-libs-dev at openjdk.java.net; hotspot compiler >> >> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX >> instructions >> >> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>> Instructions. I have tested this optimization on SKX x86_64 platform >>> and it shows ~20-30% performance improvement for larger message sizes >>> (for example 8k). >>> >>> I, smita.kamath at intel.com , Shay >>> Gueuron, (shay.gueron at intel.com )and >>> Regev Shemy (regev.shemy at intel.com ) are >>> contributors to this code. >>> >>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>> >>> For testing the implementation, I have executed TestAESMain.java. I >>> have executed Jtreg tests and tested this code on 64 bit Windows and >>> Linux platforms. >>> >>> Please review and let me know if you have any comments. >>> >>> Thanks and Regards, >>> >>> Smita >>> >> >> Hi, >> >> This intrinsic is also used with solaris-sparc, has there been a >> sanity check by anyone to make sure this does not break the sparc >> intrinsic? >> It may work as the code is now since the sparc intrinsic will only >> use the first two longs in the subkeyHtbl. >> >> In that same idea, have you consider combining the subkeyH to be the >> first two of subkeyHtbl for the non-avx operations?? It would >> eliminate an extra two longs per instance. >> >> Tony >> From james.laskey at oracle.com Tue Dec 4 13:22:09 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 4 Dec 2018 09:22:09 -0400 Subject: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed In-Reply-To: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> References: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> Message-ID: <075DEBAC-6B26-4694-A47A-17D71B9815E1@oracle.com> +1 > On Dec 3, 2018, at 5:45 PM, Roger Riggs wrote: > > Ping? > > On 11/27/2018 02:04 PM, Roger Riggs wrote: >> Please review a test update to address an intermittent test failure. >> The test is modified to accept the current implementation behavior of the input streams >> from processes that may under race conditions with close throw IOE("Stream closed"). >> >> Details and analysis in the Jira: >> https://bugs.openjdk.java.net/browse/JDK-8171426 >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426/ >> >> Thanks, Roger >> > From Roger.Riggs at oracle.com Tue Dec 4 14:14:11 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 09:14:11 -0500 Subject: RFR 4947890 : Minimize JNI upcalls in system-properties initialization In-Reply-To: References: Message-ID: <2a38a642-dbcd-b8d9-caa6-c002c8bf0329@oracle.com> Hi Thomas, No change was intended. I'll file a bug and fix it shortly. Roger On 12/04/2018 08:07 AM, Thomas St?fe wrote: > Hi Roger, > > There is a difference now as to how java.specification.version is set. > > - PUTPROP(props, "java.specification.version", > - VERSION_SPECIFICATION); > > + props.setProperty("java.specification.version", VERSION_NUMBER); > > Was that intended? > > It seems to cause errors in our JTreg tests because the jtreg runner > is expecting only the full version number without dots. > > Cheers, Thomas > > > > On Thu, Nov 15, 2018 at 2:12 AM Roger Riggs wrote: >> Hi Brent, >> >> >> On 11/14/2018 06:54 PM, Brent Christian wrote: >>> Hi, Roger >>> >>> * I like Mandy's idea of not combining the cli/VM props and the >>> well-known props into a single array. Maybe we could then avoid >>> copying between arrays (System.c L166). >> yes, it would avoid the copy. >>> * The name "Raw" doesn't really speak to me. It's OK as an inner >>> class, though I wonder if everything could be done in SystemProps >>> directly. >> Raw to make it clear that these are not system properties, just data to >> be used to >> create the system properties. >> >> In some other prototyping, there were quite a few other changes in >> SystemProps >> so keeping the primitive data separate was useful, possibly the class >> could be unloaded >> since its use-once code. >>> A few other comments: >>> >>> java.base/share/native/libjava/System.c: >>> >>> 112 * The first FIXED_LENGTH entries are the platform defined >>> property values, no names. >>> 113 * The remaining array indices are alternating key/value pairs >>> 114 * supplied by the VM including those defined on the command line >>> 115 * using -Dkey=value that may override the platform defined value. >>> >>> Some of this would also be useful information SystemProps.java, maybe >>> in the comment for Raw.initProps. Or refer the reader to >>> Java_jdk_internal_util_SystemProps_00024Raw_getRawProperties for a >>> description of the layout of the array. Or may become moot if we use >>> two separate arrays. >> Agreed, a more complete description would be good in the declaration of >> the native method. >>> -- >>> >>> file.encoding used to be set from sprops->encoding on Mac, and >>> sprops->sun_jnu_encoding otherwise: >>> >>> 382 #ifdef MACOSX >>> 383 /* >>> 384 * Since sun_jnu_encoding is now hard-coded to UTF-8 on >>> Mac, we don't >>> 385 * want to use it to overwrite file.encoding >>> 386 */ >>> 387 PUTPROP(props, "file.encoding", sprops->encoding); >>> 388 #else >>> 389 PUTPROP(props, "file.encoding", sprops->sun_jnu_encoding); >>> 390 #endif >>> >>> There is no longer an ifdef for this. But I guess this is OK, as >>> SystemProps.initProperties() will only put a value for "file.encoding" >>> if there isn't one, and only uses sun.jnu.encoding if there is no >>> file.encoding: >>> >>> 59 putIfAbsent(props, "file.encoding", >>> 60 ((raw.propDefault(Raw._file_encoding_NDX) == null) >>> 61 ? raw.propDefault(Raw._sun_jnu_encoding_NDX) >>> 62 : raw.propDefault(Raw._file_encoding_NDX))); >>> >> Yes, I spent some time ensuring that the result was the same. >> Thanks for confirming the logic. >>> -- >>> >>> 313 * Command line overrides with -D are copied above from >>> JVM_getProperties. >>> >>> s/JVM_get/JVM_Get/ >> right, fixed, Java naming conventions bleeding into native. >>> >>> java.base/share/classes/jdk/internal/util/SystemProps.java: >>> >>> 126 /** >>> 127 * Puts the property if it is non-null >>> 128 * @param props the Properties >>> 129 * @param key the key >>> 130 * @param value the value >>> 131 */ >>> 132 private static void put(Properties props, String key, String >>> value) { >>> >>> I notice that this method is only called once. >> Yes, at the moment, that is the only property that must not be >> overridden on the command line. >> There are others that probably should not be overridable but for >> compatibility... >>> -- >>> >>> 175 cmdProps.put(disp, dispValue); >>> ... >>> 186 cmdProps.put(fmt, fmtValue); >>> ) { >>> >>> } else if ( >>> Aren't L175 & L186 just putting the property that is already there ? >> Oops, that's a carryover from a different implementation that had >> separate maps. >> Those can be removed since an I18N property on the command is always >> retained >> only defined if the platform value is supplied and different than the base. >> >> Thanks for the review and suggestions >> >> Roger >> >>> Thanks, >>> -Brent >>> >>> On 11/13/18 7:59 AM, Roger Riggs wrote: >>>> Please review a re-implementation of the initialization of System >>>> properties >>>> moving some functions from native to Java. >>>> >>>> The upcalls from native to java for each property are replaced by a >>>> mechanism >>>> to gather the platform, VM and command line properties and return them >>>> from a single JNI call. The creation of the Properties instance and >>>> applying >>>> command line overrides is handled in Java instead of native. >>>> >>>> The JVM_initProperties interface in Hotspot is replaced by >>>> JVM_getProperties. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-4947890 >>>> >>>> Thanks, Roger >>>> From thomas.stuefe at gmail.com Tue Dec 4 14:18:18 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Dec 2018 15:18:18 +0100 Subject: RFR 4947890 : Minimize JNI upcalls in system-properties initialization In-Reply-To: <2a38a642-dbcd-b8d9-caa6-c002c8bf0329@oracle.com> References: <2a38a642-dbcd-b8d9-caa6-c002c8bf0329@oracle.com> Message-ID: Thanks Roger! On Tue, Dec 4, 2018 at 3:14 PM Roger Riggs wrote: > > Hi Thomas, > > No change was intended. > > I'll file a bug and fix it shortly. > > Roger > > > On 12/04/2018 08:07 AM, Thomas St?fe wrote: > > Hi Roger, > > There is a difference now as to how java.specification.version is set. > > - PUTPROP(props, "java.specification.version", > - VERSION_SPECIFICATION); > > + props.setProperty("java.specification.version", VERSION_NUMBER); > > Was that intended? > > It seems to cause errors in our JTreg tests because the jtreg runner > is expecting only the full version number without dots. > > Cheers, Thomas > > > > On Thu, Nov 15, 2018 at 2:12 AM Roger Riggs wrote: > > Hi Brent, > > > On 11/14/2018 06:54 PM, Brent Christian wrote: > > Hi, Roger > > * I like Mandy's idea of not combining the cli/VM props and the > well-known props into a single array. Maybe we could then avoid > copying between arrays (System.c L166). > > yes, it would avoid the copy. > > * The name "Raw" doesn't really speak to me. It's OK as an inner > class, though I wonder if everything could be done in SystemProps > directly. > > Raw to make it clear that these are not system properties, just data to > be used to > create the system properties. > > In some other prototyping, there were quite a few other changes in > SystemProps > so keeping the primitive data separate was useful, possibly the class > could be unloaded > since its use-once code. > > A few other comments: > > java.base/share/native/libjava/System.c: > > 112 * The first FIXED_LENGTH entries are the platform defined > property values, no names. > 113 * The remaining array indices are alternating key/value pairs > 114 * supplied by the VM including those defined on the command line > 115 * using -Dkey=value that may override the platform defined value. > > Some of this would also be useful information SystemProps.java, maybe > in the comment for Raw.initProps. Or refer the reader to > Java_jdk_internal_util_SystemProps_00024Raw_getRawProperties for a > description of the layout of the array. Or may become moot if we use > two separate arrays. > > Agreed, a more complete description would be good in the declaration of > the native method. > > -- > > file.encoding used to be set from sprops->encoding on Mac, and > sprops->sun_jnu_encoding otherwise: > > 382 #ifdef MACOSX > 383 /* > 384 * Since sun_jnu_encoding is now hard-coded to UTF-8 on > Mac, we don't > 385 * want to use it to overwrite file.encoding > 386 */ > 387 PUTPROP(props, "file.encoding", sprops->encoding); > 388 #else > 389 PUTPROP(props, "file.encoding", sprops->sun_jnu_encoding); > 390 #endif > > There is no longer an ifdef for this. But I guess this is OK, as > SystemProps.initProperties() will only put a value for "file.encoding" > if there isn't one, and only uses sun.jnu.encoding if there is no > file.encoding: > > 59 putIfAbsent(props, "file.encoding", > 60 ((raw.propDefault(Raw._file_encoding_NDX) == null) > 61 ? raw.propDefault(Raw._sun_jnu_encoding_NDX) > 62 : raw.propDefault(Raw._file_encoding_NDX))); > > Yes, I spent some time ensuring that the result was the same. > Thanks for confirming the logic. > > -- > > 313 * Command line overrides with -D are copied above from > JVM_getProperties. > > s/JVM_get/JVM_Get/ > > right, fixed, Java naming conventions bleeding into native. > > java.base/share/classes/jdk/internal/util/SystemProps.java: > > 126 /** > 127 * Puts the property if it is non-null > 128 * @param props the Properties > 129 * @param key the key > 130 * @param value the value > 131 */ > 132 private static void put(Properties props, String key, String > value) { > > I notice that this method is only called once. > > Yes, at the moment, that is the only property that must not be > overridden on the command line. > There are others that probably should not be overridable but for > compatibility... > > -- > > 175 cmdProps.put(disp, dispValue); > ... > 186 cmdProps.put(fmt, fmtValue); > ) { > > } else if ( > Aren't L175 & L186 just putting the property that is already there ? > > Oops, that's a carryover from a different implementation that had > separate maps. > Those can be removed since an I18N property on the command is always > retained > only defined if the platform value is supplied and different than the base. > > Thanks for the review and suggestions > > Roger > > Thanks, > -Brent > > On 11/13/18 7:59 AM, Roger Riggs wrote: > > Please review a re-implementation of the initialization of System > properties > moving some functions from native to Java. > > The upcalls from native to java for each property are replaced by a > mechanism > to gather the platform, VM and command line properties and return them > from a single JNI call. The creation of the Properties instance and > applying > command line overrides is handled in Java instead of native. > > The JVM_initProperties interface in Hotspot is replaced by > JVM_getProperties. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-4947890 > > Thanks, Roger > > From Roger.Riggs at oracle.com Tue Dec 4 14:36:41 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 09:36:41 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Message-ID: <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Hi Ichiroh, On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> ??? I think this is no longer needed since it only has imports. >> ??? By the way, the style is to import each specific class and >> avoid wild card imports. > "import sun.nio.cs.*;" is required because of > SimpleEUCEncoder.java.template. > SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. > It means that, > * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package > * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext > package > I could not determine which package has SimpleEUCEncoder. > And same kind code is available on ISO2022_JP.java. > Please let me know if you know another way. I understand, it is because IBM33722 may or may not be in the same package as SimpleEUCEncoder. It is SimpleEUCEncoder that may be in a different package, not IBM33722. > >> TestIBMBugs: >> ? - Please use a style consistent with other methods in the class. >> ??? In this case spaces are needed around "{" and "}, and a space >> after "," comma. > I'll changed. 226-227:? add a space before "{" to have the same style as line 210. > >> ? - The new method bug8212794, includes a test for x-IBM33722. >> ??? Is that needed since there does not appear to be a change for 33722? > Yes, it's no need. > > Could you review the fix again ? > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, looks fine. Regards, Roger > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 05:50, Roger Riggs wrote: >> Hi Ichiroh, >> >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> ??? I think this is no longer needed since it only has imports. >> ??? By the way, the style is to import each specific class and >> avoid wild card imports. >> >> TestIBMBugs: >> ? - Please use a style consistent with other methods in the class. >> ??? In this case spaces are needed around "{" and "}, and a space >> after "," comma. >> >> ? - The new method bug8212794, includes a test for x-IBM33722. >> ??? Is that needed since there does not appear to be a change for 33722? >> >> Regards, Roger >> >> >> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix again ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>> I think it looks good but please let someone from core-libs review >>> it too. >>> >>> /Magnus >>>> >>>> I just fixed only IBM964 for JDK-8212794. >>>> (IBM29626C fix is not included) >>>> >>>> On non AIX platform (Linux), >>>> ibm-euctw alias is added for IBM964. >>>> >>>> Without fix >>>> $ jshell >>>> |? Welcome to JShell -- Version 12-ea >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> With fix >>>> ====== >>>> $ jshell >>>> |? Welcome to JShell -- Version 12-internal >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> On AIX platform >>>> IBM964 is moved to java.base module from jdk.charset module. >>>> >>>> ====== >>>> $ LANG=zh_TW jshell >>>> |? Welcome to JShell -- Version 12-internal >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>> Hello Alan & Magnus. >>>>> >>>>> Sorry for you confusion. >>>>> I did many copy actions and rename actions. >>>>> So you may see, I added unexpected code into non AIX platform. >>>>> >>>>> I think I should not put 2 kind of modification. >>>>> >>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>> (also SimpleEUCEncoder.java is required) >>>>> >>>>> I'll submit code review again. >>>>> >>>>> Additionally, I'll touch >>>>> make/data/charsetmapping/charsets >>>>> make/data/charsetmapping/stdcs-aix >>>>> >>>>> I'll not touch >>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>> >>>>> My build machine is not so fast, after test is done. >>>>> I'll post new code. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>> >>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>> preferred outcome. >>>>>>> The support in the build to configure the charsets to include in >>>>>>> java.base on each platform has been working well. Charsets that >>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>> module and that has been working well too. From the result point >>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>> kept. >>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>> point that we've touched on in several threads here is dropping >>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>> will need build support. >>>>>> So build support for trivially adding specific charsets to specific >>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>>> then? >>>>>> >>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>> that needs build support? >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> -Alan >>>> >>> > From takiguc at linux.vnet.ibm.com Tue Dec 4 15:21:12 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 00:21:12 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Message-ID: Hello Roger. Thank you for your suggestion. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ Thanks, Ichiroh Takiguchi On 2018-12-04 23:36, Roger Riggs wrote: > Hi Ichiroh, > > On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: >> Hello Roger. >> >> Thank you for your suggestion. >> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> ??? I think this is no longer needed since it only has imports. >>> ??? By the way, the style is to import each specific class and >>> avoid wild card imports. >> "import sun.nio.cs.*;" is required because of >> SimpleEUCEncoder.java.template. >> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >> it. >> It means that, >> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >> package >> I could not determine which package has SimpleEUCEncoder. >> And same kind code is available on ISO2022_JP.java. >> Please let me know if you know another way. > I understand, it is because IBM33722 may or may not be in the same > package as SimpleEUCEncoder. > It is SimpleEUCEncoder that may be in a different package, not > IBM33722. >> >>> TestIBMBugs: >>> ? - Please use a style consistent with other methods in the class. >>> ??? In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >> I'll changed. > 226-227:? add a space before "{" to have the same style as line 210. >> >>> ? - The new method bug8212794, includes a test for x-IBM33722. >>> ??? Is that needed since there does not appear to be a change for >>> 33722? >> Yes, it's no need. >> >> Could you review the fix again ? >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ > > Thanks, looks fine. > > Regards, Roger > >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-04 05:50, Roger Riggs wrote: >>> Hi Ichiroh, >>> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> ??? I think this is no longer needed since it only has imports. >>> ??? By the way, the style is to import each specific class and >>> avoid wild card imports. >>> >>> TestIBMBugs: >>> ? - Please use a style consistent with other methods in the class. >>> ??? In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >>> >>> ? - The new method bug8212794, includes a test for x-IBM33722. >>> ??? Is that needed since there does not appear to be a change for >>> 33722? >>> >>> Regards, Roger >>> >>> >>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix again ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>> I think it looks good but please let someone from core-libs review >>>> it too. >>>> >>>> /Magnus >>>>> >>>>> I just fixed only IBM964 for JDK-8212794. >>>>> (IBM29626C fix is not included) >>>>> >>>>> On non AIX platform (Linux), >>>>> ibm-euctw alias is added for IBM964. >>>>> >>>>> Without fix >>>>> $ jshell >>>>> |? Welcome to JShell -- Version 12-ea >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> With fix >>>>> ====== >>>>> $ jshell >>>>> |? Welcome to JShell -- Version 12-internal >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> On AIX platform >>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>> >>>>> ====== >>>>> $ LANG=zh_TW jshell >>>>> |? Welcome to JShell -- Version 12-internal >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>> Hello Alan & Magnus. >>>>>> >>>>>> Sorry for you confusion. >>>>>> I did many copy actions and rename actions. >>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>> >>>>>> I think I should not put 2 kind of modification. >>>>>> >>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>> (also SimpleEUCEncoder.java is required) >>>>>> >>>>>> I'll submit code review again. >>>>>> >>>>>> Additionally, I'll touch >>>>>> make/data/charsetmapping/charsets >>>>>> make/data/charsetmapping/stdcs-aix >>>>>> >>>>>> I'll not touch >>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>> >>>>>> My build machine is not so fast, after test is done. >>>>>> I'll post new code. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> >>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>>> >>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>> preferred outcome. >>>>>>>> The support in the build to configure the charsets to include in >>>>>>>> java.base on each platform has been working well. Charsets that >>>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>>> module and that has been working well too. From the result point >>>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>>> kept. >>>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>>> point that we've touched on in several threads here is dropping >>>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>>> will need build support. >>>>>>> So build support for trivially adding specific charsets to >>>>>>> specific >>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>> presume, >>>>>>> then? >>>>>>> >>>>>>> Can you expand on the issue of dropping ebcdic? What's the >>>>>>> problem >>>>>>> that needs build support? >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>> >>>> >> From nishit.jain at oracle.com Tue Dec 4 15:50:30 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 4 Dec 2018 21:20:30 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> <60acf63c-b9f8-49f2-e04d-4484a5327982@oracle.com> <6bf5dd71-471f-59b0-5ba8-5e9ce4e19dcd@oracle.com> <88571ad9-dd69-9d08-6a3d-e5e884a54ffe@oracle.com> Message-ID: <6a4ea7f0-2b5b-7b68-9aa6-d444e8bca472@oracle.com> Thanks Roger, Updated Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.06/ Regards, Nishit Jain On 04-12-2018 00:58, Roger Riggs wrote: > Hi Nishit, > > Thanks for the updates and cleanup. > > CompactNumberFormat.java: > > - 827: To locate a single character use: > ??????? if (pattern.indexOf(QUOTE) < 0) { ... } OK. > > - 1488:? Since infinite returns do not depend on any of the code after > line 1454, > ?? the 1488- 1494 could be moved to 1454. (It is correct where it is). The computeParseMultiplier decides whether parse string is positive or negative based on the prefix and suffix, so the status[STATUS_POSITIVE] can be also be used to return positive or negative infinity. Other minor changes in parse(): - Taken out "int numPosition" (line 1444 in webrev.05) and used earlier defined variable "position" instead, as "position" previous value is not used after that statement. - Moved the variable "Number multiplier;" (line 1447 in webrev.05) to the place where it is assigned the value. - Moved "Number cnfResult;" (line 1496 in webrev.05) inside else block. > > > ?- in API design, I would have put the position argument immediately > after text since the position > ?? is closely related to the text argument (in matchAffix and > matchPrefixAndSuffix methods). > ?? Its probably not worth the change in these private methods. Yes, it is better to move it next to "text". Updated both "matchAffix" and "matchPrefixAndSuffix" methods. Regards, Nishit Jain > > comments below... > > On 12/03/2018 07:22 AM, Nishit Jain wrote: >> Thanks Roger, >> >> Updated the webrev based on thebelow suggested changes and some clean >> up. >> >> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.05/ >> >> On 01-12-2018 01:03, Roger Riggs wrote: >>> Hi Nishit, >>> >>> Some comments, a couple of possible bugs and several performance >>> related issues >>> could be deferred. Both formatting and parsing seem to be quite >>> heavyweight >>> due to looping and combinatorics. >>> >>> >>> CompactNumberFormat.java >>> >>> >>> 661, 727, 1507: Is there a reason to convert the divisor to a string >>> and then re-parse it to create a new BigDecimal? >>> ??????? (IntelliJ observes that divide is called without a rounding >>> argument.) >>> ??????? Given that the divisors are all powers of 10 and the digit >>> list is a base 10 set of digits >>> ??????? it seems more efficient to just move the decimal point then >>> to do the math. >>> ??????? BTW, the divisor.toString() is preferred over concat with >>> "".? (looks like a hack). >>> >>> ??????? It would be more efficient to write two methods that would >>> pass the Number >>> ??????? and return a BigInteger or BigDecimal by dispatching on the >>> concrete type and >>> ??????? using the appropriate constructor. >> Changed concatenation with toString() and added a rounding parameter, >> but not getting the benefit of having two methods and returning >> respective concrete type using constructors. >> I didn't get the point of having two methods. Can you please elaborate? > The would the same function but different return types (BigInteger vs > BigDecimal). > The code is ok as is. >>> >>> 781:? @param prefix - the parameter name is suffix >>> >>> 804: move the int start = inside the if. >>> >>> 826:? expandAffix can be more efficient if tests the pattern for the >>> presence of QUOTE >>> ??????? and returns the pattern if the QUOTE is not present. That >>> would be the most common case. >>> >>> 914: Reduce the number of compares by reordering to: >>> ??????? if number > currentValue; multiply and continue >>> ??????? if number < currentValue break; >>> ??????? else ==; assign matched index and break; >>> >>> ??????? In the normal case, there will be only one compare in the >>> loop until it is to exit. >>> >>> 1109:? IntelliJ observes that within the case QUOTE, the if (ch == >>> QUOTE) is always true >>> ????? so the if is redundant. >> OK. >>> >>> 1205:? It looks odd to prepend two characters '- to the prefix. Is >>> the single quote correct? >>> ????? Where's the closing quote if so. >> It is to specify that the minus sign is a special character, which >> needs to be replaced with its localized equivalent at the time of >> formatting. >> >> Internally, there is a difference between a "minus sign prefix with a >> single quote" and a "minus sign" (it depends on how user specify the >> pattern), because the later one is considered as a literal and should >> be used exactly same in the formatted output, but the one prefixed >> with a single quote is replaced with its localized symbol using >> DecimalFormatSymbols.getMinusSign(). > thanks for the explanation. >> >>> 1394: matchedPosPrefix.length() is compared to negativePrefix.length(). >>> ????? That's an unusual mixing of positive and negative! Please >>> re-check. >> Yes, it was a mistake. >>> >>> 1363:? Can there be an early exit from this loop if one of the >>> prefixes is identified? >>> ????? The pattern of comparing for a prefix/suffix and the length >>> might warrant >>> ????? creating a private method to reduce the repetitive parts of >>> the code. >> I had thought about it, but it was difficult unless the whole list of >> affixes are traversed, because there is always a chance to get longer >> affix later in the list. I thought to sort the lists based on the >> length and do the match, but in that case indexes get disordered >> across lists (divisor, prefix, suffix, compact patterns), and >> computation will become more complicated. >> Updated the code by moving the repetitive parts in the loop to >> private methods. > Nice use of an private method to avoid code replication. >>> >>> 1593: extra space between "- ("; should be the same style as 1591 >>> >>> 1627, 1363: Is an early exit from this loop possible? >>> ?????? or a quick comparison to avoid the regionMatches. >>> ?????? Do the regionMatches *only if* the prefix/suffix is longer >>> than the suffix already compared? >> Yes, I think this can be done. Updated. > +1 >>> >>> 1721:? IntelliJ observes that if (gotNeg) is redundant since 1708 >>> rules out them being both true or both false. >> Updated > > Thanks, Roger > >> >> Regards, >> Nishit Jain >>> >>> Thanks, Roger >>> >>>> >>>> On 11/28/18 3:46 AM, Nishit Jain wrote: >>>>> Thanks Naoto, >>>>> >>>>> Updated. >>>>> >>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ >>>>> >>> >> > From Roger.Riggs at oracle.com Tue Dec 4 16:07:22 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:07:22 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Message-ID: <1c7e7226-7cda-f622-634a-77397467047d@oracle.com> Hi Ichiroh, Looks fine. I can sponsor that for you.? Tomorrow, though, to allow time for any other comments. Thanks, Roger On 12/04/2018 10:21 AM, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 23:36, Roger Riggs wrote: >> Hi Ichiroh, >> >> On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: >>> Hello Roger. >>> >>> Thank you for your suggestion. >>> >>>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>>> >>>> ??? I think this is no longer needed since it only has imports. >>>> ??? By the way, the style is to import each specific class and >>>> avoid wild card imports. >>> "import sun.nio.cs.*;" is required because of >>> SimpleEUCEncoder.java.template. >>> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >>> it. >>> It means that, >>> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >>> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >>> package >>> I could not determine which package has SimpleEUCEncoder. >>> And same kind code is available on ISO2022_JP.java. >>> Please let me know if you know another way. >> I understand, it is because IBM33722 may or may not be in the same >> package as SimpleEUCEncoder. >> It is SimpleEUCEncoder that may be in a different package, not IBM33722. >>> >>>> TestIBMBugs: >>>> ? - Please use a style consistent with other methods in the class. >>>> ??? In this case spaces are needed around "{" and "}, and a space >>>> after "," comma. >>> I'll changed. >> 226-227:? add a space before "{" to have the same style as line 210. >>> >>>> ? - The new method bug8212794, includes a test for x-IBM33722. >>>> ??? Is that needed since there does not appear to be a change for >>>> 33722? >>> Yes, it's no need. >>> >>> Could you review the fix again ? >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ >> >> Thanks, looks fine. >> >> Regards, Roger >> >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-12-04 05:50, Roger Riggs wrote: >>>> Hi Ichiroh, >>>> >>>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>>> >>>> ??? I think this is no longer needed since it only has imports. >>>> ??? By the way, the style is to import each specific class and >>>> avoid wild card imports. >>>> >>>> TestIBMBugs: >>>> ? - Please use a style consistent with other methods in the class. >>>> ??? In this case spaces are needed around "{" and "}, and a space >>>> after "," comma. >>>> >>>> ? - The new method bug8212794, includes a test for x-IBM33722. >>>> ??? Is that needed since there does not appear to be a change for >>>> 33722? >>>> >>>> Regards, Roger >>>> >>>> >>>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> >>>>>> Could you review the fix again ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>>> I think it looks good but please let someone from core-libs review >>>>> it too. >>>>> >>>>> /Magnus >>>>>> >>>>>> I just fixed only IBM964 for JDK-8212794. >>>>>> (IBM29626C fix is not included) >>>>>> >>>>>> On non AIX platform (Linux), >>>>>> ibm-euctw alias is added for IBM964. >>>>>> >>>>>> Without fix >>>>>> $ jshell >>>>>> |? Welcome to JShell -- Version 12-ea >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> With fix >>>>>> ====== >>>>>> $ jshell >>>>>> |? Welcome to JShell -- Version 12-internal >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm-euctw >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> On AIX platform >>>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>>> >>>>>> ====== >>>>>> $ LANG=zh_TW jshell >>>>>> |? Welcome to JShell -- Version 12-internal >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm-euctw >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>>> Hello Alan & Magnus. >>>>>>> >>>>>>> Sorry for you confusion. >>>>>>> I did many copy actions and rename actions. >>>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>>> >>>>>>> I think I should not put 2 kind of modification. >>>>>>> >>>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>>> (also SimpleEUCEncoder.java is required) >>>>>>> >>>>>>> I'll submit code review again. >>>>>>> >>>>>>> Additionally, I'll touch >>>>>>> make/data/charsetmapping/charsets >>>>>>> make/data/charsetmapping/stdcs-aix >>>>>>> >>>>>>> I'll not touch >>>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>>> >>>>>>> My build machine is not so fast, after test is done. >>>>>>> I'll post new code. >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> >>>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>>> sets in the build in general. :-( I'd really like to >>>>>>>>>> modernize it. I have a, slightly fuzzy, laundry list of >>>>>>>>>> things I want to fix from a build perspective, but I'm not >>>>>>>>>> sure of what "external" requirements are coming from AIX and >>>>>>>>>> the general core-libs agenda regarding character sets in >>>>>>>>>> general. >>>>>>>>>> >>>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>>> preferred outcome. >>>>>>>>> The support in the build to configure the charsets to include >>>>>>>>> in java.base on each platform has been working well. Charsets >>>>>>>>> that aren't in java.base go into the jdk.charsets service >>>>>>>>> provider module and that has been working well too. From the >>>>>>>>> result point of view, perhaps, but definitely not from the >>>>>>>>> build perspective. ;-) But yes, I understand this is >>>>>>>>> functionality that should be kept. >>>>>>>>> One thing that we lack is some way to add charsets for >>>>>>>>> specific platforms and this comes up with the IBM patches >>>>>>>>> where they are looking to adding several additional IBM >>>>>>>>> charsets. One starting point that we've touched on in several >>>>>>>>> threads here is dropping the EBCDIC charsets from the main >>>>>>>>> stream builds. Going there will need build support. >>>>>>>> So build support for trivially adding specific charsets to >>>>>>>> specific >>>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>>> presume, >>>>>>>> then? >>>>>>>> >>>>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>>>> that needs build support? >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> >>>>>>>>> -Alan >>>>>> >>>>> >>> > From Roger.Riggs at oracle.com Tue Dec 4 16:16:37 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:16:37 -0500 Subject: RFR 8214794 : java.specification.version should be only the major version number Message-ID: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> Please review correctly setting the java.specification.version property with only the major version number.? A test is added to ensure the java spec version agrees with the major version. The symptoms are that jtreg would fail with a full version number. Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ Thanks, Roger From Roger.Riggs at oracle.com Tue Dec 4 16:23:15 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:23:15 -0500 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> Message-ID: <47169a5a-8327-d126-68fa-0acaef8a7808@oracle.com> Including build-dev for the change to GensrcMisc.gmk. thx. On 12/04/2018 11:16 AM, Roger Riggs wrote: > Please review correctly setting the java.specification.version property > with only the major version number.? A test is added to ensure the > java spec version agrees with the major version. > > The symptoms are that jtreg would fail with a full version number. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ > > Thanks, Roger > > From martinrb at google.com Tue Dec 4 16:35:54 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 4 Dec 2018 08:35:54 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> Message-ID: > > I would make a stronger assertion, that Runtime.version().feature() > converted to a String is equal to specVersion, catching bogus specVersions > like "+011" From Roger.Riggs at oracle.com Tue Dec 4 16:58:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:58:27 -0500 Subject: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed In-Reply-To: References: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> Message-ID: <85f54068-9e4f-1c83-5093-7d2dd22514d5@oracle.com> Hi Brian, Jim, Thanks for the reviews. I simplify the description, the full details are in the bug report and are more complete. Updated webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426-1/ Thanks, Roger On 12/03/2018 04:49 PM, Brian Burkhalter wrote: > Hi Roger, > > L2:copyright year, of course > L2119: The verbiage seems a little obtuse. > > Otherwise, +1. > > Thanks, > > Brian > > On 11/27/2018 02:04 PM, Roger Riggs wrote: >> Please review a test update to address an intermittent test failure. >> The test is modified to accept the current implementation behavior of >> the input streams >> from processes that may under race conditions with close throw >> IOE("Stream closed"). >> >> Details and analysis in the Jira: >> https://bugs.openjdk.java.net/browse/JDK-8171426 >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426/ >> >> >> Thanks, Roger > From james.laskey at oracle.com Tue Dec 4 17:18:16 2018 From: james.laskey at oracle.com (James Laskey) Date: Tue, 4 Dec 2018 13:18:16 -0400 Subject: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed In-Reply-To: <85f54068-9e4f-1c83-5093-7d2dd22514d5@oracle.com> References: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> <85f54068-9e4f-1c83-5093-7d2dd22514d5@oracle.com> Message-ID: <00763608-3108-438C-A82E-4A920BFED4A0@oracle.com> I wasn?t as fussy about the original comment but this one is also fine. Sent from my iPhone > On Dec 4, 2018, at 12:58 PM, Roger Riggs wrote: > > Hi Brian, Jim, > > Thanks for the reviews. > > I simplify the description, the full details are in the bug report > and are more complete. > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426-1/ > > Thanks, Roger > > >> On 12/03/2018 04:49 PM, Brian Burkhalter wrote: >> Hi Roger, >> >> L2:copyright year, of course >> L2119: The verbiage seems a little obtuse. >> >> Otherwise, +1. >> >> Thanks, >> >> Brian >> >>> On 11/27/2018 02:04 PM, Roger Riggs wrote: >>> Please review a test update to address an intermittent test failure. >>> The test is modified to accept the current implementation behavior of the input streams >>> from processes that may under race conditions with close throw IOE("Stream closed"). >>> >>> Details and analysis in the Jira: >>> https://bugs.openjdk.java.net/browse/JDK-8171426 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426/ >>> >>> Thanks, Roger >> > From brian.burkhalter at oracle.com Tue Dec 4 17:26:09 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Dec 2018 09:26:09 -0800 Subject: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed In-Reply-To: <85f54068-9e4f-1c83-5093-7d2dd22514d5@oracle.com> References: <5f2f56d4-1988-56da-5635-65774f9f3cbf@oracle.com> <85f54068-9e4f-1c83-5093-7d2dd22514d5@oracle.com> Message-ID: <77540F5F-76AB-4F30-8174-A1B2FB51A51E@oracle.com> Hi Roger, > On Dec 4, 2018, at 8:58 AM, Roger Riggs wrote: > > Thanks for the reviews. You?re welcome. > I simplify the description, the full details are in the bug report > and are more complete. > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-basic-8171426-1/ Looks fine. Thanks, Brian From Roger.Riggs at oracle.com Tue Dec 4 18:34:42 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 13:34:42 -0500 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <6a4ea7f0-2b5b-7b68-9aa6-d444e8bca472@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> <60acf63c-b9f8-49f2-e04d-4484a5327982@oracle.com> <6bf5dd71-471f-59b0-5ba8-5e9ce4e19dcd@oracle.com> <88571ad9-dd69-9d08-6a3d-e5e884a54ffe@oracle.com> <6a4ea7f0-2b5b-7b68-9aa6-d444e8bca472@oracle.com> Message-ID: Hi Nishit, Thanks for the update.? Looks fine. I have no more comments. Roger On 12/04/2018 10:50 AM, Nishit Jain wrote: > Thanks Roger, > > Updated Webrev: > http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.06/ > > Regards, > Nishit Jain > On 04-12-2018 00:58, Roger Riggs wrote: >> Hi Nishit, >> >> Thanks for the updates and cleanup. >> >> CompactNumberFormat.java: >> >> - 827: To locate a single character use: >> ??????? if (pattern.indexOf(QUOTE) < 0) { ... } > OK. >> >> - 1488:? Since infinite returns do not depend on any of the code >> after line 1454, >> ?? the 1488- 1494 could be moved to 1454. (It is correct where it is). > The computeParseMultiplier decides whether parse string is positive or > negative based on the prefix and suffix, so the > status[STATUS_POSITIVE] can be also be used to return positive or > negative infinity. ok > > Other minor changes in parse(): > > - Taken out "int numPosition" (line 1444 in webrev.05) and used > earlier defined variable "position" instead, as "position" previous > value is not used after that statement. > - Moved the variable "Number multiplier;" (line 1447 in webrev.05) to > the place where it is assigned the value. > - Moved "Number cnfResult;" (line 1496 in webrev.05) inside else block. >> >> >> ?- in API design, I would have put the position argument immediately >> after text since the position >> ?? is closely related to the text argument (in matchAffix and >> matchPrefixAndSuffix methods). >> ?? Its probably not worth the change in these private methods. > Yes, it is better to move it next to "text". Updated both "matchAffix" > and "matchPrefixAndSuffix" methods. > > Regards, > Nishit Jain >> >> comments below... >> >> On 12/03/2018 07:22 AM, Nishit Jain wrote: >>> Thanks Roger, >>> >>> Updated the webrev based on thebelow suggested changes and some >>> clean up. >>> >>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.05/ >>> >>> On 01-12-2018 01:03, Roger Riggs wrote: >>>> Hi Nishit, >>>> >>>> Some comments, a couple of possible bugs and several performance >>>> related issues >>>> could be deferred. Both formatting and parsing seem to be quite >>>> heavyweight >>>> due to looping and combinatorics. >>>> >>>> >>>> CompactNumberFormat.java >>>> >>>> >>>> 661, 727, 1507: Is there a reason to convert the divisor to a >>>> string and then re-parse it to create a new BigDecimal? >>>> ??????? (IntelliJ observes that divide is called without a rounding >>>> argument.) >>>> ??????? Given that the divisors are all powers of 10 and the digit >>>> list is a base 10 set of digits >>>> ??????? it seems more efficient to just move the decimal point then >>>> to do the math. >>>> ??????? BTW, the divisor.toString() is preferred over concat with >>>> "".? (looks like a hack). >>>> >>>> ??????? It would be more efficient to write two methods that would >>>> pass the Number >>>> ??????? and return a BigInteger or BigDecimal by dispatching on the >>>> concrete type and >>>> ??????? using the appropriate constructor. >>> Changed concatenation with toString() and added a rounding >>> parameter, but not getting the benefit of having two methods and >>> returning respective concrete type using constructors. >>> I didn't get the point of having two methods. Can you please elaborate? >> The would the same function but different return types (BigInteger vs >> BigDecimal). >> The code is ok as is. >>>> >>>> 781:? @param prefix - the parameter name is suffix >>>> >>>> 804: move the int start = inside the if. >>>> >>>> 826:? expandAffix can be more efficient if tests the pattern for >>>> the presence of QUOTE >>>> ??????? and returns the pattern if the QUOTE is not present.? That >>>> would be the most common case. >>>> >>>> 914: Reduce the number of compares by reordering to: >>>> ??????? if number > currentValue; multiply and continue >>>> ??????? if number < currentValue break; >>>> ??????? else ==; assign matched index and break; >>>> >>>> ??????? In the normal case, there will be only one compare in the >>>> loop until it is to exit. >>>> >>>> 1109:? IntelliJ observes that within the case QUOTE, the if (ch == >>>> QUOTE) is always true >>>> ????? so the if is redundant. >>> OK. >>>> >>>> 1205:? It looks odd to prepend two characters '- to the prefix. Is >>>> the single quote correct? >>>> ????? Where's the closing quote if so. >>> It is to specify that the minus sign is a special character, which >>> needs to be replaced with its localized equivalent at the time of >>> formatting. >>> >>> Internally, there is a difference between a "minus sign prefix with >>> a single quote" and a "minus sign" (it depends on how user specify >>> the pattern), because the later one is considered as a literal and >>> should be used exactly same in the formatted output, but the one >>> prefixed with a single quote is replaced with its localized symbol >>> using DecimalFormatSymbols.getMinusSign(). >> thanks for the explanation. >>> >>>> 1394: matchedPosPrefix.length() is compared to >>>> negativePrefix.length(). >>>> ????? That's an unusual mixing of positive and negative! Please >>>> re-check. >>> Yes, it was a mistake. >>>> >>>> 1363:? Can there be an early exit from this loop if one of the >>>> prefixes is identified? >>>> ????? The pattern of comparing for a prefix/suffix and the length >>>> might warrant >>>> ????? creating a private method to reduce the repetitive parts of >>>> the code. >>> I had thought about it, but it was difficult unless the whole list >>> of affixes are traversed, because there is always a chance to get >>> longer affix later in the list. I thought to sort the lists based on >>> the length and do the match, but in that case indexes get disordered >>> across lists (divisor, prefix, suffix, compact patterns), and >>> computation will become more complicated. >>> Updated the code by moving the repetitive parts in the loop to >>> private methods. >> Nice use of an private method to avoid code replication. >>>> >>>> 1593: extra space between "- ("; should be the same style as 1591 >>>> >>>> 1627, 1363: Is an early exit from this loop possible? >>>> ?????? or a quick comparison to avoid the regionMatches. >>>> ?????? Do the regionMatches *only if* the prefix/suffix is longer >>>> than the suffix already compared? >>> Yes, I think this can be done. Updated. >> +1 >>>> >>>> 1721:? IntelliJ observes that if (gotNeg) is redundant since 1708 >>>> rules out them being both true or both false. >>> Updated >> >> Thanks, Roger >> >>> >>> Regards, >>> Nishit Jain >>>> >>>> Thanks, Roger >>>> >>>>> >>>>> On 11/28/18 3:46 AM, Nishit Jain wrote: >>>>>> Thanks Naoto, >>>>>> >>>>>> Updated. >>>>>> >>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ >>>>>> >>>> >>> >> > From stuart.marks at oracle.com Tue Dec 4 18:36:11 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 Dec 2018 10:36:11 -0800 Subject: RFR - JDK-8203442 String::transform (Code Review) In-Reply-To: References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com> <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com> <8b3c5d6d-b7b3-d1fb-6afe-2640e0f0b23f@gmail.com> <22754DF6-855F-4DE4-BE68-14379EFD822F@oracle.com> <411491802.1433014.1543616582400.JavaMail.zimbra@u-pem.fr> Message-ID: Hi everybody, I've finally caught up with all of this. I see that several people are surprised by the way this has turned out. As the first-named reviewer on this changeset, I felt I should try to figure out what happened. While this API point stands on its own, this is really part of Jim's RSL work [1] which includes several API additions to String, and which will likely have a significant effect on how String literals are used in Java code. Jim started code review [2] and CSR review [3] for this proposal back in September. There was a gap of several weeks, followed by a revised proposal on 12 Nov [4][5] that changed the method's name from "transform" to "map". There was further discussion over the next couple days; in particular there were some objections to the method name "map". On 26 Nov Jim pushed the changeset with the name changed back to "transform". From reading just the messages on the mailing list, I can certainly see why people were surprised. It looked like there was an issue open for discussion, yet Jim went ahead and pushed the revised change anyway. What happened? Given that the primary open issue was about naming, and such mailing list discussions can go on for an arbitrarily long time, Jim asked Brian off-list for a decision on this. The results were: 1) the name for this method on String should be "transform"; 2) adding library methods is a reasonable way for the platform to provide this capability (as opposed to various language enhancements that might be contemplated); and 3) the intent is to colonize the name "transform" for this operation on this and other classes, such as List, Optional, etc. (It may well be the case that there is no name that is a good fit for both Stream and for everything else, given Stream's highly stylized API; we can consider the tradeoffs between consistency and clarity when we get to that particular one.) The primary thing that went wrong here was that Brian and Jim neglected to circle back to the list to record this decision. This was an oversight. There could and should have been better communication about this. Brian, Jim, or I should have documented the results of this decision and followed up on the mailing list. None of us did. Sorry about that. What else should be done here? One thing is that we (I) can make a better effort to keep up on emails, though the volume -- on a wide variety of topics -- is significant. Another point is that issues that are raised on the mailing list are often discussed and resolved off the mailing list. While we make significant and ongoing efforts to write up relevant offline discussions for public consumption (see, for example, see the recent writeup on nullable values [6]), sometimes things will fall through the cracks. Finally, we should also record that this particular decision sets a precedent for the use of the name "transform" for methods that do similar things on other classes. To this end, I've updated this bug with a note about "transform": JDK-8140283 [7] add method to Stream that facilitates fluent chaining of other methods and I've also filed the following RFE: JDK-8214753 [8] (opt) add Optional::transform, allowing an arbitrary operation on an Optional s'marks [1] http://openjdk.java.net/jeps/326 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055532.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055533.html [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html [6] http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html [7] https://bugs.openjdk.java.net/browse/JDK-8140283 [8] https://bugs.openjdk.java.net/browse/JDK-8214753 From mandy.chung at oracle.com Tue Dec 4 18:41:19 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Dec 2018 10:41:19 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> Message-ID: <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> On 12/4/18 8:16 AM, Roger Riggs wrote: > Please review correctly setting the java.specification.version property > with only the major version number.? A test is added to ensure the > java spec version agrees with the major version. > > The symptoms are that jtreg would fail with a full version number. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ > Looks okay.?? I agree with Martin to go with a stronger assertion without converting into a number. test/jdk/java/lang/System/Versions.java looks like also covering this test case.? At some point it'd be good to consolidate these two tests. Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc are a relevant group.?? VERSION_SPECIFICATION can be moved to group with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. Mandy From naoto.sato at oracle.com Tue Dec 4 18:52:45 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 4 Dec 2018 10:52:45 -0800 Subject: [12] RFR: 8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. Message-ID: <1e9dfd21-0dd2-241a-c2c5-2dfdbb34d29f@oracle.com> Hello, Please review this simple fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8214770 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8214770/webrev.00/ It is simply specifying Locale.ROOT to expect the locale independent era names. Naoto From lance.andersen at oracle.com Tue Dec 4 18:59:13 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 4 Dec 2018 13:59:13 -0500 Subject: [12] RFR: 8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. In-Reply-To: <1e9dfd21-0dd2-241a-c2c5-2dfdbb34d29f@oracle.com> References: <1e9dfd21-0dd2-241a-c2c5-2dfdbb34d29f@oracle.com> Message-ID: <7280BA48-FFE0-4E33-969A-F9E12B31BFF4@oracle.com> Looks OK Naoto > On Dec 4, 2018, at 1:52 PM, naoto.sato at oracle.com wrote: > > Hello, > > Please review this simple fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8214770 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8214770/webrev.00/ > > It is simply specifying Locale.ROOT to expect the locale independent era names. > > Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Tue Dec 4 19:00:33 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Dec 2018 11:00:33 -0800 Subject: [12] RFR: 8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. In-Reply-To: <7280BA48-FFE0-4E33-969A-F9E12B31BFF4@oracle.com> References: <1e9dfd21-0dd2-241a-c2c5-2dfdbb34d29f@oracle.com> <7280BA48-FFE0-4E33-969A-F9E12B31BFF4@oracle.com> Message-ID: <130EE7C7-C3CD-479D-A7EE-27C0FF5321FE@oracle.com> +1 Brian > On Dec 4, 2018, at 10:59 AM, Lance Andersen wrote: > > Looks OK Naoto From brian.burkhalter at oracle.com Tue Dec 4 19:02:03 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Dec 2018 11:02:03 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <47169a5a-8327-d126-68fa-0acaef8a7808@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <47169a5a-8327-d126-68fa-0acaef8a7808@oracle.com> Message-ID: <5A631884-5824-459C-9AE0-49CD175C80BE@oracle.com> Hi Roger, Looks fine. Brian > On Dec 4, 2018, at 8:23 AM, Roger Riggs wrote: > > Including build-dev for the change to GensrcMisc.gmk. > > thx. > > On 12/04/2018 11:16 AM, Roger Riggs wrote: >> Please review correctly setting the java.specification.version property >> with only the major version number. A test is added to ensure the >> java spec version agrees with the major version. >> >> The symptoms are that jtreg would fail with a full version number. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2 From scolebourne at joda.org Tue Dec 4 19:13:00 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 4 Dec 2018 19:13:00 +0000 Subject: RFR - JDK-8203442 String::transform (Code Review) In-Reply-To: References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com> <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com> <8b3c5d6d-b7b3-d1fb-6afe-2640e0f0b23f@gmail.com> <22754DF6-855F-4DE4-BE68-14379EFD822F@oracle.com> <411491802.1433014.1543616582400.JavaMail.zimbra@u-pem.fr> Message-ID: Thank you for following up - we all know the core-libs team has a busy workload, and naming topics are always tricky. I'm personally unconvinced that `transform()` is the best name out there. While transform is OK for String and maybe Optional, it is poor for List and Stream. In addition, I'm still not overly convinced that this is an appropriate stylistic direction for Java to go more generally (though I fully agree with point #2 on language change below). However, since the core-libs team is clearly indicating a desire to close the topic, I have no personal intention of objecting further.. thanks Stephen On Tue, 4 Dec 2018 at 18:38, Stuart Marks wrote: > Hi everybody, > > I've finally caught up with all of this. I see that several people are > surprised > by the way this has turned out. As the first-named reviewer on this > changeset, I > felt I should try to figure out what happened. > > While this API point stands on its own, this is really part of Jim's RSL > work > [1] which includes several API additions to String, and which will likely > have a > significant effect on how String literals are used in Java code. > > Jim started code review [2] and CSR review [3] for this proposal back in > September. There was a gap of several weeks, followed by a revised > proposal on > 12 Nov [4][5] that changed the method's name from "transform" to "map". > > There was further discussion over the next couple days; in particular > there were > some objections to the method name "map". On 26 Nov Jim pushed the > changeset > with the name changed back to "transform". > > From reading just the messages on the mailing list, I can certainly see > why > people were surprised. It looked like there was an issue open for > discussion, > yet Jim went ahead and pushed the revised change anyway. What happened? > > Given that the primary open issue was about naming, and such mailing list > discussions can go on for an arbitrarily long time, Jim asked Brian > off-list for > a decision on this. The results were: > > 1) the name for this method on String should be "transform"; > > 2) adding library methods is a reasonable way for the platform to provide > this > capability (as opposed to various language enhancements that might be > contemplated); and > > 3) the intent is to colonize the name "transform" for this operation on > this and > other classes, such as List, Optional, etc. (It may well be the case that > there > is no name that is a good fit for both Stream and for everything else, > given > Stream's highly stylized API; we can consider the tradeoffs between > consistency > and clarity when we get to that particular one.) > > The primary thing that went wrong here was that Brian and Jim neglected to > circle back to the list to record this decision. This was an oversight. > > There could and should have been better communication about this. Brian, > Jim, or > I should have documented the results of this decision and followed up on > the > mailing list. None of us did. Sorry about that. > > What else should be done here? > > One thing is that we (I) can make a better effort to keep up on emails, > though > the volume -- on a wide variety of topics -- is significant. > > Another point is that issues that are raised on the mailing list are often > discussed and resolved off the mailing list. While we make significant and > ongoing efforts to write up relevant offline discussions for public > consumption > (see, for example, see the recent writeup on nullable values [6]), > sometimes > things will fall through the cracks. > > Finally, we should also record that this particular decision sets a > precedent > for the use of the name "transform" for methods that do similar things on > other > classes. To this end, I've updated this bug with a note about "transform": > > JDK-8140283 [7] add method to Stream that facilitates fluent chaining > of > other methods > > and I've also filed the following RFE: > > JDK-8214753 [8] (opt) add Optional::transform, allowing an arbitrary > operation on an Optional > > s'marks > > [1] http://openjdk.java.net/jeps/326 > > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055532.html > > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055533.html > > [4] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html > > [5] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html > > [6] > > http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html > > [7] https://bugs.openjdk.java.net/browse/JDK-8140283 > > [8] https://bugs.openjdk.java.net/browse/JDK-8214753 > > From mandy.chung at oracle.com Tue Dec 4 19:34:06 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Dec 2018 11:34:06 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: <58ff1ee9-69c6-e739-ec73-126ae7a94767@oracle.com> The revised webrev looks okay. Mandy On 12/4/18 11:32 AM, Roger Riggs wrote: > Hi Mandy, Martin, > > The new test is unnecessary, the case is covered by > java/lang/System/Versions test > and uses the stronger comparison for the version numbers. > > It would not detect the problem unless the version included more than > the major version. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ > > Thanks, Roger > > On 12/04/2018 01:41 PM, Mandy Chung wrote: >> >> >> On 12/4/18 8:16 AM, Roger Riggs wrote: >>> Please review correctly setting the java.specification.version property >>> with only the major version number.? A test is added to ensure the >>> java spec version agrees with the major version. >>> >>> The symptoms are that jtreg would fail with a full version number. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >>> >> >> Looks okay.?? I agree with Martin to go with a stronger assertion >> without converting into a number. >> test/jdk/java/lang/System/Versions.java looks like also covering this >> test case.? At some point it'd be good to consolidate these two tests. >> >> Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc >> are a relevant group.?? VERSION_SPECIFICATION can be moved to group >> with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. >> >> Mandy > From Roger.Riggs at oracle.com Tue Dec 4 19:32:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 14:32:00 -0500 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: Hi Mandy, Martin, The new test is unnecessary, the case is covered by java/lang/System/Versions test and uses the stronger comparison for the version numbers. It would not detect the problem unless the version included more than the major version. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ Thanks, Roger On 12/04/2018 01:41 PM, Mandy Chung wrote: > > > On 12/4/18 8:16 AM, Roger Riggs wrote: >> Please review correctly setting the java.specification.version property >> with only the major version number.? A test is added to ensure the >> java spec version agrees with the major version. >> >> The symptoms are that jtreg would fail with a full version number. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >> > > Looks okay.?? I agree with Martin to go with a stronger assertion > without converting into a number. > test/jdk/java/lang/System/Versions.java looks like also covering this > test case.? At some point it'd be good to consolidate these two tests. > > Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc > are a relevant group.?? VERSION_SPECIFICATION can be moved to group > with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. > > Mandy From erik.joelsson at oracle.com Tue Dec 4 20:40:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Dec 2018 12:40:10 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: <9d26387b-bd51-7824-1749-189ff5f0e6cd@oracle.com> Looks good. /Erik On 2018-12-04 11:32, Roger Riggs wrote: > Hi Mandy, Martin, > > The new test is unnecessary, the case is covered by > java/lang/System/Versions test > and uses the stronger comparison for the version numbers. > > It would not detect the problem unless the version included more than > the major version. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ > > Thanks, Roger > > On 12/04/2018 01:41 PM, Mandy Chung wrote: >> >> >> On 12/4/18 8:16 AM, Roger Riggs wrote: >>> Please review correctly setting the java.specification.version property >>> with only the major version number.? A test is added to ensure the >>> java spec version agrees with the major version. >>> >>> The symptoms are that jtreg would fail with a full version number. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >>> >> >> Looks okay.?? I agree with Martin to go with a stronger assertion >> without converting into a number. >> test/jdk/java/lang/System/Versions.java looks like also covering this >> test case.? At some point it'd be good to consolidate these two tests. >> >> Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc >> are a relevant group.?? VERSION_SPECIFICATION can be moved to group >> with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. >> >> Mandy > From martinrb at google.com Tue Dec 4 20:43:43 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 4 Dec 2018 12:43:43 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: > > LGTM From huizhe.wang at oracle.com Tue Dec 4 21:45:40 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 04 Dec 2018 13:45:40 -0800 Subject: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec In-Reply-To: <5BEF4463.1030601@oracle.com> References: <5BEBB025.9080204@oracle.com> <5BEDD682.1070200@oracle.com> <5BEF4463.1030601@oracle.com> Message-ID: <5C06F584.7050705@oracle.com> Hi Naoto and all, Could you please take a look at the changes to the resource files for tests of JDK-8172365 & JDK-8210408? Current webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v04/ Previous: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v03/ Thanks, Joe On 11/16/18, 2:27 PM, Joe Wang wrote: > Hi Daniel, > > On 11/16/18, 10:32 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> 1. It looks as if the parser will not complain if the root element >> is seen twice - and it looks as if it is a supported feature >> since the previous implementation also had a counter. >> >> Should this be tested? >> If this is a feature and multiple roots are supported >> then the new impl might have an issue with allowing only >> one comment (maybe). > > Removed "properties" from the ALLOWED_ELEMENTS so that it will report > an error on properties inside properties, and added a test > (IllegalElement.xml). >> >> 2. The rootElm qName is now set at two locations. Is the overridden >> method below still needed? Could it have been used instead of >> introducing a new startDTD method? >> >> 212 @Override >> 213 public void notationDecl(String name, String publicId, >> String systemId) throws SAXException { >> 214 rootElm = name; >> 215 } > > Removed the method override. startDTD is the correct place to > accomplish this. > > Updated webrev: > http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v03/ > > Previous: > http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ > > Best regards, > Joe > >> >> best regards, >> >> -- daniel >> >> On 15/11/2018 20:26, Joe Wang wrote: >>> Hi Daniel, >>> >>> I deleted the endDTD method. It could have been used to signal the >>> end of DTD parsing and therefore serve as a validation point. >>> However, the parser would have thrown Exceptions if a DTD parsing >>> wasn't completed properly, that seems to make an endDTD check >>> unnecessary, at least as the current parser impl goes. >>> >>> The small footprint parser has its problems, for example, not >>> providing specific error messages when things go wrong. But since >>> this is a Properties usage only, it serves the purpose well enough. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ >>> >>> Previous: >>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v01/ >>> >>> Best regards, >>> Joe >>> >>> On 11/14/18, 2:32 AM, Daniel Fuchs wrote: >>>> Hi Joe, >>>> >>>> I do not see where the new DTDHandler::endDTD methos is called. >>>> Is that an oversight or is there more magic? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 14/11/2018 05:18, Joe Wang wrote: >>>>> Hi, >>>>> >>>>> Please review a patch to bring the small footprint parser for >>>>> java.util.Properties compliant with the specification. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8213325 >>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/ >>>>> >>>>> Thanks, >>>>> Joe >>>> >> From naoto.sato at oracle.com Tue Dec 4 21:53:49 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 4 Dec 2018 13:53:49 -0800 Subject: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec In-Reply-To: <5C06F584.7050705@oracle.com> References: <5BEBB025.9080204@oracle.com> <5BEDD682.1070200@oracle.com> <5BEF4463.1030601@oracle.com> <5C06F584.7050705@oracle.com> Message-ID: Hi Joe, Those changes in the resource bundles look fine to me. Naoto On 12/4/18 1:45 PM, Joe Wang wrote: > Hi Naoto and all, > > Could you please take a look at the changes to the resource files for > tests of JDK-8172365 & JDK-8210408? > > Current webrevs: > http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v04/ > > Previous: > http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v03/ > > Thanks, > Joe > > On 11/16/18, 2:27 PM, Joe Wang wrote: >> Hi Daniel, >> >> On 11/16/18, 10:32 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> 1. It looks as if the parser will not complain if the root element >>> ?? is seen twice - and it looks as if it is a supported feature >>> ?? since the previous implementation also had a counter. >>> >>> ?? Should this be tested? >>> ?? If this is a feature and multiple roots are supported >>> ?? then the new impl might have an issue with allowing only >>> ?? one comment (maybe). >> >> Removed "properties" from the ALLOWED_ELEMENTS so that it will report >> an error on properties inside properties, and added a test >> (IllegalElement.xml). >>> >>> 2. The rootElm qName is now set at two locations. Is the overridden >>> ?? method below still needed? Could it have been used instead of >>> ?? introducing a new startDTD method? >>> >>> ?212???? @Override >>> ?213???? public void notationDecl(String name, String publicId, >>> String systemId) throws SAXException { >>> ?214???????? rootElm = name; >>> ?215???? } >> >> Removed the method override. startDTD is the correct place to >> accomplish this. >> >> Updated webrev: >> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v03/ >> >> Previous: >> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ >> >> Best regards, >> Joe >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 15/11/2018 20:26, Joe Wang wrote: >>>> Hi Daniel, >>>> >>>> I deleted the endDTD method. It could have been used to signal the >>>> end of DTD parsing and therefore serve as a validation point. >>>> However, the parser would have thrown Exceptions if a DTD parsing >>>> wasn't completed properly, that seems to make an endDTD check >>>> unnecessary, at least as the current parser impl goes. >>>> >>>> The small footprint parser has its problems, for example, not >>>> providing specific error messages when things go wrong. But since >>>> this is a Properties usage only, it serves the purpose well enough. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ >>>> >>>> Previous: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v01/ >>>> >>>> Best regards, >>>> Joe >>>> >>>> On 11/14/18, 2:32 AM, Daniel Fuchs wrote: >>>>> Hi Joe, >>>>> >>>>> I do not see where the new DTDHandler::endDTD methos is called. >>>>> Is that an oversight or is there more magic? >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 14/11/2018 05:18, Joe Wang wrote: >>>>>> Hi, >>>>>> >>>>>> Please review a patch to bring the small footprint parser for >>>>>> java.util.Properties compliant with the specification. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8213325 >>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/ >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>> >>> From huizhe.wang at oracle.com Tue Dec 4 21:55:22 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 04 Dec 2018 13:55:22 -0800 Subject: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec In-Reply-To: References: <5BEBB025.9080204@oracle.com> <5BEDD682.1070200@oracle.com> <5BEF4463.1030601@oracle.com> <5C06F584.7050705@oracle.com> Message-ID: <5C06F7CA.7010901@oracle.com> Thanks Naoto for the fast review! Best regards, Joe On 12/4/18, 1:53 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Those changes in the resource bundles look fine to me. > > Naoto > > On 12/4/18 1:45 PM, Joe Wang wrote: >> Hi Naoto and all, >> >> Could you please take a look at the changes to the resource files for >> tests of JDK-8172365 & JDK-8210408? >> >> Current webrevs: >> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v04/ >> >> Previous: >> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v03/ >> >> Thanks, >> Joe >> >> On 11/16/18, 2:27 PM, Joe Wang wrote: >>> Hi Daniel, >>> >>> On 11/16/18, 10:32 AM, Daniel Fuchs wrote: >>>> Hi Joe, >>>> >>>> 1. It looks as if the parser will not complain if the root element >>>> is seen twice - and it looks as if it is a supported feature >>>> since the previous implementation also had a counter. >>>> >>>> Should this be tested? >>>> If this is a feature and multiple roots are supported >>>> then the new impl might have an issue with allowing only >>>> one comment (maybe). >>> >>> Removed "properties" from the ALLOWED_ELEMENTS so that it will >>> report an error on properties inside properties, and added a test >>> (IllegalElement.xml). >>>> >>>> 2. The rootElm qName is now set at two locations. Is the overridden >>>> method below still needed? Could it have been used instead of >>>> introducing a new startDTD method? >>>> >>>> 212 @Override >>>> 213 public void notationDecl(String name, String publicId, >>>> String systemId) throws SAXException { >>>> 214 rootElm = name; >>>> 215 } >>> >>> Removed the method override. startDTD is the correct place to >>> accomplish this. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v03/ >>> >>> Previous: >>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ >>> >>> Best regards, >>> Joe >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 15/11/2018 20:26, Joe Wang wrote: >>>>> Hi Daniel, >>>>> >>>>> I deleted the endDTD method. It could have been used to signal the >>>>> end of DTD parsing and therefore serve as a validation point. >>>>> However, the parser would have thrown Exceptions if a DTD parsing >>>>> wasn't completed properly, that seems to make an endDTD check >>>>> unnecessary, at least as the current parser impl goes. >>>>> >>>>> The small footprint parser has its problems, for example, not >>>>> providing specific error messages when things go wrong. But since >>>>> this is a Properties usage only, it serves the purpose well enough. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ >>>>> >>>>> Previous: >>>>> http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v01/ >>>>> >>>>> Best regards, >>>>> Joe >>>>> >>>>> On 11/14/18, 2:32 AM, Daniel Fuchs wrote: >>>>>> Hi Joe, >>>>>> >>>>>> I do not see where the new DTDHandler::endDTD methos is called. >>>>>> Is that an oversight or is there more magic? >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 14/11/2018 05:18, Joe Wang wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review a patch to bring the small footprint parser for >>>>>>> java.util.Properties compliant with the specification. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8213325 >>>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/ >>>>>>> >>>>>>> Thanks, >>>>>>> Joe >>>>>> >>>> From anthony.scarpino at oracle.com Tue Dec 4 22:30:36 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 4 Dec 2018 14:30:36 -0800 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <631d6b30-7a9d-989d-74db-f650d4f6f4e8@bell-sw.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <09a1553c-558c-fb67-9609-a544e50db43c@oracle.com> <631d6b30-7a9d-989d-74db-f650d4f6f4e8@bell-sw.com> Message-ID: I believe we have at least two approvals, Vladimir and me. Unless there is something else to be done, I'll do a final sanity check and push the code wednesday or thursday. Tony On 12/4/18 5:18 AM, Dmitry Chuyko wrote: > Hello, > > AArch64 aes test runs pass in -Dmode=GCM. > > -Dmitry > > On 12/2/18 3:37 AM, Vladimir Kozlov wrote: >> I am fine with Hotspot changes. >> >> But we need to verify changes on all platforms. >> I see that aarch64 also supports it in addition to SPARC. >> >> I will run compiler/codegen/aes/ test to make sure it pass on SPARC >> but we don't test aarch64. >> I let you know testing results when they are done. >> >> Thanks, >> Vladimir >> >> >> On 11/20/18 6:45 PM, Kamath, Smita wrote: >>> Hi Tony, >>> >>> Thanks for your comments. >>> >>> 1)? This intrinsic is also used with solaris-sparc, has there been a >>> sanity check by anyone to make sure this does not break the sparc >>> intrinsic? It may work as the code is now since the sparc intrinsic >>> will only use the first two longs in the subkeyHtbl. >>> Would it be possible to help with this sanity check?? I don't have >>> the required set-up to test this scenario. >>> >>> 2) I have changed the code so that subkeyH corresponds to the first >>> two entries of subkeyHtbl.? Please find the updated webrev link. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >>> >>> Thanks and Regards, >>> Smita >>> >>> >>> >>> -----Original Message----- >>> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >>> Sent: Tuesday, November 20, 2018 2:05 PM >>> To: Kamath, Smita ; 'Vladimir Kozlov' >>> >>> Cc: Viswanathan, Sandhya ; >>> core-libs-dev at openjdk.java.net; hotspot compiler >>> >>> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX >>> instructions >>> >>> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>>> Instructions. I have tested this optimization on SKX x86_64 platform >>>> and it shows ~20-30% performance improvement for larger message sizes >>>> (for example 8k). >>>> >>>> I, smita.kamath at intel.com , Shay >>>> Gueuron, (shay.gueron at intel.com )and >>>> Regev Shemy (regev.shemy at intel.com ) are >>>> contributors to this code. >>>> >>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>>> >>>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>>> >>>> For testing the implementation, I have executed TestAESMain.java. I >>>> have executed Jtreg tests and tested this code on 64 bit Windows and >>>> Linux platforms. >>>> >>>> Please review and let me know if you have any comments. >>>> >>>> Thanks and Regards, >>>> >>>> Smita >>>> >>> >>> Hi, >>> >>> This intrinsic is also used with solaris-sparc, has there been a >>> sanity check by anyone to make sure this does not break the sparc >>> intrinsic? >>> It may work as the code is now since the sparc intrinsic will only >>> use the first two longs in the subkeyHtbl. >>> >>> In that same idea, have you consider combining the subkeyH to be the >>> first two of subkeyHtbl for the non-avx operations?? It would >>> eliminate an extra two longs per instance. >>> >>> Tony >>> From magnus.ihse.bursie at oracle.com Tue Dec 4 23:46:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Dec 2018 00:46:49 +0100 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <58ff1ee9-69c6-e739-ec73-126ae7a94767@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> <58ff1ee9-69c6-e739-ec73-126ae7a94767@oracle.com> Message-ID: <5453A6E3-EF47-4C7C-A562-129A37B547F0@oracle.com> Looks good to me, too. /Magnus > 4 dec. 2018 kl. 20:34 skrev Mandy Chung : > > The revised webrev looks okay. > > Mandy > >> On 12/4/18 11:32 AM, Roger Riggs wrote: >> Hi Mandy, Martin, >> >> The new test is unnecessary, the case is covered by java/lang/System/Versions test >> and uses the stronger comparison for the version numbers. >> >> It would not detect the problem unless the version included more than the major version. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ >> >> Thanks, Roger >> >>> On 12/04/2018 01:41 PM, Mandy Chung wrote: >>> >>> >>>> On 12/4/18 8:16 AM, Roger Riggs wrote: >>>> Please review correctly setting the java.specification.version property >>>> with only the major version number. A test is added to ensure the >>>> java spec version agrees with the major version. >>>> >>>> The symptoms are that jtreg would fail with a full version number. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >>>> >>> >>> Looks okay. I agree with Martin to go with a stronger assertion without converting into a number. test/jdk/java/lang/System/Versions.java looks like also covering this test case. At some point it'd be good to consolidate these two tests. >>> >>> Nit: in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc are a relevant group. VERSION_SPECIFICATION can be moved to group with VERSION_CLASSFILE_MAJOR and MINOR. Magnus may have an opinion. >>> >>> Mandy >> > From stuart.marks at oracle.com Wed Dec 5 00:52:58 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 Dec 2018 16:52:58 -0800 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: <929e22f5-beec-b7a2-a4ec-3a68dc4c5a17@oracle.com> References: <49f05954-fab6-3c0d-229a-37a10fb2f19f@oracle.com> <33976421-9dd4-430e-df32-2fd80743eb60@oracle.com> <929e22f5-beec-b7a2-a4ec-3a68dc4c5a17@oracle.com> Message-ID: On 12/4/18 12:32 AM, Claes Redestad wrote: > These non-standard and tool/library specific names appear in the manifest of a > great many jar files, for example on maven central, and including the most > common non-standard manifest attributes significantly reduce allocation churn > reading such manifests. Especially true for ones that were oft repeated within > the same manifest, e.g.,"Name" and "SHA1-Digest" for signed entries. > > Was it a crucial optimization? Probably not, a few percent on some startup > applications. > > Ideals vs trade-offs... Hard-coding a bunch of arbitrarily chosen external > values isn't exactly pretty, sure, but I do think the JDK should try to optimize > for typical behavior, and the fact that many (most?) libraries on maven central > have OSGi attributes ("Bundle-*") in their manifests is one such typical > behavior, and this optimization was very low cost and net beneficial on most. > With 8214712 the overhead cost is even less (almost zero in fact). It might be worth adding a comment to say that's where these names come from. That is, they appear to occur frequently "in the wild" but otherwise have no special significance or meaning in the JDK. Also, could addName() return a Map.Entry, and then you could just initialize KNOWN_NAMES using Map.ofEntries(), passing the whole list of entries from the addName() call? It might be preferable to building an intermediate HashMap. s'marks From brian.burkhalter at oracle.com Wed Dec 5 01:07:06 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Dec 2018 17:07:06 -0800 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> <0CA96647-3B5B-41CB-A368-86F5A957C73D@oracle.com> <2864b759-b7a3-1bbc-973c-239d96340de1@oracle.com> <48FF6FE1-1E16-468C-923A-A35CC9C6E88A@oracle.com> <5A44B287-CC4F-4904-ACE2-1621658BCE81@oracle.com> <9d34f98b-9ac2-2d95-896a-3ea36c28cc6f@oracle.com> <35EE3661-242A-48DD-8A5B-10B648E854C1@oracle.com> <45fac915-2dac-bd2d-0f3a-0409e11fe947@oracle.com> <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: Hi Daniel, You are correct: at line 154 ?n? should have been passed instead of ?-1? here: http://cr.openjdk.java.net/~bpb/6516099/webrev.08-delta/ Fixing that exposed an error in the test at line 222 which I?ve fixed. An updated version is at http://cr.openjdk.java.net/~bpb/6516099/webrev.09/ with the 08-09 delta at http://cr.openjdk.java.net/~bpb/6516099/webrev.08-09-delta/ Thanks, Brian > On Dec 3, 2018, at 9:27 AM, Daniel Fuchs wrote: > > Looks good to me, though I don't understand the change > at line 154: > > The comment says: > > 152 // skip(n) returns negative value: IOE > > but if you pass -1 - you're no longer calling skip(n)? From frank.yuan at oracle.com Wed Dec 5 02:19:43 2018 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 5 Dec 2018 10:19:43 +0800 Subject: RFR (12): 8213300: jaxp/unittest/transform/CR6551600Test.java fails due to exception in jdk/jdk CI Message-ID: <205b01d48c40$fda14ff0$f8e3efd0$@oracle.com> Hi all Would you like to review this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8213300 Webrev: http://cr.openjdk.java.net/~fyuan/8213300/webrev.00/ This patch made the following changes: 1. change the path of test file from the root directory of drive C to C:\temp directory 2. check if the UNC path is accessible before running the jaxp test 3. skip the test if it's not Windows because the UNC test is only valid on Windows Thanks Frank From dan.z.zhou at oracle.com Wed Dec 5 05:35:20 2018 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Wed, 5 Dec 2018 13:35:20 +0800 Subject: [12]RFR 8213127: Refactor test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh to plain java tests Message-ID: Hello, Please help review the fix for refactor test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh to plain java tests. Thank you. Bug: https://bugs.openjdk.java.net/browse/JDK-8213127 Webrev: http://cr.openjdk.java.net/~dzhou/8213127/webrev.02/ Regards, Dora From huizhe.wang at oracle.com Wed Dec 5 07:46:29 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 04 Dec 2018 23:46:29 -0800 Subject: RFR (12): 8213300: jaxp/unittest/transform/CR6551600Test.java fails due to exception in jdk/jdk CI In-Reply-To: <205b01d48c40$fda14ff0$f8e3efd0$@oracle.com> References: <205b01d48c40$fda14ff0$f8e3efd0$@oracle.com> Message-ID: <5C078255.2070807@oracle.com> Hi Frank, The change looks good to me. Thanks for fixing the failure! Best, Joe On 12/4/18, 6:19 PM, Frank Yuan wrote: > Hi all > > > > Would you like to review this patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213300 > > Webrev: http://cr.openjdk.java.net/~fyuan/8213300/webrev.00/ > > > > This patch made the following changes: > > 1. change the path of test file from the root directory of drive C to C:\temp directory > > 2. check if the UNC path is accessible before running the jaxp test > > 3. skip the test if it's not Windows because the UNC test is only valid on Windows > > > > Thanks > > Frank > > > From thomas.stuefe at gmail.com Wed Dec 5 08:05:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Dec 2018 09:05:12 +0100 Subject: CSR for posix_spawn on JDK 12 In-Reply-To: <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> <22b2861e-696d-b02c-184c-1173b0c55fdd@oracle.com> <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> Message-ID: Hi Roger, thanks for all your help, I appreciate it. I thought a while and got some fundamental doubts about the whole process, see inline. On Fri, Nov 30, 2018 at 9:21 PM Roger Riggs wrote: > > Hi Thomas, > > On 11/30/2018 02:06 PM, Thomas St?fe wrote: > > Hi Roger, > > I updated the CSR according to your feedback. I'm a bit at a loss > about the specification though. How should I specify the behavior of > the API without describing the implementation? > > What you wrote is fine. It does need to mention posix_spawn by name, > as that is the OS function being used. > > The notes about the behavior of libc, fit better as an explanation > in the description of the Solution than in the Specification section. > > > Also, since this patch only extends an existing implementation to > Linux, I would have thought there are there technical notes in place > describing POSIX_SPAWN on other platforms, which I would have just > refered to. I searched but could not really find anything. > > Nope, that's why it was a debugging tool for Martin, > not a documented implementation feature. See, here I start getting confused. Has this switch ever been an officially released feature? If yes, I should be able to find release notes, documentation etc I could refer to and/or copy from. If not, why should we file a CSR and a release note for adding an accepted value to a feature which has never been officially released? This explains also my problems in formulating the CSR/release note. How can I describe something without describing its implementation, if the something is just basically implementation and no feature. It has no discernible API the user would face, and the consequences for switching the feature are difficult to describe in 1-2 sentences without delving deeply into details. 1-2 sentences also run the risk of giving a false picture. Basically, I do not see a difference between this switch and any other diagnostic hotspot switch, e.g., and therefore am undecided on what to do here. (Should I redirect these questions to the original mail thread?) > > I'm not sure what the proper plural of Unix's is but Unices looks odd. > Perhaps avoid the issue and just say Unix platforms. > Unices is fine I think. See: https://en.wikipedia.org/wiki/Unix Most common is the conventional Unixes, but _Unices_, treating Unix as a Latin noun of the third declension, is also popular. The pseudo-Anglo-Saxon plural form Unixen is not common, although occasionally seen. Sun Microsystems, developer of the Solaris variant, has asserted that the term Unix is itself plural, referencing its many implementations.[42] (Unixen sounds weird and genglish though :) Thanks, Thomas > > On Fri, Nov 30, 2018 at 3:50 PM Roger Riggs wrote: > > Hi Thomas, > > Looks pretty good. > > Usually 'we' avoid the first person writing in the jira. > It makes them more readable in the long term, when there is no context for 'we'. > > - Describing it as 'experimental' gives the wrong impression > and has some magnified implications as that term is being used for > other major changes. > > - The compatibility risk should be corrected: > > Supplying an unknown value on the command line produces a java.lang.Error. > > % java -Djdk.lang.Process.launchMechanism=POSIX_SPAWN ... > > java.lang.Error: POSIX_SPAWN is not a supported process launch mechanism on this platform. > > - Since CSRs should be self contained, the specification section should explicitly > specify the behavior from the API point of view. CSRs should avoid describing > the implementation (though in this case, its not entirely possible). > The webrev of the impl is not relevant. > > Thanks, Roger > > > On 11/30/2018 03:32 AM, Thomas St?fe wrote: > > CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511 > > ..Thomas > > > From bourges.laurent at gmail.com Wed Dec 5 08:35:09 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 5 Dec 2018 09:35:09 +0100 Subject: Extending Java Arrays/Collection Sort API In-Reply-To: References: <18D01558-14D2-4971-BE69-F4B9DB648E87@oracle.com> Message-ID: John, Any feedback ? We could discuss that during next OpenJDK workshop, but I would prefer going slowly but surely. Laurent Le jeu. 29 nov. 2018 ? 17:52, Laurent Bourg?s a ?crit : > Hi John & Brian, > > Thanks for the proposed approach, I agree we are in the design discussion; > adding such API enhancements will take time, I said 13 to not hurry for 12 > (CSR...). > > John, you wrote me a very detailed letter, I will try to be more concise > and focus on Array.sort() API. > > Le jeu. 29 nov. 2018 ? 02:12, John Rose a ?crit : > >> >> > >> > In this renderer, I needed a fast sort algorithm on small almost sorted >> > arrays, but more important, to deal with 2 arrays: x values and their >> > corresponding edge indices (pointer like). I derived my MergeSort class >> to >> > perform 2 swaps (x & edge ptr) as Arrays.sort() or TimSort() did not >> > provide such API. >> >> There are two distinct requirements here: 1. Selecting or tweaking a >> sorting >> algorithms for particular expected patterns in the data set >> (almost-sorted). >> 2. Sorting two arrays in tandem, with one array supplying the sort key, >> and the other serving as a passively permuted payload ("PPP"). >> >> Re 1: Another pattern sometimes expected is range-bounded values, >> which may prompt consideration of bin-sort. Perhaps unique values. >> Permutation vectors have both properties. >> > > Yes, the discussion has 2 points: > - provide more sorting algorithms in the public API > - provide new sort variants handling indices > > For example, Julia has a simple sort API: > https://docs.julialang.org/en/v0.6.2/stdlib/sort/ > It provides several basic sort functions (isort, qsort, msort) but the > general sort() accepts optional custom comparison (less) & transformation > functions. > Moreover, another sortperm() function that returns a permutation vector of > indices, it accepts an optional custom comparison (less). > > > >> >> Re 2: In some cases, it's not two arrays that need the work. Sometimes >> it is one array of keys, plus an index set; this can be reduced to two >> arrays >> one of which is an int-array carrying indexes, but in some proposals you >> see >> such an int-array appearing only as an output, with an implicit input of >> the iota-vector for the other array's indexes. >> >> More deeply, sometimes the index array is concrete, but the array of keys >> is virtualized. Canonical example (for me) is a set of indexes into a >> data >> set such as a file. (These indexes are dense for compression algorithms >> like B-W, or could be sparse for lexical analysis of bulk text in situ.) >> To >> handle this properly, a good old index array is just fine, as long as the >> sort algorithm *also* accepts an int-comparator. >> >> There is no strong need to generalize to three arrays in tandem, or to >> have separate algorithms for treating additional arrays as containing >> secondary keys instead of PPP. This is because given a two-array tandem >> sort with PPP, plus an int-array sort with int-comparator, you can compose >> many other shapes at a modest footprint cost by adding two index vector >> to control the various sorts. >> > > So you propose 2 new variants: > - sort(int[]a, int[] b, low, high) where b values are permuted > - sort(int[]a, low, high, Comparator) where b values are permuted > > I proposed the 2 array variants: sort( int[] values, int[] indices, low, > high) as it helps when the user wants both values and indices sorted > (easier use), but this can be reduced to sort(int[] indices, low, high, > comparator) as the user can use the permutation vector (indices) to reorder > values. > > I would prefer adding the more general solution sort(int[] indices, low, > high, comparator) first. > > However, having extracted the values is really helpful for performance > (locality) and simplifies the sorting algorithms but costs more data swaps. > For example in Marlin, my comparator would be: > Comparator::compare(i,j) { > return Integer.compareTo(edges[i].x, edges[j].x); > } > However, my edge data are packed in an Unsafe buffer so it is more: > Comparator::compare(i,j) { > return Integer.compareTo(Unsafe.getInt(addr0 + i), Unsafe.getInt(addr0 > + j) ); > } > I wonder if such lookups may be costly (random access + overheads) in > contrary to having the values given as an extra int[]. > > If you want, I can prototype later both solutions... > > >> >> Simplified sketch of generalized tandem array sort: >> >> 1. Let L be the common length of the N arrays, A[N][L]. >> 2. Create a new int index array P initialized to iota(L). >> 3. Create an int-comparator C over 0<=i,j> A[*][j]. >> 4. Sort P using C. Now P is a permutation vector to be applied to each >> A[*]. >> 5. Create a second index array Q such that Q[P[i]] = i for all i. Q is >> P's inverse. >> 6. Tandem-sort each Q[*] (as a PPP) using a fresh copy of Q for each >> array. >> >> There is more than one way to do this; the above sketch is intended to be >> straightforward. The temp. space required is two length-L int arrays. >> > > I like you proposal, but I dislike object allocations so I would prefer > providing result arrays as arguments if possible. > In Marlin renderer, allocations are always done in its RendererContext + > XXXArrayCache (soft ref) to ensure no GC overhead. > > >> >> My point is that the "missing primitives" are something like a. reordering >> a PPP using a different array (either indexes or keys) for steering, and >> b. reordering an index vector (or other array of primitives) using a user >> supplied comparator. >> >> An iota generator would be nice too, as well as a permutation inverter. >> The tandem sort could be restricted to a "permute this array" operation, >> giving an index vector, although I don't think this simplifies the >> implementation, >> and it removes some use cases. But those are minor points. >> > > Could you illustrate that aspect ? > > >> >> > 1. I started discussing about extending the Java Sort API with Vladimir >> > Yaroslavskiy, the author of the famous Java DualPivotQuickSort, as he is >> > currently improving it. >> > >> > His coming DPQS 2018 class provides lot of sort algorithms, I propose to >> > make them public API through a facade method in Arrays class: >> > insertionSort(), heapSort(), mergeSort(), quickSort()... Of course, his >> > current code is dedicated to DPQS, but his algorithm implementation >> could >> > be generalized to propose the Best implementations as a public Java API >> > (stable & unstable sorts) >> > >> > For example in Marlin, I need trivial insertionSort() in the Helpers >> class, >> > my MergeSort could be replaced by another best implementation. >> > Let's not reinvent the wheel? >> >> Indeed, let's not. But remember that the JDK does not claim to be (and >> cannot be) a collection of all the "wheels" we might need. >> > > I quoted Julia API as it provides only 3 basic algorithms and OpenJDK > already has such implementations but not publicly exposed. That was my > first request. Ideally these implementations will be the fastest possible > (optimized).Moreover, isort() could rely on a new intrinsics to be as fast > as possible (native code) ? > > >> >> Here's an extra thought or two on tweakable algorithms: One algorithm >> doesn't >> fit all data sets although it's amazing how far we've gone in optimizing >> the JDK's >> only sort algorithm. The JDK can't support many new algorithms to go >> with sort >> (and, ahem, parallelSort), as insertionSort, mergeSort, etc., etc. Doing >> this would >> amount to having a bunch of partially usable sort routines, more like >> "tryThiseSort" >> "orTryThisIfItDidNotWork", or "dontUseThisSort". Actually documenting >> and testing >> a multi-kinded API for {insertion,merge,parallel,plain}Sort would be a >> nightmare, >> IMO, since the properties of sort algorithms are hard to explain and >> verify. >> > > That was not my proposal, just few sort implementations that have their > own interest and are commonly useful within OpenJDK at least. > > >> >> It would be better if we could define an API for sorting algorithms, that >> a provider >> could set up. Then the various API points in Arrays.*sort(*) could be >> documented >> as sugar for specific standard providers, via the API. The provider API >> could >> include not only first-class entry points for sorting various kinds of >> arrays or >> tandem array pairs, but also provide queries for a user who wanted to be >> smart >> about which provider to choose. >> > > That's a good idea, it looks like julia sort() that accepts an extra > algorithm argument to select the algorithm to use. > > >> >> > 2. New Sort API to deal with indices... >> > >> > For now, there is no mean to obtain the indices sorted on another value, >> > see my introduction: edge indices sorted by their x positions. >> > In data science, this is very useful and general. >> > >> > What about an Arrays API extension: >> > - Arrays.sort(int[] a, int[] b, low, high) or >> > Indices int[] Arrays.sortIndices(int[] a, low high), a[] left untouched >> >> Yes, good. I don't think sortIndices buys much, since the internal >> algorithm will almost certainly create an iota vector and sort it instead >> of a. I'd prefer an iota function such that this composition works >> like sortIndices: >> >> int[] indices = indexRange(low, high); >> sort(indices, (i, j) -> Integer.compare(a[i], a[j])); >> return indices; >> > > I agree, I proposed the extra sortIndices() as an helper method that > factorize your snippet. > > >> >> > - same with preallocated buffers & runs arrays >> >> I don't follow: Is this a request for tandem sorting? Off-heap sorting? >> I think the above primitives are likely to cover. >> > > I mean preallocated buffers to avoid any allocation inside sort(), to > avoid GC overhead if the application already handles its own memory > management (like Marlin) or performs tons of sort() calls. Maybe having a > SortContext class would help and could be reused accross sort() > invocations. Efficiency matters here. > > >> >> (Exception: Sorting more that 2 billion things is desirable, but will >> bust out of Java arrays. That's why I'm not proposing sorting index >> arrays of type long, at present. We need an array-like container >> of more than 2 billion entries before we graduate to long indexes.) >> >> > - alternatively, it could be expressed as Comparator >> > Arrays.sort(int[] a, low, high, Comparator cmp) that sorts >> array >> > a using the given comparator. For example, a[] could be edge indices >> sorted >> > according to their edge x position... >> > This comparator is specific as it compares anything (external storage) >> at >> > given indices i,j. >> >> Exactly. Except note the limit of 2 billion. >> > > Agreed, but Java arrays are suffering this limit for so long ... > > >> >> > Finally Marlin renderer would benefit from Value types (array of >> structs), >> > as edge data are currently packed in int[] arrays, but this new Sort API >> > seems to me general & needed enough to be discussed here. >> >> Yes, value types will give better memory locality; today you have to use >> tandem sorts. Also, value types will more naturally work with >> comparators, >> where we have to do something different with int-arrays (IntComparator). >> >> Valhalla is aiming at generic specialization also. That, I believe, is >> the >> best future for sorting algorithms (and other algorithms too). A >> specializable >> template class could contain *one copy* of a full sort algorithm, which >> would >> then be specialized to arrays of a reference, primitive, or value type. >> The >> suggestion of a "sort provider API" would mesh nicely with this: The >> template >> class would implement that API. The index type (currently hardwired as >> "int") >> could be a type parameter, instantly releasing us from the 2-billion >> limit. >> Tweakable algorithm parameters (such as "likely run size" or "maximum >> value") >> could be hardwired into the template (as if by a C #ifdef) simply by >> defining >> them as template parameters (a la C++ non-type template parameters). >> > > Looks promising, I should try EA builds ... if ever I have some time ... > to port Marlin using Value types. > > >> >> A user-requested specialization of a template algorithm class would be a >> strong >> signal to the JVM that some "customized" code needs to be generated. >> Currently >> we have no such signals, leading to performance losses when heroic >> inlining >> fails to fully connect the user code to the sort algorithm code. I call >> this the >> "loop customization problem". >> >> ? John >> >> P.S. Loop customization problem: >> >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-September/008381.html >> http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-June/001953.html >> Each "loop syndrome" for a sort or BLAS algorithm would be a distinct >> template class instance. >> >> P.P.S. Such a template algorithm class would work naturally with Arrays >> 2.0, >> which will (someday, in my dreams!) define template interfaces for >> extending >> Java arrays in new directions, notably with index types beyond int. >> >> Independently of sort algorithms, I expect an Arrays 2.0 array could be >> truly >> 2-D if its index space were pairs of ints (a value type). It might >> internally store >> its data in some blocked cache-friendly form (a square sub-array in each >> cache >> line, maybe). I wonder if there is some useful generalization of >> linear-ordered >> sorting which applies to 2-D arrays? Clearly there are many interesting >> algorithms >> on multi-D arrays which could be instantiated and tweaked using template >> algorithm >> classes. >> >> I am lost, sorry. Let's have this extra discussion in another topic. > > Best regards, > Laurent > From frank.yuan at oracle.com Wed Dec 5 08:50:10 2018 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 5 Dec 2018 16:50:10 +0800 Subject: RFR (12): 8213300: jaxp/unittest/transform/CR6551600Test.java fails due to exception in jdk/jdk CI In-Reply-To: <5C078255.2070807@oracle.com> References: <205b01d48c40$fda14ff0$f8e3efd0$@oracle.com> <5C078255.2070807@oracle.com> Message-ID: <217601d48c77$8971a3f0$9c54ebd0$@oracle.com> Thank you, Joe! Pushed the change. Frank > > Hi Frank, > > The change looks good to me. Thanks for fixing the failure! > > Best, > Joe > > On 12/4/18, 6:19 PM, Frank Yuan wrote: > > Hi all > > > > > > > > Would you like to review this patch? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213300 > > > > Webrev: http://cr.openjdk.java.net/~fyuan/8213300/webrev.00/ > > > > > > > > This patch made the following changes: > > > > 1. change the path of test file from the root directory of drive C to C:\temp directory > > > > 2. check if the UNC path is accessible before running the jaxp test > > > > 3. skip the test if it's not Windows because the UNC test is only valid on Windows > > > > > > > > Thanks > > > > Frank > > > > > > From david.holmes at oracle.com Wed Dec 5 10:44:17 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Dec 2018 20:44:17 +1000 Subject: CSR for posix_spawn on JDK 12 In-Reply-To: References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> <22b2861e-696d-b02c-184c-1173b0c55fdd@oracle.com> <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> Message-ID: <2e818261-ddae-4931-4300-7769a2b69dbf@oracle.com> Hi Thomas, Pardon the top-posting but ... The launchMechanism property was introduced by the following issue: https://bugs.openjdk.java.net/browse/JDK-5049299 at the time there was no CSR process and it went through our internal CCC process. The "specification" was as follows: --- Specification jdk.lang.Process.launchMechanism is read once on initialisation. If an invalid value is provided an Error will be thrown immediately stating the reason. On Linux: jdk.lang.Process.launchMechanism can be set to fork or vfork - defaults to vfork on JDK7 & 8 On Solaris: jdk.lang.Process.launchMechanism can be set to posix_spawn or fork - defaults to fork on JDK7 and posix_spawn on JDK8 On Mac OS X: jdk.lang.Process.launchMechanism can be set to posix_spawn or fork - defaults to posix_spawn on JDK7 & 8 --- so IMHO for this issue the "specification" should simply be: Update the allowed values of the jdk.lang.Process.launchMechanism property on Linux to accept the value "posix_spawn", which will use the posix_spawn() API. The default value of "vfork" remains unchanged. --- But as the CSR has already been approved I'm not sure why we are "rearranging the deck chairs". Cheers, David ----- On 5/12/2018 6:05 pm, Thomas St?fe wrote: > Hi Roger, > > thanks for all your help, I appreciate it. > > I thought a while and got some fundamental doubts about the whole > process, see inline. > > On Fri, Nov 30, 2018 at 9:21 PM Roger Riggs wrote: >> >> Hi Thomas, >> >> On 11/30/2018 02:06 PM, Thomas St?fe wrote: >> >> Hi Roger, >> >> I updated the CSR according to your feedback. I'm a bit at a loss >> about the specification though. How should I specify the behavior of >> the API without describing the implementation? >> >> What you wrote is fine. It does need to mention posix_spawn by name, >> as that is the OS function being used. >> >> The notes about the behavior of libc, fit better as an explanation >> in the description of the Solution than in the Specification section. >> >> >> Also, since this patch only extends an existing implementation to >> Linux, I would have thought there are there technical notes in place >> describing POSIX_SPAWN on other platforms, which I would have just >> refered to. I searched but could not really find anything. >> >> Nope, that's why it was a debugging tool for Martin, >> not a documented implementation feature. > > See, here I start getting confused. Has this switch ever been an > officially released feature? > > If yes, I should be able to find release notes, documentation etc I > could refer to and/or copy from. > If not, why should we file a CSR and a release note for adding an > accepted value to a feature which has never been officially released? > > This explains also my problems in formulating the CSR/release note. > How can I describe something without describing its implementation, if > the something is just basically implementation and no feature. It has > no discernible API the user would face, and the consequences for > switching the feature are difficult to describe in 1-2 sentences > without delving deeply into details. 1-2 sentences also run the risk > of giving a false picture. > > Basically, I do not see a difference between this switch and any other > diagnostic hotspot switch, e.g., and therefore am undecided on what to > do here. > > (Should I redirect these questions to the original mail thread?) > >> >> I'm not sure what the proper plural of Unix's is but Unices looks odd. >> Perhaps avoid the issue and just say Unix platforms. >> > > Unices is fine I think. See: https://en.wikipedia.org/wiki/Unix > > > Most common is the conventional Unixes, but _Unices_, treating Unix as > a Latin noun of the third declension, is also popular. The > pseudo-Anglo-Saxon plural form Unixen is not common, although > occasionally seen. Sun Microsystems, developer of the Solaris variant, > has asserted that the term Unix is itself plural, referencing its many > implementations.[42] > > > (Unixen sounds weird and genglish though :) > > Thanks, Thomas > >> >> On Fri, Nov 30, 2018 at 3:50 PM Roger Riggs wrote: >> >> Hi Thomas, >> >> Looks pretty good. >> >> Usually 'we' avoid the first person writing in the jira. >> It makes them more readable in the long term, when there is no context for 'we'. >> >> - Describing it as 'experimental' gives the wrong impression >> and has some magnified implications as that term is being used for >> other major changes. >> >> - The compatibility risk should be corrected: >> >> Supplying an unknown value on the command line produces a java.lang.Error. >> >> % java -Djdk.lang.Process.launchMechanism=POSIX_SPAWN ... >> >> java.lang.Error: POSIX_SPAWN is not a supported process launch mechanism on this platform. >> >> - Since CSRs should be self contained, the specification section should explicitly >> specify the behavior from the API point of view. CSRs should avoid describing >> the implementation (though in this case, its not entirely possible). >> The webrev of the impl is not relevant. >> >> Thanks, Roger >> >> >> On 11/30/2018 03:32 AM, Thomas St?fe wrote: >> >> CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511 >> >> ..Thomas >> >> >> From Alan.Bateman at oracle.com Wed Dec 5 10:54:15 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Dec 2018 10:54:15 +0000 Subject: CSR for posix_spawn on JDK 12 In-Reply-To: <2e818261-ddae-4931-4300-7769a2b69dbf@oracle.com> References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> <22b2861e-696d-b02c-184c-1173b0c55fdd@oracle.com> <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> <2e818261-ddae-4931-4300-7769a2b69dbf@oracle.com> Message-ID: On 05/12/2018 10:44, David Holmes wrote: > > > so IMHO for this issue the "specification" should simply be: > > Update the allowed values of the jdk.lang.Process.launchMechanism > property on Linux to accept the value "posix_spawn", which will use > the posix_spawn() API. The default value of "vfork" remains unchanged. > That is what CSR JDK-8214511 is about. I agree the wording could have been a lot simpler but there is nothing controversial. To Thomas's question as to why a CSR is needed then it is because it's extending a supported interface. This is different to many of the undocumented options which were added for JDK debugging or testing purposes. -Alan From david.holmes at oracle.com Wed Dec 5 11:02:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Dec 2018 21:02:42 +1000 Subject: CSR for posix_spawn on JDK 12 In-Reply-To: References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> <22b2861e-696d-b02c-184c-1173b0c55fdd@oracle.com> <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> <2e818261-ddae-4931-4300-7769a2b69dbf@oracle.com> Message-ID: On 5/12/2018 8:54 pm, Alan Bateman wrote: > On 05/12/2018 10:44, David Holmes wrote: >> >> >> so IMHO for this issue the "specification" should simply be: >> >> Update the allowed values of the jdk.lang.Process.launchMechanism >> property on Linux to accept the value "posix_spawn", which will use >> the posix_spawn() API. The default value of "vfork" remains unchanged. >> > That is what CSR JDK-8214511 is about. I agree the wording could have > been a lot simpler but there is nothing controversial. I agree, but there seemed to be some concern over what the "specification" should be in this case and how the existing property was previously specified. > To Thomas's question as to why a CSR is needed then it is because it's > extending a supported interface. This is different to many of the > undocumented options which were added for JDK debugging or testing > purposes. As Joe already stated, because we are changing the set of allowed values for a system property, there has to be a CSR. That said this particular property doesn't seem to actually be documented directly. No mention of it in the Process API that I can see. It seems a semi-secret means of influencing the implementation. So I can understand there can be some confusion here. David > -Alan From Alan.Bateman at oracle.com Wed Dec 5 11:14:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Dec 2018 11:14:17 +0000 Subject: CSR for posix_spawn on JDK 12 In-Reply-To: References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> <22b2861e-696d-b02c-184c-1173b0c55fdd@oracle.com> <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> <2e818261-ddae-4931-4300-7769a2b69dbf@oracle.com> Message-ID: <498e3d5e-1540-99f6-8e23-7f3e73070868@oracle.com> On 05/12/2018 11:02, David Holmes wrote: > : > > That said this particular property doesn't seem to actually be > documented directly. No mention of it in the Process API that I can > see. It seems a semi-secret means of influencing the implementation. > So I can understand there can be some confusion here. Documenting JDK-specific and platform specific configuration has always been problematic. Many of the Sun era guides and documentation are dusty now and aren't easy to find. We have used release notes in recent releases but they aren't always easy to find either. With @implNote descriptions, @index and more recently @systemProperty, they we have a set of tags that should help put some of this JDK-specific documentation into the javadoc. -Alan From thomas.stuefe at gmail.com Wed Dec 5 12:18:23 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Dec 2018 13:18:23 +0100 Subject: CSR for posix_spawn on JDK 12 In-Reply-To: <498e3d5e-1540-99f6-8e23-7f3e73070868@oracle.com> References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> <22b2861e-696d-b02c-184c-1173b0c55fdd@oracle.com> <84e9c483-e01d-b6a9-aa81-e604e09a4441@oracle.com> <2e818261-ddae-4931-4300-7769a2b69dbf@oracle.com> <498e3d5e-1540-99f6-8e23-7f3e73070868@oracle.com> Message-ID: David, Roger, Alan, thank you for clarifying all this, and sorry for my confusion. I found describing jdk.lang.Process.launcMechanism especially problematic since to understand it one must understand the details of fork/vfork plus know the details of the underlying implementation of the libc. Using this feature with one libc is completely fine, with a different version may not be recommended. To distill that into a few lines for customers is difficult, especially if you do not want to lead them astray (in our port, we tend to not to mention diagnostic features with foot-shooting-opportunities :). But part of my confusion was that it was not clear what more was needed from me; but now I see the CSR (https://bugs.openjdk.java.net/browse/JDK-8214511) has already been approved by Joe. So all that is needed from me now is to finish the release note at https://bugs.openjdk.java.net/browse/JDK-8214454. I will do this presently. Thanks for all your help and explanations. ..Thomas On Wed, Dec 5, 2018 at 12:14 PM Alan Bateman wrote: > > On 05/12/2018 11:02, David Holmes wrote: > > : > > > > That said this particular property doesn't seem to actually be > > documented directly. No mention of it in the Process API that I can > > see. It seems a semi-secret means of influencing the implementation. > > So I can understand there can be some confusion here. > Documenting JDK-specific and platform specific configuration has always > been problematic. Many of the Sun era guides and documentation are dusty > now and aren't easy to find. We have used release notes in recent > releases but they aren't always easy to find either. With @implNote > descriptions, @index and more recently @systemProperty, they we have a > set of tags that should help put some of this JDK-specific documentation > into the javadoc. > > -Alan From HORIE at jp.ibm.com Wed Dec 5 12:21:21 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 5 Dec 2018 21:21:21 +0900 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: , <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa09713@oracle.com> Message-ID: >There are a few JMH tests for upper and lower in the jmh-jdk-microbenchmarks repo. [1] Here is a jmh webrev for the Character methods. http://cr.openjdk.java.net/~mhorie/8213754/jmh-webrev.00/ Also, I updated C2 changes in the latest webrev. (Thank you for giving valuable comments off-list, Vladimir and Martin!) With the change in is_disabled_by_flags, I added a JVM flag that will need another review request. I would proceed for it if this RFR is accepted. http://cr.openjdk.java.net/~mhorie/8213754/webrev.02/ I need a review on changes in the class library, anyway. Would be grateful if I could have one. Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: Michihiro Horie/Japan/IBM To: Vladimir Kozlov Cc: core-libs-dev , hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, Roger Riggs , volker.simonis at sap.com Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace Date: Fri, Nov 30, 2018 1:01 PM Hi Vladimir, Thank you for your further comments. I fixed my code, but I?m afraid discussing such a basic topic involving the two big mailing lists is not good. Please let me have a chance to talk on this off-list. Best regards, -- Michihiro, IBM Research - Tokyo Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not understand which Region node you are swapping. Where it is coming from? From: Vladimir Kozlov To: Michihiro Horie , Roger Riggs Cc: core-libs-dev , hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, volker.simonis at sap.com Date: 2018/11/30 03:01 Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace Hi Michihiro, I still do not understand which Region node you are swapping. Where it is coming from? > + // Swap current RegionNode with new one Regards, Vladimir On 11/28/18 10:31 PM, Michihiro Horie wrote: > Vladimir,Roger, > Thank you so much for your responses. > > Vladimir, > Regarding the hotspot change,I?m new in changing around library_call.cpp,so your comments are very helpful. I will fix > my code,especially inline_character_compare()would be like: > > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ > + RegionNode* old_rgn = control()->as_Region(); > + RegionNode* new_rgn = new RegionNode(1); > + record_for_igvn(new_rgn); > + > + // Swap current RegionNode with new one > + Node* new_ctrl = old_rgn->in(1); > + old_rgn->del_req(1); > + new_rgn->add_req(new_ctrl); > + > + set_control(_gvn.transform(new_rgn)); > + > + // argument(0)is receiver > + Node* codePoint = argument(1); > + Node* n = NULL; > + > + switch (id){ > + case vmIntrinsics::_isDigit_c : n = new DigitCNode(control (),codePoint);break; > + case vmIntrinsics::_isLowerCase_c : n = new LowerCaseCNode(control (),codePoint);break; > + case vmIntrinsics::_isUpperCase_c : n = new UpperCaseCNode(control (),codePoint);break; > + case vmIntrinsics::_isWhitespace_c : n = new WhitespaceCNode(control (),codePoint);break; > + default: > + fatal_unexpected_iid(id); > + } > + > + set_result(_gvn.transform(n)); > + return true; > +} > > Microbenchmark showed ~40% improvements. > > Roger, > I would wait foryour review,thanks. I understood the discussion had not been recognized from people in core-libs-dev,and > checked it was not actually archived there?. > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll look at it on Thursday.Roger Riggs ---2018/11/29 > 11:21:26---Hi, I'll look at it on Thursday. > > From: Roger Riggs > To: Vladimir Kozlov , Michihiro Horie , core-libs-dev at openjdk.java.net > Cc: volker.simonis at sap.com, hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com > Date: 2018/11/29 11:21 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------------------------------------------------------ > > > > Hi, > > I'll look at it on Thursday. > > In spite of it looking like the email was sent to core-lib-dev, I have > not seen it before > and its not in the core-libs-dev archive. > > $.02, Roger > > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > > You still need review from core-libs. > > > > About your hotspot changes. You need to add intrinsics to > > is_disabled_by_flags() to be able switch them off. > > > > Note, match_rule_supported() calls in > > C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 > > are registered. So they will not be available if they are not > > supported. match_rule_supported() checks in > > LibraryCallKit::inline_character_compare() are not needed. > > > > I don't get what you code in > > LibraryCallKit::inline_character_compare() is doing. Why you check > > Region node at the beginning and why you add Region and Phi at the end > > if you have only one path? > > You are creating code for whole method which should return boolean result > > > > + boolean isDigit(int ch) { > > + return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; > > + } > > > > but your code produce TypeInt::CHAR. why? > > > > An finally. Did you compare code generated by default and with you > > changes? what improvement you see? > > > > Thanks, > > Vladimir > > > > On 11/28/18 3:07 PM, Michihiro Horie wrote: > >> Is there any response from core-libs-dev? > >> > >> Vladimir, > >> Could you give your suggestion on how to proceed? > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> > >> ----- Original message ----- > >> From: "Michihiro Horie" > >> Sent by: "hotspot-compiler-dev" > >> > >> To: "Doerr, Martin" > >> Cc: "Simonis, Volker" , > >> "hotspot-compiler-dev at openjdk.java.net", > >> "core-libs-dev at openjdk.java.net" > >> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> isDigit/isLowerCase/isUpperCase/isWhitespace > >> Date: Thu, Nov 22, 2018 11:28 AM > >> > >> Hi Martin, > >> > >> Yes, we should wait for the feedback on class library change. > >> > >> >Btw. I think you can further simplify the code in library_call.cpp > >> (no phi). But we can discuss details when thedirection regarding the > >> java classes is clear. > >> Thank you for pointing out it, I think I understand how to simplify > >> code. > >> > >> >Hi Michi, > >> > > >> >On 11/20/2018 02:52 PM, Michihiro Horie wrote: > >> >> >Please note that we don?t have a machine, yet. So other people > >> will have to test. > >> >> I think Gustavo can help testing this change when its' ready. > >> >Sure :) > >> > > >> >Best regards, > >> >Gustavo > >> Thank you, Gustavo. > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi > >> Michihiro, thanks. This proposal makes the javacode much"Doerr, > >> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal > >> makes the java code much moreintrinsics friendly. > >> > >> From: "Doerr, Martin" > >> To: Michihiro Horie , > >> "core-libs-dev at openjdk.java.net" > >> Cc: "hotspot-compiler-dev at openjdk.java.net" > >> , "Simonis, > >> Volker", Gustavo Romero > >> > >> Date: 2018/11/22 01:33 > >> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> > ------------------------------------------------------------------------------------------------------------------------ > >> > >> > >> > >> > >> Hi Michihiro, > >> > >> thanks. This proposal makes the java code much more intrinsics friendly. > >> We should wait for feedback from the core lib folks. Maybe they have > >> some requirements or other proposals. > >> > >> I think these intrinsics should be interesting for Oracle, Intel and > >> others, too. > >> > >> Btw. I think you can further simplify the code in library_call.cpp > >> (no phi). But we can discuss details when thedirection regarding the > >> java classes is clear. > >> > >> Best regards, > >> Martin > >> > >> * > >> **From:*Michihiro Horie * > >> **Sent:*Mittwoch, 21. November 2018 17:14* > >> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin > >> * > >> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker > >> ; Gustavo Romero* > >> **Subject:*RE: 8213754: PPC64: Add Intrinsics for > >> isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> Hi Martin, > >> > >> I send this RFR to core-libs-dev too, because it changes the class > >> library. > >> > >> Through trial and error, I separated Latin1 block as in the _ > >> > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.01_ > > >> < http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.01 >_/_ > >> > >> I followed the coding way of Character.isWhitespace() that invokes > >> each ChracterData?s isWhitespace() to refactorisDigit(), > >> isLowerCase(), and isUpperCase(). > >> > >> I think this change is also useful on x86, using STTNI. > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> > >> ----- Original message ----- > >> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ > > >> Sent by: "hotspot-compiler-dev" > >> <_hotspot-compiler-dev-bounces at openjdk.java.net_< mailto:hotspot-compiler-dev-bounces at openjdk.java.net>> > >> To: "Doerr, Martin" <_martin.doerr at sap.com_ > >> > > >> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > >> >, > >> "_ppc-aix-port-dev at openjdk.java.net_< mailto:ppc-aix-port-dev at openjdk.java.net>" > >> <_ppc-aix-port-dev at openjdk.java.net_< mailto:ppc-aix-port-dev at openjdk.java.net>>, > >> "_hotspot-compiler-dev at openjdk.java.net_< mailto:hotspot-compiler-dev at openjdk.java.net>" > >> <_hotspot-compiler-dev at openjdk.java.net_< mailto:hotspot-compiler-dev at openjdk.java.net>> > >> > >> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> isDigit/isLowerCase/isUpperCase/isWhitespace > >> Date: Wed, Nov 21, 2018 1:53 AM > >> > >> Hi Martin, > >> > >> Thank you for giving your helpful comments. I did not recognize > >> ?generate_method_call_static? prevents anyoptimizations, but I now > >> checked it actually degraded the performance, thanks. > >> > >> >Please note that we don?t have a machine, yet. So other people will > >> have to test. > >> I think Gustavo can help testing this change when its' ready. > >> > >> >Would it be possible to introduce more fine-grained intrinsics such > >> that the ?slow? path is outside of them? > >> > > >> >Maybe you can factor out as in the following example? > >> >if (latin1) return isLatin1Digit(codePoint); > >> >with isLatin1Digit as HotSpotIntrinsicCandidate. > >> Thanks for an example, please let me try to separate the Latin block > >> from other blocks for some time. > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi > >> Michihiro, first of all, thanks for working onPower9 opt"Doerr, > >> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks > >> for working on Power9optimizations. Please note that we don't ha > >> > >> From: "Doerr, Martin" <_martin.doerr at sap.com_ > >> > > >> To: Michihiro Horie <_HORIE at jp.ibm.com_ >, > >> "_hotspot-compiler-dev at openjdk.java.net_< mailto:hotspot-compiler-dev at openjdk.java.net>" > >> <_hotspot-compiler-dev at openjdk.java.net_< mailto:hotspot-compiler-dev at openjdk.java.net>>, > >> "_ppc-aix-port-dev at openjdk.java.net_< mailto:ppc-aix-port-dev at openjdk.java.net>" > >> <_ppc-aix-port-dev at openjdk.java.net_ > >> > > >> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > >> >, "Lindenmaier, > >> Goetz"<_goetz.lindenmaier at sap.com_ > >> >, Gustavo Romero > >> <_gromero at linux.vnet.ibm.com_> > >> Date: 2018/11/20 01:55 > >> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> > ------------------------------------------------------------------------------------------------------------------------ > >> > >> > >> > >> > >> > >> Hi Michihiro, > >> > >> first of all, thanks for working on Power9 optimizations. Please note > >> that we don?t have a machine, yet. So other peoplewill have to test. > >> > >> I think it may be problematic to insert a slow path by > >> ?generate_method_call_static?. This may be a performancedisadvantage > >> for some users of other encodings because your intrinsics prevent > >> inlining and further optimizations. > >> Would it be possible to introduce more fine-grained intrinsics such > >> that the ?slow? path is outside of them? > >> > >> Maybe you can factor out as in the following example? > >> if (latin1) return isLatin1Digit(codePoint); > >> with isLatin1Digit as HotSpotIntrinsicCandidate. > >> > >> I can?t judge if this is needed, but I think this should be discussed > >> first before going into the details. > >> > >> Best regards, > >> Martin > >> > >> * > >> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ >* > >> **Sent:*Freitag, 16. November 2018 12:53* > >> **To:*_hotspot-compiler-dev at openjdk.java.net_ > >> ;_ppc-aix-port-dev at openjdk.java.net_ > >> * > >> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > >> >; Simonis, Volker > >> <_volker.simonis at sap.com_>; > >> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > >> >;Gustavo Romero > >> <_gromero at linux.vnet.ibm.com_ >* > >> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for > >> isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> Dear all, > >> > >> Would you please review following change? > >> > >> Bug: > _https://bugs.openjdk.java.net/browse/JDK-8213754_ > >> Webrev: > _http://cr.openjdk.java.net/~mhorie/8213754/webrev.00_ > > >> < http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.00 > > >> > >> This change includes the intrinsics of Character isDigit, > >> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block > >> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to > >> compare a character with 1 or 2 rangedbytes, while the cmpeqb > >> compares one with 1 to 8 values. Simple micro benchmark attached > >> showed improvements by 20-40%. > >> / > >> //(See attached file: Latin1Test.java)/ > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> > > > > > From thomas.stuefe at gmail.com Wed Dec 5 14:11:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Dec 2018 15:11:12 +0100 Subject: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u In-Reply-To: References: <5ebf181b-ef89-8a9f-2781-cc99d82e9150@oracle.com> <26934a06-801c-376e-0e88-1a553183f896@oracle.com> Message-ID: Hi Roger, I closed the issue as "Delivered" as you suggested: https://bugs.openjdk.java.net/browse/JDK-8214454 I hope all is well now. I am still finding my way in this process. Thanks, Thomas On Fri, Nov 30, 2018 at 3:28 PM Roger Riggs wrote: > > Hi Thomas, > > The updates to the release note look fine. > Usually they are brief, containing just enough information to quickly > recognize the function and feature that has changed. > The complete information can be found in the original Jira issue. > > Sorry about the lack of an external release note guide, one is needed. > Release notes use Markdown making them a bit more readable. > Looking at release notes from any prior release [1] will give you a good idea > as to the typical scope and wording. > > Closing the release note as "Delivered" marks it ready for an > editorial pass made before the release notes are published > with the GA release. > > Thanks, Roger > > [1] https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html > > > On 11/30/2018 01:23 AM, Thomas St?fe wrote: > > Hi all, > > I updated the Release note, please have a look. > > Note that the linked style guide under [3] was not accessible to me > outside Oracle. So I did my best by mimicking the release notes Iris > send me. > > Especially, it was not clear to me if we should clearly mark > experimental features as such. > > Cheers, Thomas > On Thu, Nov 29, 2018 at 8:54 PM Roger Riggs wrote: > > Hi Thomas, > > We'll also need a retroactive CSR for JDK 12 to change its status in JDK 12 to be documented. > Can you take a swing at that? > On the Jira issue[2] there is a "More" menu with a 'Create CSR' button. > It comes pre-filled with a template that should be pretty straightforward to fill out. > > A CSR will also be needed for JDK 11 (pretty much a copy). > In the compatibility section, point out that it does not change the default. > > I created a draft release note for JDK 12 [1]. > Please review and comment or edit it directly with suggestions. > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8214454 > [2] https://bugs.openjdk.java.net/browse/JDK-8212828 > > > On 11/28/2018 11:56 AM, Thomas St?fe wrote: > > On Wed, Nov 28, 2018 at 5:39 PM Alan Bateman wrote: > > On 28/11/2018 15:36, Thomas St?fe wrote: > > Hi all, > > I would like to have this patch in 11u too, so I just did a 11u > downport request. > > Our agreement was that launchMechanism=POSIX_SPAWN would stay as > optional non-default value for jdk12, and at the start of JDK13 > development we would switch the default to posix_spawn. > > I would like to see this non-default-but-possible-to-set option in 11u > too, just to broaden the test surface. We'd get more testers that way. > > What do you think, does that make sense? > > It would be nice to have gotten feedback from people trying it out with > JDK 12 EA builds but I don't know if that is possible. > > If it is backported then a CSR will be required as it will be adding a > new supported value. A release note or other documentation updates might > be needed too. > > Oh, you are right. Do we have a release note/documentation for jdk12? > > ..Thomas > > -Alan > > > From claes.redestad at oracle.com Wed Dec 5 15:13:14 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 5 Dec 2018 16:13:14 +0100 Subject: RFR: 8214858: Improve module graph archiving Message-ID: <765d4c69-4fe3-3eb6-7956-f38297960746@oracle.com> Hi, a few improvements to how we archive module graph information: - archive an instance of ArchiveModuleGraph rather than individual fields - archiving the exportedPackagesToOpen and concealedPackagesToOpen maps improve sharing and substantially reduce bytecode executed (~30k) - archiving the remaining flags in the ArchivedModuleGraph means we no longer need to archive SystemModules ? - this means we no longer load jdk.internal.module.SystemModules and jdk.internal.module.SystemModules$default at runtime - for robustness ensure we either resolve either everything or nothing from the archive (there are some overlapping safeguards here, e.g., CDS is disabled when you run with --limit-modules, but helps to be explicit) Bugs: https://bugs.openjdk.java.net/browse/JDK-8214858 Webrev: http://cr.openjdk.java.net/~redestad/8214858/jdk.00/ Testing: tier1-3, locally tested all module and CDS tests Startup tests verify a small speedup on my test setups (around -0.5ms on average) Thanks! /Claes From naoto.sato at oracle.com Wed Dec 5 16:54:02 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 5 Dec 2018 08:54:02 -0800 Subject: [12]RFR 8213127: Refactor test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh to plain java tests In-Reply-To: References: Message-ID: Looks good to me. Naoto On 12/4/18 9:35 PM, Dora Zhou wrote: > Hello, > > Please help review the fix for refactor > test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh to > plain java tests. Thank you. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213127 > > Webrev: http://cr.openjdk.java.net/~dzhou/8213127/webrev.02/ > > Regards, > Dora From jiangli.zhou at oracle.com Wed Dec 5 17:53:38 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 5 Dec 2018 09:53:38 -0800 Subject: RFR: 8214858: Improve module graph archiving In-Reply-To: <765d4c69-4fe3-3eb6-7956-f38297960746@oracle.com> References: <765d4c69-4fe3-3eb6-7956-f38297960746@oracle.com> Message-ID: Hi Claes, This is awesome. Like the change of encapsulating all the individual fields into the single instance of 'archivedModuleGraph'! All the improvements look great from subgraph archiving point of view. I'll leave the module part to Alan, Mandy and others. Thanks! Jiangli On 12/5/18 7:13 AM, Claes Redestad wrote: > Hi, > > a few improvements to how we archive module graph information: > > - archive an instance of ArchiveModuleGraph rather than individual fields > - archiving the exportedPackagesToOpen and concealedPackagesToOpen > maps improve sharing and substantially reduce bytecode executed (~30k) > - archiving the remaining flags in the ArchivedModuleGraph means we no > longer need to archive SystemModules > ? - this means we no longer load jdk.internal.module.SystemModules and > jdk.internal.module.SystemModules$default at runtime > - for robustness ensure we either resolve either everything or nothing > from the archive (there are some overlapping safeguards here, e.g., > CDS is disabled when you run with --limit-modules, but helps to be > explicit) > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8214858 > Webrev: http://cr.openjdk.java.net/~redestad/8214858/jdk.00/ > > Testing: tier1-3, locally tested all module and CDS tests > Startup tests verify a small speedup on my test setups (around -0.5ms > on average) > > Thanks! > > /Claes From Roger.Riggs at oracle.com Wed Dec 5 18:10:46 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 5 Dec 2018 13:10:46 -0500 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> <0CA96647-3B5B-41CB-A368-86F5A957C73D@oracle.com> <2864b759-b7a3-1bbc-973c-239d96340de1@oracle.com> <48FF6FE1-1E16-468C-923A-A35CC9C6E88A@oracle.com> <5A44B287-CC4F-4904-ACE2-1621658BCE81@oracle.com> <9d34f98b-9ac2-2d95-896a-3ea36c28cc6f@oracle.com> <35EE3661-242A-48DD-8A5B-10B648E854C1@oracle.com> <45fac915-2dac-bd2d-0f3a-0409e11fe947@oracle.com> <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: Looks fine. On 12/04/2018 08:07 PM, Brian Burkhalter wrote: > Hi Daniel, > > You are correct: at line 154 ?n? should have been passed instead of ?-1? here: > > http://cr.openjdk.java.net/~bpb/6516099/webrev.08-delta/ > > Fixing that exposed an error in the test at line 222 which I?ve fixed. > > An updated version is at > > http://cr.openjdk.java.net/~bpb/6516099/webrev.09/ > > with the 08-09 delta at > > http://cr.openjdk.java.net/~bpb/6516099/webrev.08-09-delta/ > > Thanks, > > Brian > >> On Dec 3, 2018, at 9:27 AM, Daniel Fuchs wrote: >> >> Looks good to me, though I don't understand the change >> at line 154: >> >> The comment says: >> >> 152 // skip(n) returns negative value: IOE >> >> but if you pass -1 - you're no longer calling skip(n)? From mandy.chung at oracle.com Wed Dec 5 18:12:13 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 5 Dec 2018 10:12:13 -0800 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> Message-ID: <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> On 12/3/18 11:12 AM, Vicente Romero wrote: > Hi all, > > Can I have the final nod to the JVM constants API, there have been > some changes since the last review iteration. Thanks to the internal > and external developers that have taken the time to provide feedback > so far. The links to the last versions are: > > webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ > javadoc: > http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html > specdiff: > http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html > I reviewed webrev.10 and overall looks good to me.? A couple of minor comments and some of them seems to be fixed already in amber repo.? No need to generate a new webrev. Nit: The javadoc of the new methods starts with "Returns", "Return", "Produce", "Create", "Resolve", "Compares" etc.? It'd be good to do a pass and fix the verb form consistently. src/java.base/share/classes/java/lang/Class.java ?? nit: Line 163 seems to have extra white-spaces, not aligned with the other superinterfaces. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java 74 private static final Set suppressSubtypesSet 75 = Set.of("java.lang.Object", 76 "org.omg.CORBA.Object"); This is not related to your change. CORBA is no longer in JDK. Maybe this special casing is no longer needed. It may worth filing a JBS issue to examine this. ConstantDescs.java 64 // Don't change the order of these declarations! Is there any code depending on this order? DirectMethodHandleDesc.java 46 * {@link MethodHandle}. A {@linkplain DirectMethodHandleDescImpl} corresponds to typo: DirectMethodHandleDescImpl 57 /** 58 * Kinds of method handles that can be described with {@linkplain DirectMethodHandleDesc}. 59 */ 60 enum Kind { This needs @since 12 DynamicCallSiteDesc.java 59 * @param bootstrapMethod a {@link DirectMethodHandleDescImpl} describing the 60 * bootstrap method for the {@code invokedynamic} typo: DirectMethodHandleDescImpl and in a few other @param Mandy From Roger.Riggs at oracle.com Wed Dec 5 20:08:53 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 5 Dec 2018 15:08:53 -0500 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa09713@oracle.com> Message-ID: Hi Michihiro, On 12/05/2018 07:21 AM, Michihiro Horie wrote: > > >There are a few JMH tests for upper and lower in the > jmh-jdk-microbenchmarks repo. [1] > Here is a jmh webrev for the Character methods._ > __http://cr.openjdk.java.net/~mhorie/8213754/jmh-webrev.00/_ > > Please include at least one character value that is not a member of any of the classes. The performance impact for 'other' characters is important also. The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: ?? test/micro/org/openjdk/bench/java/lang/ Now that they are in that repo, they can be included with the rest of the changeset. > Also, I updated C2 changes in the latest webrev. (Thank you for giving > valuable comments off-list, Vladimir and Martin!) > With the change in is_disabled_by_flags, I added a JVM flag that will > need another review request. I would proceed for it if this RFR is > accepted._ > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.02/_ > > The indent in the Java code should be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 spaces) Please update the copyrights to include 2018. Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' in CharacterDataLatin1.java.template?? The performance would need to be measured and compared. Is the profile of in-lining methods changed in any measurable way now that there is an extra level of method invocation? ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; instead of: ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; Regards, Roger > I need a review on changes in the class library, anyway. Would be > grateful if I could have one. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > > ----- Original message ----- > From: Michihiro Horie/Japan/IBM > To: Vladimir Kozlov > Cc: core-libs-dev , > hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, Roger > Riggs , volker.simonis at sap.com > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > Date: Fri, Nov 30, 2018 1:01 PM > > Hi Vladimir, > > Thank you for your further comments. I fixed my code,but I?m afraid > discussing such a basic topic involving the two big mailing lists is > not good. Please let me have a chance to talk on this off-list. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not > understand which Region node you are swapping. Where it is coming from? > > From: Vladimir Kozlov > To: Michihiro Horie , Roger Riggs > > Cc: core-libs-dev , > hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, > volker.simonis at sap.com > Date: 2018/11/30 03:01 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------ > > > > Hi Michihiro, > > I still do not understand which Region node you are swapping. Where it > is coming from? > > > + // Swap current RegionNode with new one > > Regards, > Vladimir > > On 11/28/18 10:31 PM, Michihiro Horie wrote: > > Vladimir,Roger, > > Thank you so much for your responses. > > > > Vladimir, > > Regarding the hotspot change,I?m new in changing around > library_call.cpp,so your comments are very helpful. I will fix > > my code,especially inline_character_compare()would be like: > > > > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ > > + RegionNode* old_rgn = control()->as_Region(); > > + RegionNode* new_rgn = new RegionNode(1); > > + record_for_igvn(new_rgn); > > + > > + // Swap current RegionNode with new one > > + Node* new_ctrl = old_rgn->in(1); > > + old_rgn->del_req(1); > > + new_rgn->add_req(new_ctrl); > > + > > + set_control(_gvn.transform(new_rgn)); > > + > > + // argument(0)is receiver > > + Node* codePoint = argument(1); > > + Node* n = NULL; > > + > > + switch (id){ > > + case vmIntrinsics::_isDigit_c : n = new > DigitCNode(control(),codePoint);break; > > + case vmIntrinsics::_isLowerCase_c : n = new > LowerCaseCNode(control(),codePoint);break; > > + case vmIntrinsics::_isUpperCase_c : n = new > UpperCaseCNode(control(),codePoint);break; > > + case vmIntrinsics::_isWhitespace_c : n = new > WhitespaceCNode(control(),codePoint);break; > > + default: > > + fatal_unexpected_iid(id); > > + } > > + > > + set_result(_gvn.transform(n)); > > + return true; > > +} > > > > Microbenchmark showed ~40% improvements. > > > > Roger, > > I would wait foryour review,thanks. I understood the discussion had > not been recognized from people in core-libs-dev,and > > checked it was not actually archived there?. > > > > Best regards, > > -- > > Michihiro, > > IBM Research - Tokyo > > > > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, > I'll look at it on Thursday.Roger Riggs ---2018/11/29 > > 11:21:26---Hi, I'll look at it on Thursday. > > > > From: Roger Riggs > > To: Vladimir Kozlov , Michihiro Horie > , core-libs-dev at openjdk.java.net > > Cc: volker.simonis at sap.com, hotspot-compiler-dev at openjdk.java.net, > martin.doerr at sap.com > > Date: 2018/11/29 11:21 > > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > > > > > ------------------------------------------------------------------------------------------------------------------------ > > > > > > > > Hi, > > > > I'll look at it on Thursday. > > > > In spite of it looking like the email was sent to core-lib-dev, I have > > not seen it before > > and its not in the core-libs-dev archive. > > > > $.02, Roger > > > > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > > ?> You still need review from core-libs. > > ?> > > ?> About your hotspot changes. You need to add intrinsics to > > ?> is_disabled_by_flags() to be able switch them off. > > ?> > > ?> Note, match_rule_supported() calls in > > ?> C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 > > ?> are registered. So they will not be available if they are not > > ?> supported. match_rule_supported() checks in > > ?> LibraryCallKit::inline_character_compare() are not needed. > > ?> > > ?> I don't get what you code in > > ?> LibraryCallKit::inline_character_compare() is doing. Why you check > > ?> Region node at the beginning and why you add Region and Phi at > the end > > ?> if you have only one path? > > ?> You are creating code for whole method which should return > boolean result > > ?> > > ?> + ? ?boolean isDigit(int ch) { > > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; > > ?> + ? ?} > > ?> > > ?> but your code produce TypeInt::CHAR. why? > > ?> > > ?> An finally. Did you compare code generated by default and with you > > ?> changes? what improvement you see? > > ?> > > ?> Thanks, > > ?> Vladimir > > ?> > > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: > > ?>> Is there any response from core-libs-dev? > > ?>> > > ?>> Vladimir, > > ?>> Could you give your suggestion on how to proceed? > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > ?>> ----- Original message ----- > > ?>> From: "Michihiro Horie" > > ?>> Sent by: "hotspot-compiler-dev" > > ?>> > > ?>> To: "Doerr, Martin" > > ?>> Cc: "Simonis, Volker" , > > ?>> > "hotspot-compiler-dev at openjdk.java.net", > > ?>> "core-libs-dev at openjdk.java.net" > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> Date: Thu, Nov 22, 2018 11:28 AM > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> Yes, we should wait for the feedback on class library change. > > ?>> > > ?>> ?>Btw. I think you can further simplify the code in library_call.cpp > > ?>> (no phi). But we can discuss details when thedirection regarding the > > ?>> java classes is clear. > > ?>> Thank you for pointing out it, I think I understand how to simplify > > ?>> code. > > ?>> > > ?>> ?>Hi Michi, > > ?>> ?> > > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: > > ?>> ?>> >Please note that we don?t have a machine, yet. So other people > > ?>> will have to test. > > ?>> ?>> I think Gustavo can help testing this change when its' ready. > > ?>> ?>Sure :) > > ?>> ?> > > ?>> ?>Best regards, > > ?>> ?>Gustavo > > ?>> Thank you, Gustavo. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 > 01:33:34---Hi > > ?>> Michihiro, thanks. This proposal makes the javacode much"Doerr, > > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal > > ?>> makes the java code much moreintrinsics friendly. > > ?>> > > ?>> From: "Doerr, Martin" > > ?>> To: Michihiro Horie , > > ?>> "core-libs-dev at openjdk.java.net" > > ?>> Cc: "hotspot-compiler-dev at openjdk.java.net" > > ?>> , "Simonis, > > ?>> Volker", Gustavo Romero > > ?>> > > ?>> Date: 2018/11/22 01:33 > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> > > > ------------------------------------------------------------------------------------------------------------------------ > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> Hi Michihiro, > > ?>> > > ?>> thanks. This proposal makes the java code much more intrinsics > friendly. > > ?>> We should wait for feedback from the core lib folks. Maybe they have > > ?>> some requirements or other proposals. > > ?>> > > ?>> I think these intrinsics should be interesting for Oracle, Intel and > > ?>> others, too. > > ?>> > > ?>> Btw. I think you can further simplify the code in library_call.cpp > > ?>> (no phi). But we can discuss details when thedirection regarding the > > ?>> java classes is clear. > > ?>> > > ?>> Best regards, > > ?>> Martin > > ?>> > > ?>> * > > ?>> **From:*Michihiro Horie * > > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* > > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin > > ?>> * > > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker > > ?>> ; Gustavo > Romero* > > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> I send this RFR to core-libs-dev too, because it changes the class > > ?>> library. > > ?>> > > ?>> Through trial and error, I separated Latin1 block as in the _ > > ?>> > > > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.01-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=K5GMqTdhkNMaMnGAqGucn9CsZllScUGvHO427jiTC5E&s=brFCGq8BK0Q6ICnXLNCUF0nI8J5LjSjhtiWAZlhjPb4&e= > > > > ?>> <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.01_>_/_ > > ?>> > > ?>> I followed the coding way of Character.isWhitespace() that invokes > > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), > > ?>> isLowerCase(), and isUpperCase(). > > ?>> > > ?>> I think this change is also useful on x86, using STTNI. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > ?>> ----- Original message ----- > > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>> > > ?>> Sent by: "hotspot-compiler-dev" > > ?>> > <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_>> > > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>> > > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > ?>> <_mailto:volker.simonis at sap.com_>>, > > ?>> > "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > ?>> > <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>>, > > ?>> > "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > > ?>> > <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>> > > ?>> > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> Date: Wed, Nov 21, 2018 1:53 AM > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> Thank you for giving your helpful comments. I did not recognize > > ?>> ?generate_method_call_static? prevents anyoptimizations, but I now > > ?>> checked it actually degraded the performance, thanks. > > ?>> > > ?>> ?>Please note that we don?t have a machine, yet. So other people > will > > ?>> have to test. > > ?>> I think Gustavo can help testing this change when its' ready. > > ?>> > > ?>> ?>Would it be possible to introduce more fine-grained intrinsics > such > > ?>> that the ?slow? path is outside of them? > > ?>> ?> > > ?>> ?>Maybe you can factor out as in the following example? > > ?>> ?>if (latin1) return isLatin1Digit(codePoint); > > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. > > ?>> Thanks for an example, please let me try to separate the Latin block > > ?>> from other blocks for some time. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 > 01:55:27---Hi > > ?>> Michihiro, first of all, thanks for working onPower9 opt"Doerr, > > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks > > ?>> for working on Power9optimizations. Please note that we don't ha > > ?>> > > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>> > > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>>, > > ?>> > "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > > ?>> > <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > ?>> > "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, > > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero > > ?>> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_>> > > ?>> Date: 2018/11/20 01:55 > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> > > > ------------------------------------------------------------------------------------------------------------------------ > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> Hi Michihiro, > > ?>> > > ?>> first of all, thanks for working on Power9 optimizations. Please > note > > ?>> that we don?t have a machine, yet. So other peoplewill have to test. > > ?>> > > ?>> I think it may be problematic to insert a slow path by > > ?>> ?generate_method_call_static?. This may be a performancedisadvantage > > ?>> for some users of other encodings because your intrinsics prevent > > ?>> inlining and further optimizations. > > ?>> Would it be possible to introduce more fine-grained intrinsics such > > ?>> that the ?slow? path is outside of them? > > ?>> > > ?>> Maybe you can factor out as in the following example? > > ?>> if (latin1) return isLatin1Digit(codePoint); > > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. > > ?>> > > ?>> I can?t judge if this is needed, but I think this should be > discussed > > ?>> first before going into the details. > > ?>> > > ?>> Best regards, > > ?>> Martin > > ?>> > > ?>> * > > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>>* > > ?>> **Sent:*Freitag, 16. November 2018 12:53* > > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ > > ?>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ > > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* > > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker > > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_>>; > > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero > > ?>> <_gromero at linux.vnet.ibm.com_ > <_mailto:gromero at linux.vnet.ibm.com_>>* > > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> Dear all, > > ?>> > > ?>> Would you please review following change? > > ?>> > > ?>> Bug: > > > _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=K5GMqTdhkNMaMnGAqGucn9CsZllScUGvHO427jiTC5E&s=GdBakB_GPQKO3fiM6o8w1OpCp76EtuynzAOZaE-OoQQ&e= > > ?>> Webrev: > > > _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=K5GMqTdhkNMaMnGAqGucn9CsZllScUGvHO427jiTC5E&s=RqwTJXnDC8QoRx_IsFshdedeLrlfJU110wDJcjzjw2c&e= > > > > ?>> <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.00_> > > ?>> > > ?>> This change includes the intrinsics of Character isDigit, > > ?>> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 > block > > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to > > ?>> compare a character with 1 or 2 rangedbytes, while the cmpeqb > > ?>> compares one with 1 to 8 values. Simple micro benchmark attached > > ?>> showed improvements by 20-40%. > > ?>> / > > ?>> //(See attached file: Latin1Test.java)/ > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > > > > > > > > > > > > From merkel05 at gmail.com Wed Dec 5 20:47:40 2018 From: merkel05 at gmail.com (Sergey) Date: Wed, 5 Dec 2018 21:47:40 +0100 Subject: [PATCH][TESTBUG] JDK-8214052: Wrong shell used Message-ID: Hi, As stated in the bug description [1] there are few places in the tests where bash syntax is being used. First one is (as per ticket): - vmTestbase/vm/compiler/CodeCacheInfoOnCompilation I've made a quick fix for that one and patch could be found inlined below. Moreover what I've observed is that simple grepping gives me another test script, that uses bash extensions: - GeneratePropertyPassword.sh [2] It seems to be linked with another ticket [3] which is closed, though it still uses the bash "[[" extension. Perhaps that fix [4] needs to be reapplied. In regards to the patch itself, please let me know if I've missed something. Changes were successfully tested with `dash v0.5.10.2-1`. [1] https://bugs.openjdk.java.net/browse/JDK-8214052 [2] http://hg.openjdk.java.net/jdk/sandbox/file/413c28945e0f/test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh#l37 [3] https://bugs.openjdk.java.net/browse/JDK-8025886 [4] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a2551e12a9ea0.5.10.2-1 Regards, su - diff --git a/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh b/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh --- a/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh +++ b/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh @@ -27,7 +27,7 @@ ver=$(${TESTED_JAVA_HOME}/bin/java ${JAVA_OPTS} -version 2>&1) isComp=$( echo ${ver} | grep -c "compiled mode") -if [[ $isComp != 1 ]]; then +if [ "$isComp" -ne 1 ]; then echo "skipped. This test works only with -Xcomp" exit fi @@ -40,7 +40,7 @@ res=$(${TESTED_JAVA_HOME}/bin/java ${JAVA_OPTS} -XX:+PrintCodeCacheOnCompilation -XX:-Inline vm.compiler.CodeCacheInfoOnCompilation.PrintOnCall | egrep -ce "${pattern}") echo "res: " ${res} -if (( "${res}" != "0" )); then +if [ "$res" != "0" ]; then echo "passed" true else From Roger.Riggs at oracle.com Wed Dec 5 21:35:39 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 5 Dec 2018 16:35:39 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> Message-ID: Hi, Editorial comments java.lang.contant package javadoc: ?- In the Nominal Descriptors? 2nd paragraph:? "of of" -> "of" -? DirectMethodHandleDescImpl - Its unusual to see a Class named *Impl in ?? a developer facing API.? And if its intended, it should be linked. - "These classes provides" plural agreement. DynamicCallSiteDesc: ?- Is the format of names clearly specified:? IAE -> if the invocation name has the 'incorrect format'. ?- typo: ? "descripbing" - > "describing" ?- missing @throws IAE for method : ?of(DirectMethodHandleDesc ?bootstrapMethod,String ?invocationName,MethodTypeDesc ?invocationType) - The withArgs method only throws NPE:? is there nothing else that can go wrong? - bootStrapArgs() - the return is always non-null, with zero length array for non args? DynamicConstantDesc.java: ?- First sentences should end with period. "." ?- ofCanonical:? 2nd sentence, "Classes ... produces ... a ConstantDesc"; grammar? ?- of Canaonical(): So a conforming implementation is not required to return the ??? well known values, only suggested. ClassDesc.java: ?- The create methods should not be required to create new instances.? Use "return"? instead of "create". ?- How are class descriptors created for 'nested' classes (as opposed to inner classes). ?? It is worth describing or referencing how that should be done. ?- Can inner() throw IAE for invalid format names? ?- How can the rank of an array ClassDesc be found? Constable.java: ?- Avoid ending the first sentence of describeConstable description with "be". ConstDesc.java: ?- "with respect to a particular to a class loader" ; extra words "to a"? DirectMethodHandleDesc.java: ?- ofField, @throws IAE might mention the possibility of an invalid name MethodTypeDesc.java: ?- First sentences should end with period. "." Regards, Roger On 12/05/2018 01:12 PM, Mandy Chung wrote: > > > On 12/3/18 11:12 AM, Vicente Romero wrote: >> Hi all, >> >> Can I have the final nod to the JVM constants API, there have been >> some changes since the last review iteration. Thanks to the internal >> and external developers that have taken the time to provide feedback >> so far. The links to the last versions are: >> >> webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ >> javadoc: >> http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html >> specdiff: >> http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html >> > > I reviewed webrev.10 and overall looks good to me.? A couple of minor > comments and some of them seems to be fixed already in amber repo.? No > need to generate a new webrev. > > Nit: The javadoc of the new methods starts with "Returns", "Return", > "Produce", "Create", "Resolve", "Compares" etc.? It'd be good to do a > pass and fix the verb form consistently. > > src/java.base/share/classes/java/lang/Class.java > ?? nit: Line 163 seems to have extra white-spaces, not aligned with > the other superinterfaces. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java > 74 private static final Set suppressSubtypesSet > 75 = Set.of("java.lang.Object", > 76 "org.omg.CORBA.Object"); > > This is not related to your change. CORBA is no longer in JDK. > Maybe this special casing is no longer needed.? It may worth > filing a JBS issue to examine this. > > ConstantDescs.java > ? 64???? // Don't change the order of these declarations! > > Is there any code depending on this order? > > DirectMethodHandleDesc.java > ? 46? * {@link MethodHandle}.? A {@linkplain > DirectMethodHandleDescImpl} corresponds to > > typo: DirectMethodHandleDescImpl > > ? 57???? /** > ? 58????? * Kinds of method handles that can be described with > {@linkplain DirectMethodHandleDesc}. > ? 59????? */ > ? 60???? enum Kind { > > This needs @since 12 > > DynamicCallSiteDesc.java > ? 59????? * @param bootstrapMethod a {@link > DirectMethodHandleDescImpl} describing the > ? 60????? *??????????????????????? bootstrap method for the {@code > invokedynamic} > > typo: DirectMethodHandleDescImpl and in a few other @param > > Mandy > From Roger.Riggs at oracle.com Wed Dec 5 21:42:58 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 5 Dec 2018 16:42:58 -0500 Subject: RFR 8214498 : java/util/Locale/bcp47u/SystemPropertyTests.java wrong locale default Message-ID: <7b79a604-c351-3832-a656-e536dcacb4da@oracle.com> Please review a bug fix for incorrect setting the user.xx.display and user.xx.format system properties when merging the native OS values for locale and the command line overiddes.? The command line argument for user.xx, if set, overrides any native OS settings. The bug causes a test failure when the OS has a non-US locale configured. Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-bcp47u-8214498/ Issue: ? https://bugs.openjdk.java.net/browse/JDK-8214498 Thanks, Roger From lance.andersen at oracle.com Wed Dec 5 22:16:59 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 5 Dec 2018 17:16:59 -0500 Subject: RFR 8214498 : java/util/Locale/bcp47u/SystemPropertyTests.java wrong locale default In-Reply-To: <7b79a604-c351-3832-a656-e536dcacb4da@oracle.com> References: <7b79a604-c351-3832-a656-e536dcacb4da@oracle.com> Message-ID: <26B27C90-18A3-4F24-9390-9A9CBC6DB32B@oracle.com> Looks OK roger :-) > On Dec 5, 2018, at 4:42 PM, Roger Riggs wrote: > > Please review a bug fix for incorrect setting the user.xx.display and user.xx.format > system properties when merging the native OS values for locale and the command > line overiddes. The command line argument for user.xx, if set, overrides any native > OS settings. > > The bug causes a test failure when the OS has a non-US locale configured. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-bcp47u-8214498/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8214498 > > Thanks, Roger > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Wed Dec 5 22:27:15 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Dec 2018 14:27:15 -0800 Subject: RFR 8214498 : java/util/Locale/bcp47u/SystemPropertyTests.java wrong locale default In-Reply-To: <26B27C90-18A3-4F24-9390-9A9CBC6DB32B@oracle.com> References: <7b79a604-c351-3832-a656-e536dcacb4da@oracle.com> <26B27C90-18A3-4F24-9390-9A9CBC6DB32B@oracle.com> Message-ID: +1 Brian > On Dec 5, 2018, at 2:16 PM, Lance Andersen wrote: > > Looks OK roger :-) >> On Dec 5, 2018, at 4:42 PM, Roger Riggs wrote: >> >> Please review a bug fix for incorrect setting the user.xx.display and user.xx.format >> system properties when merging the native OS values for locale and the command >> line overiddes. From david.holmes at oracle.com Wed Dec 5 22:45:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Dec 2018 08:45:38 +1000 Subject: [PATCH][TESTBUG] JDK-8214052: Wrong shell used In-Reply-To: References: Message-ID: Hi Sergey, Hotspot test changes should be reviewed on hotspot-dev not core-libs-dev. Thanks, David On 6/12/2018 6:47 am, Sergey wrote: > Hi, > > As stated in the bug description [1] there are few > places in the tests where bash syntax is being used. > > First one is (as per ticket): > - vmTestbase/vm/compiler/CodeCacheInfoOnCompilation > I've made a quick fix for that one and patch could be found > inlined below. > > Moreover what I've observed is that simple grepping gives me > another test script, that uses bash extensions: > - GeneratePropertyPassword.sh [2] > It seems to be linked with another ticket [3] which is closed, > though it still uses the bash "[[" extension. Perhaps that fix [4] > needs to be reapplied. > > In regards to the patch itself, please let me know if I've missed > something. Changes were successfully tested with `dash v0.5.10.2-1`. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214052 > [2] > http://hg.openjdk.java.net/jdk/sandbox/file/413c28945e0f/test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh#l37 > [3] https://bugs.openjdk.java.net/browse/JDK-8025886 > [4] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a2551e12a9ea0.5.10.2-1 > > Regards, > su - > > diff --git > a/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh > b/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh > --- > a/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh > +++ > b/test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh > @@ -27,7 +27,7 @@ > > ver=$(${TESTED_JAVA_HOME}/bin/java ${JAVA_OPTS} -version 2>&1) > isComp=$( echo ${ver} | grep -c "compiled mode") > -if [[ $isComp != 1 ]]; then > +if [ "$isComp" -ne 1 ]; then > echo "skipped. This test works only with -Xcomp" > exit > fi > @@ -40,7 +40,7 @@ > res=$(${TESTED_JAVA_HOME}/bin/java ${JAVA_OPTS} > -XX:+PrintCodeCacheOnCompilation -XX:-Inline > vm.compiler.CodeCacheInfoOnCompilation.PrintOnCall | egrep -ce "${pattern}") > echo "res: " ${res} > > -if (( "${res}" != "0" )); then > +if [ "$res" != "0" ]; then > echo "passed" > true > else > From brian.burkhalter at oracle.com Thu Dec 6 00:04:17 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Dec 2018 16:04:17 -0800 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> <0CA96647-3B5B-41CB-A368-86F5A957C73D@oracle.com> <2864b759-b7a3-1bbc-973c-239d96340de1@oracle.com> <48FF6FE1-1E16-468C-923A-A35CC9C6E88A@oracle.com> <5A44B287-CC4F-4904-ACE2-1621658BCE81@oracle.com> <9d34f98b-9ac2-2d95-896a-3ea36c28cc6f@oracle.com> <35EE3661-242A-48DD-8A5B-10B648E854C1@oracle.com> <45fac915-2dac-bd2d-0f3a-0409e11fe947@oracle.com> <0F1535F5-EE2C-488D-8142-4B09BF0ECC7D@oracle.com> Message-ID: <78FCF6FA-5A11-4167-9FE5-698AA6A4F956@oracle.com> Thanks to everyone who commented on this: it?s pushed at last. Brian From stuart.marks at oracle.com Thu Dec 6 00:39:29 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 5 Dec 2018 16:39:29 -0800 Subject: RFR(xs): 8211882: Broken links in serialized-form.html Message-ID: Hi all, Please review this small fix to correct some broken links in serialized-form.html. Patch appended below. Bug: https://bugs.openjdk.java.net/browse/JDK-8211882 Thanks, s'marks # HG changeset patch # User smarks # Date 1544056617 28800 # Wed Dec 05 16:36:57 2018 -0800 # Node ID 6c531005388bd911684e43d654c914b85a64f9a4 # Parent 413c28945e0f81559283a13d759867d6ae9e7f9d 8211882: Broken links in serialized-form.html Reviewed-by: XXX diff -r 413c28945e0f -r 6c531005388b src/java.base/share/classes/java/util/EnumSet.java --- a/src/java.base/share/classes/java/util/EnumSet.java Wed Dec 05 19:17:22 2018 +0100 +++ b/src/java.base/share/classes/java/util/EnumSet.java Wed Dec 05 16:36:57 2018 -0800 @@ -463,7 +463,7 @@ /** * Returns a - * + * * SerializationProxy * representing the state of this instance. * diff -r 413c28945e0f -r 6c531005388b src/java.base/share/classes/java/util/ImmutableCollections.java --- a/src/java.base/share/classes/java/util/ImmutableCollections.java Wed Dec 05 19:17:22 2018 +0100 +++ b/src/java.base/share/classes/java/util/ImmutableCollections.java Wed Dec 05 16:36:57 2018 -0800 @@ -1091,9 +1091,9 @@ * Creates and returns an immutable collection from this proxy class. * The instance returned is created as if by calling one of the * static factory methods for - * List, - * Map, or - * Set. + * List, + * Map, or + * Set. * This proxy class is the serial form for all immutable collection instances, * regardless of implementation type. This is necessary to ensure that the * existence of any particular implementation type is kept out of the From vicente.romero at oracle.com Thu Dec 6 00:42:37 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Dec 2018 19:42:37 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> Message-ID: <2f072c71-987f-617a-1a49-0054b7df6ed0@oracle.com> Hi Mandy, On 12/5/18 1:12 PM, Mandy Chung wrote: > > > On 12/3/18 11:12 AM, Vicente Romero wrote: >> Hi all, >> >> Can I have the final nod to the JVM constants API, there have been >> some changes since the last review iteration. Thanks to the internal >> and external developers that have taken the time to provide feedback >> so far. The links to the last versions are: >> >> webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ >> javadoc: >> http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html >> specdiff: >> http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html >> > Thanks for your suggestions I have fixed them. > I reviewed webrev.10 and overall looks good to me.? A couple of minor > comments and some of them seems to be fixed already in amber repo.? No > need to generate a new webrev. > > Nit: The javadoc of the new methods starts with "Returns", "Return", > "Produce", "Create", "Resolve", "Compares" etc.? It'd be good to do a > pass and fix the verb form consistently. > > src/java.base/share/classes/java/lang/Class.java > ?? nit: Line 163 seems to have extra white-spaces, not aligned with > the other superinterfaces. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java > 74 private static final Set suppressSubtypesSet > 75 = Set.of("java.lang.Object", > 76 "org.omg.CORBA.Object"); > > This is not related to your change. CORBA is no longer in JDK. > Maybe this special casing is no longer needed. It may worth > filing a JBS issue to examine this. > > ConstantDescs.java > 64 // Don't change the order of these declarations! > > Is there any code depending on this order? not really the order is in increasing `complexity` but there is no hard dependency on it just to keep a logical order > > DirectMethodHandleDesc.java > 46 * {@link MethodHandle}. A {@linkplain DirectMethodHandleDescImpl} corresponds to > > typo: DirectMethodHandleDescImpl > > 57 /** > 58 * Kinds of method handles that can be described with {@linkplain DirectMethodHandleDesc}. > 59 */ > 60 enum Kind { > > This needs @since 12 > > DynamicCallSiteDesc.java > 59 * @param bootstrapMethod a {@link DirectMethodHandleDescImpl} describing the > 60 * bootstrap method for the {@code invokedynamic} > > typo: DirectMethodHandleDescImpl and in a few other @param > > Mandy Thanks, Vicente From joe.darcy at oracle.com Thu Dec 6 00:52:00 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 05 Dec 2018 16:52:00 -0800 Subject: RFR(xs): 8211882: Broken links in serialized-form.html In-Reply-To: References: Message-ID: <5C0872B0.5050308@oracle.com> Hi Stuart, Looks fine; thanks, -Joe On 12/5/2018 4:39 PM, Stuart Marks wrote: > Hi all, > > Please review this small fix to correct some broken links in > serialized-form.html. Patch appended below. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211882 > > Thanks, > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1544056617 28800 > # Wed Dec 05 16:36:57 2018 -0800 > # Node ID 6c531005388bd911684e43d654c914b85a64f9a4 > # Parent 413c28945e0f81559283a13d759867d6ae9e7f9d > 8211882: Broken links in serialized-form.html > Reviewed-by: XXX > > diff -r 413c28945e0f -r 6c531005388b > src/java.base/share/classes/java/util/EnumSet.java > --- a/src/java.base/share/classes/java/util/EnumSet.java Wed Dec 05 > 19:17:22 2018 +0100 > +++ b/src/java.base/share/classes/java/util/EnumSet.java Wed Dec 05 > 16:36:57 2018 -0800 > @@ -463,7 +463,7 @@ > > /** > * Returns a > - * href="../../serialized-form.html#java.util.EnumSet.SerializationProxy"> > + * href="{@docRoot}/serialized-form.html#java.util.EnumSet.SerializationProxy"> > * SerializationProxy > * representing the state of this instance. > * > diff -r 413c28945e0f -r 6c531005388b > src/java.base/share/classes/java/util/ImmutableCollections.java > --- a/src/java.base/share/classes/java/util/ImmutableCollections.java > Wed Dec 05 19:17:22 2018 +0100 > +++ b/src/java.base/share/classes/java/util/ImmutableCollections.java > Wed Dec 05 16:36:57 2018 -0800 > @@ -1091,9 +1091,9 @@ > * Creates and returns an immutable collection from this proxy > class. > * The instance returned is created as if by calling one of the > * static factory methods for > - * List, > - * Map, or > - * Set. > + * List, > + * Map, or > + * Set. > * This proxy class is the serial form for all immutable > collection instances, > * regardless of implementation type. This is necessary to ensure > that the > * existence of any particular implementation type is kept out of > the From vicente.romero at oracle.com Thu Dec 6 02:13:38 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Dec 2018 21:13:38 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> Message-ID: <9b94a0a5-97d3-190b-32a1-e788781bce22@oracle.com> Hi Roger, Thanks for your comments, see my comments below. I have published another iteration at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.12/ On 12/5/18 4:35 PM, Roger Riggs wrote: > Hi, > > Editorial comments java.lang.contant package javadoc: > > ?- In the Nominal Descriptors? 2nd paragraph:? "of of" -> "of" > > -? DirectMethodHandleDescImpl - Its unusual to see a Class named *Impl in > ?? a developer facing API.? And if its intended, it should be linked. DirectMethodHandleDescImpl is not public > > - "These classes provides" plural agreement. > > > DynamicCallSiteDesc: > > ?- Is the format of names clearly specified:? IAE -> if the invocation > name has the 'incorrect format'. I think so, depending on the case it the related part of the JVMS is added as a reference > > ?- typo: ? "descripbing" - > "describing" > > ?- missing @throws IAE for method : > > ?? ?of(DirectMethodHandleDesc > > ?bootstrapMethod,String > > ?invocationName,MethodTypeDesc > > ?invocationType) > > > - The withArgs method only throws NPE:? is there nothing else that can > go wrong? the rest of the arguments passed to the invocation to constructor DynamicCallSiteDesc has already been checked so no other exceptions associated to them should be thrown > > - bootStrapArgs() - the return is always non-null, with zero length > array for non args? it has to be, IMO, as the private constructor that is the only one that assigns a value to field bootstrapArgs makes sure that the assigned value is non-null > > DynamicConstantDesc.java: > ?- First sentences should end with period. "." > > ?- ofCanonical:? 2nd sentence, "Classes ... produces ... a > ConstantDesc"; grammar? > > ?- of Canaonical(): So a conforming implementation is not required to > return the > ??? well known values, only suggested. > > ClassDesc.java: > ?- The create methods should not be required to create new instances.? > Use "return"? instead of "create". > > ?- How are class descriptors created for 'nested' classes (as opposed > to inner classes). > ?? It is worth describing or referencing how that should be done. not sure I get what you mean. If you want to create a class descriptor for a nested class you should be able to invoke inner() with an string containing a number, what should be made more clear here in your opinion? > > ?- Can inner() throw IAE for invalid format names? yes added > > ?- How can the rank of an array ClassDesc be found? we can add a method for this after the integration > > Constable.java: > > ?- Avoid ending the first sentence of describeConstable description > with "be". > > ConstDesc.java: > ?- "with respect to a particular to a class loader" ; extra words "to a"? > > DirectMethodHandleDesc.java: > ?- ofField, @throws IAE might mention the possibility of an invalid name right > > MethodTypeDesc.java: > ?- First sentences should end with period. "." > > Regards, Roger > > > On 12/05/2018 01:12 PM, Mandy Chung wrote: >> >> >> On 12/3/18 11:12 AM, Vicente Romero wrote: >>> Hi all, >>> >>> Can I have the final nod to the JVM constants API, there have been >>> some changes since the last review iteration. Thanks to the internal >>> and external developers that have taken the time to provide feedback >>> so far. The links to the last versions are: >>> >>> webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ >>> javadoc: >>> http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html >>> specdiff: >>> http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html >>> >> >> I reviewed webrev.10 and overall looks good to me.? A couple of minor >> comments and some of them seems to be fixed already in amber repo.? >> No need to generate a new webrev. >> >> Nit: The javadoc of the new methods starts with "Returns", "Return", >> "Produce", "Create", "Resolve", "Compares" etc.? It'd be good to do a >> pass and fix the verb form consistently. >> >> src/java.base/share/classes/java/lang/Class.java >> ?? nit: Line 163 seems to have extra white-spaces, not aligned with >> the other superinterfaces. >> >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java >> 74 private static final Set suppressSubtypesSet >> 75 = Set.of("java.lang.Object", >> 76 "org.omg.CORBA.Object"); >> >> This is not related to your change. CORBA is no longer in JDK. >> Maybe this special casing is no longer needed.? It may worth >> filing a JBS issue to examine this. >> >> ConstantDescs.java >> ? 64???? // Don't change the order of these declarations! >> >> Is there any code depending on this order? >> >> DirectMethodHandleDesc.java >> ? 46? * {@link MethodHandle}.? A {@linkplain >> DirectMethodHandleDescImpl} corresponds to >> >> typo: DirectMethodHandleDescImpl >> >> ? 57???? /** >> ? 58????? * Kinds of method handles that can be described with >> {@linkplain DirectMethodHandleDesc}. >> ? 59????? */ >> ? 60???? enum Kind { >> >> This needs @since 12 >> >> DynamicCallSiteDesc.java >> ? 59????? * @param bootstrapMethod a {@link >> DirectMethodHandleDescImpl} describing the >> ? 60????? *??????????????????????? bootstrap method for the {@code >> invokedynamic} >> >> typo: DirectMethodHandleDescImpl and in a few other @param >> >> Mandy >> > From stuart.marks at oracle.com Thu Dec 6 02:18:39 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 5 Dec 2018 18:18:39 -0800 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> Message-ID: Hi Vinnie, Roger Riggs wrote: >> The 'forEachOrdered' should not be necessary and may raise questions about why. >> if there's no good reason, use 'forEach?. Using forEachOrdered() is necessary. The dumpAsStream() method produces a stream; presumably it has a defined order that's the same as its input. The semantics of Stream.forEach() are extremely relaxed, and in particular it's not required to process stream elements in order, even if the stream is ordered. (In practice this is noticeable if the stream is run in parallel.) I'd use forEachOrdered() both in the examples and also where you use it in implementations. The methods that return streams should specify the important characteristics. Probably the ones most important one are that the returned stream is ordered and sequential. For the overloads that take fixed-size input, the resulting stream might also be SIZED. I'm not convinced that the overloads that send output to an OutputStream pull their weight. They basically wrap the OutputStream in a PrintStream, which conveniently doesn't declare IOException, making it easy to use from a lambda passed to forEachOrdered(). If an error writing the output occurs, this is recorded by the PrintStream wrapper; however, the wrapper is then thrown away, making it impossible for the caller to check its error status. The PrintStream wrapper also uses the platform default charset, and doesn't provide any way for the caller to override the charset. Instead, you can just provide the Stream-returning methods, and let the user send the output to a PrintStream using forEachOrdered() as in your examples. It might be nice to provide convenience APIs to send output elsewhere, but the problem is that it seems difficult to do so without losing control over things like error handling or charsets. In particular, since the hex formatter is producing strings, it seems like there should be an option to send the output to a Writer. Unfortunately it's difficult to do so from a Stream, because all the Writer methods throw IOException. However, solving this isn't hexdump's problem. s'marks From stuart.marks at oracle.com Thu Dec 6 02:26:56 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 5 Dec 2018 18:26:56 -0800 Subject: Both Collector.of() are not correctly typed In-Reply-To: <48874439.1429903.1543176635247.JavaMail.zimbra@u-pem.fr> References: <229287898.475572.1542120474930.JavaMail.zimbra@u-pem.fr> <48874439.1429903.1543176635247.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, I can sponsor this for you. Can you file a bug report? Thanks, s'marks On 11/25/18 12:10 PM, Remi Forax wrote: > ping ! > > R?mi > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "core-libs-dev" >> Envoy?: Mardi 13 Novembre 2018 15:47:54 >> Objet: Both Collector.of() are not correctly typed > >> Last year, >> a student of mine as remarked that the two variants of Collector.of() are not >> correctly typed (the wildcards are missing) >> and obviously, this year it's one of my teaching assistant that has found >> exactly the same issue. >> So let's fix this issue. >> >> Adding the wildcards is both source and binary backward compatible in this case >> - the methods of are static (so no overriding possible) >> - the wildcards types are super types of the types of current version, so it >> will not break at use sites and >> - the erased signature is the same so it's a binary backward compatible change. >> >> The right code is >> @SuppressWarnings("unchecked") >> public static Collector of(Supplier supplier, >> BiConsumer accumulator, >> BinaryOperator combiner, >> Characteristics... characteristics) { >> Objects.requireNonNull(supplier); >> Objects.requireNonNull(accumulator); >> Objects.requireNonNull(combiner); >> Objects.requireNonNull(characteristics); >> Set cs = (characteristics.length == 0) >> ? Collectors.CH_ID >> : >> Collections.unmodifiableSet(EnumSet.of(Collector.Characteristics.IDENTITY_FINISH, >> characteristics)); >> return new Collectors.CollectorImpl<>((Supplier)supplier, (BiConsumer> T>)accumulator, combiner, cs); >> } >> and >> @SuppressWarnings("unchecked") >> public static Collector of(Supplier supplier, >> BiConsumer accumulator, >> BinaryOperator combiner, >> Function finisher, >> Characteristics... characteristics) { >> Objects.requireNonNull(supplier); >> Objects.requireNonNull(accumulator); >> Objects.requireNonNull(combiner); >> Objects.requireNonNull(finisher); >> Objects.requireNonNull(characteristics); >> Set cs = Collectors.CH_NOID; >> if (characteristics.length > 0) { >> cs = EnumSet.noneOf(Characteristics.class); >> Collections.addAll(cs, characteristics); >> cs = Collections.unmodifiableSet(cs); >> } >> return new Collectors.CollectorImpl<>((Supplier)supplier, (BiConsumer> T>)accumulator, combiner, (Function)finisher, cs); >> } >> >> You may ask why the code is safe given there are now some >> @SuppressWarnings("unchecked"), it's because for a functional interface, >> the parameter types are contra-variant and the return type is covariant. >> >> At one point in the future, perhaps JEP 300 [1] will be implemented, in that >> case we will be able to remove the @SuppressWarnings. >> >> You may also notice that, we may want at the same time replace the >> unmodifiableSet(EnumSet.of() + add) with Set.of(), >> i've not done that change given it's not related to the typing issue. >> >> cheers, >> R?mi >> >> [1] https://openjdk.java.net/jeps/300 From patrick at os.amperecomputing.com Thu Dec 6 08:27:39 2018 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Thu, 6 Dec 2018 08:27:39 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> Message-ID: To All, Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. Regards Patrick -----Original Message----- From: David Holmes Sent: Monday, December 3, 2018 8:11 AM To: Patrick Zhang ; Florian Weimer Cc: core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: > Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). > > Hi David, > Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. > In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David > #ifdef _MSC_VER // Windows > #define gmtime_r(t, s) gmtime(t) > #endif > > Regards > Patrick > > -----Original Message----- > From: Florian Weimer > Sent: Thursday, November 29, 2018 8:02 PM > To: David Holmes > Cc: Patrick Zhang ; > jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include > inside zip.cpp comes from a non-sysroot path > > * David Holmes: > >> This should really be being discussed on core-libs-dev. > > Okay, moving the conversation. > >>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp >>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 >>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 >>> @@ -415,9 +415,7 @@ >>> ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>> } >>> -#ifdef _REENTRANT // solaris >>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>> +#if !defined(_REENTRANT) // linux >>> #define gmtime_r(t, s) gmtime(t) >>> #endif >>> /* >> >> Under the theme "two wrongs don't make a right" the use of _REENTRANT >> here is totally inappropriate AFAICS. It seems to be a misguided >> attempt at determining whether we need the thread-safe gmtime_r or >> not >> - and the answer to that should always be yes IMHO. >> >> We define _REENTRANT for: >> - linux >> - gcc >> - xlc >> >> So the original code will define: >> >> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >> >> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >> >> But Solaris has gmtime_r anyway. So the existing code seems a really >> convoluted hack. AFAICS we have gmtime_r everywhere but Windows >> (where gmtime is already thread-safe). So it seems to me that all we >> should need here is: >> >> -#ifdef _REENTRANT // solaris >> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >> +#ifdef _MSC_VER // Windows >> #define gmtime_r(t, s) gmtime(t) >> #endif > > That looks much cleaner. > > Thanks, > Florian > From Alan.Bateman at oracle.com Thu Dec 6 08:56:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Dec 2018 08:56:35 +0000 Subject: RFR: 8214858: Improve module graph archiving In-Reply-To: <765d4c69-4fe3-3eb6-7956-f38297960746@oracle.com> References: <765d4c69-4fe3-3eb6-7956-f38297960746@oracle.com> Message-ID: <798a7969-6cdc-b23c-8e6e-ddb31eabe842@oracle.com> On 05/12/2018 15:13, Claes Redestad wrote: > Hi, > > a few improvements to how we archive module graph information: > > - archive an instance of ArchiveModuleGraph rather than individual fields > - archiving the exportedPackagesToOpen and concealedPackagesToOpen > maps improve sharing and substantially reduce bytecode executed (~30k) > - archiving the remaining flags in the ArchivedModuleGraph means we no > longer need to archive SystemModules > ? - this means we no longer load jdk.internal.module.SystemModules and > jdk.internal.module.SystemModules$default at runtime > - for robustness ensure we either resolve either everything or nothing > from the archive (there are some overlapping safeguards here, e.g., > CDS is disabled when you run with --limit-modules, but helps to be > explicit) > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8214858 > Webrev: http://cr.openjdk.java.net/~redestad/8214858/jdk.00/ > > Testing: tier1-3, locally tested all module and CDS tests > Startup tests verify a small speedup on my test setups (around -0.5ms > on average) I think these changes look okay. Once we get to the point of not permitting illegal access by default then we might look at this again as the concealed/exported maps won't be needed for the default case. -Alan From takiguc at linux.vnet.ibm.com Thu Dec 6 10:56:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 06 Dec 2018 19:56:25 +0900 Subject: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset In-Reply-To: <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> Message-ID: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ IBM29626C charset is required for AIX default charset. Java cannot start because of java/lang/ExceptionInInitializerError on AIX ja_JP locale. To build team, I'd like to change following charsetmapping tool. * make/jdk/src/classes/build/tools/charsetmapping/Main.java * make/jdk/src/classes/build/tools/charsetmapping/SPI.java * make/jdk/src/classes/build/tools/charsetmapping/SRC.java build.tools.charsetmapping,Main supports "os" tag, but it seems it's not used. Currently, "os" supports "windows" or "unix". I extended "os" tag's feature. If "os aix" is there, this charset is only added into AIX platform. (I assume "type template" should be used) "aix" comes from "stdcs-aix" file name. ====== charset x-IBM29626C IBM29626C package sun.nio.cs.ext type template os aix <===== alias cp29626C # JDK historical alias ibm29626C alias ibm-29626C alias 29626C alias ibm-eucjp ====== If cs.os is null, this charset is stored into gensrc directory. Charset name is added into StandardCharsets.java or ExtendedCharsets.java If cs.os is "false", this charset is NOT stored into gensrc directory. Charset name is NOT added into StandardCharsets.java or ExtendedCharsets.java "os" tag supports multiple entries by using ",", like "aix,linux" Then we can store new charset into src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory $ locale charmap IBM-eucJP $ jshell | JShell -- 12-internal | : /help intro jshell> var cs = java.nio.charset.Charset.defaultCharset() cs ==> x-IBM29626C jshell> cs.getClass().getName() $2 ==> "sun.nio.cs.IBM29626C" jshell> System.out.println(String.join("\n", cs.aliases())) cp29626C ibm-29626C ibm-eucjp ibm29626C 29626C jshell> /exit | $ I tested Linux and Windows build. ====== $ grep 29626 build.log IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false $ find support/gensrc/ | grep 29626 $ find support/gensrc/ | grep Charsets support/gensrc/java.base/sun/nio/cs/StandardCharsets.java support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java $ find support/gensrc/ | grep Charsets | xargs grep 29626 $ ====== I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-11-28 19:10, Magnus Ihse Bursie wrote: > On 2018-11-28 10:36, Alan Bateman wrote: >> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>> I'm quite unsatisfied with the current handling of character sets in >>> the build in general. :-( I'd really like to modernize it. I have a, >>> slightly fuzzy, laundry list of things I want to fix from a build >>> perspective, but I'm not sure of what "external" requirements are >>> coming from AIX and the general core-libs agenda regarding character >>> sets in general. >>> >>> I think there is a good opportunity to solve many problems at the >>> same time here, as long as everyone agrees on what is the preferred >>> outcome. >> The support in the build to configure the charsets to include in >> java.base on each platform has been working well. Charsets that aren't >> in java.base go into the jdk.charsets service provider module and that >> has been working well too. From the result point of view, perhaps, but >> definitely not from the build perspective. ;-) But yes, I understand >> this is functionality that should be kept. >> One thing that we lack is some way to add charsets for specific >> platforms and this comes up with the IBM patches where they are >> looking to adding several additional IBM charsets. One starting point >> that we've touched on in several threads here is dropping the EBCDIC >> charsets from the main stream builds. Going there will need build >> support. > So build support for trivially adding specific charsets to specific > platforms? Both to java.base (for AIX) and jdk.charsets, I presume, > then? > > Can you expand on the issue of dropping ebcdic? What's the problem > that needs build support? > > /Magnus >> >> >> -Alan From claes.redestad at oracle.com Thu Dec 6 12:03:22 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 6 Dec 2018 13:03:22 +0100 Subject: RFR: 8214858: Improve module graph archiving In-Reply-To: <798a7969-6cdc-b23c-8e6e-ddb31eabe842@oracle.com> References: <765d4c69-4fe3-3eb6-7956-f38297960746@oracle.com> <798a7969-6cdc-b23c-8e6e-ddb31eabe842@oracle.com> Message-ID: <1b82307f-2484-d722-6494-7a8be8f8209f@oracle.com> Jiangli, Alan, thanks for reviewing! On 2018-12-06 09:56, Alan Bateman wrote: > On 05/12/2018 15:13, Claes Redestad wrote: >> Hi, >> >> a few improvements to how we archive module graph information: >> >> - archive an instance of ArchiveModuleGraph rather than individual >> fields >> - archiving the exportedPackagesToOpen and concealedPackagesToOpen >> maps improve sharing and substantially reduce bytecode executed (~30k) >> - archiving the remaining flags in the ArchivedModuleGraph means we >> no longer need to archive SystemModules >> ? - this means we no longer load jdk.internal.module.SystemModules >> and jdk.internal.module.SystemModules$default at runtime >> - for robustness ensure we either resolve either everything or >> nothing from the archive (there are some overlapping safeguards here, >> e.g., CDS is disabled when you run with --limit-modules, but helps to >> be explicit) >> >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8214858 >> Webrev: http://cr.openjdk.java.net/~redestad/8214858/jdk.00/ >> >> Testing: tier1-3, locally tested all module and CDS tests >> Startup tests verify a small speedup on my test setups (around -0.5ms >> on average) > I think these changes look okay. > > Once we get to the point of not permitting illegal access by default > then we might look at this again as the concealed/exported maps won't > be needed for the default case. Yes, I can think of a few ways to simplify once --illegal-access=deny becomes default (and either way that will be beneficial to startup time). /Claes From Roger.Riggs at oracle.com Thu Dec 6 16:07:03 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 11:07:03 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <9b94a0a5-97d3-190b-32a1-e788781bce22@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> <9b94a0a5-97d3-190b-32a1-e788781bce22@oracle.com> Message-ID: Hi Vicente, On 12/05/2018 09:13 PM, Vicente Romero wrote: > Hi Roger, > > Thanks for your comments, see my comments below. I have published > another iteration at [1] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.12/ > > >> >> - bootStrapArgs() - the return is always non-null, with zero length >> array for non args? > > it has to be, IMO, as the private constructor that is the only one > that assigns a value to field bootstrapArgs makes sure that the > assigned value is non-null My point is that the javadoc is a specification; so the reader should not need to look at an implementation to completely understand the required behavior. > >> >> DynamicConstantDesc.java: >> ?- First sentences should end with period. "." >> >> ?- ofCanonical:? 2nd sentence, "Classes ... produces ... a >> ConstantDesc"; grammar? >> >> ?- of Canaonical(): So a conforming implementation is not required to >> return the >> ??? well known values, only suggested. >> >> ClassDesc.java: >> ?- The create methods should not be required to create new >> instances.? Use "return"? instead of "create". >> >> ?- How are class descriptors created for 'nested' classes (as opposed >> to inner classes). >> ?? It is worth describing or referencing how that should be done. > > not sure I get what you mean. If you want to create a class descriptor > for a nested class you should be able to invoke inner() with an string > containing a number, what should be made more clear here in your opinion? In other places in java specs, there is a distinction made between 'inner' classes and 'nested' classes. If the same API is used for both, it would be clearer to the reader if it mentioned nested. Thanks, Roger > >> >> MethodTypeDesc.java: >> ?- First sentences should end with period. "." >> >> Regards, Roger >> >> >> On 12/05/2018 01:12 PM, Mandy Chung wrote: >>> >>> >>> On 12/3/18 11:12 AM, Vicente Romero wrote: >>>> Hi all, >>>> >>>> Can I have the final nod to the JVM constants API, there have been >>>> some changes since the last review iteration. Thanks to the >>>> internal and external developers that have taken the time to >>>> provide feedback so far. The links to the last versions are: >>>> >>>> webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ >>>> javadoc: >>>> http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html >>>> specdiff: >>>> http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html >>>> >>> >>> I reviewed webrev.10 and overall looks good to me.? A couple of >>> minor comments and some of them seems to be fixed already in amber >>> repo.? No need to generate a new webrev. >>> >>> Nit: The javadoc of the new methods starts with "Returns", "Return", >>> "Produce", "Create", "Resolve", "Compares" etc. It'd be good to do a >>> pass and fix the verb form consistently. >>> >>> src/java.base/share/classes/java/lang/Class.java >>> ?? nit: Line 163 seems to have extra white-spaces, not aligned with >>> the other superinterfaces. >>> >>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java >>> 74 private static final Set suppressSubtypesSet >>> 75 = Set.of("java.lang.Object", >>> 76 "org.omg.CORBA.Object"); >>> >>> This is not related to your change. CORBA is no longer in JDK. >>> Maybe this special casing is no longer needed.? It may worth >>> filing a JBS issue to examine this. >>> >>> ConstantDescs.java >>> ? 64???? // Don't change the order of these declarations! >>> >>> Is there any code depending on this order? >>> >>> DirectMethodHandleDesc.java >>> ? 46? * {@link MethodHandle}.? A {@linkplain >>> DirectMethodHandleDescImpl} corresponds to >>> >>> typo: DirectMethodHandleDescImpl >>> >>> ? 57???? /** >>> ? 58????? * Kinds of method handles that can be described with >>> {@linkplain DirectMethodHandleDesc}. >>> ? 59????? */ >>> ? 60???? enum Kind { >>> >>> This needs @since 12 >>> >>> DynamicCallSiteDesc.java >>> ? 59????? * @param bootstrapMethod a {@link >>> DirectMethodHandleDescImpl} describing the >>> ? 60????? *??????????????????????? bootstrap method for the {@code >>> invokedynamic} >>> >>> typo: DirectMethodHandleDescImpl and in a few other @param >>> >>> Mandy >>> >> > From Roger.Riggs at oracle.com Thu Dec 6 16:16:55 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 11:16:55 -0500 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 Message-ID: Hi Michihiro, On 12/06/2018 02:38 AM, Michihiro Horie wrote: > > Hi Roger, > > Thank you for your helpful comments. I updated new webrev,adding a > parameter in the jmh test to measure ?other?characters and moving the > file to an appropriate location,also fixing the indents and copyright > year. > http://cr.openjdk.java.net/~mhorie/8213754/webrev.03/ > > The choice of 256 for other is outside the range of Latin1 which is 0..255. 0x80 might be a good choice or 0xff. > > >Is there an opportunity to improve the performance of isDigit using > explicit '0'.. '9' > >in CharacterDataLatin1.java.template?? The performance would need to > be measured and compared. > Yes,there is an opportunity: intrinsic performed 25% better than the > original on Power9. > I was wondering about the performance without the PPC specific intrinsic but with the CharacterDataLatin1.java.template code for isDigit being: ??? ??? return '0' <= ch && ch <= '9'; > > >Is the profile of in-lining methods changed in any measurable way now > that > >there is an extra level of method invocation? > > ?? Character.isLowerCase(ch)-> CharacterData.isLowerCase(ch)-> > getType(ch)== LOWERCASE_LETTER; > > > >instead of: > >??? Character.isLowerCase(ch)-> getType(ch)== LOWERCASE_LETTER; > I missed this point,thanks. I tried jstack but could not find > additional level. > > LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled > in c1: > entry='0x00003fff5911cd00' size='1472' address='0x00003fff5911cb90' > relocation_offset='344' insts_offset='368' stub_offset='1136' > scopes_data_offset='1248' scopes_pcs_offset='1336' > dependencies_offset='1448' nul_chk_table_offset='1456' > oops_offset='1184' metadata_offset='1192' > method='java.lang.CharacterDataLatin1 isLowerCase(I)Z' bytes='15' > count='1024' iicount='1025' stamp='0.058'/> > Supposing some existing complex code was already taking advantage of the full allowed inline depth. Then adding an extra level might change the inlining behavior. > > > Existing methods in CharacterDataLatin1.java.template etc. directly > invoke getProperties(ch),so isLowerCase(ch)would be more aligned with > other methods if it looks like as follows? > + @HotSpotIntrinsicCandidate > + boolean isLowerCase(int ch){ > + int props = getProperties(ch); > + return (props & $$maskType)== Character.LOWERCASE_LETTER; > + } > Yes, that would alleviate my concern. Thanks, Roger > > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi > Michihiro, On 12/05/2018 07:21 AM, Michihiro Horie wrote:Roger Riggs > ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 07:21 AM, > Michihiro Horie wrote: > > From: Roger Riggs > To: Michihiro Horie , vladimir.kozlov at oracle.com > Cc: core-libs-dev at openjdk.java.net, > hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, > volker.simonis at sap.com > Date: 2018/12/06 05:09 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------ > > > > Hi Michihiro, > > On 12/05/2018 07:21 AM, Michihiro Horie wrote: > > >There are a few JMH tests for upper and lower in the > jmh-jdk-microbenchmarks repo. [1] > Here is a jmh webrev for the Character methods._ > __http://cr.openjdk.java.net/~mhorie/8213754/jmh-webrev.00/_ > > > Please include at least one character value that is not a member of > any of the classes. > The performance impact for 'other' characters is important also. > > The JMH tests have been moved to the OpenJDK jdk/jdk repo in the > directory: > ?? test/micro/org/openjdk/bench/java/lang/ > > Now that they are in that repo, they can be included with the rest of > the changeset. > > Also, I updated C2 changes in the latest webrev. (Thank you > for giving valuable comments off-list, Vladimir and Martin!) > With the change in is_disabled_by_flags, I added a JVM flag > that will need another review request. I would proceed for it > if this RFR is accepted._ > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.02/_ > > > The indent in the Java code should be 4 spaces. (Native lib code is 4 > spaces, Hotspot is 2 spaces) > > Please update the copyrights to include 2018. > > Is there an opportunity to improve the performance of isDigit using > explicit '0'.. '9' > in CharacterDataLatin1.java.template?? The performance would need to > be measured and compared. > > Is the profile of in-lining methods changed in any measurable way now that > there is an extra level of method invocation? > ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> > getType(ch) == LOWERCASE_LETTER; > > instead of: > ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > > Regards, Roger > > I need a review on changes in the class library, anyway. Would > be grateful if I could have one. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > > ----- Original message ----- > From: Michihiro Horie/Japan/IBM > To: Vladimir Kozlov __ > > Cc: core-libs-dev __ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ , Roger > Riggs __ > , _volker.simonis at sap.com_ > > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > Date: Fri, Nov 30, 2018 1:01 PM > > Hi Vladimir, > > Thank you for your further comments. I fixed my code, but I?m > afraid discussing such a basic topic involving the two big > mailing lists is not good. Please let me have a chance to talk > on this off-list. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still > do not understand which Region node you are swapping. Where it > is coming from? > > From: Vladimir Kozlov __ > > To: Michihiro Horie __ > , Roger Riggs > __ > Cc: core-libs-dev __ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ , > _volker.simonis at sap.com_ > Date: 2018/11/30 03:01 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > ------------------------------------------------------------------------ > > > > Hi Michihiro, > > I still do not understand which Region node you are swapping. > Where it is coming from? > > > + // Swap current RegionNode with new one > > Regards, > Vladimir > > On 11/28/18 10:31 PM, Michihiro Horie wrote: > > Vladimir,Roger, > > Thank you so much for your responses. > > > > Vladimir, > > Regarding the hotspot change,I?m new in changing around > library_call.cpp,so your comments are very helpful. I will fix > > my code,especially inline_character_compare()would be like: > > > > +bool > LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ > > + RegionNode* old_rgn = control()->as_Region(); > > + RegionNode* new_rgn = new RegionNode(1); > > + record_for_igvn(new_rgn); > > + > > + // Swap current RegionNode with new one > > + Node* new_ctrl = old_rgn->in(1); > > + old_rgn->del_req(1); > > + new_rgn->add_req(new_ctrl); > > + > > + set_control(_gvn.transform(new_rgn)); > > + > > + // argument(0)is receiver > > + Node* codePoint = argument(1); > > + Node* n = NULL; > > + > > + switch (id){ > > + case vmIntrinsics::_isDigit_c : n = new > DigitCNode(control(),codePoint);break; > > + case vmIntrinsics::_isLowerCase_c : n = new > LowerCaseCNode(control(),codePoint);break; > > + case vmIntrinsics::_isUpperCase_c : n = new > UpperCaseCNode(control(),codePoint);break; > > + case vmIntrinsics::_isWhitespace_c : n = new > WhitespaceCNode(control(),codePoint);break; > > + default: > > + fatal_unexpected_iid(id); > > + } > > + > > + set_result(_gvn.transform(n)); > > + return true; > > +} > > > > Microbenchmark showed ~40% improvements. > > > > Roger, > > I would wait foryour review,thanks. I understood the > discussion had not been recognized from people in > core-libs-dev,and > > checked it was not actually archived there?. > > > > Best regards, > > -- > > Michihiro, > > IBM Research - Tokyo > > > > Inactive hide details for Roger Riggs ---2018/11/29 > 11:21:26---Hi, I'll look at it on Thursday.Roger Riggs > ---2018/11/29 > > 11:21:26---Hi, I'll look at it on Thursday. > > > > From: Roger Riggs __ > > > To: Vladimir Kozlov __ > , Michihiro Horie > __ , > _core-libs-dev at openjdk.java.net_ > > > Cc: _volker.simonis at sap.com_ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ > > Date: 2018/11/29 11:21 > > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > > > > > ------------------------------------------------------------------------------------------------------------------------ > > > > > > > > Hi, > > > > I'll look at it on Thursday. > > > > In spite of it looking like the email was sent to > core-lib-dev, I have > > not seen it before > > and its not in the core-libs-dev archive. > > > > $.02, Roger > > > > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > > ?> You still need review from core-libs. > > ?> > > ?> About your hotspot changes. You need to add intrinsics to > > ?> is_disabled_by_flags() to be able switch them off. > > ?> > > ?> Note, match_rule_supported() calls in > > ?> C2Compiler::is_intrinsic_supported() executed before > intrinsics in C2 > > ?> are registered. So they will not be available if they are not > > ?> supported. match_rule_supported() checks in > > ?> LibraryCallKit::inline_character_compare() are not needed. > > ?> > > ?> I don't get what you code in > > ?> LibraryCallKit::inline_character_compare() is doing. Why > you check > > ?> Region node at the beginning and why you add Region and > Phi at the end > > ?> if you have only one path? > > ?> You are creating code for whole method which should > return boolean result > > ?> > > ?> + ? ?boolean isDigit(int ch) { > > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; > > ?> + ? ?} > > ?> > > ?> but your code produce TypeInt::CHAR. why? > > ?> > > ?> An finally. Did you compare code generated by default and > with you > > ?> changes? what improvement you see? > > ?> > > ?> Thanks, > > ?> Vladimir > > ?> > > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: > > ?>> Is there any response from core-libs-dev? > > ?>> > > ?>> Vladimir, > > ?>> Could you give your suggestion on how to proceed? > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > ?>> ----- Original message ----- > > ?>> From: "Michihiro Horie" __ > > > ?>> Sent by: "hotspot-compiler-dev" > > ?>> __ > > > ?>> To: "Doerr, Martin" __ > > > ?>> Cc: "Simonis, Volker" __ > , > > ?>> _"hotspot-compiler-dev at openjdk.java.net"_ > __ > , > > ?>> _"core-libs-dev at openjdk.java.net"_ > __ > > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> Date: Thu, Nov 22, 2018 11:28 AM > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> Yes, we should wait for the feedback on class library > change. > > ?>> > > ?>> ?>Btw. I think you can further simplify the code in > library_call.cpp > > ?>> (no phi). But we can discuss details when thedirection > regarding the > > ?>> java classes is clear. > > ?>> Thank you for pointing out it, I think I understand how > to simplify > > ?>> code. > > ?>> > > ?>> ?>Hi Michi, > > ?>> ?> > > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: > > ?>> ?>> >Please note that we don?t have a machine, yet. So > other people > > ?>> will have to test. > > ?>> ?>> I think Gustavo can help testing this change when > its' ready. > > ?>> ?>Sure :) > > ?>> ?> > > ?>> ?>Best regards, > > ?>> ?>Gustavo > > ?>> Thank you, Gustavo. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 > 01:33:34---Hi > > ?>> Michihiro, thanks. This proposal makes the javacode > much"Doerr, > > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. > This proposal > > ?>> makes the java code much moreintrinsics friendly. > > ?>> > > ?>> From: "Doerr, Martin" __ > > > ?>> To: Michihiro Horie __ > , > > ?>> _"core-libs-dev at openjdk.java.net"_ > __ > > > ?>> Cc: _"hotspot-compiler-dev at openjdk.java.net"_ > > > ?>> __ > , "Simonis, > > ?>> Volker"__ > , Gustavo Romero > > ?>> __ > > > ?>> Date: 2018/11/22 01:33 > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> > > > ------------------------------------------------------------------------------------------------------------------------ > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> Hi Michihiro, > > ?>> > > ?>> thanks. This proposal makes the java code much more > intrinsics friendly. > > ?>> We should wait for feedback from the core lib folks. > Maybe they have > > ?>> some requirements or other proposals. > > ?>> > > ?>> I think these intrinsics should be interesting for > Oracle, Intel and > > ?>> others, too. > > ?>> > > ?>> Btw. I think you can further simplify the code in > library_call.cpp > > ?>> (no phi). But we can discuss details when thedirection > regarding the > > ?>> java classes is clear. > > ?>> > > ?>> Best regards, > > ?>> Martin > > ?>> > > ?>> * > > ?>> **From:*Michihiro Horie __ > * > > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* > > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin > > ?>> __ * > > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker > > ?>> __ > ; Gustavo > Romero__ > * > > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> I send this RFR to core-libs-dev too, because it changes > the class > > ?>> library. > > ?>> > > ?>> Through trial and error, I separated Latin1 block as in > the _ > > ?>> > > ___http://cr.openjdk.java.net/~mhorie/8213754/webrev.01__ > > > > > ?>> > <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.01_>_/_ > > ?>> > > ?>> I followed the coding way of Character.isWhitespace() > that invokes > > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), > > ?>> isLowerCase(), and isUpperCase(). > > ?>> > > ?>> I think this change is also useful on x86, using STTNI. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > ?>> ----- Original message ----- > > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>> > > ?>> Sent by: "hotspot-compiler-dev" > > ?>> > <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_>> > > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>> > > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > ?>> <_mailto:volker.simonis at sap.com_>>, > > ?>> > "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > ?>> > <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>>, > > ?>> > "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > > ?>> > <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>> > > ?>> > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> Date: Wed, Nov 21, 2018 1:53 AM > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> Thank you for giving your helpful comments. I did not > recognize > > ?>> ?generate_method_call_static? prevents anyoptimizations, > but I now > > ?>> checked it actually degraded the performance, thanks. > > ?>> > > ?>> ?>Please note that we don?t have a machine, yet. So > other people will > > ?>> have to test. > > ?>> I think Gustavo can help testing this change when its' > ready. > > ?>> > > ?>> ?>Would it be possible to introduce more fine-grained > intrinsics such > > ?>> that the ?slow? path is outside of them? > > ?>> ?> > > ?>> ?>Maybe you can factor out as in the following example? > > ?>> ?>if (latin1) return isLatin1Digit(codePoint); > > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. > > ?>> Thanks for an example, please let me try to separate the > Latin block > > ?>> from other blocks for some time. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 > 01:55:27---Hi > > ?>> Michihiro, first of all, thanks for working onPower9 > opt"Doerr, > > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of > all, thanks > > ?>> for working on Power9optimizations. Please note that we > don't ha > > ?>> > > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>> > > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>>, > > ?>> > "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > > ?>> > <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > ?>> > "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, > > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero > > ?>> > <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_>> > > ?>> Date: 2018/11/20 01:55 > > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> > > > ------------------------------------------------------------------------------------------------------------------------ > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> Hi Michihiro, > > ?>> > > ?>> first of all, thanks for working on Power9 > optimizations. Please note > > ?>> that we don?t have a machine, yet. So other peoplewill > have to test. > > ?>> > > ?>> I think it may be problematic to insert a slow path by > > ?>> ?generate_method_call_static?. This may be a > performancedisadvantage > > ?>> for some users of other encodings because your > intrinsics prevent > > ?>> inlining and further optimizations. > > ?>> Would it be possible to introduce more fine-grained > intrinsics such > > ?>> that the ?slow? path is outside of them? > > ?>> > > ?>> Maybe you can factor out as in the following example? > > ?>> if (latin1) return isLatin1Digit(codePoint); > > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. > > ?>> > > ?>> I can?t judge if this is needed, but I think this should > be discussed > > ?>> first before going into the details. > > ?>> > > ?>> Best regards, > > ?>> Martin > > ?>> > > ?>> * > > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>>* > > ?>> **Sent:*Freitag, 16. November 2018 12:53* > > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ > > ?>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ > > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* > > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker > > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_>>; > > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero > > ?>> <_gromero at linux.vnet.ibm.com_ > <_mailto:gromero at linux.vnet.ibm.com_>>* > > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> Dear all, > > ?>> > > ?>> Would you please review following change? > > ?>> > > ?>> Bug: > > __https://bugs.openjdk.java.net/browse/JDK-8213754__ > > ?>> Webrev: > > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.00__ > > > > > ?>> <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.00_> > > ?>> > > ?>> This change includes the intrinsics of Character isDigit, > > ?>> isLowerCase, isUpperCase, and isWhitespace to support > theLatin1 block > > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb > enables to > > ?>> compare a character with 1 or 2 rangedbytes, while the > cmpeqb > > ?>> compares one with 1 to 8 values. Simple micro benchmark > attached > > ?>> showed improvements by 20-40%. > > ?>> / > > ?>> //(See attached file: Latin1Test.java)/ > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > > > > > > > > > > > > > > From takiguc at linux.vnet.ibm.com Thu Dec 6 17:05:13 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 07 Dec 2018 02:05:13 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> Message-ID: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Hello. (I'm sorry, I made a mistake, I forgot to change Subject) Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ IBM29626C charset is required for AIX default charset. Java cannot start because of java/lang/ExceptionInInitializerError on AIX ja_JP locale. To build team, I'd like to change following charsetmapping tool. * make/jdk/src/classes/build/tools/charsetmapping/Main.java * make/jdk/src/classes/build/tools/charsetmapping/SPI.java * make/jdk/src/classes/build/tools/charsetmapping/SRC.java build.tools.charsetmapping,Main supports "os" tag, but it seems it's not used. Currently, "os" supports "windows" or "unix". I extended "os" tag's feature. If "os aix" is there, this charset is only added into AIX platform. (I assume "type template" should be used) "aix" comes from "stdcs-aix" file name. ====== charset x-IBM29626C IBM29626C package sun.nio.cs.ext type template os aix <===== alias cp29626C # JDK historical alias ibm29626C alias ibm-29626C alias 29626C alias ibm-eucjp ====== If cs.os is null, this charset is stored into gensrc directory. Charset name is added into StandardCharsets.java or ExtendedCharsets.java If cs.os is "false", this charset is NOT stored into gensrc directory. Charset name is NOT added into StandardCharsets.java or ExtendedCharsets.java "os" tag supports multiple entries by using ",", like "aix,linux" Then we can store new charset into src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory $ locale charmap IBM-eucJP $ jshell | JShell -- 12-internal | : /help intro jshell> var cs = java.nio.charset.Charset.defaultCharset() cs ==> x-IBM29626C jshell> cs.getClass().getName() $2 ==> "sun.nio.cs.IBM29626C" jshell> System.out.println(String.join("\n", cs.aliases())) cp29626C ibm-29626C ibm-eucjp ibm29626C 29626C jshell> /exit | $ I tested Linux and Windows build. ====== $ grep 29626 build.log IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false $ find support/gensrc/ | grep 29626 $ find support/gensrc/ | grep Charsets support/gensrc/java.base/sun/nio/cs/StandardCharsets.java support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java $ find support/gensrc/ | grep Charsets | xargs grep 29626 $ ====== I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-11-28 19:10, Magnus Ihse Bursie wrote: > On 2018-11-28 10:36, Alan Bateman wrote: >> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>> I'm quite unsatisfied with the current handling of character sets in >>> the build in general. :-( I'd really like to modernize it. I have a, >>> slightly fuzzy, laundry list of things I want to fix from a build >>> perspective, but I'm not sure of what "external" requirements are >>> coming from AIX and the general core-libs agenda regarding character >>> sets in general. >>> >>> I think there is a good opportunity to solve many problems at the >>> same time here, as long as everyone agrees on what is the preferred >>> outcome. >> The support in the build to configure the charsets to include in >> java.base on each platform has been working well. Charsets that aren't >> in java.base go into the jdk.charsets service provider module and that >> has been working well too. From the result point of view, perhaps, but >> definitely not from the build perspective. ;-) But yes, I understand >> this is functionality that should be kept. >> One thing that we lack is some way to add charsets for specific >> platforms and this comes up with the IBM patches where they are >> looking to adding several additional IBM charsets. One starting point >> that we've touched on in several threads here is dropping the EBCDIC >> charsets from the main stream builds. Going there will need build >> support. > So build support for trivially adding specific charsets to specific > platforms? Both to java.base (for AIX) and jdk.charsets, I presume, > then? > > Can you expand on the issue of dropping ebcdic? What's the problem > that needs build support? > > /Magnus >> >> >> -Alan From vicente.romero at oracle.com Thu Dec 6 18:37:34 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 6 Dec 2018 13:37:34 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> <3dc20f9c-471d-e647-56e0-468c71a5a155@oracle.com> <96e3fcd7-5b65-c909-f426-87060db1666b@oracle.com> <9b94a0a5-97d3-190b-32a1-e788781bce22@oracle.com> Message-ID: <7c033d3c-ca28-fc63-f256-629d94b9b680@oracle.com> Hi Rogers, Thanks for your comments, I have uploaded another webrev [1], some comments below: [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.14/ On 12/6/18 11:07 AM, Roger Riggs wrote: > Hi Vicente, > > On 12/05/2018 09:13 PM, Vicente Romero wrote: >> Hi Roger, >> >> Thanks for your comments, see my comments below. I have published >> another iteration at [1] >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.12/ >> >> >>> >>> - bootStrapArgs() - the return is always non-null, with zero length >>> array for non args? >> >> it has to be, IMO, as the private constructor that is the only one >> that assigns a value to field bootstrapArgs makes sure that the >> assigned value is non-null > My point is that the javadoc is a specification; so the reader should > not need to > look at an implementation to completely understand the required behavior. got it, I added a comment to the specification to make it more clear >> >>> >>> DynamicConstantDesc.java: >>> ?- First sentences should end with period. "." >>> >>> ?- ofCanonical:? 2nd sentence, "Classes ... produces ... a >>> ConstantDesc"; grammar? >>> >>> ?- of Canaonical(): So a conforming implementation is not required >>> to return the >>> ??? well known values, only suggested. >>> >>> ClassDesc.java: >>> ?- The create methods should not be required to create new >>> instances.? Use "return"? instead of "create". >>> >>> ?- How are class descriptors created for 'nested' classes (as >>> opposed to inner classes). >>> ?? It is worth describing or referencing how that should be done. >> >> not sure I get what you mean. If you want to create a class >> descriptor for a nested class you should be able to invoke inner() >> with an string containing a number, what should be made more clear >> here in your opinion? > In other places in java specs, there is a distinction made between > 'inner' classes and 'nested' classes. > If the same API is used for both, it would be clearer to the reader if > it mentioned nested. the ::inner methods were renamed to ::nested > > Thanks, Roger Thanks Vicente >> >>> >>> MethodTypeDesc.java: >>> ?- First sentences should end with period. "." >>> >>> Regards, Roger >>> >>> >>> On 12/05/2018 01:12 PM, Mandy Chung wrote: >>>> >>>> >>>> On 12/3/18 11:12 AM, Vicente Romero wrote: >>>>> Hi all, >>>>> >>>>> Can I have the final nod to the JVM constants API, there have been >>>>> some changes since the last review iteration. Thanks to the >>>>> internal and external developers that have taken the time to >>>>> provide feedback so far. The links to the last versions are: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~vromero/8210031/webrev.10/ >>>>> javadoc: >>>>> http://cr.openjdk.java.net/~vromero/8210031/javadoc.18/overview-summary.html >>>>> specdiff: >>>>> http://cr.openjdk.java.net/~vromero/8210031/specdiff.08/overview-summary.html >>>>> >>>> >>>> I reviewed webrev.10 and overall looks good to me.? A couple of >>>> minor comments and some of them seems to be fixed already in amber >>>> repo.? No need to generate a new webrev. >>>> >>>> Nit: The javadoc of the new methods starts with "Returns", >>>> "Return", "Produce", "Create", "Resolve", "Compares" etc. It'd be >>>> good to do a pass and fix the verb form consistently. >>>> >>>> src/java.base/share/classes/java/lang/Class.java >>>> ?? nit: Line 163 seems to have extra white-spaces, not aligned with >>>> the other superinterfaces. >>>> >>>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java >>>> 74 private static final Set suppressSubtypesSet >>>> 75 = Set.of("java.lang.Object", >>>> 76 "org.omg.CORBA.Object"); >>>> >>>> This is not related to your change. CORBA is no longer in JDK. >>>> Maybe this special casing is no longer needed.? It may worth >>>> filing a JBS issue to examine this. >>>> >>>> ConstantDescs.java >>>> ? 64???? // Don't change the order of these declarations! >>>> >>>> Is there any code depending on this order? >>>> >>>> DirectMethodHandleDesc.java >>>> ? 46? * {@link MethodHandle}.? A {@linkplain >>>> DirectMethodHandleDescImpl} corresponds to >>>> >>>> typo: DirectMethodHandleDescImpl >>>> >>>> ? 57???? /** >>>> ? 58????? * Kinds of method handles that can be described with >>>> {@linkplain DirectMethodHandleDesc}. >>>> ? 59????? */ >>>> ? 60???? enum Kind { >>>> >>>> This needs @since 12 >>>> >>>> DynamicCallSiteDesc.java >>>> ? 59????? * @param bootstrapMethod a {@link >>>> DirectMethodHandleDescImpl} describing the >>>> ? 60????? *??????????????????????? bootstrap method for the {@code >>>> invokedynamic} >>>> >>>> typo: DirectMethodHandleDescImpl and in a few other @param >>>> >>>> Mandy >>>> >>> >> > From Roger.Riggs at oracle.com Thu Dec 6 20:04:19 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 15:04:19 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() Message-ID: Please review changing string.equals("") to string.isEmpty(). isEmpty is preferred, performs better and is easier to optimize. The change is a literal substitution in all files and only in these modules: java.base java.logging java.management java.management.rmi java.naming java.net.http java.prefs java.rmi java.scripting java.sql java.sql.rowset java.xml jdk.jartool jdk.javadoc jdk.jcmd jdk.jconsole jdk.management.agent jdk.naming.dns jdk.rmic Webrev: http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ Issue: ? https://bugs.openjdk.java.net/browse/JDK-8214971 Thanks, Roger From james.laskey at oracle.com Thu Dec 6 20:27:28 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 6 Dec 2018 16:27:28 -0400 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: I assume you automated this change, might be worthwhile to automate a verification (compare the -+ pairs.) Eyeballing the patch it seems complete, one comment changed as well. Question: Is it probably that vm optimizes .equals(??) to .isEmpty() and there is no net win, ie., more of an esthetic clean up than for performance? Cheers, ? Jim > On Dec 6, 2018, at 4:04 PM, Roger Riggs wrote: > > Please review changing string.equals("") to string.isEmpty(). > isEmpty is preferred, performs better and is easier to optimize. > > The change is a literal substitution in all files and only in these modules: > > java.base > java.logging > java.management > java.management.rmi > java.naming > java.net.http > java.prefs > java.rmi > java.scripting > java.sql > java.sql.rowset > java.xml > jdk.jartool > jdk.javadoc > jdk.jcmd > jdk.jconsole > jdk.management.agent > jdk.naming.dns > jdk.rmic > > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8214971 > > Thanks, Roger From pavel.rappo at oracle.com Thu Dec 6 20:40:03 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 6 Dec 2018 20:40:03 +0000 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <01C50521-716C-43AD-A4DE-84C5C5EB5C82@oracle.com> > On 6 Dec 2018, at 20:27, Jim Laskey wrote: > > I assume you automated this change, might be worthwhile to automate a verification (compare the -+ pairs.) Eyeballing the patch it seems complete, one comment changed as well. > > Question: Is it probably that vm optimizes .equals(??) to .isEmpty() and there is no net win, ie., more of an esthetic clean up than for performance? > String.isEmpty might read better (subject to preference). Builds and tests on all systems should be performed. With an automatic (batch) change like this, there's always a possibility of trying to call isEmpty on a non-String reference. -Pavel From lance.andersen at oracle.com Thu Dec 6 20:38:54 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 6 Dec 2018 15:38:54 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <4469E2C7-5C09-4787-AF2E-19856FFF8A63@oracle.com> HI Roger, Changes seem good > On Dec 6, 2018, at 3:04 PM, Roger Riggs wrote: > > Please review changing string.equals("") to string.isEmpty(). > isEmpty is preferred, performs better and is easier to optimize. > > The change is a literal substitution in all files and only in these modules: > > java.base > java.logging > java.management > java.management.rmi > java.naming > java.net.http > java.prefs > java.rmi > java.scripting > java.sql > java.sql.rowset > java.xml > jdk.jartool > jdk.javadoc > jdk.jcmd > jdk.jconsole > jdk.management.agent > jdk.naming.dns > jdk.rmic > > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8214971 > > Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.fuchs at oracle.com Thu Dec 6 20:53:00 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 6 Dec 2018 20:53:00 +0000 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <524882f8-1dd4-c49e-b35a-688f7cb0d027@oracle.com> Hi Roger, The changes look good. best regards, -- daniel On 06/12/18 20:04, Roger Riggs wrote: > Please review changing string.equals("") to string.isEmpty(). > isEmpty is preferred, performs better and is easier to optimize. > > The change is a literal substitution in all files and only in these > modules: > > ?? java.base > ?? java.logging > ?? java.management > ?? java.management.rmi > ?? java.naming > ?? java.net.http > ?? java.prefs > ?? java.rmi > ?? java.scripting > ?? java.sql > ?? java.sql.rowset > ?? java.xml > ?? jdk.jartool > ?? jdk.javadoc > ?? jdk.jcmd > ?? jdk.jconsole > ?? jdk.management.agent > ?? jdk.naming.dns > ?? jdk.rmic > > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ > > Issue: > ? https://bugs.openjdk.java.net/browse/JDK-8214971 > > Thanks, Roger From pavel.rappo at oracle.com Thu Dec 6 21:08:45 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 6 Dec 2018 21:08:45 +0000 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: Roger, changes look good. On a side note, it's impressive how many cases we have when we check for string not being null and empty. We should have had something for that *internally* in the JDK. And it's a pity that `String.trim().isEmpty()` not equivalent to `String.isBlank`. Seems to be a frequent case too. > On 6 Dec 2018, at 20:04, Roger Riggs wrote: > > Please review changing string.equals("") to string.isEmpty(). > isEmpty is preferred, performs better and is easier to optimize. > > The change is a literal substitution in all files and only in these modules: > > java.base > java.logging > java.management > java.management.rmi > java.naming > java.net.http > java.prefs > java.rmi > java.scripting > java.sql > java.sql.rowset > java.xml > jdk.jartool > jdk.javadoc > jdk.jcmd > jdk.jconsole > jdk.management.agent > jdk.naming.dns > jdk.rmic > > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8214971 > > Thanks, Roger From claes.redestad at oracle.com Thu Dec 6 21:48:53 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 6 Dec 2018 22:48:53 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <2892dfd0-d92f-e1e6-0f21-87842a033624@oracle.com> Should changes to various com.sun.org.apache.xalan classes in java.xml be deferred to upstream? Otherwise looks good to me! /Claes On 2018-12-06 21:04, Roger Riggs wroe te: > Please review changing string.equals("") to string.isEmpty(). > isEmpty is preferred, performs better and is easier to optimize. > > The change is a literal substitution in all files and only in these > modules: > > ?? java.base > ?? java.logging > ?? java.management > ?? java.management.rmi > ?? java.naming > ?? java.net.http > ?? java.prefs > ?? java.rmi > ?? java.scripting > ?? java.sql > ?? java.sql.rowset > ?? java.xml > ?? jdk.jartool > ?? jdk.javadoc > ?? jdk.jcmd > ?? jdk.jconsole > ?? jdk.management.agent > ?? jdk.naming.dns > ?? jdk.rmic > > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ > > Issue: > ? https://bugs.openjdk.java.net/browse/JDK-8214971 > > Thanks, Roger From roger.riggs at oracle.com Thu Dec 6 21:51:32 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 16:51:32 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <8b4a3225-12fd-ab49-35b6-fc1a2f2836e8@oracle.com> Hi Jim, Yes, it is likely that the compiler gets to the same optimization. But we save a little bit too by not making the compiler work so hard. And it helps during startup before the compiler kicks in. IntelliJ did the hard work and a full CI build/test is in progress. And isEmpty reads better. Thanks, Roger On 12/6/18 3:27 PM, Jim Laskey wrote: > I assume you automated this change, might be worthwhile to automate a verification (compare the -+ pairs.) Eyeballing the patch it seems complete, one comment changed as well. > > Question: Is it probably that vm optimizes .equals(??) to .isEmpty() and there is no net win, ie., more of an esthetic clean up than for performance? > > Cheers, > > ? Jim > > > >> On Dec 6, 2018, at 4:04 PM, Roger Riggs wrote: >> >> Please review changing string.equals("") to string.isEmpty(). >> isEmpty is preferred, performs better and is easier to optimize. >> >> The change is a literal substitution in all files and only in these modules: >> >> java.base >> java.logging >> java.management >> java.management.rmi >> java.naming >> java.net.http >> java.prefs >> java.rmi >> java.scripting >> java.sql >> java.sql.rowset >> java.xml >> jdk.jartool >> jdk.javadoc >> jdk.jcmd >> jdk.jconsole >> jdk.management.agent >> jdk.naming.dns >> jdk.rmic >> >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8214971 >> >> Thanks, Roger From joe.darcy at oracle.com Thu Dec 6 22:33:07 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 06 Dec 2018 14:33:07 -0800 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <5C09A3A3.30505@oracle.com> On 12/6/2018 1:08 PM, Pavel Rappo wrote: > Roger, changes look good. On a side note, it's impressive how many cases we have > when we check for string not being null and empty. We should have had something > for that *internally* in the JDK. Or perhaps that should be a utility method on String or java.util.Objects? -Joe From claes.redestad at oracle.com Thu Dec 6 22:42:00 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 6 Dec 2018 23:42:00 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> I filed this bug after seeing it in startup profiles, where isEmpty() avoids an instanceof and four(!) method calls, so getting rid of a few of these has a measurable impact on startup. It seemed prudent to just replace it all while we're at it. C2 should be able to optimize equals("") to the equivalent of isEmpty() for hot cases, of course, but those JIT threads are probably better spent optimizing other things. :-) /Claes On 2018-12-06 21:27, Jim Laskey wrote > I assume you automated this change, might be worthwhile to automate a verification (compare the -+ pairs.) Eyeballing the patch it seems complete, one comment changed as well. > > Question: Is it probably that vm optimizes .equals(??) to .isEmpty() and there is no net win, ie., more of an esthetic clean up than for performance? > > Cheers, > > ? Jim > > > >> On Dec 6, 2018, at 4:04 PM, Roger Riggs wrote: >> >> Please review changing string.equals("") to string.isEmpty(). >> isEmpty is preferred, performs better and is easier to optimize. >> >> The change is a literal substitution in all files and only in these modules: >> >> java.base >> java.logging >> java.management >> java.management.rmi >> java.naming >> java.net.http >> java.prefs >> java.rmi >> java.scripting >> java.sql >> java.sql.rowset >> java.xml >> jdk.jartool >> jdk.javadoc >> jdk.jcmd >> jdk.jconsole >> jdk.management.agent >> jdk.naming.dns >> jdk.rmic >> >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8214971 >> >> Thanks, Roger From roger.riggs at oracle.com Thu Dec 6 22:37:51 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 17:37:51 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <2892dfd0-d92f-e1e6-0f21-87842a033624@oracle.com> References: <2892dfd0-d92f-e1e6-0f21-87842a033624@oracle.com> Message-ID: <354116f5-2a4c-1d45-8b16-57bf9f5c4253@oracle.com> Hi Claes, Thanks for the reminder about xalan sources. Updated to revert changes to xalan. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-2/ Thanks, Roger On 12/6/18 4:48 PM, Claes Redestad wrote: > Should changes to various com.sun.org.apache.xalan classes in java.xml > be deferred to upstream? > > Otherwise looks good to me! > > /Claes > > On 2018-12-06 21:04, Roger Riggs wroe te: >> Please review changing string.equals("") to string.isEmpty(). >> isEmpty is preferred, performs better and is easier to optimize. >> >> The change is a literal substitution in all files and only in these >> modules: >> >> ?? java.base >> ?? java.logging >> ?? java.management >> ?? java.management.rmi >> ?? java.naming >> ?? java.net.http >> ?? java.prefs >> ?? java.rmi >> ?? java.scripting >> ?? java.sql >> ?? java.sql.rowset >> ?? java.xml >> ?? jdk.jartool >> ?? jdk.javadoc >> ?? jdk.jcmd >> ?? jdk.jconsole >> ?? jdk.management.agent >> ?? jdk.naming.dns >> ?? jdk.rmic >> >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ >> >> Issue: >> ? https://bugs.openjdk.java.net/browse/JDK-8214971 >> >> Thanks, Roger > From roger.riggs at oracle.com Thu Dec 6 23:03:20 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 18:03:20 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <354116f5-2a4c-1d45-8b16-57bf9f5c4253@oracle.com> References: <2892dfd0-d92f-e1e6-0f21-87842a033624@oracle.com> <354116f5-2a4c-1d45-8b16-57bf9f5c4253@oracle.com> Message-ID: I missed reverting other Apache source files that should be unchanged. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-3/ Thanks, Roger On 12/6/18 5:37 PM, Roger Riggs wrote: > Hi Claes, > > Thanks for the reminder about xalan sources. > > Updated to revert changes to xalan. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-2/ > > Thanks, Roger > > On 12/6/18 4:48 PM, Claes Redestad wrote: >> Should changes to various com.sun.org.apache.xalan classes in >> java.xml be deferred to upstream? >> >> Otherwise looks good to me! >> >> /Claes >> >> On 2018-12-06 21:04, Roger Riggs wroe te: >>> Please review changing string.equals("") to string.isEmpty(). >>> isEmpty is preferred, performs better and is easier to optimize. >>> >>> The change is a literal substitution in all files and only in these >>> modules: >>> >>> ?? java.base >>> ?? java.logging >>> ?? java.management >>> ?? java.management.rmi >>> ?? java.naming >>> ?? java.net.http >>> ?? java.prefs >>> ?? java.rmi >>> ?? java.scripting >>> ?? java.sql >>> ?? java.sql.rowset >>> ?? java.xml >>> ?? jdk.jartool >>> ?? jdk.javadoc >>> ?? jdk.jcmd >>> ?? jdk.jconsole >>> ?? jdk.management.agent >>> ?? jdk.naming.dns >>> ?? jdk.rmic >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ >>> >>> Issue: >>> ? https://bugs.openjdk.java.net/browse/JDK-8214971 >>> >>> Thanks, Roger >> > From claes.redestad at oracle.com Thu Dec 6 23:13:03 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 7 Dec 2018 00:13:03 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: <2892dfd0-d92f-e1e6-0f21-87842a033624@oracle.com> <354116f5-2a4c-1d45-8b16-57bf9f5c4253@oracle.com> Message-ID: On 2018-12-07 00:03, Roger Riggs wrote: > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-3/ Looks good! /Claes From lance.andersen at oracle.com Thu Dec 6 23:19:12 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 6 Dec 2018 18:19:12 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: <2892dfd0-d92f-e1e6-0f21-87842a033624@oracle.com> <354116f5-2a4c-1d45-8b16-57bf9f5c4253@oracle.com> Message-ID: +1 > On Dec 6, 2018, at 6:03 PM, Roger Riggs wrote: > > I missed reverting other Apache source files that should be unchanged. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-3/ > > Thanks, Roger > > > On 12/6/18 5:37 PM, Roger Riggs wrote: >> Hi Claes, >> >> Thanks for the reminder about xalan sources. >> >> Updated to revert changes to xalan. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-2/ >> >> Thanks, Roger >> >> On 12/6/18 4:48 PM, Claes Redestad wrote: >>> Should changes to various com.sun.org.apache.xalan classes in java.xml be deferred to upstream? >>> >>> Otherwise looks good to me! >>> >>> /Claes >>> >>> On 2018-12-06 21:04, Roger Riggs wroe te: >>>> Please review changing string.equals("") to string.isEmpty(). >>>> isEmpty is preferred, performs better and is easier to optimize. >>>> >>>> The change is a literal substitution in all files and only in these modules: >>>> >>>> java.base >>>> java.logging >>>> java.management >>>> java.management.rmi >>>> java.naming >>>> java.net.http >>>> java.prefs >>>> java.rmi >>>> java.scripting >>>> java.sql >>>> java.sql.rowset >>>> java.xml >>>> jdk.jartool >>>> jdk.javadoc >>>> jdk.jcmd >>>> jdk.jconsole >>>> jdk.management.agent >>>> jdk.naming.dns >>>> jdk.rmic >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8214971 >>>> >>>> Thanks, Roger >>> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From stuart.marks at oracle.com Fri Dec 7 02:06:58 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 6 Dec 2018 18:06:58 -0800 Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses Message-ID: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> Hi all, Please review this small update to the Object.hashCode spec to remove mention of memory addresses. This also moves the statement about the implementation of hashCode in the Object class into an @implSpec section. Bug: https://bugs.openjdk.java.net/browse/JDK-8199394 Patch appended below. (I will file a CSR before pushing this changeset.) Thanks, s'marks # HG changeset patch # User smarks # Date 1544148151 28800 # Thu Dec 06 18:02:31 2018 -0800 # Node ID abc83502ef65c408cddd0bb5dd3985ac70946427 # Parent 0d89f672c62eeec74547c20c822dfde8edbf9b62 8199394: Object.hashCode should not mention anything about memory addresses Reviewed-by: XXX diff -r 0d89f672c62e -r abc83502ef65 src/java.base/share/classes/java/lang/Object.java --- a/src/java.base/share/classes/java/lang/Object.java Thu Dec 06 14:34:11 2018 -0800 +++ b/src/java.base/share/classes/java/lang/Object.java Thu Dec 06 18:02:31 2018 -0800 @@ -94,12 +94,10 @@ * programmer should be aware that producing distinct integer results * for unequal objects may improve the performance of hash tables. * - *

    - * As much as is reasonably practical, the hashCode method defined - * by class {@code Object} does return distinct integers for - * distinct objects. (The hashCode may or may not be implemented - * as some function of an object's memory address at some point - * in time.) + * + * @implSpec + * As much as is reasonably practical, the {@code hashCode} method defined + * by class {@code Object} returns distinct integers for distinct objects. * * @return a hash code value for this object. * @see java.lang.Object#equals(java.lang.Object) From joe.darcy at oracle.com Fri Dec 7 02:31:00 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 06 Dec 2018 18:31:00 -0800 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 Message-ID: <5C09DB64.8020608@oracle.com> Hello, With the start of JDK 13 around the corner, please review the core libs portions of: JDK-8205626: Start of release updates for JDK 13 http://cr.openjdk.java.net/~darcy/jdk13-fork.2 Those changes include (but are not necessarily limited to) updates to: src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java src/java.base/share/classes/jdk/internal/module/ModuleInfo.java src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java Thanks, -Joe From ying.z.zhou at oracle.com Fri Dec 7 02:42:21 2018 From: ying.z.zhou at oracle.com (Ying Zhou) Date: Fri, 7 Dec 2018 10:42:21 +0800 Subject: [12]RFR of JDK-8213409:Refactor sun.text.IntHashtable:i18n shell tests to plain java tests Message-ID: Hello, test/jdk/sun/text/IntHashtable/Bug4170614Test.sh Please review this patch for refactoring above shell script test to java. Bug: https://bugs.openjdk.java.net/browse/JDK-8213409 Webrev: http://cr.openjdk.java.net/~yzhou/8213409/webrev.00/ Thanks, Daisy From stuart.marks at oracle.com Fri Dec 7 02:56:00 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 6 Dec 2018 18:56:00 -0800 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> Message-ID: On 12/6/18 2:42 PM, Claes Redestad wrote: > I filed this bug after seeing it in startup profiles, where isEmpty() avoids an > instanceof and four(!) method calls, so getting rid of a few of these has a > measurable impact on startup. It seemed prudent to just replace it all while > we're at it. Interesting. The compact strings stuff saves a lot of space, but it means that more setup work needs to be done before an actual equality comparison can be done. Thus, equals("") has gotten quite a bit more expensive relative to isEmpty() compared with the situation prior to compact strings. Still, it seems like a method call could be saved here: if (anObject instanceof String) { String aString = (String)anObject; if (coder() == aString.coder()) { return isLatin1() ? StringLatin1.equals(value, aString.value) : StringUTF16.equals(value, aString.value); } } by saving the result of coder() in a local variable and then comparing it directly to LATIN1. Is it worth it? (Note, this isn't relevant to the current review.) s'marks From david.holmes at oracle.com Fri Dec 7 03:12:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Dec 2018 13:12:48 +1000 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: <5C09DB64.8020608@oracle.com> References: <5C09DB64.8020608@oracle.com> Message-ID: <02382496-4efa-9a5c-0ef3-7a6fe6f3b989@oracle.com> Hi Joe, core-libs changes look good. Thanks, David On 7/12/2018 12:31 pm, Joseph D. Darcy wrote: > Hello, > > With the start of JDK 13 around the corner, please review the core libs > portions of: > > ??? JDK-8205626: Start of release updates for JDK 13 > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > Those changes include (but are not necessarily limited to) updates to: > > src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java > ??? src/java.base/share/classes/jdk/internal/module/ModuleInfo.java > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java > ??? src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java > ??? src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java > > Thanks, > > -Joe From roger.riggs at oracle.com Fri Dec 7 03:21:21 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 6 Dec 2018 22:21:21 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> Message-ID: <4a23d374-3148-4ee3-04f3-3b5ba212897b@oracle.com> Hi, I'm pretty sure, it is assumed that the JVM compiler will optimize this code and produce an optimal result.? Lots of perf work went into the string size optimizations. Also possible is to compare the value.length values before dispatching to Latin1 vs UTF16. For unequal length strings, it can return false quickly. Comparing the value.length's is the first operation in the respective Latin1/UTF16 static methods.? (And they are HS intrinsics.) This code has been tuned enough that any changes would need to start with more performance evaluation. $.02, Roger On 12/6/18 9:56 PM, Stuart Marks wrote: > On 12/6/18 2:42 PM, Claes Redestad wrote: >> I filed this bug after seeing it in startup profiles, where isEmpty() >> avoids an instanceof and four(!) method calls, so getting rid of a >> few of these has a measurable impact on startup. It seemed prudent to >> just replace it all while we're at it. > > Interesting. The compact strings stuff saves a lot of space, but it > means that more setup work needs to be done before an actual equality > comparison can be done. Thus, equals("") has gotten quite a bit more > expensive relative to isEmpty() compared with the situation prior to > compact strings. > > Still, it seems like a method call could be saved here: > > ??????? if (anObject instanceof String) { > ??????????? String aString = (String)anObject; > ??????????? if (coder() == aString.coder()) { > ??????????????? return isLatin1() ? StringLatin1.equals(value, > aString.value) > ????????????????????????????????? : StringUTF16.equals(value, > aString.value); > ??????????? } > ??????? } > > by saving the result of coder() in a local variable and then comparing > it directly to LATIN1. Is it worth it? > > (Note, this isn't relevant to the current review.) > > s'marks From mandy.chung at oracle.com Fri Dec 7 03:38:45 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 6 Dec 2018 19:38:45 -0800 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: <5C09DB64.8020608@oracle.com> References: <5C09DB64.8020608@oracle.com> Message-ID: On 12/6/18 6:31 PM, Joseph D. Darcy wrote: > Hello, > > With the start of JDK 13 around the corner, please review the core > libs portions of: > > ??? JDK-8205626: Start of release updates for JDK 13 > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > Those changes include (but are not necessarily limited to) updates to: > > src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java > src/java.base/share/classes/jdk/internal/module/ModuleInfo.java > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java > > ??? src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java > src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java These changes looks good. Mandy From james.laskey at oracle.com Fri Dec 7 03:53:27 2018 From: james.laskey at oracle.com (James Laskey) Date: Thu, 6 Dec 2018 23:53:27 -0400 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> Message-ID: <8D068FE6-7852-42D7-B4CB-941DDC37F416@oracle.com> Or simply; if (anObject instanceof String) { String aString = (String)anObject; if (coder() == aString.coder()) return Arrays.equals(value, aString.value); } } Sent from my iPhone > On Dec 6, 2018, at 10:56 PM, Stuart Marks wrote: > >> On 12/6/18 2:42 PM, Claes Redestad wrote: >> I filed this bug after seeing it in startup profiles, where isEmpty() avoids an instanceof and four(!) method calls, so getting rid of a few of these has a measurable impact on startup. It seemed prudent to just replace it all while we're at it. > > Interesting. The compact strings stuff saves a lot of space, but it means that more setup work needs to be done before an actual equality comparison can be done. Thus, equals("") has gotten quite a bit more expensive relative to isEmpty() compared with the situation prior to compact strings. > > Still, it seems like a method call could be saved here: > > if (anObject instanceof String) { > String aString = (String)anObject; > if (coder() == aString.coder()) { > return isLatin1() ? StringLatin1.equals(value, aString.value) > : StringUTF16.equals(value, aString.value); > } > } > > by saving the result of coder() in a local variable and then comparing it directly to LATIN1. Is it worth it? > > (Note, this isn't relevant to the current review.) > > s'marks From volker.simonis at gmail.com Fri Dec 7 08:05:01 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Dec 2018 09:05:01 +0100 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: Hi Steve, thanks a lot for this fix. I'm forwarding this to core-libs-dev as well, because that's where the review has to take place. The "ppc-aix-port-dev" list is mostly a marker for the port maintainers to get their attention on relevant changes (so cross-posting is fine in this case :) On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger wrote: > > Hi all, > > I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the > jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: > > > diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 > @@ -446,7 +446,7 @@ > ProcessBuilder.NullOutputStream.INSTANCE : > new ProcessPipeOutputStream(fds[0]); > > - stdout = (fds[1] == -1) ? > + stdout = (fds[1] == -1 || forceNullOutputStream) ? > ProcessBuilder.NullInputStream.INSTANCE : > new DeferredCloseProcessPipeInputStream(fds[1]); > Your change looks good and I can sponsor it. Just as a hint for other reviewers I'd like to mention that this change, albeit in a shared Java file, is still AIX-only because it is in the "AIX" case of a switch statement. @Steve: can you please verify, that your change introduces no regression by running the complete jtreg test suite. Thank you and best regards, Volker > I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. > > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Fri Dec 7 08:16:53 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Dec 2018 08:16:53 +0000 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: <5C09DB64.8020608@oracle.com> References: <5C09DB64.8020608@oracle.com> Message-ID: <3186d105-d977-4b11-4675-38f6f5357739@oracle.com> On 07/12/2018 02:31, Joseph D. Darcy wrote: > Hello, > > With the start of JDK 13 around the corner, please review the core > libs portions of: > > ??? JDK-8205626: Start of release updates for JDK 13 > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > Those changes include (but are not necessarily limited to) updates to: > > src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java > src/java.base/share/classes/jdk/internal/module/ModuleInfo.java > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java > > ??? src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java > src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java Looks okay (and the same as what we reviewed on build-dev yesterday?). -Alan From hannes.wallnoefer at oracle.com Fri Dec 7 09:24:45 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 7 Dec 2018 10:24:45 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: Message-ID: <08B22889-C08F-430C-8A5E-2E641836B753@oracle.com> Hi Roger, There are quite a few occurrences of the reverse calling pattern "".equals(str) in core libs. This is a bit more tricky because it allows str to be null, but when used following a null/not-null check it could be replaced with isEmpty() as well. I wonder if these should be included in the patch? Hannes > Am 06.12.2018 um 21:04 schrieb Roger Riggs : > > Please review changing string.equals("") to string.isEmpty(). > isEmpty is preferred, performs better and is easier to optimize. > > The change is a literal substitution in all files and only in these modules: > > java.base > java.logging > java.management > java.management.rmi > java.naming > java.net.http > java.prefs > java.rmi > java.scripting > java.sql > java.sql.rowset > java.xml > jdk.jartool > jdk.javadoc > jdk.jcmd > jdk.jconsole > jdk.management.agent > jdk.naming.dns > jdk.rmic > > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8214971 > > Thanks, Roger From shade at redhat.com Fri Dec 7 10:30:09 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 7 Dec 2018 11:30:09 +0100 Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> Message-ID: On 12/7/18 3:06 AM, Stuart Marks wrote: > # HG changeset patch > # User smarks > # Date 1544148151 28800 > #????? Thu Dec 06 18:02:31 2018 -0800 > # Node ID abc83502ef65c408cddd0bb5dd3985ac70946427 > # Parent? 0d89f672c62eeec74547c20c822dfde8edbf9b62 > 8199394: Object.hashCode should not mention anything about memory addresses > Reviewed-by: XXX > > diff -r 0d89f672c62e -r abc83502ef65 src/java.base/share/classes/java/lang/Object.java > --- a/src/java.base/share/classes/java/lang/Object.java??? Thu Dec 06 14:34:11 2018 -0800 > +++ b/src/java.base/share/classes/java/lang/Object.java??? Thu Dec 06 18:02:31 2018 -0800 > @@ -94,12 +94,10 @@ > ????? *???? programmer should be aware that producing distinct integer results > ????? *???? for unequal objects may improve the performance of hash tables. > ????? * > -???? *

    > -???? * As much as is reasonably practical, the hashCode method defined > -???? * by class {@code Object} does return distinct integers for > -???? * distinct objects. (The hashCode may or may not be implemented > -???? * as some function of an object's memory address at some point > -???? * in time.) > +???? * > +???? * @implSpec > +???? * As much as is reasonably practical, the {@code hashCode} method defined > +???? * by class {@code Object} returns distinct integers for distinct objects. > ????? * > ????? * @return? a hash code value for this object. > ????? * @see???? java.lang.Object#equals(java.lang.Object) Looks good to me. -Aleksey From forax at univ-mlv.fr Fri Dec 7 10:31:34 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 7 Dec 2018 11:31:34 +0100 (CET) Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> Message-ID: <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> Hi Stuart, what about adding "tries to" to the @implSpec section As much as is reasonably practical, the {@code hashCode} method defined by class {@code Object} tries to return distinct integers for distinct objects. otherwise looks good. R?mi ----- Mail original ----- > De: "Stuart Marks" > ?: "core-libs-dev" > Envoy?: Vendredi 7 D?cembre 2018 03:06:58 > Objet: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses > Hi all, > > Please review this small update to the Object.hashCode spec to remove mention of > memory addresses. This also moves the statement about the implementation of > hashCode in the Object class into an @implSpec section. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8199394 > > Patch appended below. > > (I will file a CSR before pushing this changeset.) > > Thanks, > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1544148151 28800 > # Thu Dec 06 18:02:31 2018 -0800 > # Node ID abc83502ef65c408cddd0bb5dd3985ac70946427 > # Parent 0d89f672c62eeec74547c20c822dfde8edbf9b62 > 8199394: Object.hashCode should not mention anything about memory addresses > Reviewed-by: XXX > > diff -r 0d89f672c62e -r abc83502ef65 > src/java.base/share/classes/java/lang/Object.java > --- a/src/java.base/share/classes/java/lang/Object.java Thu Dec 06 14:34:11 2018 > -0800 > +++ b/src/java.base/share/classes/java/lang/Object.java Thu Dec 06 18:02:31 2018 > -0800 > @@ -94,12 +94,10 @@ > * programmer should be aware that producing distinct integer results > * for unequal objects may improve the performance of hash tables. > * > - *

    > - * As much as is reasonably practical, the hashCode method defined > - * by class {@code Object} does return distinct integers for > - * distinct objects. (The hashCode may or may not be implemented > - * as some function of an object's memory address at some point > - * in time.) > + * > + * @implSpec > + * As much as is reasonably practical, the {@code hashCode} method defined > + * by class {@code Object} returns distinct integers for distinct objects. > * > * @return a hash code value for this object. > * @see java.lang.Object#equals(java.lang.Object) From nishit.jain at oracle.com Fri Dec 7 10:37:21 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 7 Dec 2018 16:07:21 +0530 Subject: [12] RFR JDK-8214935: Upgrade IANA LSR data Message-ID: <44f0c1a3-faa2-32a7-f966-bf1180dd2994@oracle.com> Hi, Please review the fix for JDK-8214935. The changes made through JDK-8213294 upgraded the LSR data to 2018-10-31, but there is a recent change seen in the LSR data with version 2018-11-30. The JDK-8214935 change is to stick to the latest available version for JDK12. RFE: https://bugs.openjdk.java.net/browse/JDK-8214935 Webrev: http://cr.openjdk.java.net/~nishjain/8214935/webrev.00/ Regards, Nishit Jain From daniel.fuchs at oracle.com Fri Dec 7 11:54:41 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Dec 2018 11:54:41 +0000 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <08B22889-C08F-430C-8A5E-2E641836B753@oracle.com> References: <08B22889-C08F-430C-8A5E-2E641836B753@oracle.com> Message-ID: <61099d02-c247-c717-070a-7ff835d0c47e@oracle.com> Hi Hannes, On 07/12/2018 09:24, Hannes Walln?fer wrote: > Hi Roger, > > There are quite a few occurrences of the reverse calling pattern "".equals(str) in core libs. > > This is a bit more tricky because it allows str to be null, but when used following a null/not-null check it could be replaced with isEmpty() as well. > > I wonder if these should be included in the patch? I would advocate either not doing it - or doing it in another patch - as I believe such a change would require a more careful review - especially as to whether 'str' can be null at the call site. Though checking for null for something that's guaranteed not to be null is harmless, it can confuse the reader (I know it usually confuses me as it makes me wonder what the programmer's intent really was and whether there's a bug lurking somewhere) - so I'd rather avoid a global mechanical change for those cases. best regards, -- daniel > > Hannes > From claes.redestad at oracle.com Fri Dec 7 12:51:10 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 7 Dec 2018 13:51:10 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> Message-ID: <2fe7e88c-ea50-f401-5149-11bc4d0b4160@oracle.com> Hi, On 2018-12-07 03:56, Stuart Marks wrote: > On 12/6/18 2:42 PM, Claes Redestad wrote: >> I filed this bug after seeing it in startup profiles, where isEmpty() >> avoids an instanceof and four(!) method calls, so getting rid of a >> few of these has a measurable impact on startup. It seemed prudent to >> just replace it all while we're at it. > > Interesting. The compact strings stuff saves a lot of space, but it > means that more setup work needs to be done before an actual equality > comparison can be done. Thus, equals("") has gotten quite a bit more > expensive relative to isEmpty() compared with the situation prior to > compact strings. > > Still, it seems like a method call could be saved here: > > ??????? if (anObject instanceof String) { > ??????????? String aString = (String)anObject; > ??????????? if (coder() == aString.coder()) { > ??????????????? return isLatin1() ? StringLatin1.equals(value, > aString.value) > ????????????????????????????????? : StringUTF16.equals(value, > aString.value); > ??????????? } > ??????? } > > by saving the result of coder() in a local variable and then comparing > it directly to LATIN1. Is it worth it? the reason this might be a bad idea is that guarding the coder field reads in methods that first test whether COMPACT_STRINGS is enabled enables the JIT to better optimize away untaken code paths. This ensures optimal as can be performance for the different run modes. See javadoc for COMPACT_STRINGS in String.java[1] for some discussion on this. One possible improvement would to wrap coder() == aString.coder() in a method isSameCoder(String): private boolean isSameCoder(String other) { ? ? return COMPACT_STRINGS ? coder == other.coder : true; } .. one less method call, but still perfectly optimizable, so less taxing during startup with no peak performance drawback. > > (Note, this isn't relevant to the current review.) But interesting nonetheless :-) /Claes [1] /** * If String compaction is disabled, the bytes in {@code value} are * always encoded in UTF16. * * For methods with several possible implementation paths, when String * compaction is disabled, only one code path is taken. * * The instance field value is generally opaque to optimizing JIT * compilers. Therefore, in performance-sensitive place, an explicit * check of the static boolean {@code COMPACT_STRINGS} is done first * before checking the {@code coder} field since the static boolean * {@code COMPACT_STRINGS} would be constant folded away by an * optimizing JIT compiler. The idioms for these cases are as follows. * * For code such as: * * if (coder == LATIN1) { ... } * * can be written more optimally as * * if (coder() == LATIN1) { ... } * * or: * * if (COMPACT_STRINGS && coder == LATIN1) { ... } * * An optimizing JIT compiler can fold the above conditional as: * * COMPACT_STRINGS == true => if (coder == LATIN1) { ... } * COMPACT_STRINGS == false => if (false) { ... } * * @implNote * The actual value for this field is injected by JVM. The static * initialization block is used to set the value here to communicate * that this static final field is not statically foldable, and to * avoid any possible circular dependency during vm initialization. */ From orionllmain at gmail.com Fri Dec 7 13:18:32 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Fri, 7 Dec 2018 20:18:32 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> Message-ID: What about forEach()? @Override public void forEach(final Consumer action) { Objects.requireNonNull(action); for (int i = 0; i < this.n; i++) { action.accept(this.element); } } I think this version has better chances to be faster than the default implementation (did not measure though). ??, 4 ???. 2018 ?. ? 14:40, Tagir Valeev : > Hello! > > > In CopiesList.equals() please use eq() instead of Objects.equal() (see a > comment at the line 5345). > > Ok > > > I think you should use iterator() instead of listIterator(). See the > explanation here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html > > Ok. I wonder why this message received no attention. > > Here's updated webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r3/ > > With best regards, > Tagir Valeev > On Tue, Dec 4, 2018 at 1:10 PM Zheka Kozlov wrote: > > > > I think you should use iterator() instead of listIterator(). See the > explanation here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html > > > > ??, 4 ???. 2018 ?. ? 12:23, Tagir Valeev : > >> > >> Hello! > >> > >> Thank you for your comments! > >> > >> Yes, deserialization will be broken if we assume that size is never 0. > >> Also we'll introduce referential identity Collections.nCopies(0, x) == > >> Collections.nCopies(0, y) which might introduce slight semantics > >> change in existing programs. Once I suggested to wire Arrays.asList() > >> (with no args) to Collections.emptyList(), but it was rejected for the > >> same reason: no need to introduce a risk of possible semantics change. > >> > >> I updated webrev with equals implementation and test: > >> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ > >> Comparing two CopiesList is much faster now indeed. Also we can spare > >> an iterator in the common case and hoist the null-check out of the > >> loop. Not sure whether we can rely that JIT will always do this for > >> us, but if you think that it's unnecessary, I can merge the loops > >> back. Note that now copiesList.equals(arrayList) could be faster than > >> arrayList.equals(copiesList). I don't think it's an issue. On the > >> other hand we could keep simpler and delegate to super-implementation > >> if the other object is not a CopiesList (like it's implemented in > >> java.util.RegularEnumSet::equals for example). What do you think? > >> > >> With best regards, > >> Tagir Valeev. > >> On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks > wrote: > >> > > >> > > >> > >> I believe it makes sense to override CopiesList.equals() > >> > > Also: contains(), iterator(), listIterator() > >> > > >> > equals(): sure > >> > > >> > contains() is already overridden. Not sure there's much benefit to > overriding > >> > the iterators. > >> > > >> > s'marks > From adinn at redhat.com Fri Dec 7 13:55:44 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Dec 2018 13:55:44 +0000 Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> Message-ID: <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> On 07/12/2018 10:31, Remi Forax wrote: > Hi Stuart, > what about adding "tries to" to the @implSpec section > > As much as is reasonably practical, the {@code hashCode} method defined > by class {@code Object} tries to return distinct integers for distinct objects. An algorithm can try? I suspect not until we reach the singularity so beloved of sci-fi hacks (I'm not holding my breath). So, in the interests of precisely nailing the colour of this bike-shed and modulo any unforeseen developments in Artificial Intelligence, I'd suggest this psychologism-free alternative: As far as is reasonably practical, the {@code hashCode} method defined by class {@code Object} returns distinct integers for distinct objects. 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 From Roger.Riggs at oracle.com Fri Dec 7 14:36:39 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 09:36:39 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <08B22889-C08F-430C-8A5E-2E641836B753@oracle.com> References: <08B22889-C08F-430C-8A5E-2E641836B753@oracle.com> Message-ID: Hi Hannes, I'd take that up as a separate issue.? [1] A nice thing about the current patch is that the change is uniform and easier to review. It would also be good to look at a utility method that efficiently does the combined check. Thanks, Roger [1] 8215014 On 12/07/2018 04:24 AM, Hannes Walln?fer wrote: > Hi Roger, > > There are quite a few occurrences of the reverse calling pattern "".equals(str) in core libs. > > This is a bit more tricky because it allows str to be null, but when used following a null/not-null check it could be replaced with isEmpty() as well. > > I wonder if these should be included in the patch? > > Hannes > > >> Am 06.12.2018 um 21:04 schrieb Roger Riggs : >> >> Please review changing string.equals("") to string.isEmpty(). >> isEmpty is preferred, performs better and is easier to optimize. >> >> The change is a literal substitution in all files and only in these modules: >> >> java.base >> java.logging >> java.management >> java.management.rmi >> java.naming >> java.net.http >> java.prefs >> java.rmi >> java.scripting >> java.sql >> java.sql.rowset >> java.xml >> jdk.jartool >> jdk.javadoc >> jdk.jcmd >> jdk.jconsole >> jdk.management.agent >> jdk.naming.dns >> jdk.rmic >> >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-string-isempty-8214971-1/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8214971 >> >> Thanks, Roger From Roger.Riggs at oracle.com Fri Dec 7 14:40:07 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 09:40:07 -0500 Subject: [12] RFR JDK-8214935: Upgrade IANA LSR data In-Reply-To: <44f0c1a3-faa2-32a7-f966-bf1180dd2994@oracle.com> References: <44f0c1a3-faa2-32a7-f966-bf1180dd2994@oracle.com> Message-ID: Looks fine. On 12/07/2018 05:37 AM, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8214935. The changes made through > JDK-8213294 upgraded the LSR data to 2018-10-31, but there is a recent > change seen in the LSR data with version 2018-11-30. > The JDK-8214935 change is to stick to the latest available version for > JDK12. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8214935 > Webrev: http://cr.openjdk.java.net/~nishjain/8214935/webrev.00/ > > Regards, > Nishit Jain From goetz.lindenmaier at sap.com Fri Dec 7 14:51:13 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 7 Dec 2018 14:51:13 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: Hi, To me, the change looks good, too. I just wondered whether solaris needs to be fixed, too. But I don?t see the test failing on solaris. The bug needs to be removed from the ProblemList in the change, though. See also http://cr.openjdk.java.net/~goetz/wr18/sgroeger/8211844-aix_pipe_proc/01/ I would sponsor this issue. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Volker Simonis > Sent: Friday, December 7, 2018 9:05 AM > To: Steve Groeger ; Java Core Libs dev at openjdk.java.net> > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created > processes does not work. > > Hi Steve, > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > well, because that's where the review has to take place. The > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > get their attention on relevant changes (so cross-posting is fine in > this case :) > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger > wrote: > > > > Hi all, > > > > I have been investigating the issue > https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz > Lindenmaier which is related to the > > jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. > Having done some investigation I have a potential fix fore the issue: > > > > > > diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java > > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 > 14:28:19 2018 +0300 > > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 > 15:01:03 2018 +0000 > > @@ -446,7 +446,7 @@ > > ProcessBuilder.NullOutputStream.INSTANCE : > > new ProcessPipeOutputStream(fds[0]); > > > > - stdout = (fds[1] == -1) ? > > + stdout = (fds[1] == -1 || forceNullOutputStream) ? > > ProcessBuilder.NullInputStream.INSTANCE : > > new DeferredCloseProcessPipeInputStream(fds[1]); > > > > Your change looks good and I can sponsor it. Just as a hint for other > reviewers I'd like to mention that this change, albeit in a shared > Java file, is still AIX-only because it is in the "AIX" case of a > switch statement. > > @Steve: can you please verify, that your change introduces no > regression by running the complete jtreg test suite. > > Thank you and best regards, > Volker > > > I would appreciate any feedback please, and for someone to be a sponsor > for this and to contributute it to OpenJDK. > > > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From Roger.Riggs at oracle.com Fri Dec 7 14:52:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 09:52:00 -0500 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> Hi, I notice that the Solaris case also does not include "|| forceNullOutputStream". I'll have to investigate why the Pipeline test didn't fail on Solaris. Please add that to the patch and I'll run it through our tests. Thanks, Roger On 12/07/2018 03:05 AM, Volker Simonis wrote: > Hi Steve, > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > well, because that's where the review has to take place. The > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > get their attention on relevant changes (so cross-posting is fine in > this case :) > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger wrote: >> Hi all, >> >> I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the >> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: >> >> >> diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java >> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 >> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 >> @@ -446,7 +446,7 @@ >> ProcessBuilder.NullOutputStream.INSTANCE : >> new ProcessPipeOutputStream(fds[0]); >> >> - stdout = (fds[1] == -1) ? >> + stdout = (fds[1] == -1 || forceNullOutputStream) ? >> ProcessBuilder.NullInputStream.INSTANCE : >> new DeferredCloseProcessPipeInputStream(fds[1]); >> > Your change looks good and I can sponsor it. Just as a hint for other > reviewers I'd like to mention that this change, albeit in a shared > Java file, is still AIX-only because it is in the "AIX" case of a > switch statement. > > @Steve: can you please verify, that your change introduces no > regression by running the complete jtreg test suite. > > Thank you and best regards, > Volker > >> I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. >> >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From federico.peralta at gmail.com Fri Dec 7 14:59:29 2018 From: federico.peralta at gmail.com (Federico Peralta Schaffner) Date: Fri, 7 Dec 2018 11:59:29 -0300 Subject: Enum enhancement In-Reply-To: References: <81e7906c-4b48-d477-5ba7-b668166151f7@oracle.com> Message-ID: I really like Tagir's suggestion about (2): Optional findValue(String name) But this leads me to a question regarding Map... Have you ever considered adding the equivalent default method to the Map interface? It might be something like this: default Optional find(Object key) { return Optional.ofNullable(this.get(key)); } Or maybe not allowing null as a key: default Optional find(Object key) { return Optional.ofNullable(this.get(Objects.requireNonNull(key))); } Of course, this might become ambiguous if the map supports null values, but we have containsKey for that... Regards, fps.- El vie., 7 dic. 2018 a las 11:38, Tagir Valeev () escribi?: > As for (2) probably Optional findValue(String name) would be better, as > you may decide what to do if it's absent using all the optional API. > > With best regards, > Tagir Valeev. > > ??, 7 ???. 2018 ?., 21:28 Brian Goetz brian.goetz at oracle.com: > > > (1) is already tracked as > > > > https://bugs.openjdk.java.net/browse/JDK-8073381 > > > > It is not as "easy" as you think in that these enum methods are > > generated by the compiler, not as ordinary library code, but it's not > > prohibited. > > > > (2) is not unreasonable. As there's no language component to it, you > > could take this directly to corelibs-dev for further evaluation. > > > > On 12/7/2018 9:13 AM, Giguere, Thierry wrote: > > > Hello, > > > > > > Related to the follow link and JEP 301< > https://openjdk.java.net/jeps/301> > > : > > > > > > > > > http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-December/000876.html > > > > > > What is also missing and long-time due for enum right now and could be > > added quickly is more methods: > > > > > > 1) We need to be able to iterate efficiently on enum. Currently calling > > method T[] values() duplicate the internal array. Moreover you need to go > > through method Arrays.stream() to convert the newly created array to > > stream. Adding a stream() method and a forEach() method would help fix > this > > problem. Optionally a iterator() method could be provided > > > > > > Arrays.stream(MyEnum.values()).forEach(); > > > > > > could be replaced by something like : > > > > > > MyEnum.forEach(); > > > > > > And > > > > > > Arrays.stream(MyEnum.values()).map(... > > > > > > could be written : > > > > > > MyEnum.stream().map(... > > > > > > 2) T valueOfOrDefault : pretty much like getOrDefault of the map > > interface. This method don't throw exception and fallback on default > value. > > That would ease use of enum in stream / lambda programming > > > > > > @Nonnull > > > MyEnum myEnum = MyEnum.DEFAULT_VALUE; > > > > > > try { > > > myEnum = MyEnum.valueOf(...); > > > } catch (NullPointerException | IllegalArgumentException > e) > > { > > > // Just keep going with on the default value > > > } > > > > > > Since exception are thrown it doesn't fit very well in stream / lambda > > usage. Something like this : > > > > > > MyData.stream().map(MyEnum::valueOf).forEach() > > > > > > Must be converted to : > > > > > > MyData.stream().map(d -> { > > > try { > > > return > > MyEnum.valueOf(...); > > > } catch (Exception e) { > > > return > > MyEnum.DEFAULT_VALUE; > > > } > > > }).forEach(); > > > > > > It would be great to write at least something like : > > > > > > MyData.stream().map(d -> MyEnum.valueOfOrDefault(d, > > MyEnum.DEFAULT_VALUE)).forEach(); > > > > > > My feeling is these enhancement could be easily and quickly added > > > > > > Thierry Gigu?re > > > > > > CONFIDENTIALIT? : Ce document est destin? uniquement ? la personne ou ? > > l'entit? ? qui il est adress?. L'information apparaissant dans ce > document > > est de nature l?galement privil?gi?e et confidentielle. Si vous n'?tes > pas > > le destinataire vis? ou la personne charg?e de le remettre ? son > > destinataire, vous ?tes, par la pr?sente, avis? que toute lecture, usage, > > copie ou communication du contenu de ce document est strictement > interdit. > > De plus, vous ?tes pri? de communiquer avec l'exp?diteur sans d?lai ou > > d'?crire ? confidentialite at bnc.ca et de d?truire ce document > > imm?diatement. > > > CONFIDENTIALITY: This document is intended solely for the individual or > > entity to whom it is addressed. The information contained in this > document > > is legally privileged and confidential. If you are not the intended > > recipient or the person responsible for delivering it to the intended > > recipient, you are hereby advised that you are strictly prohibited from > > reading, using, copying or disseminating the contents of this document. > > Please inform the sender immediately or write to confidentiality at nbc.ca > > and delete this document immediately. > > > > > > > > From brian.goetz at oracle.com Fri Dec 7 15:37:43 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 7 Dec 2018 10:37:43 -0500 Subject: Enum enhancement In-Reply-To: References: <81e7906c-4b48-d477-5ba7-b668166151f7@oracle.com> Message-ID: <64937a41-4777-a642-ad17-49875184a37b@oracle.com> > I really like Tagir's suggestion about (2): Optional findValue(String > name) Yes, it has an attractive cost-benefit. > But this leads me to a question regarding Map... Have you ever considered > adding the equivalent default method to the Map interface? Why yes, yes we have ;) The tl;dr: version is: we're not touching this until Valhalla. First, note that Map::get uses `null` as a sentinel for "not found".? What does this do when we have a `Map`? Box?? Yuck.? `Map::get` is called way too often to tolerate this kind of boxing. Similarly, if we were to add this method now, we'd have the same problem; Optional is a heavyweight object box.? Again, Map::get is called way too often to tolerate this.? (When Optional is a value, different story.) So, how would we design fetching from a Map if we knew there were some types that were non-nullable?? Well, lots of options, each with pros and cons: ??? - Like what we have today, but which returns a nullable type: `V? get(K key)` ??? - A version that takes a user-provided sentinel to express "not found", such as `V get(K key, V sentinel)` ??? - A version that takes a lambda: `boolean get(K key, Consumer lambda)` ??? - An optional-bearing version, such as `Optional get(K key)` ??? - A pattern match: `if m matches Map.withMapping(k, var v)` ??? - more... The design space here is pretty big.? The requirements on the language (nullable types?? pattern matching?? value optionals?) range all over the map too.? For each of them, they are really convenient for some use cases but really inconvenient for others. Should we require Map implementations to implement all of them? As you can see, this is far from a "why not just..." sort of question. From naoto.sato at oracle.com Fri Dec 7 15:38:42 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 7 Dec 2018 07:38:42 -0800 Subject: [12] RFR JDK-8214935: Upgrade IANA LSR data In-Reply-To: References: <44f0c1a3-faa2-32a7-f966-bf1180dd2994@oracle.com> Message-ID: <2bbee236-1663-4c63-8e5b-257aedb0e6a0@oracle.com> +1 Naoto On 12/7/18 6:40 AM, Roger Riggs wrote: > Looks fine. > > On 12/07/2018 05:37 AM, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8214935. The changes made through >> JDK-8213294 upgraded the LSR data to 2018-10-31, but there is a recent >> change seen in the LSR data with version 2018-11-30. >> The JDK-8214935 change is to stick to the latest available version for >> JDK12. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8214935 >> Webrev: http://cr.openjdk.java.net/~nishjain/8214935/webrev.00/ >> >> Regards, >> Nishit Jain > From naoto.sato at oracle.com Fri Dec 7 17:19:19 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 7 Dec 2018 09:19:19 -0800 Subject: [12]RFR of JDK-8213409:Refactor sun.text.IntHashtable:i18n shell tests to plain java tests In-Reply-To: References: Message-ID: <7242d4b4-ce40-7dda-542f-55bcc5319503@oracle.com> Hi Daisy, Looks good to me. Naoto On 12/6/18 6:42 PM, Ying Zhou wrote: > Hello, > > test/jdk/sun/text/IntHashtable/Bug4170614Test.sh > > Please review this patch for refactoring above shell script test to java. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213409 > > Webrev: http://cr.openjdk.java.net/~yzhou/8213409/webrev.00/ > > Thanks, > > Daisy > From stuart.marks at oracle.com Fri Dec 7 17:32:46 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 7 Dec 2018 09:32:46 -0800 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: <5C09DB64.8020608@oracle.com> References: <5C09DB64.8020608@oracle.com> Message-ID: <6e919916-848d-fde9-f0b0-b8992cce3879@oracle.com> On 12/6/18 6:31 PM, Joseph D. Darcy wrote: > With the start of JDK 13 around the corner, please review the core libs > portions of: > > ??? JDK-8205626: Start of release updates for JDK 13 > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > Those changes include (but are not necessarily limited to) updates to: > > src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java > src/java.base/share/classes/jdk/internal/module/ModuleInfo.java > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java > ??? src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java > src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java Hi Joe, The jdeprscan change looks good. s'marks From stuart.marks at oracle.com Fri Dec 7 17:45:58 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 7 Dec 2018 09:45:58 -0800 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <2fe7e88c-ea50-f401-5149-11bc4d0b4160@oracle.com> References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> <2fe7e88c-ea50-f401-5149-11bc4d0b4160@oracle.com> Message-ID: On 12/7/18 4:51 AM, Claes Redestad wrote: > One possible improvement would to wrap coder() == aString.coder() in a > method isSameCoder(String): > > private boolean isSameCoder(String other) { > ? ? return COMPACT_STRINGS ? coder == other.coder : true; > } > > .. one less method call, but still perfectly optimizable, so less taxing during > startup with no peak performance drawback. > >> (Note, this isn't relevant to the current review.) > > But interesting nonetheless :-) Cool. Glad something useful might come out of this line of discussion. s'marks From stuart.marks at oracle.com Fri Dec 7 17:52:44 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 7 Dec 2018 09:52:44 -0800 Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> Message-ID: <2e18da61-173d-8c7d-02b9-b4307c59b306@oracle.com> On 12/7/18 5:55 AM, Andrew Dinn wrote: > On 07/12/2018 10:31, Remi Forax wrote: >> what about adding "tries to" to the @implSpec section >> >> As much as is reasonably practical, the {@code hashCode} method defined >> by class {@code Object} tries to return distinct integers for distinct objects. > > An algorithm can try? I suspect not until we reach the singularity so > beloved of sci-fi hacks (I'm not holding my breath). So, in the > interests of precisely nailing the colour of this bike-shed and modulo > any unforeseen developments in Artificial Intelligence, I'd suggest this > psychologism-free alternative: > > As far as is reasonably practical, the {@code hashCode} method defined > by class {@code Object} returns distinct integers for distinct objects. Hi Andrew, I agree, anthropomorphisms in documentation sound quite odd. Also, "as far as" is an improvement. I'll use your suggestion. Thanks, s'marks From joe.darcy at oracle.com Fri Dec 7 17:51:46 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 7 Dec 2018 09:51:46 -0800 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: <3186d105-d977-4b11-4675-38f6f5357739@oracle.com> References: <5C09DB64.8020608@oracle.com> <3186d105-d977-4b11-4675-38f6f5357739@oracle.com> Message-ID: Hi Alan, On 12/7/2018 12:16 AM, Alan Bateman wrote: > On 07/12/2018 02:31, Joseph D. Darcy wrote: >> Hello, >> >> With the start of JDK 13 around the corner, please review the core >> libs portions of: >> >> ??? JDK-8205626: Start of release updates for JDK 13 >> ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 >> >> [snip] > Looks okay (and the same as what we reviewed on build-dev yesterday?). > Yes, same changes as on build-dev (other than the update of several more TEST.ROOT files to require jtreg 4.2 b13 rather than b12.) I wanted to have a bit more of the testing complete before sending the core libs portion out for the review. Thanks, -Joe From Roger.Riggs at oracle.com Fri Dec 7 17:53:55 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 12:53:55 -0500 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> Message-ID: Hi, I'd be interested in how PipelineTest failed on AIX? It looks like PipelineTest is flawed in that verifyProcesses() does not check all of the 1..n Processes getInputStreams for being a null stream, only the nth Process. And the test is incorrectly applied to the last Process, which returns a null stream not because of the pipeline but because the output is redirected to a file. Thanks, Roger On 12/07/2018 09:52 AM, Roger Riggs wrote: > Hi, > > I notice that the Solaris case also does not include "|| > forceNullOutputStream". > I'll have to investigate why the Pipeline test didn't fail on Solaris. > > Please add that to the patch and I'll run it through our tests. > > Thanks, Roger > > On 12/07/2018 03:05 AM, Volker Simonis wrote: >> Hi Steve, >> >> thanks a lot for this fix. I'm forwarding this to core-libs-dev as >> well, because that's where the review has to take place. The >> "ppc-aix-port-dev" list is mostly a marker for the port maintainers to >> get their attention on relevant changes (so cross-posting is fine in >> this case :) >> >> On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger wrote: >>> Hi all, >>> >>> I have been investigating the issue >>> https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz >>> Lindenmaier which is related to the >>> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on >>> AIX. Having done some investigation I have a potential fix fore the >>> issue: >>> >>> >>> diff -r 9501a7b59111 >>> src/java.base/unix/classes/java/lang/ProcessImpl.java >>> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec >>> 03 14:28:19 2018 +0300 >>> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec >>> 06 15:01:03 2018 +0000 >>> @@ -446,7 +446,7 @@ >>> ProcessBuilder.NullOutputStream.INSTANCE : >>> ????????????????????????? new ProcessPipeOutputStream(fds[0]); >>> >>> -??????????????? stdout = (fds[1] == -1) ? >>> +??????????????? stdout = (fds[1] == -1 || forceNullOutputStream) ? >>> ProcessBuilder.NullInputStream.INSTANCE : >>> ?????????????????????????? new >>> DeferredCloseProcessPipeInputStream(fds[1]); >>> >> Your change looks good and I can sponsor it. Just as a hint for other >> reviewers I'd like to mention that this change, albeit in a shared >> Java file, is still AIX-only because it is in the "AIX" case of a >> switch statement. >> >> @Steve: can you please verify, that your change introduces no >> regression by running the complete jtreg test suite. >> >> Thank you and best regards, >> Volker >> >>> I would appreciate any feedback please, and for someone to be a >>> sponsor for this and to contributute it to OpenJDK. >>> >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911? Mobex: 279990? Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU > From ali.ince at gmail.com Thu Dec 6 22:49:04 2018 From: ali.ince at gmail.com (=?utf-8?B?QWxpIMSwbmNl?=) Date: Thu, 6 Dec 2018 22:49:04 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> Message-ID: <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> Hi Magnus, Alexey, I believe we won?t be able to get further opinions from serviceability-dev. Andrew Luo suggested using a similar mechanism as is used for jvm.dll by using symbol name files mapped by platform (files are under make/hotspot/symbols and interestingly windows is almost the only platform for which a symbol file doesn?t exist). Another issue, again opened against AdoptOpenJDK 32-bit builds is somehow related with the same problem - but this time it is jimage.dll depending on zip.dll expecting the ZIP_InflateFully function to be decorated with JNICALL - whereas it was removed earlier from the implementation and the runtime image just fails with access violation just because jimage source code still declared it with JNICALL (https://github.com/AdoptOpenJDK/openjdk-build/issues/763 ). I?ve also searched for GetProcAddress calls across the source code - and I think it?s important to work on the consistency of JNICALL usages across the whole source code. Another noteworthy thing I?ve noticed is there are still JNICALL modifiers for example in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49 - which I guess will also be reported as broken since these functions are again name decorated. If we?re still determined to remove JNICALL, what about just removing __stdcall from JNICALL declaration at https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31 ? Wouldn?t that be a more consistent move? Regards, Ali > On 22 Nov 2018, at 17:29, Magnus Ihse Bursie wrote: > > I think we are in complete agreement. What's missing is some expert opinion from serviceability-dev if there is any problem with changing the signature. I'd preferably have that. > > If no one knows, I'd say, change it, and see if we still pass the relevant tests, and if so, ship it. > > /Magnus > > 22 nov. 2018 kl. 18:04 skrev Alexey Ivanov >: > >> >> On 21/11/2018 12:16, Magnus Ihse Bursie wrote: >>> >>> On 2018-11-20 16:49, Alexey Ivanov wrote: >>> >>>> Hi Ali, Magnus, >>>> >>>> I absolutely agree this change has to be reviewed by someone from serviceability. >>>> >>>> There are several options: >>>> >>>> 1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows >>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html >>>> so it partially reverts the changes from >>>> https://bugs.openjdk.java.net/browse/JDK-8200178 >>>> >>>> 2. Remove JNICALL (__stdcall) modifier, eventually changing the calling convention to __cdecl. >>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023969.html >>>> >>>> 3. Use inline /export option via #pragma: >>>> #pragma comment(linker, "/export:jdwpTransport_OnLoad= _jdwpTransport_OnLoad at 16") >>>> as referenced in >>>> https://docs.microsoft.com/en-ie/cpp/cpp/dllexport-dllimport?view=vs-2017 >>>> https://docs.microsoft.com/en-ie/cpp/build/reference/exports?view=vs-2017 >>>> >>>> The third options still needs to be tested to make sure it does not break other platforms builds. >>> I'm not fond of either solution 1 or 3. I really think the signature should be made correctly at the point of definition in the source code. >> >> That is why I proposed removing JNICALL (__stdcall) from the function declaration as we had done for libzip, libjimage [1] and mlib_image [2]. >> >> Microsoft recommends using __stdcall for DLLs, at the same time it decorates the function name making it harder to export it by its plain name. >> >> >> By removing JNICALL / __stdcall, we make the function use __cdecl calling convention. The difference between them is that with __stdcall the callee cleans the stack whereas with __cdecl the caller cleans the stack. >> >> It shouldn't be a problem as long as all function declarations use the same calling convention, which, I believe, is the case here. >> >>> We've spent some considerable effort of getting rid of the /export flags for Windows (and map files for unix), and I don't want to see them creep back in. Note that option 3 is just option 1 in disguise. The only single good thing about it is that it allows you to put the compiler option next to the signature declaration in the source code. >> >> At least in this case, the option will be near the function body definition. It will be easier to update it if the signature changes. >> >> If we are to use __stdcall, it seems to be the only way to export the undecorated name. >> >>> The same goes for def files, as suggested by Ali. It's just yet another version of option 1 in disguise/map files. >> >> If option 2 is rejected, I'm for using option 3. If option 3 cannot be used too, I'm for option 1. >> I think we should not fall back to def files in any case. And Makefile will have to include the reference to the def file, so it's even worse than option 1. >> >> >> Regards, >> Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8201226 >> [2] https://bugs.openjdk.java.net/browse/JDK-8202476 >>> >>> /Magnus >>> >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 19/11/2018 12:19, Magnus Ihse Bursie wrote: >>>>> Hi Ali, >>>>> >>>>> From a build perspective this change looks OK. I'm not aware of the finer details on the OnLoad mechanism, like what calling convention is to be used. So maybe this is a no-go from that view. >>>>> >>>>> I'm cc:ing servicability so they can have a look at it. >>>>> >>>>> /Magnus >>>>> >>>>> On 2018-11-18 13:07, Ali ?nce wrote: >>>>>> Hi Alexey, >>>>>> >>>>>> Below is a new patch content that removes JNICALL modifiers from the exported functions of interest. This results in exported functions not to be name decorated and use __cdecl calling convention. >>>>>> >>>>>> Do you have any more suggestions, or would you please guide me on next steps? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ali >>>>>> >>>>>> # HG changeset patch >>>>>> # User Ali Ince >>>>>> # Date 1542542415 0 >>>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows builds >>>>>> >>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug 14 14:28:23 2018 +0200 >>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov 18 12:00:15 2018 +0000 >>>>>> @@ -339,7 +339,7 @@ >>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>> } >>>>>> >>>>>> -JNIEXPORT jint JNICALL >>>>>> +JNIEXPORT jint >>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>> jint version, jdwpTransportEnv** result) >>>>>> { >>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Tue Aug 14 14:28:23 2018 +0200 >>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Sun Nov 18 12:00:15 2018 +0000 >>>>>> @@ -140,7 +140,7 @@ >>>>>> void (*free)(void *buffer); /* Call this for all deallocations */ >>>>>> } jdwpTransportCallback; >>>>>> >>>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>> jdwpTransportCallback *callback, >>>>>> jint version, >>>>>> jdwpTransportEnv** env); >>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>> @@ -1019,7 +1019,7 @@ >>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>> } >>>>>> >>>>>> -JNIEXPORT jint JNICALL >>>>>> +JNIEXPORT jint >>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>> jint version, jdwpTransportEnv** env) >>>>>> { >>>>>> >>>>>> >>>>>> >>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> It's exactly what I referred to. >>>>>>> >>>>>>> Yes, it does change the calling convention. >>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>> >>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>> >>>>>>> >>>>>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Thanks for your reply. >>>>>>>> >>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>> >>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 ). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>> >>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99 . >>>>>>>> >>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>> >>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709 ) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>> >>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>> >>>>>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1 . >>>>>>>>>> >>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>> )) >>>>>>>>>> >>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>> libjdwp/export, \ >>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>> >>>> >>> >> From GROEGES at uk.ibm.com Fri Dec 7 18:08:14 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 7 Dec 2018 18:08:14 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> Message-ID: Hi Roger, I have made the same change to the Solaris code and also removed the test from the ProblemList.txt I have created a webrev here: http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ Hope you can now test t Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 07/12/2018 14:55 Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. Sent by: "core-libs-dev" Hi, I notice that the Solaris case also does not include "|| forceNullOutputStream". I'll have to investigate why the Pipeline test didn't fail on Solaris. Please add that to the patch and I'll run it through our tests. Thanks, Roger On 12/07/2018 03:05 AM, Volker Simonis wrote: > Hi Steve, > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > well, because that's where the review has to take place. The > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > get their attention on relevant changes (so cross-posting is fine in > this case :) > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger wrote: >> Hi all, >> >> I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the >> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: >> >> >> diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java >> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 >> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 >> @@ -446,7 +446,7 @@ >> ProcessBuilder.NullOutputStream.INSTANCE : >> new ProcessPipeOutputStream(fds[0]); >> >> - stdout = (fds[1] == -1) ? >> + stdout = (fds[1] == -1 || forceNullOutputStream) ? >> ProcessBuilder.NullInputStream.INSTANCE : >> new DeferredCloseProcessPipeInputStream(fds[1]); >> > Your change looks good and I can sponsor it. Just as a hint for other > reviewers I'd like to mention that this change, albeit in a shared > Java file, is still AIX-only because it is in the "AIX" case of a > switch statement. > > @Steve: can you please verify, that your change introduces no > regression by running the complete jtreg test suite. > > Thank you and best regards, > Volker > >> I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. >> >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Fri Dec 7 18:08:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 13:08:00 -0500 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 Message-ID: <04ddc23c-7e1d-41ad-7cd7-4bde9459011c@oracle.com> Hi Michihiro, Looks fine with the updates. Its great that the change to isDigit is beneficial on other platforms too. A very small editorial: ? There should be a comma? "," after the 2018 in the copyright of: ? test/micro/org/openjdk/bench/java/lang/Characters.java Thanks, Roger On 12/07/2018 03:13 AM, Michihiro Horie wrote: > > Hi Roger, > > I updated my webrev. > http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ > > > >0x80 might be a good choice or 0xff. > I agree,thanks. > > >I was wondering about the performance without the PPC specific > intrinsic but with the > >CharacterDataLatin1.java.template code for isDigit being: > >??? ??? return '0' <= ch && ch <= '9'; > I now understand your point,thanks for your explanation. Both on > Power9 and Skylake, the isDigit(ch)using ?0???9?explicitly in > CharacterDataLatin1.java.template without PPC specific intrinsicwas > around 15% faster than the original code that does not include my > changes. I fixed my change using ?0???9?for this isDigit(ch). > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi > Michihiro, On 12/06/2018 02:38 AM, Michihiro Horie wrote:Roger Riggs > ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 AM, > Michihiro Horie wrote: > > From: Roger Riggs > To: Michihiro Horie > Cc: core-libs-dev at openjdk.java.net, > hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, > vladimir.kozlov at oracle.com, volker.simonis at sap.com > Date: 2018/12/07 01:23 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------ > > > > Hi Michihiro, > > On 12/06/2018 02:38 AM, Michihiro Horie wrote: > > Hi Roger, > > Thank you for your helpful comments. I updated new webrev, > adding a parameter in the jmh test to measure ?other? > characters and moving the file to an appropriate location, > also fixing the indents and copyright year._ > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.03/_ > > > The choice of 256 for other is outside the range of Latin1 which is > 0..255. > 0x80 might be a good choice or 0xff. > > > >Is there an opportunity to improve the performance of isDigit > using explicit '0'.. '9' > >in CharacterDataLatin1.java.template?? The performance would > need to be measured and compared. > Yes, there is an opportunity: intrinsic performed 25% better > than the original on Power9. > > I was wondering about the performance without the PPC specific > intrinsic but with the > CharacterDataLatin1.java.template code for isDigit being: > ??? ??? return '0' <= ch && ch <= '9'; > > > >Is the profile of in-lining methods changed in any measurable > way now that > >there is an extra level of method invocation? > > ?? Character.isLowerCase(ch) -> > CharacterData.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > > > >instead of: > >??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > I missed this point, thanks. I tried jstack but could not find > additional level. > > LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is > compiled in c1: > entry='0x00003fff5911cd00' size='1472' > address='0x00003fff5911cb90' relocation_offset='344' > insts_offset='368' stub_offset='1136' > scopes_data_offset='1248' scopes_pcs_offset='1336' > dependencies_offset='1448' nul_chk_table_offset='1456' > oops_offset='1184' metadata_offset='1192' > method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' > bytes='15' count='1024' iicount='1025' stamp='0.058'/> > > Supposing some existing complex code was already taking advantage of > the full allowed inline depth. > Then adding an extra level might change the inlining behavior. > > > Existing methods in CharacterDataLatin1.java.template etc. > directly invoke getProperties(ch), so isLowerCase(ch) would be > more aligned with other methods if it looks like as follows? > + @HotSpotIntrinsicCandidate > + boolean isLowerCase(int ch) { > + int props = getProperties(ch); > + return (props & $$maskType) == Character.LOWERCASE_LETTER; > + } > > Yes, that would alleviate my concern. > > Thanks, Roger > > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Roger Riggs ---2018/12/06 > 05:09:36---Hi Michihiro, On 12/05/2018 07:21 AM, Michihiro > Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, > On 12/05/2018 07:21 AM, Michihiro Horie wrote: > > From: Roger Riggs __ > > To: Michihiro Horie __ > , _vladimir.kozlov at oracle.com_ > > Cc: _core-libs-dev at openjdk.java.net_ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ , > _volker.simonis at sap.com_ > Date: 2018/12/06 05:09 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > ------------------------------------------------------------------------ > > > > Hi Michihiro, > > On 12/05/2018 07:21 AM, Michihiro Horie wrote: > >There are a few JMH tests for upper and lower > in the jmh-jdk-microbenchmarks repo. [1] > Here is a jmh webrev for the Character methods._ > __http://cr.openjdk.java.net/~mhorie/8213754/jmh-webrev.00/_ > > Please include at least one character value that is not a > member of any of the classes. > The performance impact for 'other' characters is important also. > > The JMH tests have been moved to the OpenJDK jdk/jdk repo in > the directory: > ?? test/micro/org/openjdk/bench/java/lang/ > > Now that they are in that repo, they can be included with the > rest of the changeset. > Also, I updated C2 changes in the latest > webrev. (Thank you for giving valuable > comments off-list, Vladimir and Martin!) > With the change in is_disabled_by_flags, I > added a JVM flag that will need another review > request. I would proceed for it if this RFR is > accepted._ > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.02/_ > > The indent in the Java code should be 4 spaces. (Native lib > code is 4 spaces, Hotspot is 2 spaces) > > Please update the copyrights to include 2018. > > Is there an opportunity to improve the performance of isDigit > using explicit '0'.. '9' > in CharacterDataLatin1.java.template?? The performance would > need to be measured and compared. > > Is the profile of in-lining methods changed in any measurable > way now that > there is an extra level of method invocation? > ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) > -> getType(ch) == LOWERCASE_LETTER; > > instead of: > ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > > Regards, Roger > I need a review on changes in the class > library, anyway. Would be grateful if I could > have one. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > > ----- Original message ----- > From: Michihiro Horie/Japan/IBM > To: Vladimir Kozlov > __ > > Cc: core-libs-dev > __ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ > , Roger Riggs > __ > , > _volker.simonis at sap.com_ > > Subject: Re: RFR: 8213754: PPC64: Add > Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > Date: Fri, Nov 30, 2018 1:01 PM > > Hi Vladimir, > > Thank you for your further comments. I fixed > my code, but I?m afraid discussing such a > basic topic involving the two big mailing > lists is not good. Please let me have a chance > to talk on this off-list. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Vladimir Kozlov ---2018/11/30 03:01:42---Hi > Michihiro, I still do not understand which > Region node you are swapping. Where it is > coming from? > > From: Vladimir Kozlov > __ > > To: Michihiro Horie __ > , Roger Riggs > __ > > Cc: core-libs-dev > __ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ > , > _volker.simonis at sap.com_ > > Date: 2018/11/30 03:01 > Subject: Re: RFR: 8213754: PPC64: Add > Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > ------------------------------------------------------------------------ > > > > Hi Michihiro, > > I still do not understand which Region node > you are swapping. Where it is coming from? > > > + // Swap current RegionNode with new one > > Regards, > Vladimir > > On 11/28/18 10:31 PM, Michihiro Horie wrote: > > Vladimir,Roger, > > Thank you so much for your responses. > > > > Vladimir, > > Regarding the hotspot change,I?m new in > changing around library_call.cpp,so your > comments are very helpful. I will fix > > my code,especially > inline_character_compare()would be like: > > > > +bool > LibraryCallKit::inline_character_compare(vmIntrinsics::ID > id){ > > + RegionNode* old_rgn = control()->as_Region(); > > + RegionNode* new_rgn = new RegionNode(1); > > + record_for_igvn(new_rgn); > > + > > + // Swap current RegionNode with new one > > + Node* new_ctrl = old_rgn->in(1); > > + old_rgn->del_req(1); > > + new_rgn->add_req(new_ctrl); > > + > > + set_control(_gvn.transform(new_rgn)); > > + > > + // argument(0)is receiver > > + Node* codePoint = argument(1); > > + Node* n = NULL; > > + > > + switch (id){ > > + case vmIntrinsics::_isDigit_c : n = new > DigitCNode(control(),codePoint);break; > > + case vmIntrinsics::_isLowerCase_c : n = > new LowerCaseCNode(control(),codePoint);break; > > + case vmIntrinsics::_isUpperCase_c : n = > new UpperCaseCNode(control(),codePoint);break; > > + case vmIntrinsics::_isWhitespace_c : n = > new WhitespaceCNode(control(),codePoint);break; > > + default: > > + fatal_unexpected_iid(id); > > + } > > + > > + set_result(_gvn.transform(n)); > > + return true; > > +} > > > > Microbenchmark showed ~40% improvements. > > > > Roger, > > I would wait foryour review,thanks. I > understood the discussion had not been > recognized from people in core-libs-dev,and > > checked it was not actually archived there?. > > > > Best regards, > > -- > > Michihiro, > > IBM Research - Tokyo > > > > Inactive hide details for Roger Riggs > ---2018/11/29 11:21:26---Hi, I'll look at it > on Thursday.Roger Riggs ---2018/11/29 > > 11:21:26---Hi, I'll look at it on Thursday. > > > > From: Roger Riggs __ > > > To: Vladimir Kozlov > __ > , Michihiro > Horie __ > , > _core-libs-dev at openjdk.java.net_ > > > Cc: _volker.simonis at sap.com_ > , > _hotspot-compiler-dev at openjdk.java.net_ > , > _martin.doerr at sap.com_ > > > Date: 2018/11/29 11:21 > > Subject: Re: RFR: 8213754: PPC64: Add > Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > > > > > ------------------------------------------------------------------------------------------------------------------------ > > > > > > > > Hi, > > > > I'll look at it on Thursday. > > > > In spite of it looking like the email was > sent to core-lib-dev, I have > > not seen it before > > and its not in the core-libs-dev archive. > > > > $.02, Roger > > > > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > > ?> You still need review from core-libs. > > ?> > > ?> About your hotspot changes. You need to > add intrinsics to > > ?> is_disabled_by_flags() to be able switch > them off. > > ?> > > ?> Note, match_rule_supported() calls in > > ?> C2Compiler::is_intrinsic_supported() > executed before intrinsics in C2 > > ?> are registered. So they will not be > available if they are not > > ?> supported. match_rule_supported() checks in > > ?> > LibraryCallKit::inline_character_compare() are > not needed. > > ?> > > ?> I don't get what you code in > > ?> > LibraryCallKit::inline_character_compare() is > doing. Why you check > > ?> Region node at the beginning and why you > add Region and Phi at the end > > ?> if you have only one path? > > ?> You are creating code for whole method > which should return boolean result > > ?> > > ?> + ? ?boolean isDigit(int ch) { > > ?> + ? ? ?return getType(ch) == > Character.DECIMAL_DIGIT_NUMBER; > > ?> + ? ?} > > ?> > > ?> but your code produce TypeInt::CHAR. why? > > ?> > > ?> An finally. Did you compare code > generated by default and with you > > ?> changes? what improvement you see? > > ?> > > ?> Thanks, > > ?> Vladimir > > ?> > > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: > > ?>> Is there any response from core-libs-dev? > > ?>> > > ?>> Vladimir, > > ?>> Could you give your suggestion on how to > proceed? > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > ?>> ----- Original message ----- > > ?>> From: "Michihiro Horie" > __ > > ?>> Sent by: "hotspot-compiler-dev" > > ?>> > __ > > > ?>> To: "Doerr, Martin" > __ > > > ?>> Cc: "Simonis, Volker" > __ > , > > ?>> > _"hotspot-compiler-dev at openjdk.java.net"_ > __ > , > > ?>> _"core-libs-dev at openjdk.java.net"_ > __ > > > ?>> Subject: RE: 8213754: PPC64: Add > Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> Date: Thu, Nov 22, 2018 11:28 AM > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> Yes, we should wait for the feedback on > class library change. > > ?>> > > ?>> ?>Btw. I think you can further simplify > the code in library_call.cpp > > ?>> (no phi). But we can discuss details > when thedirection regarding the > > ?>> java classes is clear. > > ?>> Thank you for pointing out it, I think I > understand how to simplify > > ?>> code. > > ?>> > > ?>> ?>Hi Michi, > > ?>> ?> > > ?>> ?>On 11/20/2018 02:52 PM, Michihiro > Horie wrote: > > ?>> ?>> >Please note that we don?t have a > machine, yet. So other people > > ?>> will have to test. > > ?>> ?>> I think Gustavo can help testing > this change when its' ready. > > ?>> ?>Sure :) > > ?>> ?> > > ?>> ?>Best regards, > > ?>> ?>Gustavo > > ?>> Thank you, Gustavo. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> Inactive hide details for "Doerr, > Martin" ---2018/11/22 01:33:34---Hi > > ?>> Michihiro, thanks. This proposal makes > the javacode much"Doerr, > > ?>> Martin" ---2018/11/22 01:33:34---Hi > Michihiro, thanks. This proposal > > ?>> makes the java code much moreintrinsics > friendly. > > ?>> > > ?>> From: "Doerr, Martin" > __ > > > ?>> To: Michihiro Horie __ > , > > ?>> _"core-libs-dev at openjdk.java.net"_ > __ > > > ?>> Cc: > _"hotspot-compiler-dev at openjdk.java.net"_ > > > ?>> > __ > , > "Simonis, > > ?>> Volker"__ > , Gustavo Romero > > ?>> __ > > > ?>> Date: 2018/11/22 01:33 > > ?>> Subject: RE: 8213754: PPC64: Add > Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> > > > ------------------------------------------------------------------------------------------------------------------------ > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> Hi Michihiro, > > ?>> > > ?>> thanks. This proposal makes the java > code much more intrinsics friendly. > > ?>> We should wait for feedback from the > core lib folks. Maybe they have > > ?>> some requirements or other proposals. > > ?>> > > ?>> I think these intrinsics should be > interesting for Oracle, Intel and > > ?>> others, too. > > ?>> > > ?>> Btw. I think you can further simplify > the code in library_call.cpp > > ?>> (no phi). But we can discuss details > when thedirection regarding the > > ?>> java classes is clear. > > ?>> > > ?>> Best regards, > > ?>> Martin > > ?>> > > ?>> * > > ?>> **From:*Michihiro Horie > __ * > > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* > > ?>> **To:*core-libs-dev at openjdk.java.net; > Doerr, Martin > > ?>> __ > * > > ?>> > **Cc:*hotspot-compiler-dev at openjdk.java.net; > Simonis, Volker > > ?>> __ > ; Gustavo > Romero__ > * > > ?>> **Subject:*RE: 8213754: PPC64: Add > Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> I send this RFR to core-libs-dev too, > because it changes the class > > ?>> library. > > ?>> > > ?>> Through trial and error, I separated > Latin1 block as in the _ > > ?>> > > > ___http://cr.openjdk.java.net/~mhorie/8213754/webrev.01__ > > > > > ?>> > <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.01_>_/_ > > ?>> > > ?>> I followed the coding way of > Character.isWhitespace() that invokes > > ?>> each ChracterData?s isWhitespace() to > refactorisDigit(), > > ?>> isLowerCase(), and isUpperCase(). > > ?>> > > ?>> I think this change is also useful on > x86, using STTNI. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > ?>> ----- Original message ----- > > ?>> From: "Michihiro Horie" > <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>> > > ?>> Sent by: "hotspot-compiler-dev" > > ?>> > <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_>> > > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>> > > ?>> Cc: "Simonis, Volker" > <_volker.simonis at sap.com_ > > ?>> <_mailto:volker.simonis at sap.com_>>, > > ?>> > "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > ?>> > <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>>, > > ?>> > "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > > ?>> > <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>> > > ?>> > > ?>> Subject: RE: 8213754: PPC64: Add > Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> Date: Wed, Nov 21, 2018 1:53 AM > > ?>> > > ?>> Hi Martin, > > ?>> > > ?>> Thank you for giving your helpful > comments. I did not recognize > > ?>> ?generate_method_call_static? prevents > anyoptimizations, but I now > > ?>> checked it actually degraded the > performance, thanks. > > ?>> > > ?>> ?>Please note that we don?t have a > machine, yet. So other people will > > ?>> have to test. > > ?>> I think Gustavo can help testing this > change when its' ready. > > ?>> > > ?>> ?>Would it be possible to introduce more > fine-grained intrinsics such > > ?>> that the ?slow? path is outside of them? > > ?>> ?> > > ?>> ?>Maybe you can factor out as in the > following example? > > ?>> ?>if (latin1) return > isLatin1Digit(codePoint); > > ?>> ?>with isLatin1Digit as > HotSpotIntrinsicCandidate. > > ?>> Thanks for an example, please let me try > to separate the Latin block > > ?>> from other blocks for some time. > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> Inactive hide details for "Doerr, > Martin" ---2018/11/20 01:55:27---Hi > > ?>> Michihiro, first of all, thanks for > working onPower9 opt"Doerr, > > ?>> Martin" ---2018/11/20 01:55:27---Hi > Michihiro, first of all, thanks > > ?>> for working on Power9optimizations. > Please note that we don't ha > > ?>> > > ?>> From: "Doerr, Martin" > <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>> > > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ > <_mailto:HORIE at jp.ibm.com_>>, > > ?>> > "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > > ?>> > <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > ?>> > "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > > ?>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > ?>> Cc: "Simonis, Volker" > <_volker.simonis at sap.com_ > > ?>> <_mailto:volker.simonis at sap.com_>>, > "Lindenmaier, > > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, > Gustavo Romero > > ?>> > <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_>> > > ?>> Date: 2018/11/20 01:55 > > ?>> Subject: RE: 8213754: PPC64: Add > Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> > > > ------------------------------------------------------------------------------------------------------------------------ > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> > > ?>> Hi Michihiro, > > ?>> > > ?>> first of all, thanks for working on > Power9 optimizations. Please note > > ?>> that we don?t have a machine, yet. So > other peoplewill have to test. > > ?>> > > ?>> I think it may be problematic to insert > a slow path by > > ?>> ?generate_method_call_static?. This may > be a performancedisadvantage > > ?>> for some users of other encodings > because your intrinsics prevent > > ?>> inlining and further optimizations. > > ?>> Would it be possible to introduce more > fine-grained intrinsics such > > ?>> that the ?slow? path is outside of them? > > ?>> > > ?>> Maybe you can factor out as in the > following example? > > ?>> if (latin1) return isLatin1Digit(codePoint); > > ?>> with isLatin1Digit as > HotSpotIntrinsicCandidate. > > ?>> > > ?>> I can?t judge if this is needed, but I > think this should be discussed > > ?>> first before going into the details. > > ?>> > > ?>> Best regards, > > ?>> Martin > > ?>> > > ?>> * > > ?>> **From:*Michihiro Horie > <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>>* > > ?>> **Sent:*Freitag, 16. November 2018 12:53* > > ?>> > **To:*_hotspot-compiler-dev at openjdk.java.net_ > > ?>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ > > ?>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>* > > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > > ?>> <_mailto:martin.doerr at sap.com_>>; > Simonis, Volker > > ?>> > <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_>>; > > ?>> Lindenmaier, Goetz > <_goetz.lindenmaier at sap.com_ > > ?>> > <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo > Romero > > ?>> <_gromero at linux.vnet.ibm.com_ > <_mailto:gromero at linux.vnet.ibm.com_>>* > > ?>> **Subject:*RFR: 8213754: PPC64: Add > Intrinsics for > > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > > ?>> > > ?>> Dear all, > > ?>> > > ?>> Would you please review following change? > > ?>> > > ?>> Bug: > > > __https://bugs.openjdk.java.net/browse/JDK-8213754__ > > ?>> Webrev: > > > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.00__ > > > > > ?>> > <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.00_> > > ?>> > > ?>> This change includes the intrinsics of > Character isDigit, > > ?>> isLowerCase, isUpperCase, and > isWhitespace to support theLatin1 block > > ?>> using POWER9?s instructions cmprb and > cmpeqb. The cmprb enables to > > ?>> compare a character with 1 or 2 > rangedbytes, while the cmpeqb > > ?>> compares one with 1 to 8 values. Simple > micro benchmark attached > > ?>> showed improvements by 20-40%. > > ?>> / > > ?>> //(See attached file: Latin1Test.java)/ > > ?>> > > ?>> > > ?>> Best regards, > > ?>> -- > > ?>> Michihiro, > > ?>> IBM Research - Tokyo > > ?>> > > ?>> > > > > > > > > > > > > > > > > From volker.simonis at gmail.com Fri Dec 7 18:16:00 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Dec 2018 19:16:00 +0100 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> Message-ID: It fails as shown below (I've added an additional line "res:..." to print the actual content of "test.out"). For the failing test, "test.out" is always zero bytes. I think the problem is that the first process finishes before the second process in the pipe is started. In very few cases I saw the "t2_translatePipeline" test succeeding on AIX as well. I assume that was for cases where the first "tr" process was still alive when the second one was started. in: Now is the time to check! out: Now is the time to check! res: Now is the time to check! in: Now is the time to check! out: Now is the time to check! res: result not as expected java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1383) at PipelineTest.fail(PipelineTest.java:275) at PipelineTest.fail(PipelineTest.java:276) at PipelineTest.check(PipelineTest.java:279) at PipelineTest.verify(PipelineTest.java:189) at PipelineTest.t1_simplePipeline(PipelineTest.java:68) at PipelineTest.realMain(PipelineTest.java:42) at PipelineTest.main(PipelineTest.java:286) in: Now is the time to check! out: Now is the time to check! res: result not as expected java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1383) at PipelineTest.fail(PipelineTest.java:275) at PipelineTest.fail(PipelineTest.java:276) at PipelineTest.check(PipelineTest.java:279) at PipelineTest.verify(PipelineTest.java:189) at PipelineTest.t1_simplePipeline(PipelineTest.java:71) at PipelineTest.realMain(PipelineTest.java:42) at PipelineTest.main(PipelineTest.java:286) in: Now is the time to check! out: NOw is thE timE tO chEck! res: result not as expected java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1383) at PipelineTest.fail(PipelineTest.java:275) at PipelineTest.fail(PipelineTest.java:276) at PipelineTest.check(PipelineTest.java:279) at PipelineTest.verify(PipelineTest.java:189) at PipelineTest.t2_translatePipeline(PipelineTest.java:87) at PipelineTest.realMain(PipelineTest.java:43) at PipelineTest.main(PipelineTest.java:286) The error from the first process should be in the output of the second: java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1383) at PipelineTest.fail(PipelineTest.java:275) at PipelineTest.fail(PipelineTest.java:276) at PipelineTest.check(PipelineTest.java:279) at PipelineTest.t3_redirectErrorStream(PipelineTest.java:114) at PipelineTest.realMain(PipelineTest.java:44) at PipelineTest.main(PipelineTest.java:286) Passed = 15, failed = 4 Exception in thread "main" java.lang.AssertionError: Some tests failed at PipelineTest.main(PipelineTest.java:288) On Fri, Dec 7, 2018 at 6:56 PM Roger Riggs wrote: > > Hi, > > I'd be interested in how PipelineTest failed on AIX? > > It looks like PipelineTest is flawed in that verifyProcesses() does not > check > all of the 1..n Processes getInputStreams for being a null stream, only > the nth Process. > And the test is incorrectly applied to the last Process, which returns a > null > stream not because of the pipeline but because the output is redirected > to a file. > > Thanks, Roger > > > On 12/07/2018 09:52 AM, Roger Riggs wrote: > > Hi, > > > > I notice that the Solaris case also does not include "|| > > forceNullOutputStream". > > I'll have to investigate why the Pipeline test didn't fail on Solaris. > > > > Please add that to the patch and I'll run it through our tests. > > > > Thanks, Roger > > > > On 12/07/2018 03:05 AM, Volker Simonis wrote: > >> Hi Steve, > >> > >> thanks a lot for this fix. I'm forwarding this to core-libs-dev as > >> well, because that's where the review has to take place. The > >> "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > >> get their attention on relevant changes (so cross-posting is fine in > >> this case :) > >> > >> On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger wrote: > >>> Hi all, > >>> > >>> I have been investigating the issue > >>> https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz > >>> Lindenmaier which is related to the > >>> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on > >>> AIX. Having done some investigation I have a potential fix fore the > >>> issue: > >>> > >>> > >>> diff -r 9501a7b59111 > >>> src/java.base/unix/classes/java/lang/ProcessImpl.java > >>> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec > >>> 03 14:28:19 2018 +0300 > >>> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec > >>> 06 15:01:03 2018 +0000 > >>> @@ -446,7 +446,7 @@ > >>> ProcessBuilder.NullOutputStream.INSTANCE : > >>> new ProcessPipeOutputStream(fds[0]); > >>> > >>> - stdout = (fds[1] == -1) ? > >>> + stdout = (fds[1] == -1 || forceNullOutputStream) ? > >>> ProcessBuilder.NullInputStream.INSTANCE : > >>> new > >>> DeferredCloseProcessPipeInputStream(fds[1]); > >>> > >> Your change looks good and I can sponsor it. Just as a hint for other > >> reviewers I'd like to mention that this change, albeit in a shared > >> Java file, is still AIX-only because it is in the "AIX" case of a > >> switch statement. > >> > >> @Steve: can you please verify, that your change introduces no > >> regression by running the complete jtreg test suite. > >> > >> Thank you and best regards, > >> Volker > >> > >>> I would appreciate any feedback please, and for someone to be a > >>> sponsor for this and to contributute it to OpenJDK. > >>> > >>> Steve Groeger > >>> IBM Runtime Technologies > >>> Hursley, Winchester > >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > >>> Fax (44) 1962 816800 > >>> Lotus Notes: Steve Groeger/UK/IBM > >>> Internet: groeges at uk.ibm.com > >>> > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > >>> number 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >>> PO6 3AU > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > >>> number 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >>> PO6 3AU > > > From stuart.marks at oracle.com Fri Dec 7 18:17:29 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 7 Dec 2018 10:17:29 -0800 Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <2e18da61-173d-8c7d-02b9-b4307c59b306@oracle.com> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> <2e18da61-173d-8c7d-02b9-b4307c59b306@oracle.com> Message-ID: <344583cf-e94a-e98c-8c90-7d36ee4cf915@oracle.com> Hi Andrew, Aleksey, R?mi, Thanks for looking at the patch. Could one or more of you add yourselves as reviewers on the corresponding CSR? https://bugs.openjdk.java.net/browse/JDK-8215025 Thanks, s'marks From vincent.x.ryan at oracle.com Fri Dec 7 18:22:46 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 7 Dec 2018 18:22:46 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> Message-ID: <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> Thanks for your review Stuart. Comments below. > On 6 Dec 2018, at 02:18, Stuart Marks wrote: > > Hi Vinnie, > > Roger Riggs wrote: >>> The 'forEachOrdered' should not be necessary and may raise questions about why. >>> if there's no good reason, use 'forEach?. > > Using forEachOrdered() is necessary. The dumpAsStream() method produces a stream; presumably it has a defined order that's the same as its input. The semantics of Stream.forEach() are extremely relaxed, and in particular it's not required to process stream elements in order, even if the stream is ordered. (In practice this is noticeable if the stream is run in parallel.) > > I'd use forEachOrdered() both in the examples and also where you use it in implementations. I?ve retained forEachOrdered() throughout. > > The methods that return streams should specify the important characteristics. Probably the ones most important one are that the returned stream is ordered and sequential. For the overloads that take fixed-size input, the resulting stream might also be SIZED. I?ve updated the javadoc @return tag for the Stream-returning methods. Let me know if you?d prefer the stream characteristics to also appear in the method?s first sentence. > > I'm not convinced that the overloads that send output to an OutputStream pull their weight. They basically wrap the OutputStream in a PrintStream, which conveniently doesn't declare IOException, making it easy to use from a lambda passed to forEachOrdered(). If an error writing the output occurs, this is recorded by the PrintStream wrapper; however, the wrapper is then thrown away, making it impossible for the caller to check its error status. The intent is to support a trivial convenience method call that generates the well-known hexdump format. Especially for users that are interested in the hexdump data rather than the low-level details of how to terminate a stream. The dumpAsStream methods are available to support cases that differ from that format. Have you a suggestion to improve the dump() methods, or you?d like to see them omitted? > > The PrintStream wrapper also uses the platform default charset, and doesn't provide any way for the caller to override the charset. Is there a need for that? Originally the requirement was driven by the hexdump format which is ASCII-only. Recently the class has been enhanced to also support the printable characters from ISO 8859-1. A custom formatter be supplied to dumpAsStream() to cater for all other cases? > > Instead, you can just provide the Stream-returning methods, and let the user send the output to a PrintStream using forEachOrdered() as in your examples. > > It might be nice to provide convenience APIs to send output elsewhere, but the problem is that it seems difficult to do so without losing control over things like error handling or charsets. In particular, since the hex formatter is producing strings, it seems like there should be an option to send the output to a Writer. Unfortunately it's difficult to do so from a Stream, because all the Writer methods throw IOException. However, solving this isn't hexdump's problem. It?s a little more effort but those cases can always be handled by a custom formatter. > > s'marks From vladimir.kozlov at oracle.com Fri Dec 7 18:49:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Dec 2018 10:49:28 -0800 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: <04ddc23c-7e1d-41ad-7cd7-4bde9459011c@oracle.com> References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 <04ddc23c-7e1d-41ad-7cd7-4bde9459011c@oracle.com> Message-ID: Hi Michihiro, Hotspot changes looks fine. Did you look on code generated by C2 with your latest changes? And Copyright year change in intrinsicnode.hpp is incorrect: - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. Should be * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. Thanks, Vladimir On 12/7/18 10:08 AM, Roger Riggs wrote: > Hi Michihiro, > > Looks fine with the updates. > > Its great that the change to isDigit is beneficial on other platforms too. > > A very small editorial: > ? There should be a comma? "," after the 2018 in the copyright of: > ? test/micro/org/openjdk/bench/java/lang/Characters.java > > Thanks, Roger > > > On 12/07/2018 03:13 AM, Michihiro Horie wrote: >> >> Hi Roger, >> >> I updated my webrev. >> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ >> >> >> >0x80 might be a good choice or 0xff. >> I agree,thanks. >> >> >I was wondering about the performance without the PPC specific intrinsic but with the >> >CharacterDataLatin1.java.template code for isDigit being: >> >??? ??? return '0' <= ch && ch <= '9'; >> I now understand your point,thanks for your explanation. Both on Power9 and Skylake, the >> isDigit(ch)using ?0???9?explicitly in CharacterDataLatin1.java.template without PPC specific >> intrinsicwas around 15% faster than the original code that does not include my changes. I fixed my >> change using ?0???9?for this isDigit(ch). >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> >> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 >> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 >> AM, Michihiro Horie wrote: >> >> From: Roger Riggs >> To: Michihiro Horie >> Cc: core-libs-dev at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, >> vladimir.kozlov at oracle.com, volker.simonis at sap.com >> Date: 2018/12/07 01:23 >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> Hi Michihiro, >> >> On 12/06/2018 02:38 AM, Michihiro Horie wrote: >> >> Hi Roger, >> >> Thank you for your helpful comments. I updated new webrev, adding a parameter in the jmh >> test to measure ?other? characters and moving the file to an appropriate location, also >> fixing the indents and copyright year._ >> __http://cr.openjdk.java.net/~mhorie/8213754/webrev.03/_ >> >> >> The choice of 256 for other is outside the range of Latin1 which is 0..255. >> 0x80 might be a good choice or 0xff. >> >> >> >Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' >> >in CharacterDataLatin1.java.template?? The performance would need to be measured and >> compared. >> Yes, there is an opportunity: intrinsic performed 25% better than the original on Power9. >> >> I was wondering about the performance without the PPC specific intrinsic but with the >> CharacterDataLatin1.java.template code for isDigit being: >> ??? ??? return '0' <= ch && ch <= '9'; >> >> >> >Is the profile of in-lining methods changed in any measurable way now that >> >there is an extra level of method invocation? >> > ?? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == >> LOWERCASE_LETTER; >> > >> >instead of: >> >??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; >> I missed this point, thanks. I tried jstack but could not find additional level. >> >> LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled in c1: >> > address='0x00003fff5911cb90' relocation_offset='344' insts_offset='368' stub_offset='1136' >> scopes_data_offset='1248' scopes_pcs_offset='1336' dependencies_offset='1448' >> nul_chk_table_offset='1456' oops_offset='1184' metadata_offset='1192' >> method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' bytes='15' count='1024' >> iicount='1025' stamp='0.058'/> >> >> Supposing some existing complex code was already taking advantage of the full allowed inline depth. >> Then adding an extra level might change the inlining behavior. >> >> >> Existing methods in CharacterDataLatin1.java.template etc. directly invoke >> getProperties(ch), so isLowerCase(ch) would be more aligned with other methods if it looks >> like as follows? >> + @HotSpotIntrinsicCandidate >> + boolean isLowerCase(int ch) { >> + int props = getProperties(ch); >> + return (props & $$maskType) == Character.LOWERCASE_LETTER; >> + } >> >> Yes, that would alleviate my concern. >> >> Thanks, Roger >> >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> >> Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 >> 07:21 AM, Michihiro Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On >> 12/05/2018 07:21 AM, Michihiro Horie wrote: >> >> From: Roger Riggs __ >> To: Michihiro Horie __ , >> _vladimir.kozlov at oracle.com_ >> Cc: _core-libs-dev at openjdk.java.net_ , >> _hotspot-compiler-dev at openjdk.java.net_ , >> _martin.doerr at sap.com_ , _volker.simonis at sap.com_ >> >> Date: 2018/12/06 05:09 >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> isDigit/isLowerCase/isUpperCase/isWhitespace >> ---------------------------------------------------------------------------------------------------- >> >> >> >> Hi Michihiro, >> >> On 12/05/2018 07:21 AM, Michihiro Horie wrote: >> >There are a few JMH tests for upper and lower in the >> jmh-jdk-microbenchmarks repo. [1] >> Here is a jmh webrev for the Character methods._ >> __http://cr.openjdk.java.net/~mhorie/8213754/jmh-webrev.00/_ >> Please include at least one character value that is not a member of any of the classes. >> The performance impact for 'other' characters is important also. >> >> The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: >> ?? test/micro/org/openjdk/bench/java/lang/ >> >> Now that they are in that repo, they can be included with the rest of the changeset. >> Also, I updated C2 changes in the latest webrev. (Thank you for giving >> valuable comments off-list, Vladimir and Martin!) >> With the change in is_disabled_by_flags, I added a JVM flag that will need >> another review request. I would proceed for it if this RFR is accepted._ >> __http://cr.openjdk.java.net/~mhorie/8213754/webrev.02/_ >> The indent in the Java code should be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 >> spaces) >> >> Please update the copyrights to include 2018. >> >> Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' >> in CharacterDataLatin1.java.template?? The performance would need to be measured and compared. >> >> Is the profile of in-lining methods changed in any measurable way now that >> there is an extra level of method invocation? >> ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == >> LOWERCASE_LETTER; >> >> instead of: >> ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; >> >> Regards, Roger >> I need a review on changes in the class library, anyway. Would be grateful >> if I could have one. >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> >> >> ----- Original message ----- >> From: Michihiro Horie/Japan/IBM >> To: Vladimir Kozlov __ >> >> Cc: core-libs-dev __ >> , >> _hotspot-compiler-dev at openjdk.java.net_ >> , _martin.doerr at sap.com_ >> , Roger Riggs __ >> , _volker.simonis at sap.com_ >> >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> isDigit/isLowerCase/isUpperCase/isWhitespace >> Date: Fri, Nov 30, 2018 1:01 PM >> >> Hi Vladimir, >> >> Thank you for your further comments. I fixed my code, but I?m afraid >> discussing such a basic topic involving the two big mailing lists is not >> good. Please let me have a chance to talk on this off-list. >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> >> Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not >> understand which Region node you are swapping. Where it is coming from? >> >> From: Vladimir Kozlov __ >> >> To: Michihiro Horie __ , Roger >> Riggs __ >> Cc: core-libs-dev __ >> , >> _hotspot-compiler-dev at openjdk.java.net_ >> , _martin.doerr at sap.com_ >> , _volker.simonis at sap.com_ >> >> Date: 2018/11/30 03:01 >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> isDigit/isLowerCase/isUpperCase/isWhitespace >> ---------------------------------------------------------------------------------------------------- >> >> >> >> Hi Michihiro, >> >> I still do not understand which Region node you are swapping. Where it is >> coming from? >> >> > + // Swap current RegionNode with new one >> >> Regards, >> Vladimir >> >> On 11/28/18 10:31 PM, Michihiro Horie wrote: >> > Vladimir,Roger, >> > Thank you so much for your responses. >> > >> > Vladimir, >> > Regarding the hotspot change,I?m new in changing around >> library_call.cpp,so your comments are very helpful. I will fix >> > my code,especially inline_character_compare()would be like: >> > >> > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ >> > + RegionNode* old_rgn = control()->as_Region(); >> > + RegionNode* new_rgn = new RegionNode(1); >> > + record_for_igvn(new_rgn); >> > + >> > + // Swap current RegionNode with new one >> > + Node* new_ctrl = old_rgn->in(1); >> > + old_rgn->del_req(1); >> > + new_rgn->add_req(new_ctrl); >> > + >> > + set_control(_gvn.transform(new_rgn)); >> > + >> > + // argument(0)is receiver >> > + Node* codePoint = argument(1); >> > + Node* n = NULL; >> > + >> > + switch (id){ >> > + case vmIntrinsics::_isDigit_c : n = new >> DigitCNode(control(),codePoint);break; >> > + case vmIntrinsics::_isLowerCase_c : n = new >> LowerCaseCNode(control(),codePoint);break; >> > + case vmIntrinsics::_isUpperCase_c : n = new >> UpperCaseCNode(control(),codePoint);break; >> > + case vmIntrinsics::_isWhitespace_c : n = new >> WhitespaceCNode(control(),codePoint);break; >> > + default: >> > + fatal_unexpected_iid(id); >> > + } >> > + >> > + set_result(_gvn.transform(n)); >> > + return true; >> > +} >> > >> > Microbenchmark showed ~40% improvements. >> > >> > Roger, >> > I would wait foryour review,thanks. I understood the discussion had not >> been recognized from people in core-libs-dev,and >> > checked it was not actually archived there?. >> > >> > Best regards, >> > -- >> > Michihiro, >> > IBM Research - Tokyo >> > >> > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll >> look at it on Thursday.Roger Riggs ---2018/11/29 >> > 11:21:26---Hi, I'll look at it on Thursday. >> > >> > From: Roger Riggs __ >> > To: Vladimir Kozlov __ >> , Michihiro Horie __ >> , _core-libs-dev at openjdk.java.net_ >> >> > Cc: _volker.simonis at sap.com_ , >> _hotspot-compiler-dev at openjdk.java.net_ >> , _martin.doerr at sap.com_ >> >> > Date: 2018/11/29 11:21 >> > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> isDigit/isLowerCase/isUpperCase/isWhitespace >> > >> > >> ------------------------------------------------------------------------------------------------------------------------ >> > >> > >> > >> > Hi, >> > >> > I'll look at it on Thursday. >> > >> > In spite of it looking like the email was sent to core-lib-dev, I have >> > not seen it before >> > and its not in the core-libs-dev archive. >> > >> > $.02, Roger >> > >> > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: >> > ?> You still need review from core-libs. >> > ?> >> > ?> About your hotspot changes. You need to add intrinsics to >> > ?> is_disabled_by_flags() to be able switch them off. >> > ?> >> > ?> Note, match_rule_supported() calls in >> > ?> C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 >> > ?> are registered. So they will not be available if they are not >> > ?> supported. match_rule_supported() checks in >> > ?> LibraryCallKit::inline_character_compare() are not needed. >> > ?> >> > ?> I don't get what you code in >> > ?> LibraryCallKit::inline_character_compare() is doing. Why you check >> > ?> Region node at the beginning and why you add Region and Phi at the end >> > ?> if you have only one path? >> > ?> You are creating code for whole method which should return boolean result >> > ?> >> > ?> + ? ?boolean isDigit(int ch) { >> > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; >> > ?> + ? ?} >> > ?> >> > ?> but your code produce TypeInt::CHAR. why? >> > ?> >> > ?> An finally. Did you compare code generated by default and with you >> > ?> changes? what improvement you see? >> > ?> >> > ?> Thanks, >> > ?> Vladimir >> > ?> >> > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: >> > ?>> Is there any response from core-libs-dev? >> > ?>> >> > ?>> Vladimir, >> > ?>> Could you give your suggestion on how to proceed? >> > ?>> >> > ?>> >> > ?>> Best regards, >> > ?>> -- >> > ?>> Michihiro, >> > ?>> IBM Research - Tokyo >> > ?>> >> > ?>> >> > ?>> ----- Original message ----- >> > ?>> From: "Michihiro Horie" __ >> > ?>> Sent by: "hotspot-compiler-dev" >> > ?>> __ >> >> > ?>> To: "Doerr, Martin" __ >> >> > ?>> Cc: "Simonis, Volker" __ >> , >> > ?>> _"hotspot-compiler-dev at openjdk.java.net"_ >> __ >> , >> > ?>> _"core-libs-dev at openjdk.java.net"_ >> __ >> >> > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> > ?>> Date: Thu, Nov 22, 2018 11:28 AM >> > ?>> >> > ?>> Hi Martin, >> > ?>> >> > ?>> Yes, we should wait for the feedback on class library change. >> > ?>> >> > ?>> ?>Btw. I think you can further simplify the code in library_call.cpp >> > ?>> (no phi). But we can discuss details when thedirection regarding the >> > ?>> java classes is clear. >> > ?>> Thank you for pointing out it, I think I understand how to simplify >> > ?>> code. >> > ?>> >> > ?>> ?>Hi Michi, >> > ?>> ?> >> > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: >> > ?>> ?>> >Please note that we don?t have a machine, yet. So other people >> > ?>> will have to test. >> > ?>> ?>> I think Gustavo can help testing this change when its' ready. >> > ?>> ?>Sure :) >> > ?>> ?> >> > ?>> ?>Best regards, >> > ?>> ?>Gustavo >> > ?>> Thank you, Gustavo. >> > ?>> >> > ?>> >> > ?>> Best regards, >> > ?>> -- >> > ?>> Michihiro, >> > ?>> IBM Research - Tokyo >> > ?>> >> > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi >> > ?>> Michihiro, thanks. This proposal makes the javacode much"Doerr, >> > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal >> > ?>> makes the java code much moreintrinsics friendly. >> > ?>> >> > ?>> From: "Doerr, Martin" __ >> >> > ?>> To: Michihiro Horie __ , >> > ?>> _"core-libs-dev at openjdk.java.net"_ >> __ >> >> > ?>> Cc: _"hotspot-compiler-dev at openjdk.java.net"_ >> >> > ?>> __ >> , "Simonis, >> > ?>> Volker"__ , >> Gustavo Romero >> > ?>> __ >> > ?>> Date: 2018/11/22 01:33 >> > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> > ?>> >> > ?>> >> > >> ------------------------------------------------------------------------------------------------------------------------ >> > ?>> >> > ?>> >> > ?>> >> > ?>> >> > ?>> Hi Michihiro, >> > ?>> >> > ?>> thanks. This proposal makes the java code much more intrinsics friendly. >> > ?>> We should wait for feedback from the core lib folks. Maybe they have >> > ?>> some requirements or other proposals. >> > ?>> >> > ?>> I think these intrinsics should be interesting for Oracle, Intel and >> > ?>> others, too. >> > ?>> >> > ?>> Btw. I think you can further simplify the code in library_call.cpp >> > ?>> (no phi). But we can discuss details when thedirection regarding the >> > ?>> java classes is clear. >> > ?>> >> > ?>> Best regards, >> > ?>> Martin >> > ?>> >> > ?>> * >> > ?>> **From:*Michihiro Horie __ * >> > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* >> > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin >> > ?>> __ * >> > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker >> > ?>> __ ; Gustavo >> Romero__ * >> > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for >> > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> > ?>> >> > ?>> Hi Martin, >> > ?>> >> > ?>> I send this RFR to core-libs-dev too, because it changes the class >> > ?>> library. >> > ?>> >> > ?>> Through trial and error, I separated Latin1 block as in the _ >> > ?>> >> > ___http://cr.openjdk.java.net/~mhorie/8213754/webrev.01__ >> >> > >> > ?>> <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.01_>_/_ >> > ?>> >> > ?>> I followed the coding way of Character.isWhitespace() that invokes >> > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), >> > ?>> isLowerCase(), and isUpperCase(). >> > ?>> >> > ?>> I think this change is also useful on x86, using STTNI. >> > ?>> >> > ?>> >> > ?>> Best regards, >> > ?>> -- >> > ?>> Michihiro, >> > ?>> IBM Research - Tokyo >> > ?>> >> > ?>> >> > ?>> ----- Original message ----- >> > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>> >> > ?>> Sent by: "hotspot-compiler-dev" >> > ?>> >> <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_>> >> > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ >> > ?>> <_mailto:martin.doerr at sap.com_>> >> > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ >> > ?>> <_mailto:volker.simonis at sap.com_>>, >> > ?>> >> "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" >> > ?>> >> <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>>, >> > ?>> >> "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" >> > ?>> >> <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>> >> > ?>> >> > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> > ?>> Date: Wed, Nov 21, 2018 1:53 AM >> > ?>> >> > ?>> Hi Martin, >> > ?>> >> > ?>> Thank you for giving your helpful comments. I did not recognize >> > ?>> ?generate_method_call_static? prevents anyoptimizations, but I now >> > ?>> checked it actually degraded the performance, thanks. >> > ?>> >> > ?>> ?>Please note that we don?t have a machine, yet. So other people will >> > ?>> have to test. >> > ?>> I think Gustavo can help testing this change when its' ready. >> > ?>> >> > ?>> ?>Would it be possible to introduce more fine-grained intrinsics such >> > ?>> that the ?slow? path is outside of them? >> > ?>> ?> >> > ?>> ?>Maybe you can factor out as in the following example? >> > ?>> ?>if (latin1) return isLatin1Digit(codePoint); >> > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. >> > ?>> Thanks for an example, please let me try to separate the Latin block >> > ?>> from other blocks for some time. >> > ?>> >> > ?>> >> > ?>> Best regards, >> > ?>> -- >> > ?>> Michihiro, >> > ?>> IBM Research - Tokyo >> > ?>> >> > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi >> > ?>> Michihiro, first of all, thanks for working onPower9 opt"Doerr, >> > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks >> > ?>> for working on Power9optimizations. Please note that we don't ha >> > ?>> >> > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ >> > ?>> <_mailto:martin.doerr at sap.com_>> >> > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>>, >> > ?>> >> "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" >> > ?>> >> <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>>, >> > ?>> >> "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" >> > ?>> <_ppc-aix-port-dev at openjdk.java.net_ >> > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> >> > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ >> > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, >> > ?>> Goetz"<_goetz.lindenmaier at sap.com_ >> > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero >> > ?>> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_>> >> > ?>> Date: 2018/11/20 01:55 >> > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> > ?>> >> > ?>> >> > >> ------------------------------------------------------------------------------------------------------------------------ >> > ?>> >> > ?>> >> > ?>> >> > ?>> >> > ?>> >> > ?>> Hi Michihiro, >> > ?>> >> > ?>> first of all, thanks for working on Power9 optimizations. Please note >> > ?>> that we don?t have a machine, yet. So other peoplewill have to test. >> > ?>> >> > ?>> I think it may be problematic to insert a slow path by >> > ?>> ?generate_method_call_static?. This may be a performancedisadvantage >> > ?>> for some users of other encodings because your intrinsics prevent >> > ?>> inlining and further optimizations. >> > ?>> Would it be possible to introduce more fine-grained intrinsics such >> > ?>> that the ?slow? path is outside of them? >> > ?>> >> > ?>> Maybe you can factor out as in the following example? >> > ?>> if (latin1) return isLatin1Digit(codePoint); >> > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. >> > ?>> >> > ?>> I can?t judge if this is needed, but I think this should be discussed >> > ?>> first before going into the details. >> > ?>> >> > ?>> Best regards, >> > ?>> Martin >> > ?>> >> > ?>> * >> > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ >> <_mailto:HORIE at jp.ibm.com_>>* >> > ?>> **Sent:*Freitag, 16. November 2018 12:53* >> > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ >> > ?>> >> <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ >> > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* >> > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ >> > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker >> > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_>>; >> > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ >> > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero >> > ?>> <_gromero at linux.vnet.ibm.com_ <_mailto:gromero at linux.vnet.ibm.com_>>* >> > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for >> > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> > ?>> >> > ?>> Dear all, >> > ?>> >> > ?>> Would you please review following change? >> > ?>> >> > ?>> Bug: >> > __https://bugs.openjdk.java.net/browse/JDK-8213754__ >> > ?>> Webrev: >> > __http://cr.openjdk.java.net/~mhorie/8213754/webrev.00__ >> >> > >> > ?>> <_http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.00_> >> > ?>> >> > ?>> This change includes the intrinsics of Character isDigit, >> > ?>> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block >> > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to >> > ?>> compare a character with 1 or 2 rangedbytes, while the cmpeqb >> > ?>> compares one with 1 to 8 values. Simple micro benchmark attached >> > ?>> showed improvements by 20-40%. >> > ?>> / >> > ?>> //(See attached file: Latin1Test.java)/ >> > ?>> >> > ?>> >> > ?>> Best regards, >> > ?>> -- >> > ?>> Michihiro, >> > ?>> IBM Research - Tokyo >> > ?>> >> > ?>> >> > >> > >> > >> > >> > >> >> >> >> >> >> > From kasperni at gmail.com Fri Dec 7 18:49:03 2018 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 7 Dec 2018 18:49:03 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <5BF813FE.8060708@oracle.com> References: <5BF813FE.8060708@oracle.com> Message-ID: Hi, I don't know if performance is an issue. But if it is, I think it world make sense to use a precompute array. And replace private static int hexToBinary(char ch) { if ('0' <= ch && ch <= '9') { return ch - '0'; } if ('A' <= ch && ch <= 'F') { return ch - 'A' + 10; } if ('a' <= ch && ch <= 'f') { return ch - 'a' + 10; } return -1; } with private static int hexToBinary(char ch) { return ch <= 'f' ? staticPrecomputedArray[ch] : -1; } where int[] staticPrecomputedArray is computed in a static initializer block. /Kasper On Fri, 23 Nov 2018 at 14:51, Vincent Ryan wrote: > Hello, > > Please review this proposal for a new API to conveniently generate and > display binary data using hexadecimal string representation. > It supports both bulk and stream operations and it can also generate the > well-known hexdump format [1]. > > This latest revision addresses review comments provided earlier. > These include adding methods to support for data supplied in a > ByteBuffer, exposing the default formatter implementation as a public > static and dropping the superfluous 'Hex' term from several method names. > > Thanks > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > API: > > http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ > > > ____ > [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html > From vincent.x.ryan at oracle.com Fri Dec 7 18:56:12 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 7 Dec 2018 18:56:12 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> Message-ID: <95FE52C3-5E2D-4E0D-B13F-FEE283934852@oracle.com> I?ll add that replacement method. Thanks. > On 7 Dec 2018, at 18:49, Kasper Nielsen wrote: > > Hi, > > I don't know if performance is an issue. But if it is, I think it world make sense to use a precompute array. And replace > > private static int hexToBinary(char ch) { > if ('0' <= ch && ch <= '9') { > return ch - '0'; > } > if ('A' <= ch && ch <= 'F') { > return ch - 'A' + 10; > } > if ('a' <= ch && ch <= 'f') { > return ch - 'a' + 10; > } > return -1; > } > > with > > private static int hexToBinary(char ch) { > return ch <= 'f' ? staticPrecomputedArray[ch] : -1; > } > > where int[] staticPrecomputedArray is computed in a static initializer block. > > /Kasper > > On Fri, 23 Nov 2018 at 14:51, Vincent Ryan > wrote: > Hello, > > Please review this proposal for a new API to conveniently generate and > display binary data using hexadecimal string representation. > It supports both bulk and stream operations and it can also generate the > well-known hexdump format [1]. > > This latest revision addresses review comments provided earlier. > These include adding methods to support for data supplied in a > ByteBuffer, exposing the default formatter implementation as a public > static and dropping the superfluous 'Hex' term from several method names. > > Thanks > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > API: > http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ > > > ____ > [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html From Roger.Riggs at oracle.com Fri Dec 7 19:04:41 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 14:04:41 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> Message-ID: <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> Hi, I don't think this is performance sensitive and less code is better. Use java.lang.Character.digit(ch, 16) to convert the char to an int. Roger On 12/07/2018 01:49 PM, Kasper Nielsen wrote: > Hi, > > I don't know if performance is an issue. But if it is, I think it world > make sense to use a precompute array. And replace > > private static int hexToBinary(char ch) { > if ('0' <= ch && ch <= '9') { > return ch - '0'; > } > if ('A' <= ch && ch <= 'F') { > return ch - 'A' + 10; > } > if ('a' <= ch && ch <= 'f') { > return ch - 'a' + 10; > } > return -1; > } > > with > > private static int hexToBinary(char ch) { > return ch <= 'f' ? staticPrecomputedArray[ch] : -1; > } > > where int[] staticPrecomputedArray is computed in a static initializer > block. > > /Kasper > > On Fri, 23 Nov 2018 at 14:51, Vincent Ryan > wrote: > >> Hello, >> >> Please review this proposal for a new API to conveniently generate and >> display binary data using hexadecimal string representation. >> It supports both bulk and stream operations and it can also generate the >> well-known hexdump format [1]. >> >> This latest revision addresses review comments provided earlier. >> These include adding methods to support for data supplied in a >> ByteBuffer, exposing the default formatter implementation as a public >> static and dropping the superfluous 'Hex' term from several method names. >> >> Thanks >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> API: >> >> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >> >> >> ____ >> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >> From alexey.ivanov at oracle.com Fri Dec 7 19:09:45 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 7 Dec 2018 19:09:45 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> Message-ID: Hi Andrew, Sorry for my belated reply. Yes, it's also an option? however, this solution seems to be overcomplicated to export one function or two. The calling convention of exported functions for JVM cannot be changed, they can be called from third-party software. If the function is used internally-only, its calling convention can be changed as long as all components are updated. Thank you for the pointer to another approach used to handle name decorations of __stdcall functions. It looks we have to work out a common approach to this problem. Regards, Alexey On 27/11/2018 18:49, Andrew Luo wrote: > By the way, in hotspot we are generating a .def file dynamically while keeping the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe (just by looking through the code in http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, unless this code is inactive - someone who knows this area better than me might want to comment...). Shouldn't the same approach be taken here as well? > > Thanks > Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of Ali Ince > Sent: Monday, November 19, 2018 2:08 PM > To: Alexey Ivanov ; build-dev ; core-libs > Subject: Re: [PATCH] Windows 32-bit DLL name decoration > > Hi Alexey, > > I don?t have an account on JBS as I?m not an author yet, my OCA has just been processed. Would it be possible for someone with an author status to create an issue? > > Regards, > > Ali > >> On 19 Nov 2018, at 12:12, Alexey Ivanov wrote: >> >> Hi Ali, >> >> The fix looks good to me provided it resolves your problem. >> I am not a reviewer so you'll have to get OK from reviewers, likely from build-dev and from core-libs. >> >> Have you submitted the issue in JBS? >> >> You have to sign OCA to be able to contribute to OpenJDK: >> https://openjdk.java.net/contribute/ >> and also >> https://openjdk.java.net/sponsor/ >> >> Regards, >> Alexey >> >> On 18/11/2018 12:07, Ali ?nce wrote: >>> Hi Alexey, >>> >>> Below is a new patch content that removes JNICALL modifiers from the exported functions of interest. This results in exported functions not to be name decorated and use __cdecl calling convention. >>> >>> Do you have any more suggestions, or would you please guide me on next steps? >>> >>> Thanks, >>> >>> Ali >>> >>> # HG changeset patch >>> # User Ali Ince >>> # Date 1542542415 0 >>> # Sun Nov 18 12:00:15 2018 +0000 >>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>> builds >>> >>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov 18 12:00:15 2018 +0000 >>> @@ -339,7 +339,7 @@ >>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>> +JNIEXPORT jint >>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>> jint version, jdwpTransportEnv** result) { >>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Sun Nov 18 12:00:15 2018 +0000 >>> @@ -140,7 +140,7 @@ >>> void (*free)(void *buffer); /* Call this for all deallocations */ >>> } jdwpTransportCallback; >>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>> jdwpTransportCallback *callback, >>> jint version, >>> jdwpTransportEnv** >>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>> @@ -1019,7 +1019,7 @@ >>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>> +JNIEXPORT jint >>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>> jint version, jdwpTransportEnv** env) { >>> >>> >>> >>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>> >>>> Hi Ali, >>>> >>>> It's exactly what I referred to. >>>> >>>> Yes, it does change the calling convention. >>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>> >>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>> >>>> >>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>> Hi Alexey, >>>>> >>>>> Thanks for your reply. >>>>> >>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>> >>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds. >>>>> >>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>> >>>>> Any thoughts? >>>>> >>>>> Regards, >>>>> >>>>> Ali >>>>> >>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>> >>>>>> Hi Ali, >>>>>> >>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>> >>>>>> Some build / link issues were resolved by adding / removing >>>>>> JNICALL modifier, see >>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>> .html >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>> tml >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>> Hi, >>>>>>> >>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>> >>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>> >>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>> >>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>> jdk.jdwp.agent:include \ >>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>> )) >>>>>>> >>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>> 100644 >>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>> libjdwp/export, \ >>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>> LIBS_linux := -lpthread, \ >>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ From claes.redestad at oracle.com Fri Dec 7 19:35:18 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 7 Dec 2018 20:35:18 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <8D068FE6-7852-42D7-B4CB-941DDC37F416@oracle.com> References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> <8D068FE6-7852-42D7-B4CB-941DDC37F416@oracle.com> Message-ID: <6173c114-af3d-24d6-6ddc-f8e0ab93c59b@oracle.com> This is an interesting point: can anyone explain why there are two distinct methods for LATIN1 and UTF16 equality, with corresponding intrinsics? Aleksey? Tobias? Testing with Arrays.equals then performance profile is quite different due vectorization (often better, sometimes worse), but this is performance-neutral for a variety of latin1 and utf16 inputs: if (coder() == aString.coder()) return StringLatin1.equals(value, aString.value); Is there some UTF16 input where StringLatin1.equals != StringUTF16.equals that forbids the above? Performance-wise it seems neutral, and all tests seem to pass with the above (obviously need to run more tests...). Thanks! /Claes On 2018-12-07 04:53, James Laskey wrote: > Or simply; > > if (anObject instanceof String) { > String aString = (String)anObject; > if (coder() == aString.coder()) > return Arrays.equals(value, aString.value); > } > } > > Sent from my iPhone From forax at univ-mlv.fr Fri Dec 7 19:49:36 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 7 Dec 2018 20:49:36 +0100 (CET) Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> Message-ID: <1166463316.44995.1544212176198.JavaMail.zimbra@u-pem.fr> :) yes, you're right. R?mi ----- Mail original ----- > De: "Andrew Dinn" > ?: "Remi Forax" , "Stuart Marks" > Cc: "core-libs-dev" > Envoy?: Vendredi 7 D?cembre 2018 14:55:44 > Objet: Re: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses > On 07/12/2018 10:31, Remi Forax wrote: >> Hi Stuart, >> what about adding "tries to" to the @implSpec section >> >> As much as is reasonably practical, the {@code hashCode} method defined >> by class {@code Object} tries to return distinct integers for distinct objects. > > An algorithm can try? I suspect not until we reach the singularity so > beloved of sci-fi hacks (I'm not holding my breath). So, in the > interests of precisely nailing the colour of this bike-shed and modulo > any unforeseen developments in Artificial Intelligence, I'd suggest this > psychologism-free alternative: > > As far as is reasonably practical, the {@code hashCode} method defined > by class {@code Object} returns distinct integers for distinct objects. > > 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 From vincent.x.ryan at oracle.com Fri Dec 7 19:51:25 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 7 Dec 2018 19:51:25 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> Message-ID: Even shorter. I?ll add that instead. Thanks. > On 7 Dec 2018, at 19:04, Roger Riggs wrote: > > Hi, > > I don't think this is performance sensitive and less code is better. > > Use java.lang.Character.digit(ch, 16) to convert the char to an int. > > Roger > > On 12/07/2018 01:49 PM, Kasper Nielsen wrote: >> Hi, >> >> I don't know if performance is an issue. But if it is, I think it world >> make sense to use a precompute array. And replace >> >> private static int hexToBinary(char ch) { >> if ('0' <= ch && ch <= '9') { >> return ch - '0'; >> } >> if ('A' <= ch && ch <= 'F') { >> return ch - 'A' + 10; >> } >> if ('a' <= ch && ch <= 'f') { >> return ch - 'a' + 10; >> } >> return -1; >> } >> >> with >> >> private static int hexToBinary(char ch) { >> return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >> } >> >> where int[] staticPrecomputedArray is computed in a static initializer >> block. >> >> /Kasper >> >> On Fri, 23 Nov 2018 at 14:51, Vincent Ryan >> wrote: >> >>> Hello, >>> >>> Please review this proposal for a new API to conveniently generate and >>> display binary data using hexadecimal string representation. >>> It supports both bulk and stream operations and it can also generate the >>> well-known hexdump format [1]. >>> >>> This latest revision addresses review comments provided earlier. >>> These include adding methods to support for data supplied in a >>> ByteBuffer, exposing the default formatter implementation as a public >>> static and dropping the superfluous 'Hex' term from several method names. >>> >>> Thanks >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>> API: >>> >>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>> >>> >>> ____ >>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >>> > From Roger.Riggs at oracle.com Fri Dec 7 20:01:32 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 15:01:32 -0500 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <6173c114-af3d-24d6-6ddc-f8e0ab93c59b@oracle.com> References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> <8D068FE6-7852-42D7-B4CB-941DDC37F416@oracle.com> <6173c114-af3d-24d6-6ddc-f8e0ab93c59b@oracle.com> Message-ID: <076b45fe-0cee-6e82-2211-27697a471789@oracle.com> Hi Claes, Early in the design there was a question about whether the coder was in the array or the String. That probably translated into following the general pattern that the UTF16 coding was nearly identical and parallel to Latin1 with minimal differences for the size of the data. $.02, Roger On 12/07/2018 02:35 PM, Claes Redestad wrote: > This is an interesting point: can anyone explain why there are two > distinct methods for LATIN1 and UTF16 equality, with corresponding > intrinsics? Aleksey? Tobias? > > Testing with Arrays.equals then performance profile is > quite different due vectorization (often better, sometimes worse), > but this is performance-neutral for a variety of latin1 and utf16 inputs: > > if (coder() == aString.coder()) > ??? return StringLatin1.equals(value, aString.value); > > Is there some UTF16 input where StringLatin1.equals != > StringUTF16.equals that forbids the above? Performance-wise it seems > neutral, and all tests seem to pass with the above (obviously need to > run more tests...). > > Thanks! > > /Claes > > On 2018-12-07 04:53, James Laskey wrote: >> Or simply; >> >> if (anObject instanceof String) { >> ??????????? String aString = (String)anObject; >> ??????????? if (coder() == aString.coder()) >> ???????????????? return Arrays.equals(value, aString.value); >> ??????????? } >> ??????? } >> >> Sent from my iPhone From Roger.Riggs at oracle.com Fri Dec 7 20:20:32 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 15:20:32 -0500 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Message-ID: <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> Hi, It is a nice feature that charsets are selected at build time using the stdcs-xxx files. This change breaks that pattern and embeds os specific information in more than one place. That does not seem like an improvement.? Is there any alternative? Thanks, Roger On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote: > Hello. > (I'm sorry, I made a mistake, I forgot to change Subject) > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214533 > Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ > > IBM29626C charset is required for AIX default charset. > Java cannot start because of java/lang/ExceptionInInitializerError on > AIX ja_JP locale. > > To build team, > I'd like to change following charsetmapping tool. > * make/jdk/src/classes/build/tools/charsetmapping/Main.java > * make/jdk/src/classes/build/tools/charsetmapping/SPI.java > * make/jdk/src/classes/build/tools/charsetmapping/SRC.java > > build.tools.charsetmapping,Main supports "os" tag, but it seems it's > not used. > Currently, "os" supports "windows" or "unix". > I extended "os" tag's feature. > If "os aix" is there, this charset is only added into AIX platform. > (I assume "type template" should be used) > "aix" comes from "stdcs-aix" file name. > ====== > charset x-IBM29626C IBM29626C > ??? package sun.nio.cs.ext > ??? type??? template > ??? os????? aix?????? <===== > ??? alias?? cp29626C?????????????? # JDK historical > ??? alias?? ibm29626C > ??? alias?? ibm-29626C > ??? alias?? 29626C > ??? alias?? ibm-eucjp > ====== > > If cs.os is null, > this charset is stored into gensrc directory. > Charset name is added into StandardCharsets.java or ExtendedCharsets.java > If cs.os is "false", > this charset is NOT stored into gensrc directory. > Charset name is NOT added into StandardCharsets.java or > ExtendedCharsets.java > > "os" tag supports multiple entries by using ",", like "aix,linux" > Then we can store new charset into > src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory > > > $ locale charmap > IBM-eucJP > $ jshell > |? JShell????? --????? 12-internal > |??????????????????? : /help intro > > jshell> var cs = java.nio.charset.Charset.defaultCharset() > cs ==> x-IBM29626C > > jshell> cs.getClass().getName() > $2 ==> "sun.nio.cs.IBM29626C" > > jshell> System.out.println(String.join("\n", cs.aliases())) > cp29626C > ibm-29626C > ibm-eucjp > ibm29626C > 29626C > > jshell> /exit > | > $ > > I tested Linux and Windows build. > ====== > $ grep 29626 build.log > IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template? false > > $ find support/gensrc/? | grep 29626 > > $ find support/gensrc/? | grep Charsets > support/gensrc/java.base/sun/nio/cs/StandardCharsets.java > support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java > > $ find support/gensrc/? | grep Charsets | xargs grep 29626 > > $ > ====== > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >> On 2018-11-28 10:36, Alan Bateman wrote: >>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>> I'm quite unsatisfied with the current handling of character sets >>>> in the build in general. :-( I'd really like to modernize it. I >>>> have a, slightly fuzzy, laundry list of things I want to fix from a >>>> build perspective, but I'm not sure of what "external" requirements >>>> are coming from AIX and the general core-libs agenda regarding >>>> character sets in general. >>>> >>>> I think there is a good opportunity to solve many problems at the >>>> same time here, as long as everyone agrees on what is the preferred >>>> outcome. >>> The support in the build to configure the charsets to include in >>> java.base on each platform has been working well. Charsets that >>> aren't in java.base go into the jdk.charsets service provider module >>> and that has been working well too. From the result point of view, >>> perhaps, but definitely not from the build perspective. ;-) But yes, >>> I understand this is functionality that should be kept. >>> One thing that we lack is some way to add charsets for specific >>> platforms and this comes up with the IBM patches where they are >>> looking to adding several additional IBM charsets. One starting >>> point that we've touched on in several threads here is dropping the >>> EBCDIC charsets from the main stream builds. Going there will need >>> build support. >> So build support for trivially adding specific charsets to specific >> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >> then? >> >> Can you expand on the issue of dropping ebcdic? What's the problem >> that needs build support? >> >> /Magnus >>> >>> >>> -Alan > From alexey.ivanov at oracle.com Fri Dec 7 20:24:29 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 7 Dec 2018 20:24:29 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> Message-ID: <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> Hi Ali, On 06/12/2018 22:49, Ali ?nce wrote: > Hi Magnus, Alexey, > > I believe we won?t be able to get further opinions from > serviceability-dev. Unfortunately, no one has replied as of now. Have you found any issues with jdwpTransport_OnLoad after removing JNICALL? > Andrew Luo suggested using a similar mechanism as is used for jvm.dll > by using symbol name files mapped by platform (files are under > make/hotspot/symbols and interestingly windows is almost the only > platform for which a symbol file doesn?t exist). Andrew says the .def files are auto-generated for Windows. There's a set of shared functions. JVM cannot change the calling convention, jvm.dll is the public interface to JVM. > Another issue, again opened against AdoptOpenJDK 32-bit builds is > somehow related with the same problem - but this time it is jimage.dll > depending on zip.dll expecting the ZIP_InflateFully function to be > decorated with JNICALL - whereas it was removed earlier from the > implementation and the runtime image just fails with access violation > just because jimage source code still declared it with JNICALL > (https://github.com/AdoptOpenJDK/openjdk-build/issues/763). The usage of ZIP_InflateFully from zip.dll by jimage.dll was overlooked during work on https://bugs.openjdk.java.net/browse/JDK-8201226. I can take care of it. (I could not build 32 bit Windows. It seem to have overcome the problem by adding --disable-warnings-as-errors option to configure.) However, the report says the resulting image crashes in 64 bit windows too which shouldn't be affected by JNICALL mismatch. > I?ve also searched for GetProcAddress calls across the source code - > and I think it?s important to work on the consistency of JNICALL > usages across the whole source code. There are many places where libraries are loaded dynamically or a function may be unavailable on older versions of the platform. Have you identified any other place where functions from JDK DLLs are looked up by names? > Another noteworthy thing I?ve noticed is there are still JNICALL > modifiers for example in > https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49?- > which I guess will also be reported as broken since these functions > are again name decorated. This is a JNI method. It should use JNICALL modifier. If it wasn't found, the class sun.security.pkcs11.Secmod would fail to load. I guess JVM handles name mangling somehow for native method implementation. Such functions were never explicitly exported using mapfiles or /export options on Windows, at least in the client area. For Linux and Solaris, adding or removing a native method required editing mapfiles. > If we?re still determined to remove JNICALL, what about just removing > __stdcall from JNICALL declaration at > https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31???Wouldn?t > that be a more consistent move? We can't do that. Implementation of Java native methods must use __stdcall calling convention. > > Regards, > > Ali > >> On 22 Nov 2018, at 17:29, Magnus Ihse Bursie >> > > wrote: >> >> I think we are in complete agreement. What's missing is some expert >> opinion from serviceability-dev if there is any problem with changing >> the signature. I'd preferably have that. >> >> If no one knows, I'd say, change it, and see if we still pass the >> relevant tests, and if so, ship it. >> >> /Magnus >> >> 22 nov. 2018 kl. 18:04 skrev Alexey Ivanov > >: >> >>> >>> On 21/11/2018 12:16, Magnus Ihse Bursie wrote: >>>> >>>> On 2018-11-20 16:49, Alexey Ivanov wrote: >>>> >>>>> Hi Ali, Magnus, >>>>> >>>>> I absolutely agree this change has to be reviewed by someone from >>>>> serviceability. >>>>> >>>>> There are several options: >>>>> >>>>> 1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html >>>>> so it partially reverts the changes from >>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 >>>>> >>>>> 2. Remove JNICALL (__stdcall) modifier, eventually changing the >>>>> calling convention to __cdecl. >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023969.html >>>>> >>>>> 3. Use inline /export option via #pragma: >>>>> #pragma comment(linker, "/export:jdwpTransport_OnLoad= >>>>> _jdwpTransport_OnLoad at 16") >>>>> as referenced in >>>>> https://docs.microsoft.com/en-ie/cpp/cpp/dllexport-dllimport?view=vs-2017 >>>>> https://docs.microsoft.com/en-ie/cpp/build/reference/exports?view=vs-2017 >>>>> >>>>> The third options still needs to be tested to make sure it does >>>>> not break other platforms builds. >>>> I'm not fond of either solution 1 or 3. I really think the >>>> signature should be made correctly at the point of definition in >>>> the source code. >>> >>> That is why I proposed removing JNICALL (__stdcall) from the >>> function declaration as we had done for libzip, libjimage [1] and >>> mlib_image [2]. >>> >>> Microsoft recommends using __stdcall for DLLs, at the same time it >>> decorates the function name making it harder to export it by its >>> plain name. >>> >>> >>> By removing JNICALL / __stdcall, we make the function use __cdecl >>> calling convention. The difference between them is that with >>> __stdcall the callee cleans the stack whereas with __cdecl the >>> caller cleans the stack. >>> >>> It shouldn't be a problem as long as all function declarations use >>> the same calling convention, which, I believe, is the case here. >>> >>>> We've spent some considerable effort of getting rid of the /export >>>> flags for Windows (and map files for unix), and I don't want to see >>>> them creep back in. Note that option 3 is just option 1 in >>>> disguise. The only single good thing about it is that it allows you >>>> to put the compiler option next to the signature declaration in the >>>> source code. >>> >>> At least in this case, the option will be near the function body >>> definition. It will be easier to update it if the signature changes. >>> >>> If we are to use __stdcall, it seems to be the only way to export >>> the undecorated name. >>> >>>> The same goes for def files, as suggested by Ali. It's just yet >>>> another version of option 1 in disguise/map files. >>> >>> If option 2 is rejected, I'm for using option 3. If option 3 cannot >>> be used too, I'm for option 1. >>> I think we should not fall back to def files in any case. And >>> Makefile will have to include the reference to the def file, so it's >>> even worse than option 1. >>> >>> >>> Regards, >>> Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8201226 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8202476 >>>> >>>> /Magnus >>>> >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 19/11/2018 12:19, Magnus Ihse Bursie wrote: >>>>>> Hi Ali, >>>>>> >>>>>> From a build perspective this change looks OK. I'm not aware of >>>>>> the finer details on the OnLoad mechanism, like what calling >>>>>> convention is to be used. So maybe this is a no-go from that view. >>>>>> >>>>>> I'm cc:ing servicability so they can have a look at it. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> On 2018-11-18 13:07, Ali ?nce wrote: >>>>>>> Hi Alexey, >>>>>>> >>>>>>> Below is a new patch content that removes JNICALL modifiers from the exported functions of interest. This results in exported functions not to be name decorated and use __cdecl calling convention. >>>>>>> >>>>>>> Do you have any more suggestions, or would you please guide me on next steps? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> # HG changeset patch >>>>>>> # User Ali Ince >>>>>>> # Date 1542542415 0 >>>>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows builds >>>>>>> >>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>> @@ -339,7 +339,7 @@ >>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>> } >>>>>>> >>>>>>> -JNIEXPORT jint JNICALL >>>>>>> +JNIEXPORT jint >>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>> jint version, jdwpTransportEnv** result) >>>>>>> { >>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Tue Aug 14 14:28:23 2018 +0200 >>>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Sun Nov 18 12:00:15 2018 +0000 >>>>>>> @@ -140,7 +140,7 @@ >>>>>>> void (*free)(void *buffer); /* Call this for all deallocations */ >>>>>>> } jdwpTransportCallback; >>>>>>> >>>>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>> jdwpTransportCallback *callback, >>>>>>> jint version, >>>>>>> jdwpTransportEnv** env); >>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>> } >>>>>>> >>>>>>> -JNIEXPORT jint JNICALL >>>>>>> +JNIEXPORT jint >>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>> jint version, jdwpTransportEnv** env) >>>>>>> { >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>>> >>>>>>>> Hi Ali, >>>>>>>> >>>>>>>> It's exactly what I referred to. >>>>>>>> >>>>>>>> Yes, it does change the calling convention. >>>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>>> >>>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>>> >>>>>>>> >>>>>>>> Mapfiles and export options have been removed byhttps://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>> Hi Alexey, >>>>>>>>> >>>>>>>>> Thanks for your reply. >>>>>>>>> >>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>>> >>>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>> >>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as inhttps://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ali >>>>>>>>> >>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>>> >>>>>>>>>> Hi Ali, >>>>>>>>>> >>>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>>> >>>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexey >>>>>>>>>> >>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>>> >>>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>> >>>>>>>>>>> Below is the proposed patch, which can also be browsed athttps://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>>>>> >>>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Ali >>>>>>>>>>> >>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>> )) >>>>>>>>>>> >>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>> >>>>> >>>> >>> > From merkel05 at gmail.com Fri Dec 7 23:53:05 2018 From: merkel05 at gmail.com (Sergey) Date: Sat, 8 Dec 2018 00:53:05 +0100 Subject: Type variable information is not always maintained for anonymous classes Message-ID: Hi everyone, Recently I've stumbled upon this bug https://bugs.openjdk.java.net/browse/JDK-8213465 which is named the same way as in the header of an email. I've done a little bit of investigation and keen to fix it. Though I'm afraid that most likely fix wouldn't be just a one-liner. Thus I want to ask for a little bit of a guidance and make sure, that I do not cross anyone else. With that being said, if ticket isn't in progress and no one minds I want to make an attempt on it. Thanks and regards, Sergei From claes.redestad at oracle.com Sat Dec 8 00:11:03 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 8 Dec 2018 01:11:03 +0100 Subject: RFR: 8215017: Improve String::equals warmup characteristics Message-ID: Hi, following up from discussions during review of JDK-8214971[1], I examined the startup and peak performance of a few different variant of writing String::equals. Webrev: http://cr.openjdk.java.net/~redestad/8215017/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215017 - folding coder() == aString.coder() into sameCoder(aString) helps interpreter without adversely affecting higher optimization levels - Jim's proposal to use Arrays.equals is _interesting_: it improves peak performance on some inputs but regress it on others. I'll defer that to a future RFE as it needs a more thorough examination. - what we can do is simplify to only use StringLatin1.equals. If I'm not completely mistaken these are all semantically neutral (and StringUTF16.equals effectively redundant). If I'm completely wrong here I'll welcome the learning opportunity. :-) This removes a branch and two method calls, and for UTF16 Strings we'll use a simpler algorithm early, which turns out to be beneficial during interpreter and C1 level. I added a simple microbenchmark to explore this, results show 1.2-2.5x improvements in interpreter performance, while remaining perfectly neutral results for optimized code on this simple micro[2]. This could be extended to clean up and move StringLatin1.equals back into String and remove StringUTF16, but we'd also need to rearrange the intrinsics on the VM side. Let me know what you think. Thanks! /Claes [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057162.html [2] ========== Baseline ================= -Xint Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 968.640 ? 1.337 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 2082.007 ? 5.303 ns/op StringEquals.equalsDifferent avgt 4 583.166 ? 29.461 ns/op StringEquals.equalsDifferentCoders avgt 4 422.993 ? 1.291 ns/op StringEquals.equalsEqual avgt 4 988.671 ? 1.492 ns/op StringEquals.equalsEqualsUTF16 avgt 4 2103.060 ? 5.705 ns/op -XX:+CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 23.896 ? 0.089 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 23.935 ? 0.562 ns/op StringEquals.equalsDifferent avgt 4 15.086 ? 0.044 ns/op StringEquals.equalsDifferentCoders avgt 4 12.572 ? 0.008 ns/op StringEquals.equalsEqual avgt 4 25.143 ? 0.025 ns/op StringEquals.equalsEqualsUTF16 avgt 4 25.148 ? 0.021 ns/op -XX:-CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 24.539 ? 0.127 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 22.638 ? 0.047 ns/op StringEquals.equalsDifferent avgt 4 13.930 ? 0.835 ns/op StringEquals.equalsDifferentCoders avgt 4 13.836 ? 0.025 ns/op StringEquals.equalsEqual avgt 4 26.420 ? 0.020 ns/op StringEquals.equalsEqualsUTF16 avgt 4 23.889 ? 0.037 ns/op ========== Fix ====================== -Xint Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 811.859 ? 8.663 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 802.784 ? 352.884 ns/op StringEquals.equalsDifferent avgt 4 431.837 ? 1.884 ns/op StringEquals.equalsDifferentCoders avgt 4 358.244 ? 1.208 ns/op StringEquals.equalsEqual avgt 4 832.056 ? 3.541 ns/op StringEquals.equalsEqualsUTF16 avgt 4 832.434 ? 3.516 ns/op -XX:+CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 23.906 ? 0.151 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 23.905 ? 0.123 ns/op StringEquals.equalsDifferent avgt 4 15.088 ? 0.023 ns/op StringEquals.equalsDifferentCoders avgt 4 12.575 ? 0.030 ns/op StringEquals.equalsEqual avgt 4 25.149 ? 0.059 ns/op StringEquals.equalsEqualsUTF16 avgt 4 25.149 ? 0.033 ns/op -XX:-CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 24.521 ? 0.050 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 22.639 ? 0.035 ns/op StringEquals.equalsDifferent avgt 4 13.831 ? 0.020 ns/op StringEquals.equalsDifferentCoders avgt 4 13.884 ? 0.345 ns/op StringEquals.equalsEqual avgt 4 26.395 ? 0.066 ns/op StringEquals.equalsEqualsUTF16 avgt 4 23.904 ? 0.112 ns/op From vicente.romero at oracle.com Sat Dec 8 00:12:33 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 7 Dec 2018 19:12:33 -0500 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: References: Message-ID: <9ea3dce9-ae45-0645-1b40-b842481db6af@oracle.com> Hi Sergey, Thanks for your interest in the bug, yes if you feel like, please feel free to give it a try. Vicente On 12/7/18 6:53 PM, Sergey wrote: > Hi everyone, > > Recently I've stumbled upon this bug > https://bugs.openjdk.java.net/browse/JDK-8213465 > which is named the same way as in the header of an email. I've done a > little bit of > investigation and keen to fix it. Though I'm afraid that most likely fix > wouldn't be just > a one-liner. Thus I want to ask for a little bit of a guidance and make > sure, that I do not cross > anyone else. With that being said, if ticket isn't in progress and no one > minds I want to make > an attempt on it. > > Thanks and regards, > Sergei From cushon at google.com Sat Dec 8 01:02:19 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 7 Dec 2018 17:02:19 -0800 Subject: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: I rebased the webrev, and made some additional improvements and simplifications: http://cr.openjdk.java.net/~cushon/8198526/webrev.01/ There was some more discussion of the underlying spec issue here: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-November/012649.html https://bugs.openjdk.java.net/browse/JDK-8215035 On Thu, Feb 22, 2018 at 10:48 AM Liam Miller-Cushon wrote: > (replying to edit the subject) > > On Wed, Feb 21, 2018 at 2:18 PM, Liam Miller-Cushon > wrote: > >> Hello, >> >> Please review this fix to the handling of static nested classes >> in getAnnotatedOwnerType. >> >> webrev: http://cr.openjdk.java.net/~cushon/8198526/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8198526 >> > > From merkel05 at gmail.com Sat Dec 8 01:06:38 2018 From: merkel05 at gmail.com (Sergey) Date: Sat, 8 Dec 2018 02:06:38 +0100 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: <9ea3dce9-ae45-0645-1b40-b842481db6af@oracle.com> References: <9ea3dce9-ae45-0645-1b40-b842481db6af@oracle.com> Message-ID: Hi Vicente, Thanks for your quick reply! Let me briefly summarize what I've discovered and maybe you'll give me some thoughts on how you think I should approach the problem. During the execution inside the lambda body, in order to be able to fetch class' generic type parameters, lookup inside the ClassScope [1] should happen. That lookup is done on the anonymous class first, thus it is a "class scope". In both cases ClassScope is obtained and during the lookup [2] call is delegated to the enclosing scope. In case of anonymous class being enclosed by a method (a main method in the attached test case) lookup works perfectly fine - it just takes the TypeVariable from within the method's scope. In case of lambda that's a bit trickier as there's a synthetic method being generated which in it's turn enclosed by the same class as the main method in the attached test case. I'm not sure if that is intended behavior. In that case the lookup is being delegated to the enclosing class, which shouldn't happen. Lookup in my opinion should happen within the lambda's enclosing method. Amusing part is that if enclosing class has the same type variable name lookup will succeed: public class Bug8213465 { static abstract class A {} public static void main(String[] args) { Runnable r2 = () -> printIt(new A(){}.getClass()); // that will suceed r2.run(); }} I think special treatment of synthetic methods is necessary here. At least for the case above Type Variable lookup should be delegated to the main method instead of the enclosing class. So if you have any suggestions on how should I try to approach the problem, please let me know. Any thoughts/suggestions/advise would be much appreciated! [1] http://hg.openjdk.java.net/jdk/sandbox/file/2446962c555c/src/java.base/share/classes/sun/reflect/generics/scope/ClassScope.java#l50 [2] http://hg.openjdk.java.net/jdk/sandbox/file/2446962c555c/src/java.base/share/classes/sun/reflect/generics/scope/AbstractScope.java#l95 Regards, Sergei On Sat, 8 Dec 2018 at 01:12, Vicente Romero wrote: > Hi Sergey, > > Thanks for your interest in the bug, yes if you feel like, please feel > free to give it a try. > > Vicente > > On 12/7/18 6:53 PM, Sergey wrote: > > Hi everyone, > > > > Recently I've stumbled upon this bug > > https://bugs.openjdk.java.net/browse/JDK-8213465 > > which is named the same way as in the header of an email. I've done a > > little bit of > > investigation and keen to fix it. Though I'm afraid that most likely fix > > wouldn't be just > > a one-liner. Thus I want to ask for a little bit of a guidance and make > > sure, that I do not cross > > anyone else. With that being said, if ticket isn't in progress and no one > > minds I want to make > > an attempt on it. > > > > Thanks and regards, > > Sergei > > From vincent.x.ryan at oracle.com Sat Dec 8 01:18:16 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 8 Dec 2018 01:18:16 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> Message-ID: <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> Here?s the latest version that addresses all the current open issues: webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ javadoc: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 > On 7 Dec 2018, at 19:51, Vincent Ryan wrote: > > Even shorter. I?ll add that instead. > Thanks. > >> On 7 Dec 2018, at 19:04, Roger Riggs wrote: >> >> Hi, >> >> I don't think this is performance sensitive and less code is better. >> >> Use java.lang.Character.digit(ch, 16) to convert the char to an int. >> >> Roger >> >> On 12/07/2018 01:49 PM, Kasper Nielsen wrote: >>> Hi, >>> >>> I don't know if performance is an issue. But if it is, I think it world >>> make sense to use a precompute array. And replace >>> >>> private static int hexToBinary(char ch) { >>> if ('0' <= ch && ch <= '9') { >>> return ch - '0'; >>> } >>> if ('A' <= ch && ch <= 'F') { >>> return ch - 'A' + 10; >>> } >>> if ('a' <= ch && ch <= 'f') { >>> return ch - 'a' + 10; >>> } >>> return -1; >>> } >>> >>> with >>> >>> private static int hexToBinary(char ch) { >>> return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >>> } >>> >>> where int[] staticPrecomputedArray is computed in a static initializer >>> block. >>> >>> /Kasper >>> >>> On Fri, 23 Nov 2018 at 14:51, Vincent Ryan >>> wrote: >>> >>>> Hello, >>>> >>>> Please review this proposal for a new API to conveniently generate and >>>> display binary data using hexadecimal string representation. >>>> It supports both bulk and stream operations and it can also generate the >>>> well-known hexdump format [1]. >>>> >>>> This latest revision addresses review comments provided earlier. >>>> These include adding methods to support for data supplied in a >>>> ByteBuffer, exposing the default formatter implementation as a public >>>> static and dropping the superfluous 'Hex' term from several method names. >>>> >>>> Thanks >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>>> API: >>>> >>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>>> >>>> >>>> ____ >>>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >>>> >> > From andrewluotechnologies at outlook.com Sat Dec 8 02:18:12 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sat, 8 Dec 2018 02:18:12 +0000 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: References: <5C09DB64.8020608@oracle.com> <3186d105-d977-4b11-4675-38f6f5357739@oracle.com> Message-ID: Not a reviewer - looks good anyways - however, I would if some of those constants be refactored to fewer locations? For example, I see many copies of: @SupportedSourceVersion(SourceVersion.RELEASE_13) Perhaps if you declare SourceVersion as: RELEASE_12, RELEASE_13, CURRENT_RELEASE = RELEASE_13; Then you could use: @SupportedSourceVersion(SourceVersion.CURRENT_RELEASE) Thanks, -Andrew -----Original Message----- From: core-libs-dev On Behalf Of joe darcy Sent: Friday, December 7, 2018 9:52 AM To: Alan Bateman ; Core-Libs-Dev Subject: Re: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 Hi Alan, On 12/7/2018 12:16 AM, Alan Bateman wrote: > On 07/12/2018 02:31, Joseph D. Darcy wrote: >> Hello, >> >> With the start of JDK 13 around the corner, please review the core >> libs portions of: >> >> ??? JDK-8205626: Start of release updates for JDK 13 >> ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 >> >> [snip] > Looks okay (and the same as what we reviewed on build-dev yesterday?). > Yes, same changes as on build-dev (other than the update of several more TEST.ROOT files to require jtreg 4.2 b13 rather than b12.) I wanted to have a bit more of the testing complete before sending the core libs portion out for the review. Thanks, -Joe From david.holmes at oracle.com Sat Dec 8 11:03:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 8 Dec 2018 21:03:07 +1000 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: References: Message-ID: Hi Sergey, Just FYI we're in the process of moving away from using anonymous classes for lambda's to using an extended Lookup.defineClass API - see: https://bugs.openjdk.java.net/browse/JDK-8171335 this is being done under Project Valhalla, with current work in the nestmates branch. We need to see how this example work in that case. Cheers, David On 8/12/2018 9:53 am, Sergey wrote: > Hi everyone, > > Recently I've stumbled upon this bug > https://bugs.openjdk.java.net/browse/JDK-8213465 > which is named the same way as in the header of an email. I've done a > little bit of > investigation and keen to fix it. Though I'm afraid that most likely fix > wouldn't be just > a one-liner. Thus I want to ask for a little bit of a guidance and make > sure, that I do not cross > anyone else. With that being said, if ticket isn't in progress and no one > minds I want to make > an attempt on it. > > Thanks and regards, > Sergei > From martinrb at google.com Sat Dec 8 17:55:23 2018 From: martinrb at google.com (Martin Buchholz) Date: Sat, 8 Dec 2018 09:55:23 -0800 Subject: RFR: 8215048: Some classloader typos Message-ID: This is all I got for jdk12: https://cr.openjdk.java.net/~martin/webrevs/jdk/classloader-typos/ https://bugs.openjdk.java.net/browse/JDK-8215048 From martinrb at google.com Sat Dec 8 18:07:38 2018 From: martinrb at google.com (Martin Buchholz) Date: Sat, 8 Dec 2018 10:07:38 -0800 Subject: RFR: jsr166 integration 2018-12 Message-ID: Last jdk12 jsr166 integration. https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8214559: Use {@systemProperty} for definitions of system properties https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/systemProperty/index.html https://bugs.openjdk.java.net/browse/JDK-8214559 8214427: probable bug in logic of ConcurrentHashMap.addCount() https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/addCount/index.html https://bugs.openjdk.java.net/browse/JDK-8214427 Still in limbo: 8203662: remove increment of modCount from ArrayList and Vector replaceAll() https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html https://bugs.openjdk.java.net/browse/JDK-8203662 8214457: Miscellaneous changes imported from jsr166 CVS 2018-12 https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html https://bugs.openjdk.java.net/browse/JDK-8214457 From merkel05 at gmail.com Sat Dec 8 20:04:30 2018 From: merkel05 at gmail.com (Sergey) Date: Sat, 8 Dec 2018 21:04:30 +0100 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: References: Message-ID: Hi David, Thanks for pointing that out! >We need to see how this example work in that case. I guess anyone involved could have straight away two test cases: one from the bug itself and another from the observation above. In any case. looking forward for that being fixed. I would also be happy to be able to help with anything if needed. Thanks and regards, Sergei On Sat, 8 Dec 2018 at 12:03, David Holmes wrote: > Hi Sergey, > > Just FYI we're in the process of moving away from using anonymous > classes for lambda's to using an extended Lookup.defineClass API - see: > > https://bugs.openjdk.java.net/browse/JDK-8171335 > > this is being done under Project Valhalla, with current work in the > nestmates branch. > > We need to see how this example work in that case. > > Cheers, > David > > On 8/12/2018 9:53 am, Sergey wrote: > > Hi everyone, > > > > Recently I've stumbled upon this bug > > https://bugs.openjdk.java.net/browse/JDK-8213465 > > which is named the same way as in the header of an email. I've done a > > little bit of > > investigation and keen to fix it. Though I'm afraid that most likely fix > > wouldn't be just > > a one-liner. Thus I want to ask for a little bit of a guidance and make > > sure, that I do not cross > > anyone else. With that being said, if ticket isn't in progress and no one > > minds I want to make > > an attempt on it. > > > > Thanks and regards, > > Sergei > > > From philip.race at oracle.com Sun Dec 9 07:59:12 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 08 Dec 2018 23:59:12 -0800 Subject: RFR: 8212703: Remove sun.java2d.fontpath property from java launcher code In-Reply-To: <7b4d4735-eae2-5a32-d6ed-5c140d50ddf4@oracle.com> References: <270a99cf-2f95-9730-5c92-b947abd2d99c@oracle.com> <5fcbf33a-004d-8156-d917-f4652e871d4a@oracle.com> <7b4d4735-eae2-5a32-d6ed-5c140d50ddf4@oracle.com> Message-ID: <5C0CCB50.4050603@oracle.com> Here is an update with a Java-only test, using ProcessBuilder. http://cr.openjdk.java.net/~prr/8212703.1/index.html -phil. On 12/1/18, 9:27 AM, Alan Bateman wrote: > On 30/11/2018 23:11, Roger Riggs wrote: >> Hi Phil, >> >> That looks fine. >> >> Too bad it introduces a new shell test, we're trying to get rid of them. >> The other alternative would have the test program needed to set the >> environment >> and launch a java program. >> > The implementation look good to me too and I agree with Roger that we > shouldn't be introducing a shell test for this. In this case, it looks > like you just need a /othervm test that checks for the env variable > and property. > > -Alan From Alan.Bateman at oracle.com Sun Dec 9 07:59:52 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 9 Dec 2018 07:59:52 +0000 Subject: RFR: 8215048: Some classloader typos In-Reply-To: References: Message-ID: <02c52ba6-2d35-473d-8656-217d18c518fc@oracle.com> On 08/12/2018 17:55, Martin Buchholz wrote: > This is all I got for jdk12: > https://cr.openjdk.java.net/~martin/webrevs/jdk/classloader-typos/ > > https://bugs.openjdk.java.net/browse/JDK-8215048 > Looks okay. From Rob.Griffin at quest.com Sun Dec 9 22:44:29 2018 From: Rob.Griffin at quest.com (Rob Griffin (rgriffin)) Date: Sun, 9 Dec 2018 22:44:29 +0000 Subject: Add convenience collect methods to the Stream interface Message-ID: Hi, I have raised an enhancement request (Incident Report 913453) about adding some convenience methods to the Stream interface that collect the stream and Pallavi Sonal asked me to start a thread here about that. More than 50% of our Stream collect calls use Collectors.toList() or Collectors.toSet() as arguments so I think it would be very handy if the Stream interface had default collectToList and collectToList and collectToMap methods. The advantages are: it would be easier to use code completion in IDEs. There are lot of classes starting with Collect so finding the Collectors class is a bit of a pain. one less method call in what is usually a long chain of calls. Regards, Rob Griffin Software Analyst, Spotlight on SQL Server Quest | R&D rob.griffin at quest.com From james at lightbend.com Mon Dec 10 00:03:02 2018 From: james at lightbend.com (James Roper) Date: Mon, 10 Dec 2018 11:03:02 +1100 Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: Message-ID: Just wanted to put my hand up to say that I have had the same experience, more than 50% of the time that I've used JDK8 streams I've used .collect(Collectors.toList()). But, as a counter point, let me speculate that many or most uses of streams fall into two broad use cases. One is for actual stream processing, where you aren't necessarily dealing with a stream that is materialized in memory, where you may want the power of parallel processing, where you certainly do want multiple stages of the stream processing chained together rather than having each stage materialize a new collection in memory, and this is what the stream API was created for. In this case, collecting to a list is common but not that common, perhaps not common enough to warrant a convenience method on Stream. The other broad use case category is to work with Lists and Sets in a functional programming style. In this case, you simply want to map, filter, flatMap etc every element in your list/set, and this is where collecting to a list and set is almost always the terminal operation for a stream. Although you can use the stream API to do this, I speculate that it wasn't primarily designed for this, and I think if the JDK wanted to provide first class support for doing this, there would be better ways to go about it - for example, by placing map/filter/flatMap methods directly on the Collection interfaces and returning the collections directly, rather than having to convert to a stream and back. Going through a stream still has its advantages (eg, it uses less memory since you don't need to materialize a new collection between each stage of the processing), but lacks the convenience that other collection APIs that offer true functional programming for Java have (eg, vavr, formerly javaslang). And, if the JDK was to start adding features for functional programming like that to its collection API, then it may be worth considering other features, such as persistent collections, that is, collections where operations such as add/remove aren't destructive, ie, immutable collections that support efficient (constant time) append/prepend operations that return a copy of the list. My point is that if the JDK does start to consider adding functional programming to its collection APIs, a holistic approach should be taken to work out what things would look like long term, even if not all of those features are added immediately (or ever). On Mon, 10 Dec 2018 at 10:04, Rob Griffin (rgriffin) wrote: > Hi, > > I have raised an enhancement request (Incident Report 913453) about adding > some convenience methods to the Stream interface that collect the stream > and Pallavi Sonal asked me to start a thread here about that. > > More than 50% of our Stream collect calls use Collectors.toList() or > Collectors.toSet() as arguments so I think it would be very handy if the > Stream interface had default collectToList and collectToList and > collectToMap methods. > > The advantages are: > it would be easier to use code completion in IDEs. There are lot > of classes starting with Collect so finding the Collectors class is a bit > of a pain. > one less method call in what is usually a long chain of calls. > > Regards, > > Rob Griffin > Software Analyst, Spotlight on SQL Server > Quest | R&D > rob.griffin at quest.com > > -- James Roper Architect, Office of the CTO, Lightbend, Inc. @jroper From ivan.gerasimov at oracle.com Mon Dec 10 03:37:39 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 9 Dec 2018 19:37:39 -0800 Subject: RFR 8214761 : Bug in parallel Kahan summation implementation Message-ID: <6fb0565c-81cd-07fa-1c4f-fdf406b75f25@oracle.com> Hello! DoubleSummaryStatistics takes advantage of Kahan summation algorithm to reduce the error of the total sum. Internally it maintains a field double sumCompensation, which keeps lower bits (which were rounded off) of the last addition. Note, that the compensation has to be subtracted from the result to add those bits back: 166 private void sumWithCompensation(double value) { 167 double tmp = value - sumCompensation; 168 double velvel = sum + tmp; // Little wolf of rounding error 169 sumCompensation = (velvel - sum) - tmp; 170 sum = velvel; 171 } At the line 169, tmp normally has more lower bits than (velvel - sum). However, when two DoubleSummaryStatistics objects are combined, this compensation part is *added* to the total, which may result in a less accurate result. The same bug is replicated in DoubleStreams. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214761 WEBREV: http://cr.openjdk.java.net/~igerasim/8214761/00/webrev/ -- With kind regards, Ivan Gerasimov From tobias.hartmann at oracle.com Mon Dec 10 08:31:56 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 10 Dec 2018 09:31:56 +0100 Subject: RFR 8214971 : Replace use of string.equals("") with isEmpty() In-Reply-To: <6173c114-af3d-24d6-6ddc-f8e0ab93c59b@oracle.com> References: <5ec892af-26f6-2bdb-1cdf-ce3ffc1c6113@oracle.com> <8D068FE6-7852-42D7-B4CB-941DDC37F416@oracle.com> <6173c114-af3d-24d6-6ddc-f8e0ab93c59b@oracle.com> Message-ID: <9f43f26c-ecfe-1783-e5c1-5805325198b9@oracle.com> Hi Claes, the difference is the "array encoding" (ae) argument passed to the intrinsic. See MacroAssembler::string_compare(... int ae). If we compare an UTF16 String, we know that the number of bytes is always even (two byte / char encoding), whereas a Latin1 string has a byte encoding. So basically, the UTF16 intrinsics loads/compares chars whereas the Latin1 intrinsic compares bytes (both apply vectorization accordingly). But you are right, we could always use the Latin1 intrinsic but in theory it should be slower. At least on x86_64, might be different on ARM or other platforms. Thanks, Tobias On 07.12.18 20:35, Claes Redestad wrote: > This is an interesting point: can anyone explain why there are two distinct methods for LATIN1 and > UTF16 equality, with corresponding > intrinsics? Aleksey? Tobias? > > Testing with Arrays.equals then performance profile is > quite different due vectorization (often better, sometimes worse), > but this is performance-neutral for a variety of latin1 and utf16 inputs: > > if (coder() == aString.coder()) > ??? return StringLatin1.equals(value, aString.value); > > Is there some UTF16 input where StringLatin1.equals != StringUTF16.equals that forbids the above? > Performance-wise it seems neutral, and all tests seem to pass with the above (obviously need to run > more tests...). > > Thanks! > > /Claes > > On 2018-12-07 04:53, James Laskey wrote: >> Or simply; >> >> if (anObject instanceof String) { >> ??????????? String aString = (String)anObject; >> ??????????? if (coder() == aString.coder()) >> ???????????????? return Arrays.equals(value, aString.value); >> ??????????? } >> ??????? } >> >> Sent from my iPhone From goetz.lindenmaier at sap.com Mon Dec 10 10:02:20 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 10 Dec 2018 10:02:20 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> Message-ID: <8993984c04d14dcca306993a96bbb82f@sap.com> Hi, I ran the fix through our tests. There are no new regressions, and the addressed test works. So reviewed from my side. I increased the bug to P3 so we can push it to jdk12 in case we miss Thursday. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Steve Groeger > Sent: Freitag, 7. Dezember 2018 19:08 > To: Roger Riggs > Cc: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created > processes does not work. > > Hi Roger, > > I have made the same change to the Solaris code and also removed the test > from the ProblemList.txt > I have created a webrev here: > http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ > Hope you can now test t > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: Roger Riggs > To: core-libs-dev at openjdk.java.net > Date: 07/12/2018 14:55 > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between > created processes does not work. > Sent by: "core-libs-dev" > > > > Hi, > > I notice that the Solaris case also does not include "|| > forceNullOutputStream". > I'll have to investigate why the Pipeline test didn't fail on Solaris. > > Please add that to the patch and I'll run it through our tests. > > Thanks, Roger > > On 12/07/2018 03:05 AM, Volker Simonis wrote: > > Hi Steve, > > > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > > well, because that's where the review has to take place. The > > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > > get their attention on relevant changes (so cross-posting is fine in > > this case :) > > > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger > wrote: > >> Hi all, > >> > >> I have been investigating the issue > https://bugs.openjdk.java.net/browse/JDK-8211844 > raised by Goetz Lindenmaier which is related to the > >> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on > AIX. Having done some investigation I have a potential fix fore the issue: > >> > >> > >> diff -r 9501a7b59111 > src/java.base/unix/classes/java/lang/ProcessImpl.java > >> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec > 03 14:28:19 2018 +0300 > >> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec > 06 15:01:03 2018 +0000 > >> @@ -446,7 +446,7 @@ > >> ProcessBuilder.NullOutputStream.INSTANCE : > >> new ProcessPipeOutputStream(fds[0]); > >> > >> - stdout = (fds[1] == -1) ? > >> + stdout = (fds[1] == -1 || forceNullOutputStream) ? > >> ProcessBuilder.NullInputStream.INSTANCE : > >> new > DeferredCloseProcessPipeInputStream(fds[1]); > >> > > Your change looks good and I can sponsor it. Just as a hint for other > > reviewers I'd like to mention that this change, albeit in a shared > > Java file, is still AIX-only because it is in the "AIX" case of a > > switch statement. > > > > @Steve: can you please verify, that your change introduces no > > regression by running the complete jtreg test suite. > > > > Thank you and best regards, > > Volker > > > >> I would appreciate any feedback please, and for someone to be a sponsor > for this and to contributute it to OpenJDK. > >> > >> Steve Groeger > >> IBM Runtime Technologies > >> Hursley, Winchester > >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > >> Fax (44) 1962 816800 > >> Lotus Notes: Steve Groeger/UK/IBM > >> Internet: groeges at uk.ibm.com > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From magnus.ihse.bursie at oracle.com Mon Dec 10 10:41:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 11:41:35 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> Message-ID: On 2018-12-07 22:18, Simon Tooke wrote: > Looking at the code, it seems (to me) the "correct" thing to do is to is > to create a Windows-specific version of dbgsysBuildFunName() in > linker_md.c, and have it decorate the function name as appropriate for > 32-bit windows. Note that in transport.c, you'd need to pass in the > parameter stack size (the bit after the @), but it could at least behave > properly on 32 vs 64 bit Windows. > > Notice this approach is already used for the library name, via > dbgsysBuildLibName() > > If the function is never intended to be called by Java via JNI, then it > should never have been declared JNICALL in the first place - but that > ship has sailed. > > I don't think changing the decorated exported name to undecorated is a > good idea, as it obfuscates the calling convention used. Good analysis, Simon. I agree. I have now looked more into the situation. In fact, it looks a lot like JDWP has been broken on Windows 32-bit for a long time, but we have patched around the issue in the JDK by using /export. This is the spec we're dealing with: https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. I quote: > The transport library must export an/onload/function with the > following prototype: > > |JNIEXPORT jint JNICALL jdwpTransport_OnLoad(JavaVM *jvm, > jdwpTransportCallback *callback, jint version, jdwpTransportEnv** env);| > > This function will be called by the JDWP (or other agent) when the > library is loaded. > > Nothing here says anything that the function should be exported using anything other than the normal _stdcall (implied by JNICALL) name mangling rules. However, JDWP has not been working according to the spec and looking for the correct symbol, and while we could have noticed that in the JDK, we didn't, because someone (long ago) added /export:jdwpTransport_OnLoad as a workaround to the affected libraries, instead of fixing JDWP. Now, given that we've shipped code that didn't adhere to the specs for so long, we can probably not break that behavior. Instead, I propose we amend dbgsysBuildFunName() so that on Windows 32-bit, it looks for both the "jdwpTransport_OnLoad", and the symbol as mangled by _stdcall rules. I also propose that if both symbols are present, the _stdcall named one should take precedence, since that's according to the spec (and the other is just a fallback to maintain backwards compatibility). /Magnus > > -Simon Tooke > > > On 12/7/2018 2:09 PM, Alexey Ivanov wrote: >> Hi Andrew, >> >> Sorry for my belated reply. >> Yes, it's also an option? however, this solution seems to be >> overcomplicated to export one function or two. The calling convention >> of exported functions for JVM cannot be changed, they can be called >> from third-party software. >> >> If the function is used internally-only, its calling convention can be >> changed as long as all components are updated. >> >> Thank you for the pointer to another approach used to handle name >> decorations of __stdcall functions. It looks we have to work out a >> common approach to this problem. >> >> Regards, >> Alexey >> >> On 27/11/2018 18:49, Andrew Luo wrote: >>> By the way, in hotspot we are generating a .def file dynamically >>> while keeping the JNICALL calling convention (for symbols such as >>> JNI_CreateJavaVM) I believe (just by looking through the code in >>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, >>> unless this code is inactive - someone who knows this area better >>> than me might want to comment...). Shouldn't the same approach be >>> taken here as well? >>> >>> Thanks >>> Andrew >>> >>> -----Original Message----- >>> From: core-libs-dev On >>> Behalf Of Ali Ince >>> Sent: Monday, November 19, 2018 2:08 PM >>> To: Alexey Ivanov ; build-dev >>> ; core-libs >>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >>> >>> Hi Alexey, >>> >>> I don?t have an account on JBS as I?m not an author yet, my OCA has >>> just been processed. Would it be possible for someone with an author >>> status to create an issue? >>> >>> Regards, >>> >>> Ali >>> >>>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>>> wrote: >>>> >>>> Hi Ali, >>>> >>>> The fix looks good to me provided it resolves your problem. >>>> I am not a reviewer so you'll have to get OK from reviewers, likely >>>> from build-dev and from core-libs. >>>> >>>> Have you submitted the issue in JBS? >>>> >>>> You have to sign OCA to be able to contribute to OpenJDK: >>>> https://openjdk.java.net/contribute/ >>>> and also >>>> https://openjdk.java.net/sponsor/ >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 18/11/2018 12:07, Ali ?nce wrote: >>>>> Hi Alexey, >>>>> >>>>> Below is a new patch content that removes JNICALL modifiers from >>>>> the exported functions of interest. This results in exported >>>>> functions not to be name decorated and use __cdecl calling convention. >>>>> >>>>> Do you have any more suggestions, or would you please guide me on >>>>> next steps? >>>>> >>>>> Thanks, >>>>> >>>>> Ali >>>>> >>>>> # HG changeset patch >>>>> # User Ali Ince >>>>> # Date 1542542415 0 >>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>>>> builds >>>>> >>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>> src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug >>>>> 14 14:28:23 2018 +0200 >>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov >>>>> 18 12:00:15 2018 +0000 >>>>> @@ -339,7 +339,7 @@ >>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>> +JNIEXPORT jint >>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>> jint version, jdwpTransportEnv** result) { >>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>> src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>> @@ -140,7 +140,7 @@ >>>>> void (*free)(void *buffer); /* Call this for all >>>>> deallocations */ >>>>> } jdwpTransportCallback; >>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>> >>>>> jdwpTransportCallback *callback, >>>>> jint version, >>>>> jdwpTransportEnv** >>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>> --- >>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>> +++ >>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>> @@ -1019,7 +1019,7 @@ >>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>> +JNIEXPORT jint >>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>> jint version, jdwpTransportEnv** env) { >>>>> >>>>> >>>>> >>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>>> wrote: >>>>>> >>>>>> Hi Ali, >>>>>> >>>>>> It's exactly what I referred to. >>>>>> >>>>>> Yes, it does change the calling convention. >>>>>> Yet it's not a (big) problem because both parties will use the >>>>>> same calling convention. >>>>>> >>>>>> Using a DLL from another build will not be possible. But it's not >>>>>> a good idea to do so anyway. >>>>>> >>>>>> >>>>>> Mapfiles and export options have been removed by >>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify >>>>>> managing exported functions. So that to add or remove an exported >>>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>>> just edit the source files. >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>> Hi Alexey, >>>>>>> >>>>>>> Thanks for your reply. >>>>>>> >>>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>>> be __stdcall on windows which is both specified on >>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>>> and dt_shmem.dll. >>>>>>> >>>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>>> decoration is not applied >>>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). >>>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>>> >>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>>> applies to x86 builds) will result in the calling convention to >>>>>>> be changed, and thus will change how parameters are ordered and >>>>>>> also the stack cleanup rules. I think this may result in problems >>>>>>> in programs that are designed to load shared libraries and its >>>>>>> exported functions at runtime (not bound by link time which >>>>>>> probably won?t cause any issues - assuming that they use the >>>>>>> shared function signature) - as in >>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Ali, >>>>>>>> >>>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>>> the affected functions? >>>>>>>> >>>>>>>> Some build / link issues were resolved by adding / removing >>>>>>>> JNICALL modifier, see >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>>> .html >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>>> tml >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> An issue >>>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) >>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>>> >>>>>>>>> Although the expected linker arguments were present on previous >>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>> >>>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>>> >>>>>>>>> Would you please have a look and let me know of any points I >>>>>>>>> may have missed (I don?t have any background information about >>>>>>>>> why the export flags were removed in jdk11)? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ali >>>>>>>>> >>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>> )) >>>>>>>>> >>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>>> 100644 >>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>>> libjdwp/export, \ >>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ From magnus.ihse.bursie at oracle.com Mon Dec 10 10:45:46 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 11:45:46 +0100 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> Message-ID: <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> On 2018-12-07 21:24, Alexey Ivanov wrote: > Hi Ali, > > On 06/12/2018 22:49, Ali ?nce wrote: >> Hi Magnus, Alexey, >> >> I believe we won?t be able to get further opinions from >> serviceability-dev. > > Unfortunately, no one has replied as of now. > Have you found any issues with jdwpTransport_OnLoad after removing > JNICALL? > >> Andrew Luo suggested using a similar mechanism as is used for jvm.dll >> by using symbol name files mapped by platform (files are under >> make/hotspot/symbols and interestingly windows is almost the only >> platform for which a symbol file doesn?t exist). > > Andrew says the .def files are auto-generated for Windows. There's a > set of shared functions. > JVM cannot change the calling convention, jvm.dll is the public > interface to JVM. > >> Another issue, again opened against AdoptOpenJDK 32-bit builds is >> somehow related with the same problem - but this time it is >> jimage.dll depending on zip.dll expecting the ZIP_InflateFully >> function to be decorated with JNICALL - whereas it was removed >> earlier from the implementation and the runtime image just fails with >> access violation just because jimage source code still declared it >> with JNICALL (https://github.com/AdoptOpenJDK/openjdk-build/issues/763). > > The usage of ZIP_InflateFully from zip.dll by jimage.dll was > overlooked during work on > https://bugs.openjdk.java.net/browse/JDK-8201226. > > I can take care of it. It might be worthwhile to scan the entire code base for JNICALL and verify that we have no more mismatches. In general, JNICALL should be preserved on all officially supported, exported interfaces. It need not be present on interfaces used only internally, and my current thinking is that it would be better if it were removed on all internal interfaces. But at the very least, it should be consistently specificed where exported and imported. (Any misses here is probably due to duplicate declarations, instead of properly including header files, so that's the correct way to resolve any problems found...) /Magnus > (I could not build 32 bit Windows. It seem to have overcome the > problem by adding --disable-warnings-as-errors option to configure.) > > However, the report says the resulting image crashes in 64 bit windows > too which shouldn't be affected by JNICALL mismatch. > >> I?ve also searched for GetProcAddress calls across the source code - >> and I think it?s important to work on the consistency of JNICALL >> usages across the whole source code. > > There are many places where libraries are loaded dynamically or a > function may be unavailable on older versions of the platform. > Have you identified any other place where functions from JDK DLLs are > looked up by names? > >> Another noteworthy thing I?ve noticed is there are still JNICALL >> modifiers for example in >> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49 - >> which I guess will also be reported as broken since these functions >> are again name decorated. > > This is a JNI method. It should use JNICALL modifier. If it wasn't > found, the class sun.security.pkcs11.Secmod would fail to load. I > guess JVM handles name mangling somehow for native method implementation. > > Such functions were never explicitly exported using mapfiles or > /export options on Windows, at least in the client area. For Linux and > Solaris, adding or removing a native method required editing mapfiles. > >> If we?re still determined to remove JNICALL, what about just removing >> __stdcall from JNICALL declaration at >> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31 ? Wouldn?t >> that be a more consistent move? > > We can't do that. > Implementation of Java native methods must use __stdcall calling > convention. > >> >> Regards, >> >> Ali >> >>> On 22 Nov 2018, at 17:29, Magnus Ihse Bursie >>> >> > wrote: >>> >>> I think we are in complete agreement. What's missing is some expert >>> opinion from serviceability-dev if there is any problem with >>> changing the signature. I'd preferably have that. >>> >>> If no one knows, I'd say, change it, and see if we still pass the >>> relevant tests, and if so, ship it. >>> >>> /Magnus >>> >>> 22 nov. 2018 kl. 18:04 skrev Alexey Ivanov >> >: >>> >>>> >>>> On 21/11/2018 12:16, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2018-11-20 16:49, Alexey Ivanov wrote: >>>>> >>>>>> Hi Ali, Magnus, >>>>>> >>>>>> I absolutely agree this change has to be reviewed by someone from >>>>>> serviceability. >>>>>> >>>>>> There are several options: >>>>>> >>>>>> 1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html >>>>>> so it partially reverts the changes from >>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 >>>>>> >>>>>> 2. Remove JNICALL (__stdcall) modifier, eventually changing the >>>>>> calling convention to __cdecl. >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023969.html >>>>>> >>>>>> 3. Use inline /export option via #pragma: >>>>>> #pragma comment(linker, "/export:jdwpTransport_OnLoad= >>>>>> _jdwpTransport_OnLoad at 16") >>>>>> as referenced in >>>>>> https://docs.microsoft.com/en-ie/cpp/cpp/dllexport-dllimport?view=vs-2017 >>>>>> https://docs.microsoft.com/en-ie/cpp/build/reference/exports?view=vs-2017 >>>>>> >>>>>> The third options still needs to be tested to make sure it does >>>>>> not break other platforms builds. >>>>> I'm not fond of either solution 1 or 3. I really think the >>>>> signature should be made correctly at the point of definition in >>>>> the source code. >>>> >>>> That is why I proposed removing JNICALL (__stdcall) from the >>>> function declaration as we had done for libzip, libjimage [1] and >>>> mlib_image [2]. >>>> >>>> Microsoft recommends using __stdcall for DLLs, at the same time it >>>> decorates the function name making it harder to export it by its >>>> plain name. >>>> >>>> >>>> By removing JNICALL / __stdcall, we make the function use __cdecl >>>> calling convention. The difference between them is that with >>>> __stdcall the callee cleans the stack whereas with __cdecl the >>>> caller cleans the stack. >>>> >>>> It shouldn't be a problem as long as all function declarations use >>>> the same calling convention, which, I believe, is the case here. >>>> >>>>> We've spent some considerable effort of getting rid of the /export >>>>> flags for Windows (and map files for unix), and I don't want to >>>>> see them creep back in. Note that option 3 is just option 1 in >>>>> disguise. The only single good thing about it is that it allows >>>>> you to put the compiler option next to the signature declaration >>>>> in the source code. >>>> >>>> At least in this case, the option will be near the function body >>>> definition. It will be easier to update it if the signature changes. >>>> >>>> If we are to use __stdcall, it seems to be the only way to export >>>> the undecorated name. >>>> >>>>> The same goes for def files, as suggested by Ali. It's just yet >>>>> another version of option 1 in disguise/map files. >>>> >>>> If option 2 is rejected, I'm for using option 3. If option 3 cannot >>>> be used too, I'm for option 1. >>>> I think we should not fall back to def files in any case. And >>>> Makefile will have to include the reference to the def file, so >>>> it's even worse than option 1. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8201226 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 19/11/2018 12:19, Magnus Ihse Bursie wrote: >>>>>>> Hi Ali, >>>>>>> >>>>>>> From a build perspective this change looks OK. I'm not aware of >>>>>>> the finer details on the OnLoad mechanism, like what calling >>>>>>> convention is to be used. So maybe this is a no-go from that view. >>>>>>> >>>>>>> I'm cc:ing servicability so they can have a look at it. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2018-11-18 13:07, Ali ?nce wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Below is a new patch content that removes JNICALL modifiers from the exported functions of interest. This results in exported functions not to be name decorated and use __cdecl calling convention. >>>>>>>> >>>>>>>> Do you have any more suggestions, or would you please guide me on next steps? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>> # HG changeset patch >>>>>>>> # User Ali Ince >>>>>>>> # Date 1542542415 0 >>>>>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows builds >>>>>>>> >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -339,7 +339,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>>> } >>>>>>>> >>>>>>>> -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** result) >>>>>>>> { >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -140,7 +140,7 @@ >>>>>>>> void (*free)(void *buffer); /* Call this for all deallocations */ >>>>>>>> } jdwpTransportCallback; >>>>>>>> >>>>>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>>> jdwpTransportCallback *callback, >>>>>>>> jint version, >>>>>>>> jdwpTransportEnv** env); >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>>> } >>>>>>>> >>>>>>>> -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** env) >>>>>>>> { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> It's exactly what I referred to. >>>>>>>>> >>>>>>>>> Yes, it does change the calling convention. >>>>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>>>> >>>>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>>>> >>>>>>>>> >>>>>>>>> Mapfiles and export options have been removed byhttps://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>>> Hi Alexey, >>>>>>>>>> >>>>>>>>>> Thanks for your reply. >>>>>>>>>> >>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>>>> >>>>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>>> >>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as inhttps://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Ali, >>>>>>>>>>> >>>>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>>>> >>>>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexey >>>>>>>>>>> >>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>>>> >>>>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>>> >>>>>>>>>>>> Below is the proposed patch, which can also be browsed athttps://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>>>>>> >>>>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Ali >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>>> )) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>>> >>>>>> >>>>> >>>> >> > From magnus.ihse.bursie at oracle.com Mon Dec 10 10:47:14 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 11:47:14 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> Message-ID: <036e55d4-4646-c885-53bf-32bbf4961b54@oracle.com> On 2018-11-27 19:49, Andrew Luo wrote: > By the way, in hotspot we are generating a .def file dynamically while keeping the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe (just by looking through the code in http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, unless this code is inactive - someone who knows this area better than me might want to comment...). Shouldn't the same approach be taken here as well? This is code that is on it's way out. It should not be copied elsewhere. On the contrary, the long-term plan is to use compiler attributes for symbol visibility in Hotspot, just as in the rest of the JDK. /Magnus > > Thanks > Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of Ali Ince > Sent: Monday, November 19, 2018 2:08 PM > To: Alexey Ivanov ; build-dev ; core-libs > Subject: Re: [PATCH] Windows 32-bit DLL name decoration > > Hi Alexey, > > I don?t have an account on JBS as I?m not an author yet, my OCA has just been processed. Would it be possible for someone with an author status to create an issue? > > Regards, > > Ali > >> On 19 Nov 2018, at 12:12, Alexey Ivanov wrote: >> >> Hi Ali, >> >> The fix looks good to me provided it resolves your problem. >> I am not a reviewer so you'll have to get OK from reviewers, likely from build-dev and from core-libs. >> >> Have you submitted the issue in JBS? >> >> You have to sign OCA to be able to contribute to OpenJDK: >> https://openjdk.java.net/contribute/ >> and also >> https://openjdk.java.net/sponsor/ >> >> Regards, >> Alexey >> >> On 18/11/2018 12:07, Ali ?nce wrote: >>> Hi Alexey, >>> >>> Below is a new patch content that removes JNICALL modifiers from the exported functions of interest. This results in exported functions not to be name decorated and use __cdecl calling convention. >>> >>> Do you have any more suggestions, or would you please guide me on next steps? >>> >>> Thanks, >>> >>> Ali >>> >>> # HG changeset patch >>> # User Ali Ince >>> # Date 1542542415 0 >>> # Sun Nov 18 12:00:15 2018 +0000 >>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>> builds >>> >>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov 18 12:00:15 2018 +0000 >>> @@ -339,7 +339,7 @@ >>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>> +JNIEXPORT jint >>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>> jint version, jdwpTransportEnv** result) { >>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Sun Nov 18 12:00:15 2018 +0000 >>> @@ -140,7 +140,7 @@ >>> void (*free)(void *buffer); /* Call this for all deallocations */ >>> } jdwpTransportCallback; >>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>> jdwpTransportCallback *callback, >>> jint version, >>> jdwpTransportEnv** >>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>> @@ -1019,7 +1019,7 @@ >>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>> +JNIEXPORT jint >>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>> jint version, jdwpTransportEnv** env) { >>> >>> >>> >>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>> >>>> Hi Ali, >>>> >>>> It's exactly what I referred to. >>>> >>>> Yes, it does change the calling convention. >>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>> >>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>> >>>> >>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>> Hi Alexey, >>>>> >>>>> Thanks for your reply. >>>>> >>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>> >>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds. >>>>> >>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>> >>>>> Any thoughts? >>>>> >>>>> Regards, >>>>> >>>>> Ali >>>>> >>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>> >>>>>> Hi Ali, >>>>>> >>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>> >>>>>> Some build / link issues were resolved by adding / removing >>>>>> JNICALL modifier, see >>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>> .html >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>> tml >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>> Hi, >>>>>>> >>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>> >>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>> >>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>> >>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>> jdk.jdwp.agent:include \ >>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>> )) >>>>>>> >>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>> 100644 >>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>> libjdwp/export, \ >>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>> LIBS_linux := -lpthread, \ >>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ From Nick.Gasson at arm.com Mon Dec 10 10:56:26 2018 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Mon, 10 Dec 2018 10:56:26 +0000 Subject: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32 In-Reply-To: References: <7adbcbb2-d34f-8314-ab90-a65cdc6769aa@oracle.com> <49c634ab-6fb4-6983-4d62-222c1fe4148b@oracle.com> Message-ID: Hi, Any update on this one? Or do we want to give up on it until JDK-8165620 is implemented? Thanks, Nick On 28/11/2018 11:33, Martin Buchholz wrote: > > > On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson > wrote: > > > I missed one thing then looking at this. In TimeZone_md.c it should be > > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but > > I need to change this one line before pushing. > > Hi Alan, > > Yes feel free to modify it. I think looking at the at other files > with these #defines more closely, is it the case that the #ifndef > MACOSX check is only required for statvfs64? As in > e.g. UnixNativeDispatcher.c. So TimeZone_md.c should look like > this: > > #if defined(_ALLBSD_SOURCE) > ? #define stat64 stat > ? #define lstat64 lstat > ? #define fstat64 fstat > #endif > > I don't have access to any OS X machines to test unfortunately. > > But I wonder if a better way to handle this is to check for the > presence of the stat64 functions in the configure script, and > then we could just write something like this, which would be a > lot clearer: > > #if !defined(HAVE_STAT64) > ? #define stat64 stat > #endif > > > > The best way is to implement > > https://bugs.openjdk.java.net/browse/JDK-8165620 > > "Entire JDK should be built with -D_FILE_OFFSET_BITS=64" > > but yes, another good way is to do as you suggest, have configure define > HAVE_XXXX for all known functions with a 64-bit variant and then put > them into a header file with proper ifdefs for platforms that don't have > them. > > You could also "simply" add > #define _FILE_OFFSET_BITS 64 > but you have to do it for cliques of files that share ambiguously sized > data simultaneously. From magnus.ihse.bursie at oracle.com Mon Dec 10 11:01:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 12:01:08 +0100 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> Message-ID: <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> On 2018-12-07 21:20, Roger Riggs wrote: > Hi, > > It is a nice feature that charsets are selected at build time using > the stdcs-xxx files. > This change breaks that pattern and embeds os specific information in > more than one place. > That does not seem like an improvement. Is there any alternative? I agree. Why is it not enough just to add it to stdcs-aix? /Magnus > > Thanks, Roger > > > On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote: >> Hello. >> (I'm sorry, I made a mistake, I forgot to change Subject) >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ >> >> IBM29626C charset is required for AIX default charset. >> Java cannot start because of java/lang/ExceptionInInitializerError on >> AIX ja_JP locale. >> >> To build team, >> I'd like to change following charsetmapping tool. >> * make/jdk/src/classes/build/tools/charsetmapping/Main.java >> * make/jdk/src/classes/build/tools/charsetmapping/SPI.java >> * make/jdk/src/classes/build/tools/charsetmapping/SRC.java >> >> build.tools.charsetmapping,Main supports "os" tag, but it seems it's >> not used. >> Currently, "os" supports "windows" or "unix". >> I extended "os" tag's feature. >> If "os aix" is there, this charset is only added into AIX platform. >> (I assume "type template" should be used) >> "aix" comes from "stdcs-aix" file name. >> ====== >> charset x-IBM29626C IBM29626C >> package sun.nio.cs.ext >> type template >> os aix <===== >> alias cp29626C # JDK historical >> alias ibm29626C >> alias ibm-29626C >> alias 29626C >> alias ibm-eucjp >> ====== >> >> If cs.os is null, >> this charset is stored into gensrc directory. >> Charset name is added into StandardCharsets.java or >> ExtendedCharsets.java >> If cs.os is "false", >> this charset is NOT stored into gensrc directory. >> Charset name is NOT added into StandardCharsets.java or >> ExtendedCharsets.java >> >> "os" tag supports multiple entries by using ",", like "aix,linux" >> Then we can store new charset into >> src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory >> >> >> $ locale charmap >> IBM-eucJP >> $ jshell >> | JShell -- 12-internal >> | : /help intro >> >> jshell> var cs = java.nio.charset.Charset.defaultCharset() >> cs ==> x-IBM29626C >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.IBM29626C" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> cp29626C >> ibm-29626C >> ibm-eucjp >> ibm29626C >> 29626C >> >> jshell> /exit >> | >> $ >> >> I tested Linux and Windows build. >> ====== >> $ grep 29626 build.log >> IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false >> >> $ find support/gensrc/ | grep 29626 >> >> $ find support/gensrc/ | grep Charsets >> support/gensrc/java.base/sun/nio/cs/StandardCharsets.java >> support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java >> >> $ find support/gensrc/ | grep Charsets | xargs grep 29626 >> >> $ >> ====== >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>> On 2018-11-28 10:36, Alan Bateman wrote: >>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>> I'm quite unsatisfied with the current handling of character sets >>>>> in the build in general. :-( I'd really like to modernize it. I >>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>> a build perspective, but I'm not sure of what "external" >>>>> requirements are coming from AIX and the general core-libs agenda >>>>> regarding character sets in general. >>>>> >>>>> I think there is a good opportunity to solve many problems at the >>>>> same time here, as long as everyone agrees on what is the >>>>> preferred outcome. >>>> The support in the build to configure the charsets to include in >>>> java.base on each platform has been working well. Charsets that >>>> aren't in java.base go into the jdk.charsets service provider >>>> module and that has been working well too. From the result point of >>>> view, perhaps, but definitely not from the build perspective. ;-) >>>> But yes, I understand this is functionality that should be kept. >>>> One thing that we lack is some way to add charsets for specific >>>> platforms and this comes up with the IBM patches where they are >>>> looking to adding several additional IBM charsets. One starting >>>> point that we've touched on in several threads here is dropping the >>>> EBCDIC charsets from the main stream builds. Going there will need >>>> build support. >>> So build support for trivially adding specific charsets to specific >>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>> then? >>> >>> Can you expand on the issue of dropping ebcdic? What's the problem >>> that needs build support? >>> >>> /Magnus >>>> >>>> >>>> -Alan >> > From magnus.ihse.bursie at oracle.com Mon Dec 10 11:05:54 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 12:05:54 +0100 Subject: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32 In-Reply-To: References: <7adbcbb2-d34f-8314-ab90-a65cdc6769aa@oracle.com> <49c634ab-6fb4-6983-4d62-222c1fe4148b@oracle.com> Message-ID: On 2018-12-10 11:56, Nick Gasson (Arm Technology China) wrote: > Hi, > > Any update on this one? Or do we want to give up on it until JDK-8165620 > is implemented? I think Alan reviewed it as OK with just a minor fix, and offered to sponsor it for you. Then the discussion started about some major changes, rewriting configure to provide individual support for every possible system function... I recommend that you go with the fix that solves your problem. In fact, I disagree with the premise of JDK-8165620. I think it's better to do what you're doing here, to update the source code, so that it is clear that we know that we're handing 64-bit data. /Magnus > > Thanks, > Nick > > > On 28/11/2018 11:33, Martin Buchholz wrote: >> >> On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson > > wrote: >> >> > I missed one thing then looking at this. In TimeZone_md.c it should be >> > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but >> > I need to change this one line before pushing. >> >> Hi Alan, >> >> Yes feel free to modify it. I think looking at the at other files >> with these #defines more closely, is it the case that the #ifndef >> MACOSX check is only required for statvfs64? As in >> e.g. UnixNativeDispatcher.c. So TimeZone_md.c should look like >> this: >> >> #if defined(_ALLBSD_SOURCE) >> #define stat64 stat >> #define lstat64 lstat >> #define fstat64 fstat >> #endif >> >> I don't have access to any OS X machines to test unfortunately. >> >> But I wonder if a better way to handle this is to check for the >> presence of the stat64 functions in the configure script, and >> then we could just write something like this, which would be a >> lot clearer: >> >> #if !defined(HAVE_STAT64) >> #define stat64 stat >> #endif >> >> >> >> The best way is to implement >> >> https://bugs.openjdk.java.net/browse/JDK-8165620 >> >> "Entire JDK should be built with -D_FILE_OFFSET_BITS=64" >> >> but yes, another good way is to do as you suggest, have configure define >> HAVE_XXXX for all known functions with a 64-bit variant and then put >> them into a header file with proper ifdefs for platforms that don't have >> them. >> >> You could also "simply" add >> #define _FILE_OFFSET_BITS 64 >> but you have to do it for cliques of files that share ambiguously sized >> data simultaneously. From Alan.Bateman at oracle.com Mon Dec 10 11:36:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2018 11:36:17 +0000 Subject: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32 In-Reply-To: References: <7adbcbb2-d34f-8314-ab90-a65cdc6769aa@oracle.com> <49c634ab-6fb4-6983-4d62-222c1fe4148b@oracle.com> Message-ID: <79c35c0f-6867-256d-85c1-ccfe14f262b2@oracle.com> On 10/12/2018 11:05, Magnus Ihse Bursie wrote: > > > On 2018-12-10 11:56, Nick Gasson (Arm Technology China) wrote: >> Hi, >> >> Any update on this one? Or do we want to give up on it until JDK-8165620 >> is implemented? > I think Alan reviewed it as OK with just a minor fix, and offered to > sponsor it for you. That's right, the change broke the macOS build. It's on my list to re-test and sponsor this week. -Alan From Alan.Bateman at oracle.com Mon Dec 10 11:50:47 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2018 11:50:47 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> Message-ID: On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > On 2018-12-07 21:20, Roger Riggs wrote: >> Hi, >> >> It is a nice feature that charsets are selected at build time using >> the stdcs-xxx files. >> This change breaks that pattern and embeds os specific information in >> more than one place. >> That does not seem like an improvement.? Is there any alternative? > I agree. Why is it not enough just to add it to stdcs-aix? My reading of the patch is that the "os" key is to avoid generating it on non-AIX platforms, it will otherwise end up in jdk.charsets on non-AIX platforms. The general direction is welcome but I think further work and discussion will be needed to get the right set of changes to support filtering in the build. It can probably be separated from the changes to add IBM-29626C to AIX's java.base. -Alan From adinn at redhat.com Mon Dec 10 12:01:44 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 10 Dec 2018 12:01:44 +0000 Subject: RFR(xs): 8199394: Object.hashCode should not mention anything about memory addresses In-Reply-To: <344583cf-e94a-e98c-8c90-7d36ee4cf915@oracle.com> References: <37e12c7d-6e48-6c0f-b820-ddc846a96f03@oracle.com> <2093915897.1148644.1544178694936.JavaMail.zimbra@u-pem.fr> <6749dfc2-1e37-0e05-8b1f-be56877935c3@redhat.com> <2e18da61-173d-8c7d-02b9-b4307c59b306@oracle.com> <344583cf-e94a-e98c-8c90-7d36ee4cf915@oracle.com> Message-ID: On 07/12/2018 18:17, Stuart Marks wrote: > Hi Andrew, Aleksey, R?mi, > > Thanks for looking at the patch. Could one or more of you add yourselves > as reviewers on the corresponding CSR? > > https://bugs.openjdk.java.net/browse/JDK-8215025 Done. 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 From takiguc at linux.vnet.ibm.com Mon Dec 10 12:21:23 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 10 Dec 2018 21:21:23 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> Message-ID: Hello Roger, Magnus and Alan. I may need to put alias information into charsets file. stdcs-xxx cannot handle this information... Still AIX needs IBM-29626C charset for default encoding... I appreciate if you give me further suggestions. Thanks, Ichiroh Takiguchi On 2018-12-10 20:50, Alan Bateman wrote: > On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> On 2018-12-07 21:20, Roger Riggs wrote: >>> Hi, >>> >>> It is a nice feature that charsets are selected at build time using >>> the stdcs-xxx files. >>> This change breaks that pattern and embeds os specific information in >>> more than one place. >>> That does not seem like an improvement.? Is there any alternative? >> I agree. Why is it not enough just to add it to stdcs-aix? > My reading of the patch is that the "os" key is to avoid generating it > on non-AIX platforms, it will otherwise end up in jdk.charsets on > non-AIX platforms. The general direction is welcome but I think > further work and discussion will be needed to get the right set of > changes to support filtering in the build. It can probably be > separated from the changes to add IBM-29626C to AIX's java.base. > > -Alan From alexey.ivanov at oracle.com Mon Dec 10 12:32:05 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 10 Dec 2018 12:32:05 +0000 Subject: [12] RFR for JDK-8215123: Crash in runtime image built with jlink --compress=2 Message-ID: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com> Hi, Could you please review the following fix for jdk12? bug: https://bugs.openjdk.java.net/browse/JDK-8215123 webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/ The problem is that calling convention was changed on ZIP_InflateFully function in zip.dll. Yet it hasn't been updated in jimage.dll which uses this function. It could be considered a regression from JDK-8200178 [1] and JDK-8201226 [2]. After the first fix, ZIP_InflateFully was exported with a mangled name so that function could not be found in zip.dll. After the second fix, the function uses __cdecl; mismatched calling convention leads to stack corruption. The fix is to remove JNICALL (__stdcall) from ZIP_InflateFully function prototype in imageDecompressor.cpp so that the calling convention is the same. This issue was brought up by Ali ?nce from AdoptOpenJDK: http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024300.html Thank you in advance. Regards, Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8200178 [2] https://bugs.openjdk.java.net/browse/JDK-8201226 From magnus.ihse.bursie at oracle.com Mon Dec 10 13:01:23 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 14:01:23 +0100 Subject: [12] RFR for JDK-8215123: Crash in runtime image built with jlink --compress=2 In-Reply-To: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com> References: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com> Message-ID: <4319182e-5365-0e4e-29db-47ba749bad92@oracle.com> Hi Alexey, On 2018-12-10 13:32, Alexey Ivanov wrote: > Hi, > > Could you please review the following fix for jdk12? > > bug: https://bugs.openjdk.java.net/browse/JDK-8215123 > webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/ The fix looks good to me. /Magnus > > > The problem is that calling convention was changed on ZIP_InflateFully > function in zip.dll. Yet it hasn't been updated in jimage.dll which > uses this function. > > It could be considered a regression from JDK-8200178 [1] and > JDK-8201226 [2]. After the first fix, ZIP_InflateFully was exported > with a mangled name so that function could not be found in zip.dll. > After the second fix, the function uses __cdecl; mismatched calling > convention leads to stack corruption. > > The fix is to remove JNICALL (__stdcall) from ZIP_InflateFully > function prototype in imageDecompressor.cpp so that the calling > convention is the same. > > > This issue was brought up by Ali ?nce from AdoptOpenJDK: > http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024300.html > > > > Thank you in advance. > > Regards, > Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8200178 > [2] https://bugs.openjdk.java.net/browse/JDK-8201226 From Alan.Bateman at oracle.com Mon Dec 10 13:12:30 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2018 13:12:30 +0000 Subject: [12] RFR for JDK-8215123: Crash in runtime image built with jlink --compress=2 In-Reply-To: <4319182e-5365-0e4e-29db-47ba749bad92@oracle.com> References: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com> <4319182e-5365-0e4e-29db-47ba749bad92@oracle.com> Message-ID: <012a5fb5-57e5-3d6a-2384-7dfa684b8761@oracle.com> On 10/12/2018 13:01, Magnus Ihse Bursie wrote: > Hi Alexey, > > On 2018-12-10 13:32, Alexey Ivanov wrote: >> Hi, >> >> Could you please review the following fix for jdk12? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8215123 >> webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/ > The fix looks good to me. Looks okay to me too. -Alan From magnus.ihse.bursie at oracle.com Mon Dec 10 13:19:09 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 14:19:09 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT Message-ID: I propose that we introduce a new define, available to all JDK native files (Hotspot included), called JDK_EXPORT. The behavior of this symbol will be very similar (as of now, in fact identical) to JNIEXPORT; however, the semantics will not. Currently, we "mis-use" the JNIEXPORT define to mark a function for exporting from the library. The problem with this is that JNIEXPORT is part of the JNI interface, and is supposed to be used when C programs interact with Java. And, when doing this, the function should be fully decorated like this: "JNIEXPORT foo JNICALL". We do have many such JNI exports in our native libraries, but we also have a lot of other, non-JNI exports, where one native library just provides an interface to other libraries. In these cases, we have still used JNIEXPORT for the functionality of getting the function exported, but we have not been consistent in our use of JNICALL. This has caused us way too much trouble for something that should Just Work. I therefore propose that we define "JDK_EXPORT", with the same behavior as JNIEXPORT (that is, flagging the function for external visibility in the resulting native library), but which is *not* supposed to be exported to Java code using JNI, nor supposed to be decorated with JNICALL. All current instances of JNIEXPORT which is not pure JNI native functions should be changed to use JDK_EXPORT instead. I further propose that this macro should reside in a new file "jdk.h", placed in the new directory src/java.base/share/native/include/internal. This header file path will automatically be provided to all native libraries, but not copied to the JDK being built. (The existence of a "include/internal" directory with this behavior has been discussed before. There are more files that ought to be moved there, if/when it is created.) I believe in many cases the #include "jni.h" can be just modified to #include "#jdk.h", since most native code will not require "jni.h" unless actually doing JNI calls -- most have included this file to get the JNIEXPORT macro, which would explain the pervasive use of #include "jni.h" in our code base. Thoughts? /Magnus From GROEGES at uk.ibm.com Mon Dec 10 13:42:27 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Mon, 10 Dec 2018 13:42:27 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: <8993984c04d14dcca306993a96bbb82f@sap.com> References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> <8993984c04d14dcca306993a96bbb82f@sap.com> Message-ID: Hi Goetz, It is good that the tests you ran passed. What needs to be done now to get this change pushed into the main code? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Lindenmaier, Goetz" To: Steve Groeger , Roger Riggs Cc: "core-libs-dev at openjdk.java.net" Date: 10/12/2018 10:06 Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. Hi, I ran the fix through our tests. There are no new regressions, and the addressed test works. So reviewed from my side. I increased the bug to P3 so we can push it to jdk12 in case we miss Thursday. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Steve Groeger > Sent: Freitag, 7. Dezember 2018 19:08 > To: Roger Riggs > Cc: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created > processes does not work. > > Hi Roger, > > I have made the same change to the Solaris code and also removed the test > from the ProblemList.txt > I have created a webrev here: > http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ > Hope you can now test t > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: Roger Riggs > To: core-libs-dev at openjdk.java.net > Date: 07/12/2018 14:55 > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between > created processes does not work. > Sent by: "core-libs-dev" > > > > Hi, > > I notice that the Solaris case also does not include "|| > forceNullOutputStream". > I'll have to investigate why the Pipeline test didn't fail on Solaris. > > Please add that to the patch and I'll run it through our tests. > > Thanks, Roger > > On 12/07/2018 03:05 AM, Volker Simonis wrote: > > Hi Steve, > > > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > > well, because that's where the review has to take place. The > > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > > get their attention on relevant changes (so cross-posting is fine in > > this case :) > > > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger > wrote: > >> Hi all, > >> > >> I have been investigating the issue > https://bugs.openjdk.java.net/browse/JDK-8211844 > raised by Goetz Lindenmaier which is related to the > >> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on > AIX. Having done some investigation I have a potential fix fore the issue: > >> > >> > >> diff -r 9501a7b59111 > src/java.base/unix/classes/java/lang/ProcessImpl.java > >> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec > 03 14:28:19 2018 +0300 > >> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec > 06 15:01:03 2018 +0000 > >> @@ -446,7 +446,7 @@ > >> ProcessBuilder.NullOutputStream.INSTANCE : > >> new ProcessPipeOutputStream(fds[0]); > >> > >> - stdout = (fds[1] == -1) ? > >> + stdout = (fds[1] == -1 || forceNullOutputStream) ? > >> ProcessBuilder.NullInputStream.INSTANCE : > >> new > DeferredCloseProcessPipeInputStream(fds[1]); > >> > > Your change looks good and I can sponsor it. Just as a hint for other > > reviewers I'd like to mention that this change, albeit in a shared > > Java file, is still AIX-only because it is in the "AIX" case of a > > switch statement. > > > > @Steve: can you please verify, that your change introduces no > > regression by running the complete jtreg test suite. > > > > Thank you and best regards, > > Volker > > > >> I would appreciate any feedback please, and for someone to be a sponsor > for this and to contributute it to OpenJDK. > >> > >> Steve Groeger > >> IBM Runtime Technologies > >> Hursley, Winchester > >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > >> Fax (44) 1962 816800 > >> Lotus Notes: Steve Groeger/UK/IBM > >> Internet: groeges at uk.ibm.com > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From goetz.lindenmaier at sap.com Mon Dec 10 14:00:48 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 10 Dec 2018 14:00:48 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> <8993984c04d14dcca306993a96bbb82f@sap.com> Message-ID: Hi Steve, I will push it once Roger gives his ok. Best regards, Goetz. > -----Original Message----- > From: Steve Groeger > Sent: Montag, 10. Dezember 2018 14:42 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net; Roger Riggs > Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created > processes does not work. > > Hi Goetz, > > It is good that the tests you ran passed. What needs to be done now to get > this change pushed into the main code? > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: "Lindenmaier, Goetz" > To: Steve Groeger , Roger Riggs > > Cc: "core-libs-dev at openjdk.java.net" > Date: 10/12/2018 10:06 > Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created > processes does not work. > > ________________________________ > > > > > Hi, > > I ran the fix through our tests. There are no new regressions, and the > addressed test works. > > So reviewed from my side. > > I increased the bug to P3 so we can push it to jdk12 in case we > miss Thursday. > > Best regards, > Goetz. > > > -----Original Message----- > > From: core-libs-dev On Behalf > Of > > Steve Groeger > > Sent: Freitag, 7. Dezember 2018 19:08 > > To: Roger Riggs > > Cc: core-libs-dev at openjdk.java.net > > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created > > processes does not work. > > > > Hi Roger, > > > > I have made the same change to the Solaris code and also removed the test > > from the ProblemList.txt > > I have created a webrev here: > > http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ > > > Hope you can now test t > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > > > From: Roger Riggs > > To: core-libs-dev at openjdk.java.net > > Date: 07/12/2018 14:55 > > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between > > created processes does not work. > > Sent by: "core-libs-dev" > > > > > > > > Hi, > > > > I notice that the Solaris case also does not include "|| > > forceNullOutputStream". > > I'll have to investigate why the Pipeline test didn't fail on Solaris. > > > > Please add that to the patch and I'll run it through our tests. > > > > Thanks, Roger > > > > On 12/07/2018 03:05 AM, Volker Simonis wrote: > > > Hi Steve, > > > > > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > > > well, because that's where the review has to take place. The > > > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > > > get their attention on relevant changes (so cross-posting is fine in > > > this case :) > > > > > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger > > wrote: > > >> Hi all, > > >> > > >> I have been investigating the issue > > https://bugs.openjdk.java.net/browse/JDK-8211844 > > > raised by Goetz Lindenmaier which is related to the > > >> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on > > AIX. Having done some investigation I have a potential fix fore the issue: > > >> > > >> > > >> diff -r 9501a7b59111 > > src/java.base/unix/classes/java/lang/ProcessImpl.java > > >> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec > > 03 14:28:19 2018 +0300 > > >> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec > > 06 15:01:03 2018 +0000 > > >> @@ -446,7 +446,7 @@ > > >> ProcessBuilder.NullOutputStream.INSTANCE : > > >> new ProcessPipeOutputStream(fds[0]); > > >> > > >> - stdout = (fds[1] == -1) ? > > >> + stdout = (fds[1] == -1 || forceNullOutputStream) ? > > >> ProcessBuilder.NullInputStream.INSTANCE : > > >> new > > DeferredCloseProcessPipeInputStream(fds[1]); > > >> > > > Your change looks good and I can sponsor it. Just as a hint for other > > > reviewers I'd like to mention that this change, albeit in a shared > > > Java file, is still AIX-only because it is in the "AIX" case of a > > > switch statement. > > > > > > @Steve: can you please verify, that your change introduces no > > > regression by running the complete jtreg test suite. > > > > > > Thank you and best regards, > > > Volker > > > > > >> I would appreciate any feedback please, and for someone to be a > sponsor > > for this and to contributute it to OpenJDK. > > >> > > >> Steve Groeger > > >> IBM Runtime Technologies > > >> Hursley, Winchester > > >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > >> Fax (44) 1962 816800 > > >> Lotus Notes: Steve Groeger/UK/IBM > > >> Internet: groeges at uk.ibm.com > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > 3AU > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > 3AU > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From dmitry.chuyko at bell-sw.com Mon Dec 10 14:16:56 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 10 Dec 2018 17:16:56 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli Message-ID: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> Hello, Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense to add intermediate void* cast to silence the error. bug: https://bugs.openjdk.java.net/browse/JDK-8215009 webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) -Dmitry From alexey.ivanov at oracle.com Mon Dec 10 15:02:05 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 10 Dec 2018 15:02:05 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> Message-ID: <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> On 10/12/2018 10:41, Magnus Ihse Bursie wrote: > > > On 2018-12-07 22:18, Simon Tooke wrote: >> Looking at the code, it seems (to me) the "correct" thing to do is to is >> to create a Windows-specific version of dbgsysBuildFunName() in >> linker_md.c, and have it decorate the function name as appropriate for >> 32-bit windows.? Note that in transport.c, you'd need to pass in the >> parameter stack size (the bit after the @), but it could at least behave >> properly on 32 vs 64 bit Windows. >> >> Notice this approach is already used for the library name, via >> dbgsysBuildLibName() >> >> If the function is never intended to be called by Java via JNI, then it >> should never have been declared JNICALL in the first place - but that >> ship has sailed. >> >> I don't think changing the decorated exported name to undecorated is a >> good idea, as it obfuscates the calling convention used. > Good analysis, Simon. I agree. > > I have now looked more into the situation. In fact, it looks a lot > like JDWP has been broken on Windows 32-bit for a long time, but we > have patched around the issue in the JDK by using /export. This is the > spec we're dealing with: > https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. > I quote: > >> The transport library must export an/onload/function with the >> following prototype: >> >> |JNIEXPORT jint JNICALL jdwpTransport_OnLoad(JavaVM *jvm, >> jdwpTransportCallback *callback, jint version, jdwpTransportEnv** env);| >> >> This function will be called by the JDWP (or other agent) when the >> library is loaded. >> >> > > Nothing here says anything that the function should be exported using > anything other than the normal _stdcall (implied by JNICALL) name > mangling rules. However, JDWP has not been working according to the > spec and looking for the correct symbol, and while we could have > noticed that in the JDK, we didn't, because someone (long ago) added > /export:jdwpTransport_OnLoad as a workaround to the affected > libraries, instead of fixing JDWP. This means that we cannot change the calling convention: it must stay as it is now. I think JDWP has always been working according to the spec. Using __stdcall is the recommended calling convention for Win32 and for DLLs in particular. Usually function names are exported undecorated in DLL. (If my memory serves me well, older Microsoft tools exported |extern "C" __stdcall| functions undecorated.) I believe this ? exporting the undecorated function names ? allows for interoperability between 32 bit and 64 bit in cases where you load a DLL and dynamically look up a function in it. There were too many /export options to export Win32 functions undecorated for this one to be an accident rather than the intention. > Now, given that we've shipped code that didn't adhere to the specs for > so long, we can probably not break that behavior. Instead, I propose > we amend dbgsysBuildFunName() so that on Windows 32-bit, it looks for > both the "jdwpTransport_OnLoad", and the symbol as mangled by _stdcall > rules. I also propose that if both symbols are present, the _stdcall > named one should take precedence, since that's according to the spec > (and the other is just a fallback to maintain backwards compatibility). Since removing JNICALL is not an option, there are only two options: 1. Add |/export| option to the Makefile or pragma-comment to the source file; 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 with fallback to undecorated one. I just wonder how it's possible to implement a generic |dbgsysBuildFunName| for an arbitrary function without knowing the size of function parameters. Could it be the reason why most DLLs export __stdcall functions undecorated? Regards, Alexey > > /Magnus >> -Simon Tooke >> >> >> On 12/7/2018 2:09 PM, Alexey Ivanov wrote: >>> Hi Andrew, >>> >>> Sorry for my belated reply. >>> Yes, it's also an option? however, this solution seems to be >>> overcomplicated to export one function or two. The calling convention >>> of exported functions for JVM cannot be changed, they can be called >>> from third-party software. >>> >>> If the function is used internally-only, its calling convention can be >>> changed as long as all components are updated. >>> >>> Thank you for the pointer to another approach used to handle name >>> decorations of __stdcall functions. It looks we have to work out a >>> common approach to this problem. >>> >>> Regards, >>> Alexey >>> >>> On 27/11/2018 18:49, Andrew Luo wrote: >>>> By the way, in hotspot we are generating a .def file dynamically >>>> while keeping the JNICALL calling convention (for symbols such as >>>> JNI_CreateJavaVM) I believe (just by looking through the code in >>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, >>>> unless this code is inactive - someone who knows this area better >>>> than me might want to comment...).? Shouldn't the same approach be >>>> taken here as well? >>>> >>>> Thanks >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: core-libs-dev On >>>> Behalf Of Ali Ince >>>> Sent: Monday, November 19, 2018 2:08 PM >>>> To: Alexey Ivanov; build-dev >>>> ; core-libs >>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >>>> >>>> Hi Alexey, >>>> >>>> I don?t have an account on JBS as I?m not an author yet, my OCA has >>>> just been processed. Would it be possible for someone with an author >>>> status to create an issue? >>>> >>>> Regards, >>>> >>>> Ali >>>> >>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>>>> wrote: >>>>> >>>>> Hi Ali, >>>>> >>>>> The fix looks good to me provided it resolves your problem. >>>>> I am not a reviewer so you'll have to get OK from reviewers, likely >>>>> from build-dev and from core-libs. >>>>> >>>>> Have you submitted the issue in JBS? >>>>> >>>>> You have to sign OCA to be able to contribute to OpenJDK: >>>>> https://openjdk.java.net/contribute/ >>>>> and also >>>>> https://openjdk.java.net/sponsor/ >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 18/11/2018 12:07, Ali ?nce wrote: >>>>>> Hi Alexey, >>>>>> >>>>>> Below is a new patch content that removes JNICALL modifiers from >>>>>> the exported functions of interest. This results in exported >>>>>> functions not to be name decorated and use __cdecl calling convention. >>>>>> >>>>>> Do you have any more suggestions, or would you please guide me on >>>>>> next steps? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ali >>>>>> >>>>>> # HG changeset patch >>>>>> # User Ali Ince >>>>>> # Date 1542542415 0 >>>>>> #????? Sun Nov 18 12:00:15 2018 +0000 >>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>> # Parent? 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>>>>> builds >>>>>> >>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>> src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c??? Tue Aug >>>>>> 14 14:28:23 2018 +0200 >>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c??? Sun Nov >>>>>> 18 12:00:15 2018 +0000 >>>>>> @@ -339,7 +339,7 @@ >>>>>> ????? return JDWPTRANSPORT_ERROR_NONE;? }? -JNIEXPORT jint JNICALL >>>>>> +JNIEXPORT jint >>>>>> ? jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>> ?????????????????????? jint version, jdwpTransportEnv** result)? { >>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>> src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>> @@ -140,7 +140,7 @@ >>>>>> ????? void (*free)(void *buffer);????? /* Call this for all >>>>>> deallocations */ >>>>>> ? } jdwpTransportCallback; >>>>>> ? -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>> >>>>>> jdwpTransportCallback *callback, >>>>>> ???????????????????????????????????????????????? jint version, >>>>>> ???????????????????????????????????????????????? jdwpTransportEnv** >>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>> --- >>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>> +++ >>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>> @@ -1019,7 +1019,7 @@ >>>>>> ????? return JDWPTRANSPORT_ERROR_NONE;? }? -JNIEXPORT jint JNICALL >>>>>> +JNIEXPORT jint >>>>>> ? jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>> ?????????????????????? jint version, jdwpTransportEnv** env)? { >>>>>> >>>>>> >>>>>> >>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>>>> wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> It's exactly what I referred to. >>>>>>> >>>>>>> Yes, it does change the calling convention. >>>>>>> Yet it's not a (big) problem because both parties will use the >>>>>>> same calling convention. >>>>>>> >>>>>>> Using a DLL from another build will not be possible. But it's not >>>>>>> a good idea to do so anyway. >>>>>>> >>>>>>> >>>>>>> Mapfiles and export options have been removed by >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify >>>>>>> managing exported functions. So that to add or remove an exported >>>>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>>>> just edit the source files. >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Thanks for your reply. >>>>>>>> >>>>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>>>> be __stdcall on windows which is both specified on >>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>>>> and dt_shmem.dll. >>>>>>>> >>>>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>>>> decoration is not applied >>>>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). >>>>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>> >>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>>>> applies to x86 builds) will result in the calling convention to >>>>>>>> be changed, and thus will change how parameters are ordered and >>>>>>>> also the stack cleanup rules. I think this may result in problems >>>>>>>> in programs that are designed to load shared libraries and its >>>>>>>> exported functions at runtime (not bound by link time which >>>>>>>> probably won?t cause any issues - assuming that they use the >>>>>>>> shared function signature) - as in >>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>>>> >>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>>>> the affected functions? >>>>>>>>> >>>>>>>>> Some build / link issues were resolved by adding / removing >>>>>>>>> JNICALL modifier, see >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>>>> .html >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>>>> tml >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> An issue >>>>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) >>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>>>> >>>>>>>>>> Although the expected linker arguments were present on previous >>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>> >>>>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>>>> >>>>>>>>>> Would you please have a look and let me know of any points I >>>>>>>>>> may have missed (I don?t have any background information about >>>>>>>>>> why the export flags were removed in jdk11)? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>> ??????????? jdk.jdwp.agent:include \ >>>>>>>>>> ??????????? jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>> ??????? LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>> +????? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>> ??????? LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>> ??? )) >>>>>>>>>> >>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>>>> 100644 >>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>>>> ????????? libjdwp/export, \ >>>>>>>>>> ????? LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>> ????????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>> +??? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>> ????? LIBS_linux := -lpthread, \ >>>>>>>>>> ????? LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>> ????? LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ > From magnus.ihse.bursie at oracle.com Mon Dec 10 15:11:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 16:11:25 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: On 2018-12-10 16:02, Alexey Ivanov wrote: > > > On 10/12/2018 10:41, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-07 22:18, Simon Tooke wrote: >>> Looking at the code, it seems (to me) the "correct" thing to do is to is >>> to create a Windows-specific version of dbgsysBuildFunName() in >>> linker_md.c, and have it decorate the function name as appropriate for >>> 32-bit windows. Note that in transport.c, you'd need to pass in the >>> parameter stack size (the bit after the @), but it could at least behave >>> properly on 32 vs 64 bit Windows. >>> >>> Notice this approach is already used for the library name, via >>> dbgsysBuildLibName() >>> >>> If the function is never intended to be called by Java via JNI, then it >>> should never have been declared JNICALL in the first place - but that >>> ship has sailed. >>> >>> I don't think changing the decorated exported name to undecorated is a >>> good idea, as it obfuscates the calling convention used. >> Good analysis, Simon. I agree. >> >> I have now looked more into the situation. In fact, it looks a lot >> like JDWP has been broken on Windows 32-bit for a long time, but we >> have patched around the issue in the JDK by using /export. This is >> the spec we're dealing with: >> https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. >> I quote: >> >>> The transport library must export an/onload/function with the >>> following prototype: >>> >>> |JNIEXPORT jint JNICALL jdwpTransport_OnLoad(JavaVM *jvm, >>> jdwpTransportCallback *callback, jint version, jdwpTransportEnv** env);| >>> >>> This function will be called by the JDWP (or other agent) when the >>> library is loaded. >>> >>> >> >> Nothing here says anything that the function should be exported using >> anything other than the normal _stdcall (implied by JNICALL) name >> mangling rules. However, JDWP has not been working according to the >> spec and looking for the correct symbol, and while we could have >> noticed that in the JDK, we didn't, because someone (long ago) added >> /export:jdwpTransport_OnLoad as a workaround to the affected >> libraries, instead of fixing JDWP. > > This means that we cannot change the calling convention: it must stay > as it is now. > > I think JDWP has always been working according to the spec. Using > __stdcall is the recommended calling convention for Win32 and for DLLs > in particular. Usually function names are exported undecorated in DLL. > (If my memory serves me well, older Microsoft tools exported |extern > "C" __stdcall| functions undecorated.) So then the question becomes: what does the spec mean? That the __stdcall convention should be used, or that the function name should be explicitly exported under a non __stdcall-convention name? Neither behavior seems clearly written out, so this is left to an implicit interpretation of what that "usually" means..? > > I believe this ? exporting the undecorated function names ? allows for > interoperability between 32 bit and 64 bit in cases where you load a > DLL and dynamically look up a function in it. > > There were too many /export options to export Win32 functions > undecorated for this one to be an accident rather than the intention. How do you mean? > >> Now, given that we've shipped code that didn't adhere to the specs >> for so long, we can probably not break that behavior. Instead, I >> propose we amend dbgsysBuildFunName() so that on Windows 32-bit, it >> looks for both the "jdwpTransport_OnLoad", and the symbol as mangled >> by _stdcall rules. I also propose that if both symbols are present, >> the _stdcall named one should take precedence, since that's according >> to the spec (and the other is just a fallback to maintain backwards >> compatibility). > > Since removing JNICALL is not an option, there are only two options: > > 1. Add |/export| option to the Makefile or pragma-comment to the > source file; > 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 with > fallback to undecorated one. Yes. I think the correct solution here is 2. > > > I just wonder how it's possible to implement a generic > |dbgsysBuildFunName| for an arbitrary function without knowing the > size of function parameters. Could it be the reason why most DLLs > export __stdcall functions undecorated? (I assume you mean dbgsysFindLibraryEntry; there is a dbgsysBuildFunName as well but it appears to be dead code.) The dbgsysFindLibraryEntry does not need to work with an arbitrary function. It's implemented in jdk.jdwp.agent, for the sole reason of locating the jdwpTransport_OnLoad function. In general, I assume this to hold true. If you don't know the signature of the function you want to call, you're screwed anyway, regardless of calling convention. /Magnus > > Regards, > Alexey > >> >> /Magnus >>> -Simon Tooke >>> >>> >>> On 12/7/2018 2:09 PM, Alexey Ivanov wrote: >>>> Hi Andrew, >>>> >>>> Sorry for my belated reply. >>>> Yes, it's also an option? however, this solution seems to be >>>> overcomplicated to export one function or two. The calling convention >>>> of exported functions for JVM cannot be changed, they can be called >>>> from third-party software. >>>> >>>> If the function is used internally-only, its calling convention can be >>>> changed as long as all components are updated. >>>> >>>> Thank you for the pointer to another approach used to handle name >>>> decorations of __stdcall functions. It looks we have to work out a >>>> common approach to this problem. >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 27/11/2018 18:49, Andrew Luo wrote: >>>>> By the way, in hotspot we are generating a .def file dynamically >>>>> while keeping the JNICALL calling convention (for symbols such as >>>>> JNI_CreateJavaVM) I believe (just by looking through the code in >>>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, >>>>> unless this code is inactive - someone who knows this area better >>>>> than me might want to comment...). Shouldn't the same approach be >>>>> taken here as well? >>>>> >>>>> Thanks >>>>> Andrew >>>>> >>>>> -----Original Message----- >>>>> From: core-libs-dev On >>>>> Behalf Of Ali Ince >>>>> Sent: Monday, November 19, 2018 2:08 PM >>>>> To: Alexey Ivanov; build-dev >>>>> ; core-libs >>>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >>>>> >>>>> Hi Alexey, >>>>> >>>>> I don?t have an account on JBS as I?m not an author yet, my OCA has >>>>> just been processed. Would it be possible for someone with an author >>>>> status to create an issue? >>>>> >>>>> Regards, >>>>> >>>>> Ali >>>>> >>>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>>>>> wrote: >>>>>> >>>>>> Hi Ali, >>>>>> >>>>>> The fix looks good to me provided it resolves your problem. >>>>>> I am not a reviewer so you'll have to get OK from reviewers, likely >>>>>> from build-dev and from core-libs. >>>>>> >>>>>> Have you submitted the issue in JBS? >>>>>> >>>>>> You have to sign OCA to be able to contribute to OpenJDK: >>>>>> https://openjdk.java.net/contribute/ >>>>>> and also >>>>>> https://openjdk.java.net/sponsor/ >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 18/11/2018 12:07, Ali ?nce wrote: >>>>>>> Hi Alexey, >>>>>>> >>>>>>> Below is a new patch content that removes JNICALL modifiers from >>>>>>> the exported functions of interest. This results in exported >>>>>>> functions not to be name decorated and use __cdecl calling convention. >>>>>>> >>>>>>> Do you have any more suggestions, or would you please guide me on >>>>>>> next steps? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> # HG changeset patch >>>>>>> # User Ali Ince >>>>>>> # Date 1542542415 0 >>>>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>>>>>> builds >>>>>>> >>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>> src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug >>>>>>> 14 14:28:23 2018 +0200 >>>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov >>>>>>> 18 12:00:15 2018 +0000 >>>>>>> @@ -339,7 +339,7 @@ >>>>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>>>> +JNIEXPORT jint >>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>> jint version, jdwpTransportEnv** result) { >>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>> src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>>> @@ -140,7 +140,7 @@ >>>>>>> void (*free)(void *buffer); /* Call this for all >>>>>>> deallocations */ >>>>>>> } jdwpTransportCallback; >>>>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>> >>>>>>> jdwpTransportCallback *callback, >>>>>>> jint version, >>>>>>> jdwpTransportEnv** >>>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>> --- >>>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>>> +++ >>>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>>>> +JNIEXPORT jint >>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>> jint version, jdwpTransportEnv** env) { >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Ali, >>>>>>>> >>>>>>>> It's exactly what I referred to. >>>>>>>> >>>>>>>> Yes, it does change the calling convention. >>>>>>>> Yet it's not a (big) problem because both parties will use the >>>>>>>> same calling convention. >>>>>>>> >>>>>>>> Using a DLL from another build will not be possible. But it's not >>>>>>>> a good idea to do so anyway. >>>>>>>> >>>>>>>> >>>>>>>> Mapfiles and export options have been removed by >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify >>>>>>>> managing exported functions. So that to add or remove an exported >>>>>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>>>>> just edit the source files. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>> Hi Alexey, >>>>>>>>> >>>>>>>>> Thanks for your reply. >>>>>>>>> >>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>>>>> be __stdcall on windows which is both specified on >>>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>>>>> and dt_shmem.dll. >>>>>>>>> >>>>>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>>>>> decoration is not applied >>>>>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). >>>>>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>> >>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>>>>> applies to x86 builds) will result in the calling convention to >>>>>>>>> be changed, and thus will change how parameters are ordered and >>>>>>>>> also the stack cleanup rules. I think this may result in problems >>>>>>>>> in programs that are designed to load shared libraries and its >>>>>>>>> exported functions at runtime (not bound by link time which >>>>>>>>> probably won?t cause any issues - assuming that they use the >>>>>>>>> shared function signature) - as in >>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ali >>>>>>>>> >>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Ali, >>>>>>>>>> >>>>>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>>>>> the affected functions? >>>>>>>>>> >>>>>>>>>> Some build / link issues were resolved by adding / removing >>>>>>>>>> JNICALL modifier, see >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>>>>> .html >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>>>>> tml >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexey >>>>>>>>>> >>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> An issue >>>>>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) >>>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>>>>> >>>>>>>>>>> Although the expected linker arguments were present on previous >>>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>> >>>>>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>>>>> >>>>>>>>>>> Would you please have a look and let me know of any points I >>>>>>>>>>> may have missed (I don?t have any background information about >>>>>>>>>>> why the export flags were removed in jdk11)? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Ali >>>>>>>>>>> >>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>> )) >>>>>>>>>>> >>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >> > From brian.goetz at oracle.com Mon Dec 10 16:14:41 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2018 11:14:41 -0500 Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: Message-ID: As will surprise no one, this was extensively discussed during the development of the Streams API.? (Our default position on "convenience methods" is hostile.? While everyone sees the benefit of convenience methods (it's convenient!), most people don't see the cost, which includes the complexity for users to understand the model by looking at the API; having lots of ad-hoc convenience method obscures the underlying model, making it harder for everyone to learn or reason about.? That default position seems to stand up pretty well here, as the stream API is pretty well factored.) Let's be honest: the "convenience" or concision of being able to say .toList() instead of .collect(toList()) is really small.? I don't think you'll be able to justify it by saying "but we do it a lot."? (Digression: to whoever is about to say "then why `toArray()`?? Arrays are different; for better or worse, they're part of the language, and they lend themselves particularly poorly to the Collector API, and there are particular parallelization optimizations that are possible for arrays that can't be accessed through Collector.? End digression.) It is possible, however, that one could justify `toList()` on the basis of _discoverability_.? (Though I'm having a hard time seeing any world where `toSet()` makes the cut.)? New users who approach streams will not easily be able to figure out how to materialize a list from a stream, even though this is an entirely reasonable and quite common thing to want to do.? Having to learn about `collect()` first is asking a lot of users who are still wrapping their heads around streams.? Not only would `toList()` be more discoverable, it would provide a path to discovery of the rest of the `collect()` API.? This is a point in its favor. A significant downside of adding `toList()` is that by diluting the orthogonality of the existing API, it provides both incentive and justification for further dilution, leading to someplace we don't want to be.? (And, the cost of that falls heavily on the stewards, which in turn takes time away from far more valuable activities.) Put it this way: imagine we have a budget of one convenience method in Stream for every five years.? Is this the one we want to spend the next five year's budget on?? (And, who of the proponents will volunteer to answer the next 200 "I have an idea for a stream method" mails, explaining that the budget is spent?) So, summary: ?- I won't outright veto `toList`, as I would for almost all other "convenience" streams additions, because this one actually has a valid non-convenience argument; ?- But, it's still not a slam dunk. On 12/9/2018 5:44 PM, Rob Griffin (rgriffin) wrote: > Hi, > > I have raised an enhancement request (Incident Report 913453) about adding some convenience methods to the Stream interface that collect the stream and Pallavi Sonal asked me to start a thread here about that. > > More than 50% of our Stream collect calls use Collectors.toList() or Collectors.toSet() as arguments so I think it would be very handy if the Stream interface had default collectToList and collectToList and collectToMap methods. > > The advantages are: > it would be easier to use code completion in IDEs. There are lot of classes starting with Collect so finding the Collectors class is a bit of a pain. > one less method call in what is usually a long chain of calls. > > Regards, > > Rob Griffin > Software Analyst, Spotlight on SQL Server > Quest | R&D > rob.griffin at quest.com > From brian.goetz at oracle.com Mon Dec 10 16:15:25 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2018 11:15:25 -0500 Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: Message-ID: <5f25e6ae-091d-d0fe-8f85-3903a51595ed@oracle.com> FTR: already tracking as JDK-8180352. On 12/9/2018 5:44 PM, Rob Griffin (rgriffin) wrote: > Hi, > > I have raised an enhancement request (Incident Report 913453) about adding some convenience methods to the Stream interface that collect the stream and Pallavi Sonal asked me to start a thread here about that. > > More than 50% of our Stream collect calls use Collectors.toList() or Collectors.toSet() as arguments so I think it would be very handy if the Stream interface had default collectToList and collectToList and collectToMap methods. > > The advantages are: > it would be easier to use code completion in IDEs. There are lot of classes starting with Collect so finding the Collectors class is a bit of a pain. > one less method call in what is usually a long chain of calls. > > Regards, > > Rob Griffin > Software Analyst, Spotlight on SQL Server > Quest | R&D > rob.griffin at quest.com > From Roger.Riggs at oracle.com Mon Dec 10 16:59:42 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 10 Dec 2018 11:59:42 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> Message-ID: <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> Hi, Looks good, though some points to clarify. - The methods that use ByteBuffers should be clear that accesses to the ByteBuffers ?? are relative and use and modify the position and ByteBuffer exceptions may be thrown. - The methods that write output (Strings) to an output stream might be more general ? if the argument was a PrintStream, allowing the hex formatted output to be ? assembled with other localized output. ? I do see that as long as HexFormat is only writing hex digits, the effect would be almost the same. ? (It would also eliminate, the inefficient code in getPrintStream that creates a PrintStream on demand). ?- toString(byte[], from, to) and other methods there's no need for parens around the note about fromIndex==toIndex. ?- fromString methods: The optional prefix of "0x": add the phrase "is ignored". ??? The IAE, does not mention the optional prefix, I'm not sure if that allows some confusion. - dumpAsStream(InputStream) does not have a throws NPE for in == null. ? A catch all in the class javadoc could cover that. ? " Unless otherwise noted, passing a null argument to a constructor or method in any class or ?? interface in this package will cause a |NullPointerException| to be thrown. " ?- dumpAsStream methods, the formatter argument is described as being used "if present"; ?? it might be clearer as "if not null". ?- dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be confusing because it ?? is using the relative methods of ByteBuffer, but the from and to offsets are within ?? the position .. limit buffer.? That should be explicit. ?? (Or consider switching to the absolute accesses in the ByteBuffer and not affect the position) - dump(byte[], OutputStream) - I don't think the example is correct, there is no reference ? to a stream, only the PrintStream::println method, which is not static. Regards, Roger On 12/07/2018 08:18 PM, Vincent Ryan wrote: > Here?s the latest version that addresses all the current open issues: > > webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ > > > javadoc: > http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html > > > > CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 > > >> On 7 Dec 2018, at 19:51, Vincent Ryan > > wrote: >> >> Even shorter. I?ll add that instead. >> Thanks. >> >>> On 7 Dec 2018, at 19:04, Roger Riggs >> > wrote: >>> >>> Hi, >>> >>> I don't think this is performance sensitive and less code is better. >>> >>> Use java.lang.Character.digit(ch, 16) to convert the char to an int. >>> >>> Roger >>> >>> On 12/07/2018 01:49 PM, Kasper Nielsen wrote: >>>> Hi, >>>> >>>> I don't know if performance is an issue. But if it is, I think it world >>>> make sense to use a precompute array. And replace >>>> >>>> private static int hexToBinary(char ch) { >>>> ???if ('0' <= ch && ch <= '9') { >>>> ???????return ch - '0'; >>>> ???} >>>> ???if ('A' <= ch && ch <= 'F') { >>>> ???????return ch - 'A' + 10; >>>> ???} >>>> ???if ('a' <= ch && ch <= 'f') { >>>> ???????return ch - 'a' + 10; >>>> ???} >>>> ???return -1; >>>> } >>>> >>>> with >>>> >>>> private static int hexToBinary(char ch) { >>>> ???return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >>>> } >>>> >>>> where int[] staticPrecomputedArray is computed in a static initializer >>>> block. >>>> >>>> /Kasper >>>> >>>> On Fri, 23 Nov 2018 at 14:51, Vincent Ryan >>>> > >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review this proposal for a new API to conveniently generate and >>>>> display binary data using hexadecimal string representation. >>>>> It supports both bulk and stream operations and it can also >>>>> generate the >>>>> well-known hexdump format [1]. >>>>> >>>>> This latest revision addresses review comments provided earlier. >>>>> These include adding methods to support for data supplied in a >>>>> ByteBuffer, exposing the default formatter implementation as a public >>>>> static and dropping the superfluous 'Hex' term from several method >>>>> names. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>>>> API: >>>>> >>>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>>>> >>>>> >>>>> ____ >>>>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >>>>> >>> >> > From Roger.Riggs at oracle.com Mon Dec 10 17:10:28 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 10 Dec 2018 12:10:28 -0500 Subject: RFR: 8212703: Remove sun.java2d.fontpath property from java launcher code In-Reply-To: <5C0CCB50.4050603@oracle.com> References: <270a99cf-2f95-9730-5c92-b947abd2d99c@oracle.com> <5fcbf33a-004d-8156-d917-f4652e871d4a@oracle.com> <7b4d4735-eae2-5a32-d6ed-5c140d50ddf4@oracle.com> <5C0CCB50.4050603@oracle.com> Message-ID: <4496349a-fd51-aa81-4735-bdd9feed715e@oracle.com> Looks fine, Thanks for the test update. Roger On 12/09/2018 02:59 AM, Philip Race wrote: > Here is an update with a Java-only test, using ProcessBuilder. > > http://cr.openjdk.java.net/~prr/8212703.1/index.html > > -phil. > > > On 12/1/18, 9:27 AM, Alan Bateman wrote: >> On 30/11/2018 23:11, Roger Riggs wrote: >>> Hi Phil, >>> >>> That looks fine. >>> >>> Too bad it introduces a new shell test, we're trying to get rid of >>> them. >>> The other alternative would have the test program needed to set the >>> environment >>> and launch a java program. >>> >> The implementation look good to me too and I agree with Roger that we >> shouldn't be introducing a shell test for this. In this case, it >> looks like you just need a /othervm test that checks for the env >> variable and property. >> >> -Alan From erik.joelsson at oracle.com Mon Dec 10 17:25:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 09:25:57 -0800 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: Message-ID: <7f36135b-4c6d-4b14-9477-1cd4d969d3ac@oracle.com> Sounds good to me. /Erik On 2018-12-10 05:19, Magnus Ihse Bursie wrote: > I propose that we introduce a new define, available to all JDK native > files (Hotspot included), called JDK_EXPORT. The behavior of this > symbol will be very similar (as of now, in fact identical) to > JNIEXPORT; however, the semantics will not. > > Currently, we "mis-use" the JNIEXPORT define to mark a function for > exporting from the library. The problem with this is that JNIEXPORT is > part of the JNI interface, and is supposed to be used when C programs > interact with Java. And, when doing this, the function should be fully > decorated like this: "JNIEXPORT foo JNICALL". > > We do have many such JNI exports in our native libraries, but we also > have a lot of other, non-JNI exports, where one native library just > provides an interface to other libraries. In these cases, we have > still used JNIEXPORT for the functionality of getting the function > exported, but we have not been consistent in our use of JNICALL. This > has caused us way too much trouble for something that should Just > Work. > > I therefore propose that we define "JDK_EXPORT", with the same > behavior as JNIEXPORT (that is, flagging the function for external > visibility in the resulting native library), but which is *not* > supposed to be exported to Java code using JNI, nor supposed to be > decorated with JNICALL. All current instances of JNIEXPORT which is > not pure JNI native functions should be changed to use JDK_EXPORT > instead. > > I further propose that this macro should reside in a new file "jdk.h", > placed in the new directory > src/java.base/share/native/include/internal. This header file path > will automatically be provided to all native libraries, but not copied > to the JDK being built. (The existence of a "include/internal" > directory with this behavior has been discussed before. There are more > files that ought to be moved there, if/when it is created.) I believe > in many cases the #include "jni.h" can be just modified to #include > "#jdk.h", since most native code will not require "jni.h" unless > actually doing JNI calls -- most have included this file to get the > JNIEXPORT macro, which would explain the pervasive use of #include > "jni.h" in our code base. > > Thoughts? > > /Magnus > From forax at univ-mlv.fr Mon Dec 10 17:26:18 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 10 Dec 2018 18:26:18 +0100 (CET) Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: Message-ID: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> Hi Rob, i will add to the answer of Brian that if you have too many .collect(toList()), it's perhaps your application perhaps suffers of the equivalent of the n + 1 select query you have with SQL but with the Stream API. You should try to see if returning a Stream instead of a List for some of methods is not a better option: public List getAllEmployee() { return employees.stream().filter(Employee::isActive).collect(toList()); } public List getManager(List list) { return list.stream().filter(Employee::isManager).collect(toList()); } ... getManager(getAllEmployee()); should be: public Stream getAllEmployee() { return employees.stream().filter(Employee::isActive); } public Stream getManager(Stream stream) { return stream.filter(Employee::isManager); } ... getManager(getAllEmployee()).collect(toList()); regards, R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Rob Griffin (rgriffin)" , "core-libs-dev" > Envoy?: Lundi 10 D?cembre 2018 17:14:41 > Objet: Re: Add convenience collect methods to the Stream interface > As will surprise no one, this was extensively discussed during the > development of the Streams API.? (Our default position on "convenience > methods" is hostile.? While everyone sees the benefit of convenience > methods (it's convenient!), most people don't see the cost, which > includes the complexity for users to understand the model by looking at > the API; having lots of ad-hoc convenience method obscures the > underlying model, making it harder for everyone to learn or reason > about.? That default position seems to stand up pretty well here, as the > stream API is pretty well factored.) > > Let's be honest: the "convenience" or concision of being able to say > .toList() instead of .collect(toList()) is really small.? I don't think > you'll be able to justify it by saying "but we do it a lot." > (Digression: to whoever is about to say "then why `toArray()`?? Arrays > are different; for better or worse, they're part of the language, and > they lend themselves particularly poorly to the Collector API, and there > are particular parallelization optimizations that are possible for > arrays that can't be accessed through Collector.? End digression.) > > It is possible, however, that one could justify `toList()` on the basis > of _discoverability_.? (Though I'm having a hard time seeing any world > where `toSet()` makes the cut.)? New users who approach streams will not > easily be able to figure out how to materialize a list from a stream, > even though this is an entirely reasonable and quite common thing to > want to do.? Having to learn about `collect()` first is asking a lot of > users who are still wrapping their heads around streams.? Not only would > `toList()` be more discoverable, it would provide a path to discovery of > the rest of the `collect()` API.? This is a point in its favor. > > A significant downside of adding `toList()` is that by diluting the > orthogonality of the existing API, it provides both incentive and > justification for further dilution, leading to someplace we don't want > to be.? (And, the cost of that falls heavily on the stewards, which in > turn takes time away from far more valuable activities.) > > Put it this way: imagine we have a budget of one convenience method in > Stream for every five years.? Is this the one we want to spend the next > five year's budget on?? (And, who of the proponents will volunteer to > answer the next 200 "I have an idea for a stream method" mails, > explaining that the budget is spent?) > > > So, summary: > > ?- I won't outright veto `toList`, as I would for almost all other > "convenience" streams additions, because this one actually has a valid > non-convenience argument; > ?- But, it's still not a slam dunk. > > > On 12/9/2018 5:44 PM, Rob Griffin (rgriffin) wrote: >> Hi, >> >> I have raised an enhancement request (Incident Report 913453) about adding some >> convenience methods to the Stream interface that collect the stream and Pallavi >> Sonal asked me to start a thread here about that. >> >> More than 50% of our Stream collect calls use Collectors.toList() or >> Collectors.toSet() as arguments so I think it would be very handy if the Stream >> interface had default collectToList and collectToList and collectToMap methods. >> >> The advantages are: >> it would be easier to use code completion in IDEs. There are lot of classes >> starting with Collect so finding the Collectors class is a bit of a pain. >> one less method call in what is usually a long chain of calls. >> >> Regards, >> >> Rob Griffin >> Software Analyst, Spotlight on SQL Server >> Quest | R&D >> rob.griffin at quest.com From Roger.Riggs at oracle.com Mon Dec 10 17:29:47 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 10 Dec 2018 12:29:47 -0500 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> <8993984c04d14dcca306993a96bbb82f@sap.com> Message-ID: Hi, The change looks fine and passes the current tests. So ok to push. I think the test isn't correct, but I have not yet worked up a revised test. Thanks, Roger On 12/10/2018 09:00 AM, Lindenmaier, Goetz wrote: > Hi Steve, > > I will push it once Roger gives his ok. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Steve Groeger >> Sent: Montag, 10. Dezember 2018 14:42 >> To: Lindenmaier, Goetz >> Cc: core-libs-dev at openjdk.java.net; Roger Riggs >> Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created >> processes does not work. >> >> Hi Goetz, >> >> It is good that the tests you ran passed. What needs to be done now to get >> this change pushed into the main code? >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> >> >> >> From: "Lindenmaier, Goetz" >> To: Steve Groeger , Roger Riggs >> >> Cc: "core-libs-dev at openjdk.java.net" >> Date: 10/12/2018 10:06 >> Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created >> processes does not work. >> >> ________________________________ >> >> >> >> >> Hi, >> >> I ran the fix through our tests. There are no new regressions, and the >> addressed test works. >> >> So reviewed from my side. >> >> I increased the bug to P3 so we can push it to jdk12 in case we >> miss Thursday. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: core-libs-dev On Behalf >> Of >>> Steve Groeger >>> Sent: Freitag, 7. Dezember 2018 19:08 >>> To: Roger Riggs >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created >>> processes does not work. >>> >>> Hi Roger, >>> >>> I have made the same change to the Solaris code and also removed the test >>> from the ProblemList.txt >>> I have created a webrev here: >>> http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ >> >>> Hope you can now test t >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >> number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >>> >>> >>> >>> From: Roger Riggs >>> To: core-libs-dev at openjdk.java.net >>> Date: 07/12/2018 14:55 >>> Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between >>> created processes does not work. >>> Sent by: "core-libs-dev" >>> >>> >>> >>> Hi, >>> >>> I notice that the Solaris case also does not include "|| >>> forceNullOutputStream". >>> I'll have to investigate why the Pipeline test didn't fail on Solaris. >>> >>> Please add that to the patch and I'll run it through our tests. >>> >>> Thanks, Roger >>> >>> On 12/07/2018 03:05 AM, Volker Simonis wrote: >>>> Hi Steve, >>>> >>>> thanks a lot for this fix. I'm forwarding this to core-libs-dev as >>>> well, because that's where the review has to take place. The >>>> "ppc-aix-port-dev" list is mostly a marker for the port maintainers to >>>> get their attention on relevant changes (so cross-posting is fine in >>>> this case :) >>>> >>>> On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger >>> wrote: >>>>> Hi all, >>>>> >>>>> I have been investigating the issue >>> https://bugs.openjdk.java.net/browse/JDK-8211844 >> >>> raised by Goetz Lindenmaier which is related to the >>>>> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on >>> AIX. Having done some investigation I have a potential fix fore the issue: >>>>> >>>>> diff -r 9501a7b59111 >>> src/java.base/unix/classes/java/lang/ProcessImpl.java >>>>> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec >>> 03 14:28:19 2018 +0300 >>>>> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec >>> 06 15:01:03 2018 +0000 >>>>> @@ -446,7 +446,7 @@ >>>>> ProcessBuilder.NullOutputStream.INSTANCE : >>>>> new ProcessPipeOutputStream(fds[0]); >>>>> >>>>> - stdout = (fds[1] == -1) ? >>>>> + stdout = (fds[1] == -1 || forceNullOutputStream) ? >>>>> ProcessBuilder.NullInputStream.INSTANCE : >>>>> new >>> DeferredCloseProcessPipeInputStream(fds[1]); >>>> Your change looks good and I can sponsor it. Just as a hint for other >>>> reviewers I'd like to mention that this change, albeit in a shared >>>> Java file, is still AIX-only because it is in the "AIX" case of a >>>> switch statement. >>>> >>>> @Steve: can you please verify, that your change introduces no >>>> regression by running the complete jtreg test suite. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>>> I would appreciate any feedback please, and for someone to be a >> sponsor >>> for this and to contributute it to OpenJDK. >>>>> Steve Groeger >>>>> IBM Runtime Technologies >>>>> Hursley, Winchester >>>>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>>>> Fax (44) 1962 816800 >>>>> Lotus Notes: Steve Groeger/UK/IBM >>>>> Internet: groeges at uk.ibm.com >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 >>> 3AU >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>> number 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 >>> 3AU >>> >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >> number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU From claes.redestad at oracle.com Mon Dec 10 17:36:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 10 Dec 2018 18:36:05 +0100 Subject: RFR: 8215017: Improve String::equals warmup characteristics In-Reply-To: References: Message-ID: Hi, Tobias weighed in on this in another thread[1], and while he thinks the proposed patch is semantically correct, concerns was raised that maybe the UTF16 intrinsics could be superior (on some platforms). I ran the microbenchmark below as well as existing string-density- benchmark[2] suite, noting no statistically significant differences for peak performance on x64_86 (Windows, Linux, Mac) and SPARC T4 through M7. Warmup improvements are similar across all platforms. So from our point of view things look green. However, I have no means of testing the intrinsics on other platforms (S390, aarch64, ppc), so it'd be much appreciated if performance could be verified on those platforms using the proposed patch and benchmark. By inspecting code it seems the difference should be negligible or even positive, e.g., on aarch64 there's a trailing comparison that is elided when treating the byte[] as a char[] - overhead that is possibly offset entirely by removing an extra branch before going into the intrinsics. Thanks! /Claes [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057240.html [2] http://cr.openjdk.java.net/~shade/density/string-density-bench.zip (had to remove hg maven plugin, reference to sun.misc.Version and update JMH version for this to build and run on latest JDK) On 2018-12-08 01:11, Claes Redestad wrote: > Hi, > > following up from discussions during review of JDK-8214971[1], I > examined the startup and peak performance of a few different variant of > writing String::equals. > > Webrev: http://cr.openjdk.java.net/~redestad/8215017/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215017 > > - folding coder() == aString.coder() into sameCoder(aString) helps > interpreter without adversely affecting higher optimization levels > > - Jim's proposal to use Arrays.equals is _interesting_: it improves > peak performance on some inputs but regress it on others. I'll defer > that to a future RFE as it needs a more thorough examination. > > - what we can do is simplify to only use StringLatin1.equals. If I'm not > completely mistaken these are all semantically neutral (and > StringUTF16.equals effectively redundant). If I'm completely wrong here > I'll welcome the learning opportunity. :-) > > This removes a branch and two method calls, and for UTF16 Strings we'll > use a simpler algorithm early, which turns out to be beneficial during > interpreter and C1 level. > > I added a simple microbenchmark to explore this, results show 1.2-2.5x > improvements in interpreter performance, while remaining perfectly > neutral results for optimized code on this simple micro[2]. > > This could be extended to clean up and move StringLatin1.equals back > into String and remove StringUTF16, but we'd also need to rearrange the > intrinsics on the VM side. Let me know what you think. > > Thanks! > > /Claes > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057162.html > > > [2] > ========== Baseline ================= > > -Xint > Benchmark??????????????????????????? Mode? Cnt???? Score??? Error? Units > StringEquals.equalsAlmostEqual?????? avgt??? 4?? 968.640 ?? 1.337? ns/op > StringEquals.equalsAlmostEqualUTF16? avgt??? 4? 2082.007 ?? 5.303? ns/op > StringEquals.equalsDifferent???????? avgt??? 4?? 583.166 ? 29.461? ns/op > StringEquals.equalsDifferentCoders?? avgt??? 4?? 422.993 ?? 1.291? ns/op > StringEquals.equalsEqual???????????? avgt??? 4?? 988.671 ?? 1.492? ns/op > StringEquals.equalsEqualsUTF16?????? avgt??? 4? 2103.060 ?? 5.705? ns/op > > -XX:+CompactStrings > Benchmark??????????????????????????? Mode? Cnt?? Score?? Error? Units > StringEquals.equalsAlmostEqual?????? avgt??? 4? 23.896 ? 0.089? ns/op > StringEquals.equalsAlmostEqualUTF16? avgt??? 4? 23.935 ? 0.562? ns/op > StringEquals.equalsDifferent???????? avgt??? 4? 15.086 ? 0.044? ns/op > StringEquals.equalsDifferentCoders?? avgt??? 4? 12.572 ? 0.008? ns/op > StringEquals.equalsEqual???????????? avgt??? 4? 25.143 ? 0.025? ns/op > StringEquals.equalsEqualsUTF16?????? avgt??? 4? 25.148 ? 0.021? ns/op > > -XX:-CompactStrings > Benchmark??????????????????????????? Mode? Cnt?? Score?? Error? Units > StringEquals.equalsAlmostEqual?????? avgt??? 4? 24.539 ? 0.127? ns/op > StringEquals.equalsAlmostEqualUTF16? avgt??? 4? 22.638 ? 0.047? ns/op > StringEquals.equalsDifferent???????? avgt??? 4? 13.930 ? 0.835? ns/op > StringEquals.equalsDifferentCoders?? avgt??? 4? 13.836 ? 0.025? ns/op > StringEquals.equalsEqual???????????? avgt??? 4? 26.420 ? 0.020? ns/op > StringEquals.equalsEqualsUTF16?????? avgt??? 4? 23.889 ? 0.037? ns/op > > ========== Fix ====================== > > -Xint > Benchmark??????????????????????????? Mode? Cnt??? Score???? Error? Units > StringEquals.equalsAlmostEqual?????? avgt??? 4? 811.859 ??? 8.663? ns/op > StringEquals.equalsAlmostEqualUTF16? avgt??? 4? 802.784 ? 352.884? ns/op > StringEquals.equalsDifferent???????? avgt??? 4? 431.837 ??? 1.884? ns/op > StringEquals.equalsDifferentCoders?? avgt??? 4? 358.244 ??? 1.208? ns/op > StringEquals.equalsEqual???????????? avgt??? 4? 832.056 ??? 3.541? ns/op > StringEquals.equalsEqualsUTF16?????? avgt??? 4? 832.434 ??? 3.516? ns/op > > -XX:+CompactStrings > Benchmark??????????????????????????? Mode? Cnt?? Score?? Error? Units > StringEquals.equalsAlmostEqual?????? avgt??? 4? 23.906 ? 0.151? ns/op > StringEquals.equalsAlmostEqualUTF16? avgt??? 4? 23.905 ? 0.123? ns/op > StringEquals.equalsDifferent???????? avgt??? 4? 15.088 ? 0.023? ns/op > StringEquals.equalsDifferentCoders?? avgt??? 4? 12.575 ? 0.030? ns/op > StringEquals.equalsEqual???????????? avgt??? 4? 25.149 ? 0.059? ns/op > StringEquals.equalsEqualsUTF16?????? avgt??? 4? 25.149 ? 0.033? ns/op > > -XX:-CompactStrings > Benchmark??????????????????????????? Mode? Cnt?? Score?? Error? Units > StringEquals.equalsAlmostEqual?????? avgt??? 4? 24.521 ? 0.050? ns/op > StringEquals.equalsAlmostEqualUTF16? avgt??? 4? 22.639 ? 0.035? ns/op > StringEquals.equalsDifferent???????? avgt??? 4? 13.831 ? 0.020? ns/op > StringEquals.equalsDifferentCoders?? avgt??? 4? 13.884 ? 0.345? ns/op > StringEquals.equalsEqual???????????? avgt??? 4? 26.395 ? 0.066? ns/op > StringEquals.equalsEqualsUTF16?????? avgt??? 4? 23.904 ? 0.112? ns/op From martinrb at google.com Mon Dec 10 17:44:09 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 10 Dec 2018 09:44:09 -0800 Subject: RFR: 8215017: Improve String::equals warmup characteristics In-Reply-To: References: Message-ID: Claes, make sure you've mind-melded with Aleksey on this, e.g. via https://www.youtube.com/watch?v=wIyeOaitmWM On Fri, Dec 7, 2018 at 4:07 PM Claes Redestad wrote: > Hi, > > following up from discussions during review of JDK-8214971[1], I > examined the startup and peak performance of a few different variant of > writing String::equals. > > Webrev: http://cr.openjdk.java.net/~redestad/8215017/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215017 > > - folding coder() == aString.coder() into sameCoder(aString) helps > interpreter without adversely affecting higher optimization levels > > - Jim's proposal to use Arrays.equals is _interesting_: it improves > peak performance on some inputs but regress it on others. I'll defer > that to a future RFE as it needs a more thorough examination. > > - what we can do is simplify to only use StringLatin1.equals. If I'm not > completely mistaken these are all semantically neutral (and > StringUTF16.equals effectively redundant). If I'm completely wrong here > I'll welcome the learning opportunity. :-) > > This removes a branch and two method calls, and for UTF16 Strings we'll > use a simpler algorithm early, which turns out to be beneficial during > interpreter and C1 level. > > I added a simple microbenchmark to explore this, results show 1.2-2.5x > improvements in interpreter performance, while remaining perfectly > neutral results for optimized code on this simple micro[2]. > > This could be extended to clean up and move StringLatin1.equals back > into String and remove StringUTF16, but we'd also need to rearrange the > intrinsics on the VM side. Let me know what you think. > > Thanks! > > /Claes > > [1] > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057162.html > > [2] > ========== Baseline ================= > > -Xint > Benchmark Mode Cnt Score Error Units > StringEquals.equalsAlmostEqual avgt 4 968.640 ? 1.337 ns/op > StringEquals.equalsAlmostEqualUTF16 avgt 4 2082.007 ? 5.303 ns/op > StringEquals.equalsDifferent avgt 4 583.166 ? 29.461 ns/op > StringEquals.equalsDifferentCoders avgt 4 422.993 ? 1.291 ns/op > StringEquals.equalsEqual avgt 4 988.671 ? 1.492 ns/op > StringEquals.equalsEqualsUTF16 avgt 4 2103.060 ? 5.705 ns/op > > -XX:+CompactStrings > Benchmark Mode Cnt Score Error Units > StringEquals.equalsAlmostEqual avgt 4 23.896 ? 0.089 ns/op > StringEquals.equalsAlmostEqualUTF16 avgt 4 23.935 ? 0.562 ns/op > StringEquals.equalsDifferent avgt 4 15.086 ? 0.044 ns/op > StringEquals.equalsDifferentCoders avgt 4 12.572 ? 0.008 ns/op > StringEquals.equalsEqual avgt 4 25.143 ? 0.025 ns/op > StringEquals.equalsEqualsUTF16 avgt 4 25.148 ? 0.021 ns/op > > -XX:-CompactStrings > Benchmark Mode Cnt Score Error Units > StringEquals.equalsAlmostEqual avgt 4 24.539 ? 0.127 ns/op > StringEquals.equalsAlmostEqualUTF16 avgt 4 22.638 ? 0.047 ns/op > StringEquals.equalsDifferent avgt 4 13.930 ? 0.835 ns/op > StringEquals.equalsDifferentCoders avgt 4 13.836 ? 0.025 ns/op > StringEquals.equalsEqual avgt 4 26.420 ? 0.020 ns/op > StringEquals.equalsEqualsUTF16 avgt 4 23.889 ? 0.037 ns/op > > ========== Fix ====================== > > -Xint > Benchmark Mode Cnt Score Error Units > StringEquals.equalsAlmostEqual avgt 4 811.859 ? 8.663 ns/op > StringEquals.equalsAlmostEqualUTF16 avgt 4 802.784 ? 352.884 ns/op > StringEquals.equalsDifferent avgt 4 431.837 ? 1.884 ns/op > StringEquals.equalsDifferentCoders avgt 4 358.244 ? 1.208 ns/op > StringEquals.equalsEqual avgt 4 832.056 ? 3.541 ns/op > StringEquals.equalsEqualsUTF16 avgt 4 832.434 ? 3.516 ns/op > > -XX:+CompactStrings > Benchmark Mode Cnt Score Error Units > StringEquals.equalsAlmostEqual avgt 4 23.906 ? 0.151 ns/op > StringEquals.equalsAlmostEqualUTF16 avgt 4 23.905 ? 0.123 ns/op > StringEquals.equalsDifferent avgt 4 15.088 ? 0.023 ns/op > StringEquals.equalsDifferentCoders avgt 4 12.575 ? 0.030 ns/op > StringEquals.equalsEqual avgt 4 25.149 ? 0.059 ns/op > StringEquals.equalsEqualsUTF16 avgt 4 25.149 ? 0.033 ns/op > > -XX:-CompactStrings > Benchmark Mode Cnt Score Error Units > StringEquals.equalsAlmostEqual avgt 4 24.521 ? 0.050 ns/op > StringEquals.equalsAlmostEqualUTF16 avgt 4 22.639 ? 0.035 ns/op > StringEquals.equalsDifferent avgt 4 13.831 ? 0.020 ns/op > StringEquals.equalsDifferentCoders avgt 4 13.884 ? 0.345 ns/op > StringEquals.equalsEqual avgt 4 26.395 ? 0.066 ns/op > StringEquals.equalsEqualsUTF16 avgt 4 23.904 ? 0.112 ns/op > From Alan.Bateman at oracle.com Mon Dec 10 18:03:54 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2018 18:03:54 +0000 Subject: RFR: 8212703: Remove sun.java2d.fontpath property from java launcher code In-Reply-To: <5C0CCB50.4050603@oracle.com> References: <270a99cf-2f95-9730-5c92-b947abd2d99c@oracle.com> <5fcbf33a-004d-8156-d917-f4652e871d4a@oracle.com> <7b4d4735-eae2-5a32-d6ed-5c140d50ddf4@oracle.com> <5C0CCB50.4050603@oracle.com> Message-ID: <926138eb-4c77-b472-0869-d0b0bbec1a26@oracle.com> On 09/12/2018 07:59, Philip Race wrote: > Here is an update with a Java-only test, using ProcessBuilder. > > http://cr.openjdk.java.net/~prr/8212703.1/index.html Looks okay to me. -Alan From andy.herrick at oracle.com Mon Dec 10 18:21:42 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 10 Dec 2018 13:21:42 -0500 Subject: JEP 343: Packaging Tool Implementation - Status Update Message-ID: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation The initial request for review was sent out on October 23, with a refresh on November 11. Since then we have been continuing to fix bugs and add needed functionality in response to the feedback we have received (full list below). Our current plan is: 1.) To publish /jpackage/ EA (Early Access) binaries (built from the sandbox repository) soon (before end of 2018). 2.) To have JEP 343 targeted and integrated into JDK13 early in 2019. We are continuing to work through issues targeted to "internal" (meaning we expect to integrate them into JDK-8200758-branch of the open sandbox before before the whole branch is merged into OpenJDK). The list of issues we have pushed to the sandbox since the initial RFR is as follows: JDK-8214070???? Analyze and Fix issues reported by Parfait JDK-8214051???? rename jpackager tool to jpackage JDK-8212936???? Makefile and other improvements for jpackager JDK-8213756???? SingleInstance runtime improvements JDK-8213324???? jpackager deletes existing app directory without warning JDK-8213166???? jpackager --argument arg is broken JDK-8213163???? --app-image arg does not work creating exe installers JDK-8213385???? jpackager Command-Line Argument File. JDK-8214143???? Reduce Resource files JDK-8213748???? jpackager native launcher for macosx, linux. JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk JDK-8213963???? Flatten out jpackager packages and resources. JDK-8214021???? Create additional automated tests for jpackager JDK-8213332???? Create minimal automated tests for jpackager JDK-8213333???? Fix issues found in jpackager with automated tests JDK-8213394???? Stop using Log.info() except for expected output. JDK-8213345???? Secondary Launchers broken on mac. JDK-8213156???? rename packages for jpackager JDK-8213244???? Fix all warnings in jpackager java code JDK-8213162???? Association description in Inno Setup cannot contain double quotes /Andy Herrick From vladimir.kozlov at oracle.com Mon Dec 10 19:32:37 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Dec 2018 11:32:37 -0800 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 Message-ID: <8f0a6226-d0b1-8c19-fb36-b620f6ee0819@oracle.com> On 12/9/18 5:28 PM, Michihiro Horie wrote: > Hi Vladimir, > > Thanks a lot for your review. I also fixed the copyright in intrinsicnode.hpp. > > >Did you look on code generated by C2 with your latest changes? > Yes,I usually check generated code with Oprofile and they were as expected like: > : > 90 0.0905 : 3fff64c27654: rlwinm r12,r9,24,8,31 > 12 0.0121 : 3fff64c27658: li r11,14640 > 15 0.0151 : 3fff64c2765c: cmprb cr5,0,r31,r11 > 5527 5.5587 : 3fff64c27660: setb r11,cr5 > 36010 36.2164 : 3fff64c27664: stb r11,16(r15) Good. > : > > I found a CSR FAQ that mentions adding a diagnostic flag do not need CSR process. This time I do not need CSR. > https://wiki.openjdk.java.net/display/csr/CSR+FAQs Thank is correct. > > Hi Gustavo, > Could I ask you to sponsor the latest change webrev.05? I would like you to test it on your P9 node too. Thanks, Vladimir > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Vladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > To: RogerVladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov To: Roger Riggs > , Michihiro Horie > > From: Vladimir Kozlov > To: Roger Riggs , Michihiro Horie > Cc: core-libs-dev at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, volker.simonis at sap.com > Date: 2018/12/08 03:48 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------------------------------------------------------ > > > > Hi Michihiro, > > Hotspot changes looks fine. > Did you look on code generated by C2 with your latest changes? > > And Copyright year change in intrinsicnode.hpp is incorrect: > > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > > Should be > > * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > > > Thanks, > Vladimir > > On 12/7/18 10:08 AM, Roger Riggs wrote: > > Hi Michihiro, > > > > Looks fine with the updates. > > > > Its great that the change to isDigit is beneficial on other platforms too. > > > > A very small editorial: > > ?? There should be a comma? "," after the 2018 in the copyright of: > > ?? test/micro/org/openjdk/bench/java/lang/Characters.java > > > > Thanks, Roger > > > > > > On 12/07/2018 03:13 AM, Michihiro Horie wrote: > >> > >> Hi Roger, > >> > >> I updated my webrev. > >> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ > >> > >> > >> >0x80 might be a good choice or 0xff. > >> I agree,thanks. > >> > >> >I was wondering about the performance without the PPC specific intrinsic but with the > >> >CharacterDataLatin1.java.template code for isDigit being: > >> >??? ??? return '0' <= ch && ch <= '9'; > >> I now understand your point,thanks for your explanation. Both on Power9 and Skylake, the > >> isDigit(ch)using ?0???9?explicitly in CharacterDataLatin1.java.template without PPC specific > >> intrinsicwas around 15% faster than the original code that does not include my changes. I fixed my > >> change using ?0???9?for this isDigit(ch). > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 > >> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 > >> AM, Michihiro Horie wrote: > >> > >> From: Roger Riggs > >> To: Michihiro Horie > >> Cc: core-libs-dev at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, > >> vladimir.kozlov at oracle.com, volker.simonis at sap.com > >> Date: 2018/12/07 01:23 > >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> ---------------------------------------------------------------------------------------------------- > >> > >> > >> > >> Hi Michihiro, > >> > >> On 12/06/2018 02:38 AM, Michihiro Horie wrote: > >> > >> ? ? ? ? Hi Roger, > >> > >> ? ? ? ? Thank you for your helpful comments. I updated new webrev, adding a parameter in the jmh > >> ? ? ? ? test to measure ?other? characters and moving the file to an appropriate location, also > >> ? ? ? ? fixing the indents and copyright year._ > >> > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.03_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=aKLGn7JZawWsl9UR7H-PyYoTpBc23BAKMqGScywbC5U&e= > >> ? ? ? ? > >> > >> The choice of 256 for other is outside the range of Latin1 which is 0..255. > >> 0x80 might be a good choice or 0xff. > >> > >> > >> ? ? ? ? >Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' > >> ? ? ? ? >in CharacterDataLatin1.java.template?? The performance would need to be measured and > >> ? ? ? ? compared. > >> ? ? ? ? Yes, there is an opportunity: intrinsic performed 25% better than the original on Power9. > >> > >> I was wondering about the performance without the PPC specific intrinsic but with the > >> CharacterDataLatin1.java.template code for isDigit being: > >> ??? ??? return '0' <= ch && ch <= '9'; > >> > >> > >> ? ? ? ? >Is the profile of in-lining methods changed in any measurable way now that > >> ? ? ? ? >there is an extra level of method invocation? > >> ? ? ? ? > ?? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == > >> ? ? ? ? LOWERCASE_LETTER; > >> ? ? ? ? > > >> ? ? ? ? >instead of: > >> ? ? ? ? >??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > >> ? ? ? ? I missed this point, thanks. I tried jstack but could not find additional level. > >> > >> ? ? ? ? LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled in c1: > >> ? ? ? ? >> ? ? ? ? address='0x00003fff5911cb90' relocation_offset='344' insts_offset='368' stub_offset='1136' > >> ? ? ? ? scopes_data_offset='1248' scopes_pcs_offset='1336' dependencies_offset='1448' > >> ? ? ? ? nul_chk_table_offset='1456' oops_offset='1184' metadata_offset='1192' > >> ? ? ? ? method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' bytes='15' count='1024' > >> ? ? ? ? iicount='1025' stamp='0.058'/> > >> > >> Supposing some existing complex code was already taking advantage of the full allowed inline depth. > >> Then adding an extra level might change the inlining behavior. > >> > >> > >> ? ? ? ? Existing methods in CharacterDataLatin1.java.template etc. directly invoke > >> ? ? ? ? getProperties(ch), so isLowerCase(ch) would be more aligned with other methods if it looks > >> ? ? ? ? like as follows? > >> ? ? ? ? + @HotSpotIntrinsicCandidate > >> ? ? ? ? + boolean isLowerCase(int ch) { > >> ? ? ? ? + int props = getProperties(ch); > >> ? ? ? ? + return (props & $$maskType) == Character.LOWERCASE_LETTER; > >> ? ? ? ? + } > >> > >> Yes, that would alleviate my concern. > >> > >> Thanks, Roger > >> > >> > >> > >> ? ? ? ? Best regards, > >> ? ? ? ? -- > >> ? ? ? ? Michihiro, > >> ? ? ? ? IBM Research - Tokyo > >> > >> ? ? ? ? Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 > >> ? ? ? ? 07:21 AM, Michihiro Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On > >> ? ? ? ? 12/05/2018 07:21 AM, Michihiro Horie wrote: > >> > >> ? ? ? ? From: Roger Riggs __ > >> ? ? ? ? To: Michihiro Horie __ , > >> ? ? ? ? _vladimir.kozlov at oracle.com_ > >> ? ? ? ? Cc: _core-libs-dev at openjdk.java.net_ , > >> ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ , > >> ? ? ? ? _martin.doerr at sap.com_ , _volker.simonis at sap.com_ > >> ? ? ? ? > >> ? ? ? ? Date: 2018/12/06 05:09 > >> ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ---------------------------------------------------------------------------------------------------- > >> > >> > >> > >> ? ? ? ? Hi Michihiro, > >> > >> ? ? ? ? On 12/05/2018 07:21 AM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? >There are a few JMH tests for upper and lower in the > >> ? ? ? ? ? ? ? ? ? ? ? ? jmh-jdk-microbenchmarks repo. [1] > >> ? ? ? ? ? ? ? ? ? ? ? ? Here is a jmh webrev for the Character methods._ > >> > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_jmh-2Dwebrev.00_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=v22au5r5gvv48ufyda1poelXBjJWwuotSFrv-M2AlRY&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? Please include at least one > character value that is not a member of any of the classes. > >> ? ? ? ? The performance impact for 'other' characters is important also. > >> > >> ? ? ? ? The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: > >> ? ? ? ? ?? test/micro/org/openjdk/bench/java/lang/ > >> > >> ? ? ? ? Now that they are in that repo, they can be included with the rest of the changeset. > >> ? ? ? ? ? ? ? ? ? ? ? ? Also, I updated C2 changes in the latest webrev. (Thank you for giving > >> ? ? ? ? ? ? ? ? ? ? ? ? valuable comments off-list, Vladimir and Martin!) > >> ? ? ? ? ? ? ? ? ? ? ? ? With the change in is_disabled_by_flags, I added a JVM flag that will need > >> ? ? ? ? ? ? ? ? ? ? ? ? another review request. I would proceed for it if this RFR is accepted._ > >> > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.02_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=UXQByb5dFxfAwCCppkizqG_-RWf6DhE_PFkr9TsyzKo&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? The indent in the Java code should > be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 > >> ? ? ? ? spaces) > >> > >> ? ? ? ? Please update the copyrights to include 2018. > >> > >> ? ? ? ? Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' > >> ? ? ? ? in CharacterDataLatin1.java.template?? The performance would need to be measured and compared. > >> > >> ? ? ? ? Is the profile of in-lining methods changed in any measurable way now that > >> ? ? ? ? there is an extra level of method invocation? > >> ? ? ? ? ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == > >> ? ? ? ? LOWERCASE_LETTER; > >> > >> ? ? ? ? instead of: > >> ? ? ? ? ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > >> > >> ? ? ? ? Regards, Roger > >> ? ? ? ? ? ? ? ? ? ? ? ? I need a review on changes in the class library, anyway. Would be grateful > >> ? ? ? ? ? ? ? ? ? ? ? ? if I could have one. > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? -- > >> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? ----- Original message ----- > >> ? ? ? ? ? ? ? ? ? ? ? ? From: Michihiro Horie/Japan/IBM > >> ? ? ? ? ? ? ? ? ? ? ? ? To: Vladimir Kozlov __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , Roger Riggs __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? Date: Fri, Nov 30, 2018 1:01 PM > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Hi Vladimir, > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Thank you for your further comments. I fixed my code, but I?m afraid > >> ? ? ? ? ? ? ? ? ? ? ? ? discussing such a basic topic involving the two big mailing lists is not > >> ? ? ? ? ? ? ? ? ? ? ? ? good. Please let me have a chance to talk on this off-list. > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? -- > >> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not > >> ? ? ? ? ? ? ? ? ? ? ? ? understand which Region node you are swapping. Where it is coming from? > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? From: Vladimir Kozlov __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? To: Michihiro Horie __ , Roger > >> ? ? ? ? ? ? ? ? ? ? ? ? Riggs __ > >> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? Date: 2018/11/30 03:01 > >> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> > ---------------------------------------------------------------------------------------------------- > >> > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Hi Michihiro, > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? I still do not understand which Region node you are swapping. Where it is > >> ? ? ? ? ? ? ? ? ? ? ? ? coming from? > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? On 11/28/18 10:31 PM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir,Roger, > >> ? ? ? ? ? ? ? ? ? ? ? ? > Thank you so much for your responses. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir, > >> ? ? ? ? ? ? ? ? ? ? ? ? > Regarding the hotspot change,I?m new in changing around > >> ? ? ? ? ? ? ? ? ? ? ? ? library_call.cpp,so your comments are very helpful. I will fix > >> ? ? ? ? ? ? ? ? ? ? ? ? > my code,especially inline_character_compare()would be like: > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ > >> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* old_rgn = control()->as_Region(); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* new_rgn = new RegionNode(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + record_for_igvn(new_rgn); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one > >> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* new_ctrl = old_rgn->in(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + old_rgn->del_req(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + new_rgn->add_req(new_ctrl); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + set_control(_gvn.transform(new_rgn)); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + // argument(0)is receiver > >> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* codePoint = argument(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* n = NULL; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + switch (id){ > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isDigit_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? DigitCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isLowerCase_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? LowerCaseCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isUpperCase_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? UpperCaseCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isWhitespace_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? WhitespaceCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + default: > >> ? ? ? ? ? ? ? ? ? ? ? ? > + fatal_unexpected_iid(id); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + } > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + set_result(_gvn.transform(n)); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + return true; > >> ? ? ? ? ? ? ? ? ? ? ? ? > +} > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Microbenchmark showed ~40% improvements. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Roger, > >> ? ? ? ? ? ? ? ? ? ? ? ? > I would wait foryour review,thanks. I understood the discussion had not > >> ? ? ? ? ? ? ? ? ? ? ? ? been recognized from people in core-libs-dev,and > >> ? ? ? ? ? ? ? ? ? ? ? ? > checked it was not actually archived there?. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll > >> ? ? ? ? ? ? ? ? ? ? ? ? look at it on Thursday.Roger Riggs ---2018/11/29 > >> ? ? ? ? ? ? ? ? ? ? ? ? > 11:21:26---Hi, I'll look at it on Thursday. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > From: Roger Riggs __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > To: Vladimir Kozlov __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , Michihiro Horie __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _core-libs-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > Cc: _volker.simonis at sap.com_ , > >> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > Date: 2018/11/29 11:21 > >> ? ? ? ? ? ? ? ? ? ? ? ? > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > ------------------------------------------------------------------------------------------------------------------------ > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Hi, > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > I'll look at it on Thursday. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > In spite of it looking like the email was sent to core-lib-dev, I have > >> ? ? ? ? ? ? ? ? ? ? ? ? > not seen it before > >> ? ? ? ? ? ? ? ? ? ? ? ? > and its not in the core-libs-dev archive. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > $.02, Roger > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You still need review from core-libs. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> About your hotspot changes. You need to add intrinsics to > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> is_disabled_by_flags() to be able switch them off. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Note, match_rule_supported() calls in > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> are registered. So they will not be available if they are not > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> supported. match_rule_supported() checks in > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() are not needed. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> I don't get what you code in > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() is doing. Why you check > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Region node at the beginning and why you add Region and Phi at the end > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> if you have only one path? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You are creating code for whole method which should return boolean result > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?boolean isDigit(int ch) { > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?} > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> but your code produce TypeInt::CHAR. why? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> An finally. Did you compare code generated by default and with you > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> changes? what improvement you see? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Thanks, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Vladimir > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Is there any response from core-libs-dev? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Vladimir, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Could you give your suggestion on how to proceed? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"hotspot-compiler-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Thu, Nov 22, 2018 11:28 AM > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Yes, we should wait for the feedback on class library change. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Btw. I think you can further simplify the code in library_call.cpp > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for pointing out it, I think I understand how to simplify > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> code. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Hi Michi, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> >Please note that we don?t have a machine, yet. So other people > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> will have to test. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> I think Gustavo can help testing this change when its' ready. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Sure :) > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Gustavo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you, Gustavo. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, thanks. This proposal makes the javacode much"Doerr, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> makes the java code much moreintrinsics friendly. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie __ , > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: _"hotspot-compiler-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , "Simonis, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Volker"__ , > >> ? ? ? ? ? ? ? ? ? ? ? ? Gustavo Romero > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/22 01:33 > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > ------------------------------------------------------------------------------------------------------------------------ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> thanks. This proposal makes the java code much more intrinsics friendly. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> We should wait for feedback from the core lib folks. Maybe they have > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> some requirements or other proposals. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think these intrinsics should be interesting for Oracle, Intel and > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> others, too. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Btw. I think you can further simplify the code in library_call.cpp > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie __ * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ ; Gustavo > >> ? ? ? ? ? ? ? ? ? ? ? ? Romero__ * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I send this RFR to core-libs-dev too, because it changes the class > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> library. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Through trial and error, I separated Latin1 block as in the _ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > ___https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.01-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=co8xQFD19i2JBuYtSh2KKr-qUmwPdt6MEpJErzBfsd0&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.01-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=w78kALiRtp6DIYAfslpK_TGpubqajF0h32O_z_ITAF4&e=>_/_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I followed the coding way of Character.isWhitespace() that invokes > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase(), and isUpperCase(). > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think this change is also useful on x86, using STTNI. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> > <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Wed, Nov 21, 2018 1:53 AM > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for giving your helpful comments. I did not recognize > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static? prevents anyoptimizations, but I now > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> checked it actually degraded the performance, thanks. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Please note that we don?t have a machine, yet. So other people will > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> have to test. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think Gustavo can help testing this change when its' ready. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Would it be possible to introduce more fine-grained intrinsics such > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Maybe you can factor out as in the following example? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>if (latin1) return isLatin1Digit(codePoint); > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thanks for an example, please let me try to separate the Latin block > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> from other blocks for some time. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, first of all, thanks for working onPower9 opt"Doerr, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for working on Power9optimizations. Please note that we don't ha > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/20 01:55 > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > ------------------------------------------------------------------------------------------------------------------------ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first of all, thanks for working on Power9 optimizations. Please note > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that we don?t have a machine, yet. So other peoplewill have to test. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think it may be problematic to insert a slow path by > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static?. This may be a performancedisadvantage > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for some users of other encodings because your intrinsics prevent > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> inlining and further optimizations. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would it be possible to introduce more fine-grained intrinsics such > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Maybe you can factor out as in the following example? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> if (latin1) return isLatin1Digit(codePoint); > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I can?t judge if this is needed, but I think this should be discussed > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first before going into the details. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:HORIE at jp.ibm.com_>>* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Freitag, 16. November 2018 12:53* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_>>; > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_ <_mailto:gromero at linux.vnet.ibm.com_>>* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Dear all, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would you please review following change? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Bug: > >> ? ? ? ? ? ? ? ? ? ? ? ? > > __https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=yTUTl4D2EPdboqkkAHXYtHx5KijWhAzXOXPBqwME0iQ&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Webrev: > >> ? ? ? ? ? ? ? ? ? ? ? ? > > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.00-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=88Ms75RO8511eAgWMsvWrTDLmRRcxcKiEs_DkSZmVlc&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=zZl2pxTY0Dn-5RZHkTZSnIRpYzb-w9T_4d8cV7gU3iw&e=> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> This change includes the intrinsics of Character isDigit, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compare a character with 1 or 2 rangedbytes, while the cmpeqb > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compares one with 1 to 8 values. Simple micro benchmark attached > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> showed improvements by 20-40%. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> / > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> //(See attached file: Latin1Test.java)/ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > >> > >> > >> > >> > >> > > > > > > From vincent.x.ryan at oracle.com Mon Dec 10 20:59:54 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 10 Dec 2018 20:59:54 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> Message-ID: <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> Comments in-line. Thanks. > On 10 Dec 2018, at 16:59, Roger Riggs wrote: > > Hi, > > Looks good, though some points to clarify. > > - The methods that use ByteBuffers should be clear that accesses to the ByteBuffers > are relative and use and modify the position and ByteBuffer exceptions may be thrown. Added the line: 'Access to the ByteBuffer is relative and its position gets set to the buffer's limit.' > > - The methods that write output (Strings) to an output stream might be more general > if the argument was a PrintStream, allowing the hex formatted output to be > assembled with other localized output. > I do see that as long as HexFormat is only writing hex digits, the effect would be almost the same. > (It would also eliminate, the inefficient code in getPrintStream that creates a PrintStream on demand). I had wanted to provide flexibility by favouring OutputStream over PrintStream. It is convenient for the common case of dumping to a file using 'new FileOutputStream?. As you note it complicates assembly with other output. I guess it?s fine to change the OutputStream args to PrintStream. > > - toString(byte[], from, to) and other methods there's no need for parens around the note about fromIndex==toIndex. OK > > - fromString methods: The optional prefix of "0x": add the phrase "is ignored". > The IAE, does not mention the optional prefix, I'm not sure if that allows some confusion. Added the line: 'The optional prefix of {@code "0x"} is ignored.' > > - dumpAsStream(InputStream) does not have a throws NPE for in == null. > A catch all in the class javadoc could cover that. > " Unless otherwise noted, passing a null argument to a constructor or method in any class or > interface in this package will cause a NullPointerException to be thrown. ? Added an @throws to the method. > > - dumpAsStream methods, the formatter argument is described as being used "if present"; > it might be clearer as "if not null?. OK > > - dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be confusing because it > is using the relative methods of ByteBuffer, but the from and to offsets are within > the position .. limit buffer. That should be explicit. > (Or consider switching to the absolute accesses in the ByteBuffer and not affect the position) Is the additional javadoc line added earlier sufficient? > > - dump(byte[], OutputStream) - I don't think the example is correct, there is no reference > to a stream, only the PrintStream::println method, which is not static. The code is just illustrative. Real values would have to be supplied for the input bytes and the chosen print method on the output stream. Typically, that print method will be System.out::println > > Regards, Roger > > > > On 12/07/2018 08:18 PM, Vincent Ryan wrote: >> Here?s the latest version that addresses all the current open issues: >> >> webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ >> javadoc: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html >> >> CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 >> >> >>> On 7 Dec 2018, at 19:51, Vincent Ryan > wrote: >>> >>> Even shorter. I?ll add that instead. >>> Thanks. >>> >>>> On 7 Dec 2018, at 19:04, Roger Riggs > wrote: >>>> >>>> Hi, >>>> >>>> I don't think this is performance sensitive and less code is better. >>>> >>>> Use java.lang.Character.digit(ch, 16) to convert the char to an int. >>>> >>>> Roger >>>> >>>> On 12/07/2018 01:49 PM, Kasper Nielsen wrote: >>>>> Hi, >>>>> >>>>> I don't know if performance is an issue. But if it is, I think it world >>>>> make sense to use a precompute array. And replace >>>>> >>>>> private static int hexToBinary(char ch) { >>>>> if ('0' <= ch && ch <= '9') { >>>>> return ch - '0'; >>>>> } >>>>> if ('A' <= ch && ch <= 'F') { >>>>> return ch - 'A' + 10; >>>>> } >>>>> if ('a' <= ch && ch <= 'f') { >>>>> return ch - 'a' + 10; >>>>> } >>>>> return -1; >>>>> } >>>>> >>>>> with >>>>> >>>>> private static int hexToBinary(char ch) { >>>>> return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >>>>> } >>>>> >>>>> where int[] staticPrecomputedArray is computed in a static initializer >>>>> block. >>>>> >>>>> /Kasper >>>>> >>>>> On Fri, 23 Nov 2018 at 14:51, Vincent Ryan > >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review this proposal for a new API to conveniently generate and >>>>>> display binary data using hexadecimal string representation. >>>>>> It supports both bulk and stream operations and it can also generate the >>>>>> well-known hexdump format [1]. >>>>>> >>>>>> This latest revision addresses review comments provided earlier. >>>>>> These include adding methods to support for data supplied in a >>>>>> ByteBuffer, exposing the default formatter implementation as a public >>>>>> static and dropping the superfluous 'Hex' term from several method names. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>>>>> API: >>>>>> >>>>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>>>>> >>>>>> >>>>>> ____ >>>>>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >>>>>> >>>> >>> >> > From claes.redestad at oracle.com Mon Dec 10 21:17:31 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 10 Dec 2018 22:17:31 +0100 Subject: RFR: 8215159: Improve initial setup of system Properties Message-ID: Hi, by inverting the order in which the internal property maps are created, we avoid some classloading and get a slightly more efficient code execution profile in System.initPhase1. Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 This reduces bytecode executed in initPhase1 from ~48k to ~36k. Not much by any measure, but minimizing System.initPhase1 is important since certain parts of the VM (JIT etc) are blocked from initializing until it's done. Thanks! /Claes From Roger.Riggs at oracle.com Mon Dec 10 21:38:57 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 10 Dec 2018 16:38:57 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> Message-ID: <93c7eb10-4716-6f92-1622-39f0af54c1e5@oracle.com> Hi Vincent, On 12/10/2018 03:59 PM, Vincent Ryan wrote: > Comments in-line. > Thanks. > >> On 10 Dec 2018, at 16:59, Roger Riggs > > wrote: >> >> Hi, >> >> Looks good, though some points to clarify. >> >> - The methods that use ByteBuffers should be clear that accesses to >> the ByteBuffers >> ?? are relative and use and modify the position and ByteBuffer >> exceptions may be thrown. > > Added the line: > 'Access to the?ByteBuffer?is relative and its position gets set to > the?buffer's limit.' ok > >> >> - The methods that write output (Strings) to an output stream >> might?be more general >> ? if the argument was a PrintStream, allowing the hex >> formatted?output to be >> ? assembled with other localized output. >> ? I do see that as long as HexFormat is only writing hex digits, >> the?effect would be almost the same. >> ? (It would also eliminate, the inefficient code in >> getPrintStream?that creates a PrintStream on demand). > > I had wanted to provide flexibility by favouring OutputStream over > PrintStream. > It is convenient for the common case of dumping to a file using 'new > FileOutputStream?. > As you note it complicates assembly with other output. > > I guess it?s fine to change the OutputStream args to PrintStream. ok, if the caller has a direct OutputStream, a PrintStream could be created. But I think the PrintStream is more common. > > >> >> ?- toString(byte[], from, to) and other methods there's no need >> for?parens around the note about fromIndex==toIndex. > > OK > >> >> ?- fromString methods: The optional prefix of "0x": add the phrase? >> "is ignored". >> ??? The IAE, does not mention the optional prefix, I'm not sure if >> that allows some confusion. > > Added the line: > 'The optional prefix of?{@code "0x"}?is ignored.' ok > >> >> - dumpAsStream(InputStream) does not have a throws NPE for in ==?null. >> ? A catch all in the class javadoc could cover that. >> ? " Unless otherwise noted, passing a null argument to a >> constructor?or method in any class or >> ? ?interface in this package will cause a?NullPointerException?to be >> thrown. ? > > Added an @throws to the method. ok > >> >> ?- dumpAsStream methods, the formatter argument is described as being >> used "if present"; >> ?? it might be clearer as "if not null?. > > OK > Its really nice/necessary that examples can be copy/pasted and compile. >> >> ?- dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be >> confusing because it >> ?? is using the relative methods of ByteBuffer, but the from and to >> offsets are within >> ?? the position .. limit buffer.? That should be explicit. >> ?? (Or consider switching to the absolute accesses in the ByteBuffer >> and not affect the position) > > Is the additional javadoc line added earlier sufficient? I would bear some reinforcing that the entire remainder of the buffer is read and the from and to are indexes within that remainder. And I'm not sure that's the desirable semantics. It would make more sense if the from bytes from the buffer are skipped and only the (to - from) bytes are dumped.? That leaves the ByteBuffer reading only the requested bytes.? A natural usage such as: ?dumpAsStream?(ByteBuffer buffer, 0, 256, 16, formatter) would dump the next 256bytes of the ByteBuffer and position would be moved by 256. > > >> >> - dump(byte[], OutputStream) - I don't think the example is correct, >> there is no reference >> ? to a stream, only the PrintStream::println method, which is not static. > > The code is just illustrative. Real values would have to be supplied > for the input bytes and the > chosen print method on the output stream. Typically, that print method > will be System.out::println Examples that don't compile are really confusing and annoying. Thanks, Roger > > >> >> Regards, Roger >> >> >> >> On 12/07/2018 08:18 PM, Vincent Ryan wrote: >>> Here?s the latest version that addresses all the current open issues: >>> >>> webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ >>> >>> >>> javadoc: >>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html >>> >>> >>> >>> CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 >>> >>> >>>> On 7 Dec 2018, at 19:51, Vincent Ryan >>> > wrote: >>>> >>>> Even shorter. I?ll add that instead. >>>> Thanks. >>>> >>>>> On 7 Dec 2018, at 19:04, Roger Riggs >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> I don't think this is performance sensitive and less code is better. >>>>> >>>>> Use java.lang.Character.digit(ch, 16) to convert the char to an int. >>>>> >>>>> Roger >>>>> >>>>> On 12/07/2018 01:49 PM, Kasper Nielsen wrote: >>>>>> Hi, >>>>>> >>>>>> I don't know if performance is an issue. But if it is, I think it >>>>>> world >>>>>> make sense to use a precompute array. And replace >>>>>> >>>>>> private static int hexToBinary(char ch) { >>>>>> ???if ('0' <= ch && ch <= '9') { >>>>>> ???????return ch - '0'; >>>>>> ???} >>>>>> ???if ('A' <= ch && ch <= 'F') { >>>>>> ???????return ch - 'A' + 10; >>>>>> ???} >>>>>> ???if ('a' <= ch && ch <= 'f') { >>>>>> ???????return ch - 'a' + 10; >>>>>> ???} >>>>>> ???return -1; >>>>>> } >>>>>> >>>>>> with >>>>>> >>>>>> private static int hexToBinary(char ch) { >>>>>> ???return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >>>>>> } >>>>>> >>>>>> where int[] staticPrecomputedArray is computed in a static >>>>>> initializer >>>>>> block. >>>>>> >>>>>> /Kasper >>>>>> >>>>>> On Fri, 23 Nov 2018 at 14:51, Vincent Ryan >>>>>> > >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review this proposal for a new API to conveniently >>>>>>> generate and >>>>>>> display binary data using hexadecimal string representation. >>>>>>> It supports both bulk and stream operations and it can also >>>>>>> generate the >>>>>>> well-known hexdump format [1]. >>>>>>> >>>>>>> This latest revision addresses review comments provided earlier. >>>>>>> These include adding methods to support for data supplied in a >>>>>>> ByteBuffer, exposing the default formatter implementation as a >>>>>>> public >>>>>>> static and dropping the superfluous 'Hex' term from several >>>>>>> method names. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>>>>>> API: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>>>>>> >>>>>>> >>>>>>> ____ >>>>>>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >>>>>>> >>>>> >>>> >>> >> > From Rob.Griffin at quest.com Mon Dec 10 22:11:54 2018 From: Rob.Griffin at quest.com (Rob Griffin (rgriffin)) Date: Mon, 10 Dec 2018 22:11:54 +0000 Subject: Add convenience collect methods to the Stream interface In-Reply-To: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> References: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, There are certainly places where we could do this when we are simply iterating over the results but that is not always the case. However I was disappointed to find that the enhanced for loop can't iterate over a stream so if callers of your example methods where doing something like this for (Employee emp : getAllEmployee()) { ... } then it would have to change to a forEach call if getAllEmployee returned a Stream. Regards, Rob Griffin Software Analyst, Spotlight on SQL Server Quest | R&D rob.griffin at quest.com Office +613-9811-8021?? -----Original Message----- From: Remi Forax Sent: Tuesday, 11 December 2018 4:26 AM To: Rob Griffin (rgriffin) Cc: core-libs-dev ; Brian Goetz Subject: Re: Add convenience collect methods to the Stream interface CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Rob, i will add to the answer of Brian that if you have too many .collect(toList()), it's perhaps your application perhaps suffers of the equivalent of the n + 1 select query you have with SQL but with the Stream API. You should try to see if returning a Stream instead of a List for some of methods is not a better option: public List getAllEmployee() { return employees.stream().filter(Employee::isActive).collect(toList()); } public List getManager(List list) { return list.stream().filter(Employee::isManager).collect(toList()); } ... getManager(getAllEmployee()); should be: public Stream getAllEmployee() { return employees.stream().filter(Employee::isActive); } public Stream getManager(Stream stream) { return stream.filter(Employee::isManager); } ... getManager(getAllEmployee()).collect(toList()); regards, R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Rob Griffin (rgriffin)" , "core-libs-dev" > > Envoy?: Lundi 10 D?cembre 2018 17:14:41 > Objet: Re: Add convenience collect methods to the Stream interface > As will surprise no one, this was extensively discussed during the > development of the Streams API. (Our default position on "convenience > methods" is hostile. While everyone sees the benefit of convenience > methods (it's convenient!), most people don't see the cost, which > includes the complexity for users to understand the model by looking > at the API; having lots of ad-hoc convenience method obscures the > underlying model, making it harder for everyone to learn or reason > about. That default position seems to stand up pretty well here, as > the stream API is pretty well factored.) > > Let's be honest: the "convenience" or concision of being able to say > .toList() instead of .collect(toList()) is really small. I don't > think you'll be able to justify it by saying "but we do it a lot." > (Digression: to whoever is about to say "then why `toArray()`? Arrays > are different; for better or worse, they're part of the language, and > they lend themselves particularly poorly to the Collector API, and > there are particular parallelization optimizations that are possible > for arrays that can't be accessed through Collector. End digression.) > > It is possible, however, that one could justify `toList()` on the > basis of _discoverability_. (Though I'm having a hard time seeing any > world where `toSet()` makes the cut.) New users who approach streams > will not easily be able to figure out how to materialize a list from a > stream, even though this is an entirely reasonable and quite common > thing to want to do. Having to learn about `collect()` first is > asking a lot of users who are still wrapping their heads around > streams. Not only would `toList()` be more discoverable, it would > provide a path to discovery of the rest of the `collect()` API. This is a point in its favor. > > A significant downside of adding `toList()` is that by diluting the > orthogonality of the existing API, it provides both incentive and > justification for further dilution, leading to someplace we don't want > to be. (And, the cost of that falls heavily on the stewards, which in > turn takes time away from far more valuable activities.) > > Put it this way: imagine we have a budget of one convenience method in > Stream for every five years. Is this the one we want to spend the > next five year's budget on? (And, who of the proponents will > volunteer to answer the next 200 "I have an idea for a stream method" > mails, explaining that the budget is spent?) > > > So, summary: > > - I won't outright veto `toList`, as I would for almost all other > "convenience" streams additions, because this one actually has a valid > non-convenience argument; > - But, it's still not a slam dunk. > > > On 12/9/2018 5:44 PM, Rob Griffin (rgriffin) wrote: >> Hi, >> >> I have raised an enhancement request (Incident Report 913453) about >> adding some convenience methods to the Stream interface that collect >> the stream and Pallavi Sonal asked me to start a thread here about that. >> >> More than 50% of our Stream collect calls use Collectors.toList() or >> Collectors.toSet() as arguments so I think it would be very handy if >> the Stream interface had default collectToList and collectToList and collectToMap methods. >> >> The advantages are: >> it would be easier to use code completion in IDEs. There are lot of classes >> starting with Collect so finding the Collectors class is a bit of a pain. >> one less method call in what is usually a long chain of calls. >> >> Regards, >> >> Rob Griffin >> Software Analyst, Spotlight on SQL Server Quest | R&D >> rob.griffin at quest.com From ali.ince at gmail.com Mon Dec 10 21:05:28 2018 From: ali.ince at gmail.com (=?utf-8?B?QWxpIMSwbmNl?=) Date: Mon, 10 Dec 2018 21:05:28 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: <6700A382-6D68-4565-A3C5-3FA1BF2029C4@gmail.com> > On 10 Dec 2018, at 15:11, Magnus Ihse Bursie wrote: > > > > On 2018-12-10 16:02, Alexey Ivanov wrote: >> >> >> On 10/12/2018 10:41, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-07 22:18, Simon Tooke wrote: >>>> Looking at the code, it seems (to me) the "correct" thing to do is to is >>>> to create a Windows-specific version of dbgsysBuildFunName() in >>>> linker_md.c, and have it decorate the function name as appropriate for >>>> 32-bit windows. Note that in transport.c, you'd need to pass in the >>>> parameter stack size (the bit after the @), but it could at least behave >>>> properly on 32 vs 64 bit Windows. >>>> >>>> Notice this approach is already used for the library name, via >>>> dbgsysBuildLibName() >>>> >>>> If the function is never intended to be called by Java via JNI, then it >>>> should never have been declared JNICALL in the first place - but that >>>> ship has sailed. >>>> >>>> I don't think changing the decorated exported name to undecorated is a >>>> good idea, as it obfuscates the calling convention used. >>>> >>> Good analysis, Simon. I agree. >>> >>> I have now looked more into the situation. In fact, it looks a lot like JDWP has been broken on Windows 32-bit for a long time, but we have patched around the issue in the JDK by using /export. This is the spec we're dealing with: https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. I quote: >>> >>>> The transport library must export an onload function with the following prototype: >>>> >>>> JNIEXPORT jint JNICALL >>>> jdwpTransport_OnLoad(JavaVM *jvm, >>>> jdwpTransportCallback *callback, >>>> jint version, >>>> jdwpTransportEnv** env); >>>> >>>> This function will be called by the JDWP (or other agent) when the library is loaded. >>>> >>>> >>> >>> Nothing here says anything that the function should be exported using anything other than the normal _stdcall (implied by JNICALL) name mangling rules. However, JDWP has not been working according to the spec and looking for the correct symbol, and while we could have noticed that in the JDK, we didn't, because someone (long ago) added /export:jdwpTransport_OnLoad as a workaround to the affected libraries, instead of fixing JDWP. >> >> This means that we cannot change the calling convention: it must stay as it is now. >> >> I think JDWP has always been working according to the spec. Using __stdcall is the recommended calling convention for Win32 and for DLLs in particular. Usually function names are exported undecorated in DLL. (If my memory serves me well, older Microsoft tools exported extern "C" __stdcall functions undecorated.) > So then the question becomes: what does the spec mean? That the __stdcall convention should be used, or that the function name should be explicitly exported under a non __stdcall-convention name? Neither behavior seems clearly written out, so this is left to an implicit interpretation of what that "usually" means..? A couple of MSFT quotes on name decoration from https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 says; > Normally, you don't have to know the decorated name to write code that compiles and links successfully. Decorated names are an implementation detail internal to the compiler and linker. > Name decoration is also important when linking to code written in other programming languages or using other compilers. Different compilers use different name decoration conventions. When your executable links to code written in another language, special care must be taken to match the exported and imported names and calling conventions. And we should also keep in mind that MSFT itself doesn?t use name mangling in the core windows API. I still see this |jdwpTransport_OnLoad| not much different than |JNI_CreateJavaVM| in the context of it?s availability and accessibility from outer world. >> >> I believe this ? exporting the undecorated function names ? allows for interoperability between 32 bit and 64 bit in cases where you load a DLL and dynamically look up a function in it. >> >> There were too many /export options to export Win32 functions undecorated for this one to be an accident rather than the intention. > How do you mean? >> >>> Now, given that we've shipped code that didn't adhere to the specs for so long, we can probably not break that behavior. Instead, I propose we amend dbgsysBuildFunName() so that on Windows 32-bit, it looks for both the "jdwpTransport_OnLoad", and the symbol as mangled by _stdcall rules. I also propose that if both symbols are present, the _stdcall named one should take precedence, since that's according to the spec (and the other is just a fallback to maintain backwards compatibility). >> >> Since removing JNICALL is not an option, there are only two options: >> >> 1. Add /export option to the Makefile or pragma-comment to the source file; >> 2. Lookup the decorated name _jdwpTransport_OnLoad at 16 for Win32 with fallback to undecorated one. > Yes. > > I think the correct solution here is 2. Does keeping name mangling in-place gives anyone any value? It would probably only add the overhead of making the callers compute the stack size of the parameters. And I couldn?t find any sign or history of changes but name mangling, theoretically, it could change over versions of compilers. The pragma-comment approach could also be overly simplified as shown https://stackoverflow.com/a/41910450, which will leave us with a single line addition to the function body as; #pragma EXPORT which is from my point of view a simpler (and maintainable) approach than adding a decorated name lookup logic. Regards, Ali >> >> >> I just wonder how it's possible to implement a generic dbgsysBuildFunName for an arbitrary function without knowing the size of function parameters. Could it be the reason why most DLLs export __stdcall functions undecorated? > (I assume you mean dbgsysFindLibraryEntry; there is a dbgsysBuildFunName as well but it appears to be dead code.) > > The dbgsysFindLibraryEntry does not need to work with an arbitrary function. It's implemented in jdk.jdwp.agent, for the sole reason of locating the jdwpTransport_OnLoad function. > > In general, I assume this to hold true. If you don't know the signature of the function you want to call, you're screwed anyway, regardless of calling convention. > > /Magnus > >> >> Regards, >> Alexey >> >>> >>> /Magnus >>>> -Simon Tooke >>>> >>>> >>>> On 12/7/2018 2:09 PM, Alexey Ivanov wrote: >>>> >>>>> Hi Andrew, >>>>> >>>>> Sorry for my belated reply. >>>>> Yes, it's also an option? however, this solution seems to be >>>>> overcomplicated to export one function or two. The calling convention >>>>> of exported functions for JVM cannot be changed, they can be called >>>>> from third-party software. >>>>> >>>>> If the function is used internally-only, its calling convention can be >>>>> changed as long as all components are updated. >>>>> >>>>> Thank you for the pointer to another approach used to handle name >>>>> decorations of __stdcall functions. It looks we have to work out a >>>>> common approach to this problem. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 27/11/2018 18:49, Andrew Luo wrote: >>>>> >>>>>> By the way, in hotspot we are generating a .def file dynamically >>>>>> while keeping the JNICALL calling convention (for symbols such as >>>>>> JNI_CreateJavaVM) I believe (just by looking through the code in >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk >>>>>> , >>>>>> unless this code is inactive - someone who knows this area better >>>>>> than me might want to comment...). Shouldn't the same approach be >>>>>> taken here as well? >>>>>> >>>>>> Thanks >>>>>> Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: core-libs-dev >>>>>> >>>>>> On >>>>>> Behalf Of Ali Ince >>>>>> Sent: Monday, November 19, 2018 2:08 PM >>>>>> To: Alexey Ivanov >>>>>> >>>>>> ; build-dev >>>>>> >>>>>> ; core-libs >>>>>> >>>>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> I don?t have an account on JBS as I?m not an author yet, my OCA has >>>>>> just been processed. Would it be possible for someone with an author >>>>>> status to create an issue? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ali >>>>>> >>>>>> >>>>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> The fix looks good to me provided it resolves your problem. >>>>>>> I am not a reviewer so you'll have to get OK from reviewers, likely >>>>>>> from build-dev and from core-libs. >>>>>>> >>>>>>> Have you submitted the issue in JBS? >>>>>>> >>>>>>> You have to sign OCA to be able to contribute to OpenJDK: >>>>>>> >>>>>>> https://openjdk.java.net/contribute/ >>>>>>> >>>>>>> and also >>>>>>> >>>>>>> https://openjdk.java.net/sponsor/ >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 18/11/2018 12:07, Ali ?nce wrote: >>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Below is a new patch content that removes JNICALL modifiers from >>>>>>>> the exported functions of interest. This results in exported >>>>>>>> functions not to be name decorated and use __cdecl calling convention. >>>>>>>> >>>>>>>> Do you have any more suggestions, or would you please guide me on >>>>>>>> next steps? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>> # HG changeset patch >>>>>>>> # User Ali Ince >>>>>>>> >>>>>>>> >>>>>>>> # Date 1542542415 0 >>>>>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>>>>>>> builds >>>>>>>> >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>>> src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug >>>>>>>> 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov >>>>>>>> 18 12:00:15 2018 +0000 >>>>>>>> @@ -339,7 +339,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** result) { >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>>> src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -140,7 +140,7 @@ >>>>>>>> void (*free)(void *buffer); /* Call this for all >>>>>>>> deallocations */ >>>>>>>> } jdwpTransportCallback; >>>>>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>>> >>>>>>>> jdwpTransportCallback *callback, >>>>>>>> jint version, >>>>>>>> jdwpTransportEnv** >>>>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> --- >>>>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ >>>>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** env) { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> It's exactly what I referred to. >>>>>>>>> >>>>>>>>> Yes, it does change the calling convention. >>>>>>>>> Yet it's not a (big) problem because both parties will use the >>>>>>>>> same calling convention. >>>>>>>>> >>>>>>>>> Using a DLL from another build will not be possible. But it's not >>>>>>>>> a good idea to do so anyway. >>>>>>>>> >>>>>>>>> >>>>>>>>> Mapfiles and export options have been removed by >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 >>>>>>>>> to simplify >>>>>>>>> managing exported functions. So that to add or remove an exported >>>>>>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>>>>>> just edit the source files. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>> >>>>>>>>>> Hi Alexey, >>>>>>>>>> >>>>>>>>>> Thanks for your reply. >>>>>>>>>> >>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>>>>>> be __stdcall on windows which is both specified on >>>>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>>>>>> and dt_shmem.dll. >>>>>>>>>> >>>>>>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>>>>>> decoration is not applied >>>>>>>>>> ( >>>>>>>>>> https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 >>>>>>>>>> ). >>>>>>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>>> >>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>>>>>> applies to x86 builds) will result in the calling convention to >>>>>>>>>> be changed, and thus will change how parameters are ordered and >>>>>>>>>> also the stack cleanup rules. I think this may result in problems >>>>>>>>>> in programs that are designed to load shared libraries and its >>>>>>>>>> exported functions at runtime (not bound by link time which >>>>>>>>>> probably won?t cause any issues - assuming that they use the >>>>>>>>>> shared function signature) - as in >>>>>>>>>> >>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99 >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Ali, >>>>>>>>>>> >>>>>>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>>>>>> the affected functions? >>>>>>>>>>> >>>>>>>>>>> Some build / link issues were resolved by adding / removing >>>>>>>>>>> JNICALL modifier, see >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>>>>>> >>>>>>>>>>> .html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>>>>>> >>>>>>>>>>> tml >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexey >>>>>>>>>>> >>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> An issue >>>>>>>>>>>> ( >>>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-build/issues/709 >>>>>>>>>>>> ) >>>>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>>>>>> >>>>>>>>>>>> Although the expected linker arguments were present on previous >>>>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>>> >>>>>>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1 >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> Would you please have a look and let me know of any points I >>>>>>>>>>>> may have missed (I don?t have any background information about >>>>>>>>>>>> why the export flags were removed in jdk11)? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Ali >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>>> )) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>>>>>>>> >>> >> > From ali.ince at gmail.com Mon Dec 10 21:13:57 2018 From: ali.ince at gmail.com (=?utf-8?B?QWxpIMSwbmNl?=) Date: Mon, 10 Dec 2018 21:13:57 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> Message-ID: <998A7FEB-9846-40F5-8880-1812302F002F@gmail.com> Hi Alexey, I?ve searched for |GetProcAddress| usages across source code and couldn?t find (hopefully tbh) other occurrences of such mismatches. Regards, Ali > On 7 Dec 2018, at 20:24, Alexey Ivanov wrote: > > Hi Ali, > > On 06/12/2018 22:49, Ali ?nce wrote: >> Hi Magnus, Alexey, >> >> I believe we won?t be able to get further opinions from serviceability-dev. > > Unfortunately, no one has replied as of now. > Have you found any issues with jdwpTransport_OnLoad after removing JNICALL? > >> Andrew Luo suggested using a similar mechanism as is used for jvm.dll by using symbol name files mapped by platform (files are under make/hotspot/symbols and interestingly windows is almost the only platform for which a symbol file doesn?t exist). > > Andrew says the .def files are auto-generated for Windows. There's a set of shared functions. > JVM cannot change the calling convention, jvm.dll is the public interface to JVM. > >> Another issue, again opened against AdoptOpenJDK 32-bit builds is somehow related with the same problem - but this time it is jimage.dll depending on zip.dll expecting the ZIP_InflateFully function to be decorated with JNICALL - whereas it was removed earlier from the implementation and the runtime image just fails with access violation just because jimage source code still declared it with JNICALL (https://github.com/AdoptOpenJDK/openjdk-build/issues/763 ). > > The usage of ZIP_InflateFully from zip.dll by jimage.dll was overlooked during work on https://bugs.openjdk.java.net/browse/JDK-8201226 . > > I can take care of it. > (I could not build 32 bit Windows. It seem to have overcome the problem by adding --disable-warnings-as-errors option to configure.) > > However, the report says the resulting image crashes in 64 bit windows too which shouldn't be affected by JNICALL mismatch. > >> I?ve also searched for GetProcAddress calls across the source code - and I think it?s important to work on the consistency of JNICALL usages across the whole source code. > > There are many places where libraries are loaded dynamically or a function may be unavailable on older versions of the platform. > Have you identified any other place where functions from JDK DLLs are looked up by names? > >> Another noteworthy thing I?ve noticed is there are still JNICALL modifiers for example in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49 - which I guess will also be reported as broken since these functions are again name decorated. > > This is a JNI method. It should use JNICALL modifier. If it wasn't found, the class sun.security.pkcs11.Secmod would fail to load. I guess JVM handles name mangling somehow for native method implementation. > > Such functions were never explicitly exported using mapfiles or /export options on Windows, at least in the client area. For Linux and Solaris, adding or removing a native method required editing mapfiles. > >> If we?re still determined to remove JNICALL, what about just removing __stdcall from JNICALL declaration at https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31 ? Wouldn?t that be a more consistent move? > > We can't do that. > Implementation of Java native methods must use __stdcall calling convention. > >> >> Regards, >> >> Ali >> >>> On 22 Nov 2018, at 17:29, Magnus Ihse Bursie > wrote: >>> >>> I think we are in complete agreement. What's missing is some expert opinion from serviceability-dev if there is any problem with changing the signature. I'd preferably have that. >>> >>> If no one knows, I'd say, change it, and see if we still pass the relevant tests, and if so, ship it. >>> >>> /Magnus >>> >>> 22 nov. 2018 kl. 18:04 skrev Alexey Ivanov >: >>> >>>> >>>> On 21/11/2018 12:16, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2018-11-20 16:49, Alexey Ivanov wrote: >>>>> >>>>>> Hi Ali, Magnus, >>>>>> >>>>>> I absolutely agree this change has to be reviewed by someone from serviceability. >>>>>> >>>>>> There are several options: >>>>>> >>>>>> 1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html >>>>>> so it partially reverts the changes from >>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 >>>>>> >>>>>> 2. Remove JNICALL (__stdcall) modifier, eventually changing the calling convention to __cdecl. >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023969.html >>>>>> >>>>>> 3. Use inline /export option via #pragma: >>>>>> #pragma comment(linker, "/export:jdwpTransport_OnLoad= _jdwpTransport_OnLoad at 16") >>>>>> as referenced in >>>>>> https://docs.microsoft.com/en-ie/cpp/cpp/dllexport-dllimport?view=vs-2017 >>>>>> https://docs.microsoft.com/en-ie/cpp/build/reference/exports?view=vs-2017 >>>>>> >>>>>> The third options still needs to be tested to make sure it does not break other platforms builds. >>>>> I'm not fond of either solution 1 or 3. I really think the signature should be made correctly at the point of definition in the source code. >>>> >>>> That is why I proposed removing JNICALL (__stdcall) from the function declaration as we had done for libzip, libjimage [1] and mlib_image [2]. >>>> >>>> Microsoft recommends using __stdcall for DLLs, at the same time it decorates the function name making it harder to export it by its plain name. >>>> >>>> >>>> By removing JNICALL / __stdcall, we make the function use __cdecl calling convention. The difference between them is that with __stdcall the callee cleans the stack whereas with __cdecl the caller cleans the stack. >>>> >>>> It shouldn't be a problem as long as all function declarations use the same calling convention, which, I believe, is the case here. >>>> >>>>> We've spent some considerable effort of getting rid of the /export flags for Windows (and map files for unix), and I don't want to see them creep back in. Note that option 3 is just option 1 in disguise. The only single good thing about it is that it allows you to put the compiler option next to the signature declaration in the source code. >>>> >>>> At least in this case, the option will be near the function body definition. It will be easier to update it if the signature changes. >>>> >>>> If we are to use __stdcall, it seems to be the only way to export the undecorated name. >>>> >>>>> The same goes for def files, as suggested by Ali. It's just yet another version of option 1 in disguise/map files. >>>> >>>> If option 2 is rejected, I'm for using option 3. If option 3 cannot be used too, I'm for option 1. >>>> I think we should not fall back to def files in any case. And Makefile will have to include the reference to the def file, so it's even worse than option 1. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8201226 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 19/11/2018 12:19, Magnus Ihse Bursie wrote: >>>>>>> Hi Ali, >>>>>>> >>>>>>> From a build perspective this change looks OK. I'm not aware of the finer details on the OnLoad mechanism, like what calling convention is to be used. So maybe this is a no-go from that view. >>>>>>> >>>>>>> I'm cc:ing servicability so they can have a look at it. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2018-11-18 13:07, Ali ?nce wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Below is a new patch content that removes JNICALL modifiers from the exported functions of interest. This results in exported functions not to be name decorated and use __cdecl calling convention. >>>>>>>> >>>>>>>> Do you have any more suggestions, or would you please guide me on next steps? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>> # HG changeset patch >>>>>>>> # User Ali Ince >>>>>>>> # Date 1542542415 0 >>>>>>>> # Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>>>>>> # Parent 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>>>>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows builds >>>>>>>> >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>>>>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -339,7 +339,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>>> } >>>>>>>> >>>>>>>> -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** result) >>>>>>>> { >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>>>>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -140,7 +140,7 @@ >>>>>>>> void (*free)(void *buffer); /* Call this for all deallocations */ >>>>>>>> } jdwpTransportCallback; >>>>>>>> >>>>>>>> -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>>>>>> jdwpTransportCallback *callback, >>>>>>>> jint version, >>>>>>>> jdwpTransportEnv** env); >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>>> } >>>>>>>> >>>>>>>> -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** env) >>>>>>>> { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> It's exactly what I referred to. >>>>>>>>> >>>>>>>>> Yes, it does change the calling convention. >>>>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>>>> >>>>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>>>> >>>>>>>>> >>>>>>>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>>> Hi Alexey, >>>>>>>>>> >>>>>>>>>> Thanks for your reply. >>>>>>>>>> >>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>>>> >>>>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 ). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>>> >>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99 . >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Ali, >>>>>>>>>>> >>>>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>>>> >>>>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexey >>>>>>>>>>> >>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709 ) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>>>> >>>>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>>> >>>>>>>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1 . >>>>>>>>>>>> >>>>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Ali >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>>> )) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>>> >>>>>> >>>>> >>>> >> > From stooke at redhat.com Fri Dec 7 21:18:59 2018 From: stooke at redhat.com (Simon Tooke) Date: Fri, 7 Dec 2018 16:18:59 -0500 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> Message-ID: <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> Looking at the code, it seems (to me) the "correct" thing to do is to is to create a Windows-specific version of dbgsysBuildFunName() in linker_md.c, and have it decorate the function name as appropriate for 32-bit windows.? Note that in transport.c, you'd need to pass in the parameter stack size (the bit after the @), but it could at least behave properly on 32 vs 64 bit Windows. Notice this approach is already used for the library name, via dbgsysBuildLibName() If the function is never intended to be called by Java via JNI, then it should never have been declared JNICALL in the first place - but that ship has sailed. I don't think changing the decorated exported name to undecorated is a good idea, as it obfuscates the calling convention used. -Simon Tooke On 12/7/2018 2:09 PM, Alexey Ivanov wrote: > Hi Andrew, > > Sorry for my belated reply. > Yes, it's also an option? however, this solution seems to be > overcomplicated to export one function or two. The calling convention > of exported functions for JVM cannot be changed, they can be called > from third-party software. > > If the function is used internally-only, its calling convention can be > changed as long as all components are updated. > > Thank you for the pointer to another approach used to handle name > decorations of __stdcall functions. It looks we have to work out a > common approach to this problem. > > Regards, > Alexey > > On 27/11/2018 18:49, Andrew Luo wrote: >> By the way, in hotspot we are generating a .def file dynamically >> while keeping the JNICALL calling convention (for symbols such as >> JNI_CreateJavaVM) I believe (just by looking through the code in >> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, >> unless this code is inactive - someone who knows this area better >> than me might want to comment...).? Shouldn't the same approach be >> taken here as well? >> >> Thanks >> Andrew >> >> -----Original Message----- >> From: core-libs-dev On >> Behalf Of Ali Ince >> Sent: Monday, November 19, 2018 2:08 PM >> To: Alexey Ivanov ; build-dev >> ; core-libs >> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >> >> Hi Alexey, >> >> I don?t have an account on JBS as I?m not an author yet, my OCA has >> just been processed. Would it be possible for someone with an author >> status to create an issue? >> >> Regards, >> >> Ali >> >>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>> wrote: >>> >>> Hi Ali, >>> >>> The fix looks good to me provided it resolves your problem. >>> I am not a reviewer so you'll have to get OK from reviewers, likely >>> from build-dev and from core-libs. >>> >>> Have you submitted the issue in JBS? >>> >>> You have to sign OCA to be able to contribute to OpenJDK: >>> https://openjdk.java.net/contribute/ >>> and also >>> https://openjdk.java.net/sponsor/ >>> >>> Regards, >>> Alexey >>> >>> On 18/11/2018 12:07, Ali ?nce wrote: >>>> Hi Alexey, >>>> >>>> Below is a new patch content that removes JNICALL modifiers from >>>> the exported functions of interest. This results in exported >>>> functions not to be name decorated and use __cdecl calling convention. >>>> >>>> Do you have any more suggestions, or would you please guide me on >>>> next steps? >>>> >>>> Thanks, >>>> >>>> Ali >>>> >>>> # HG changeset patch >>>> # User Ali Ince >>>> # Date 1542542415 0 >>>> #????? Sun Nov 18 12:00:15 2018 +0000 >>>> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39 >>>> # Parent? 16d5ec7dbbb49ef3f969e34be870e3f917ea89ff >>>> Remove JNICALL modifiers to prevent name decoration on 32-bit windows >>>> builds >>>> >>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>> src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>>> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c??? Tue Aug >>>> 14 14:28:23 2018 +0200 >>>> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c??? Sun Nov >>>> 18 12:00:15 2018 +0000 >>>> @@ -339,7 +339,7 @@ >>>> ????? return JDWPTRANSPORT_ERROR_NONE;? }? -JNIEXPORT jint JNICALL >>>> +JNIEXPORT jint >>>> ? jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>> ?????????????????????? jint version, jdwpTransportEnv** result)? { >>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>> src/jdk.jdwp.agent/share/native/include/jdwpTransport.h >>>> --- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h??? >>>> Tue Aug 14 14:28:23 2018 +0200 >>>> +++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h??? >>>> Sun Nov 18 12:00:15 2018 +0000 >>>> @@ -140,7 +140,7 @@ >>>> ????? void (*free)(void *buffer);????? /* Call this for all >>>> deallocations */ >>>> ? } jdwpTransportCallback; >>>> ? -typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>> +typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm, >>>> ???????????????????????????????????????????????? >>>> jdwpTransportCallback *callback, >>>> ???????????????????????????????????????????????? jint version, >>>> ???????????????????????????????????????????????? jdwpTransportEnv** >>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>> --- >>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c??? >>>> Tue Aug 14 14:28:23 2018 +0200 >>>> +++ >>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c??? >>>> Sun Nov 18 12:00:15 2018 +0000 >>>> @@ -1019,7 +1019,7 @@ >>>> ????? return JDWPTRANSPORT_ERROR_NONE;? }? -JNIEXPORT jint JNICALL >>>> +JNIEXPORT jint >>>> ? jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>> ?????????????????????? jint version, jdwpTransportEnv** env)? { >>>> >>>> >>>> >>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>> wrote: >>>>> >>>>> Hi Ali, >>>>> >>>>> It's exactly what I referred to. >>>>> >>>>> Yes, it does change the calling convention. >>>>> Yet it's not a (big) problem because both parties will use the >>>>> same calling convention. >>>>> >>>>> Using a DLL from another build will not be possible. But it's not >>>>> a good idea to do so anyway. >>>>> >>>>> >>>>> Mapfiles and export options have been removed by >>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify >>>>> managing exported functions. So that to add or remove an exported >>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>> just edit the source files. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>> Hi Alexey, >>>>>> >>>>>> Thanks for your reply. >>>>>> >>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>> be __stdcall on windows which is both specified on >>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>> and dt_shmem.dll. >>>>>> >>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>> decoration is not applied >>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). >>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>> >>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>> applies to x86 builds) will result in the calling convention to >>>>>> be changed, and thus will change how parameters are ordered and >>>>>> also the stack cleanup rules. I think this may result in problems >>>>>> in programs that are designed to load shared libraries and its >>>>>> exported functions at runtime (not bound by link time which >>>>>> probably won?t cause any issues - assuming that they use the >>>>>> shared function signature) - as in >>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ali >>>>>> >>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>> wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>> the affected functions? >>>>>>> >>>>>>> Some build / link issues were resolved by adding / removing >>>>>>> JNICALL modifier, see >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>> .html >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>> tml >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> An issue >>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) >>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>> >>>>>>>> Although the expected linker arguments were present on previous >>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>> >>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>> >>>>>>>> Would you please have a look and let me know of any points I >>>>>>>> may have missed (I don?t have any background information about >>>>>>>> why the export flags were removed in jdk11)? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>> ??????????? jdk.jdwp.agent:include \ >>>>>>>> ??????????? jdk.jdwp.agent:libjdwp/export, \ >>>>>>>> ??????? LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>> +????? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>> ??????? LIBS := $(JDKLIB_LIBS), \ >>>>>>>> ??? )) >>>>>>>> >>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>> 100644 >>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>> ????????? libjdwp/export, \ >>>>>>>> ????? LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>> ????????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>> +??? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>> ????? LIBS_linux := -lpthread, \ >>>>>>>> ????? LIBS_solaris := -lnsl -lsocket, \ >>>>>>>> ????? LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ > From david.holmes at oracle.com Mon Dec 10 23:23:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 09:23:08 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: Message-ID: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> Hi Magnus, On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > I propose that we introduce a new define, available to all JDK native > files (Hotspot included), called JDK_EXPORT. The behavior of this symbol > will be very similar (as of now, in fact identical) to JNIEXPORT; > however, the semantics will not. > > Currently, we "mis-use" the JNIEXPORT define to mark a function for > exporting from the library. The problem with this is that JNIEXPORT is > part of the JNI interface, and is supposed to be used when C programs > interact with Java. And, when doing this, the function should be fully > decorated like this: "JNIEXPORT foo JNICALL". I've seen a lot of the emails on this issue and I don't fully understand what has been going wrong. But the intent is obviously the JNIEXPORT represents what is needed to export this function for use by JNI, while JNICALL defines the calling convention. I agree there may be some mistmatch when functions are actually not intended for general export outside the JDK but are only for internal JDK use. > We do have many such JNI exports in our native libraries, but we also > have a lot of other, non-JNI exports, where one native library just > provides an interface to other libraries. In these cases, we have still > used JNIEXPORT for the functionality of getting the function exported, > but we have not been consistent in our use of JNICALL. This has caused > us way too much trouble for something that should Just Work. Are you suggesting that the interface between different libraries in the JDK should not be a JNI interface? Is this because you think the functions in these libraries are only for JDK internal use or ... ?? > I therefore propose that we define "JDK_EXPORT", with the same behavior > as JNIEXPORT (that is, flagging the function for external visibility in > the resulting native library), but which is *not* supposed to be > exported to Java code using JNI, nor supposed to be decorated with Just a clarification there. JNI functions are not exported to Java code, they are exported to native code. Java code can declare native methods and those native methods must be written as JNI functions, but that's not what we are discussing. Libraries expose a JNI interface (a set of functions in the library) that can be called by application native code, using JNI. > JNICALL. All current instances of JNIEXPORT which is not pure JNI native > functions should be changed to use JDK_EXPORT instead. > > I further propose that this macro should reside in a new file "jdk.h", > placed in the new directory src/java.base/share/native/include/internal. > This header file path will automatically be provided to all native > libraries, but not copied to the JDK being built. (The existence of a > "include/internal" directory with this behavior has been discussed > before. There are more files that ought to be moved there, if/when it is > created.) I believe in many cases the #include "jni.h" can be just > modified to #include "#jdk.h", since most native code will not require > "jni.h" unless actually doing JNI calls -- most have included this file > to get the JNIEXPORT macro, which would explain the pervasive use of > #include "jni.h" in our code base. jni.h also defines all of the types used by the JNI. Those types are pervsive to the native code used throughout the JDK. > Thoughts? I think we need to understand the problems on Windows that prompted all this. Then I think we need to look at exactly how jni.h and JNIEXPORT etc are being used and understand whether this is truly an exported interface or not. Cheers, David > /Magnus > From david.holmes at oracle.com Tue Dec 11 01:03:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 11:03:42 +1000 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> Message-ID: Hi Dmitry, On 11/12/2018 12:16 am, Dmitry Chuyko wrote: > Hello, > > Please review a small fix in java_md_solinux.c: continuation is not > truly compatible with pthread_create start_routine's signature but we > control what actually happens. So it makes sense to add intermediate > void* cast to silence the error. I'd be tempted to fix the signature and get rid of all the casts. Cheers, David > bug: https://bugs.openjdk.java.net/browse/JDK-8215009 > webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ > testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: > PASSED) > > -Dmitry > From david.holmes at oracle.com Tue Dec 11 01:34:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 11:34:41 +1000 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: References: Message-ID: <707b29c2-630b-6d47-425a-1ea745a78f7f@oracle.com> Hi Sergey, I've had a look and I don't think this issue is relevant to JDK-8171335. The problem seems to occur when you have a "hidden" enclosing context for the type, and that doesn't change with JDK-8171335. David On 9/12/2018 6:04 am, Sergey wrote: > Hi David, > > Thanks for pointing that out! > > >We need to see how this example work in that case. > > I guess anyone involved could have straight away two > test cases: one from the bug itself and another from the > observation above. > > In any case. looking forward for that being fixed. I would > also be happy to be able to help with anything if needed. > > Thanks and regards, > Sergei > > On Sat, 8 Dec 2018 at 12:03, David Holmes > wrote: > > Hi Sergey, > > Just FYI we're in the process of moving away from using anonymous > classes for lambda's to using an extended Lookup.defineClass API - see: > > https://bugs.openjdk.java.net/browse/JDK-8171335 > > this is being done under Project Valhalla, with current work in the > nestmates branch. > > We need to see how this example work in that case. > > Cheers, > David > > On 8/12/2018 9:53 am, Sergey wrote: > > Hi everyone, > > > > Recently I've stumbled upon this bug > > https://bugs.openjdk.java.net/browse/JDK-8213465 > > which is named the same way as in the header of an email. I've done a > > little bit of > > investigation and keen to fix it. Though I'm afraid that most > likely fix > > wouldn't be just > > a one-liner. Thus I want to ask for a little bit of a guidance > and make > > sure, that I do not cross > > anyone else. With that being said, if ticket isn't in progress > and no one > > minds I want to make > > an attempt on it. > > > > Thanks and regards, > > Sergei > > > From stuart.marks at oracle.com Tue Dec 11 02:11:33 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 10 Dec 2018 18:11:33 -0800 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> Message-ID: <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> On 12/7/18 10:22 AM, Vincent Ryan wrote: >> I'm not convinced that the overloads that send output to an OutputStream pull their weight. They basically wrap the OutputStream in a PrintStream, which conveniently doesn't declare IOException, making it easy to use from a lambda passed to forEachOrdered(). If an error writing the output occurs, this is recorded by the PrintStream wrapper; however, the wrapper is then thrown away, making it impossible for the caller to check its error status. > The intent is to support a trivial convenience method call that generates the well-known hexdump format. > Especially for users that are interested in the hexdump data rather than the low-level details of how to terminate a stream. > The dumpAsStream methods are available to support cases that differ from that format. > > Have you a suggestion to improve the dump() methods, or you?d like to see them omitted? > >> The PrintStream wrapper also uses the platform default charset, and doesn't provide any way for the caller to override the charset. > Is there a need for that? Originally the requirement was driven by the hexdump format which is ASCII-only. > Recently the class has been enhanced to also support the printable characters from ISO 8859-1. > A custom formatter be supplied to dumpAsStream() to cater for all other cases? OK, let's step back from this a bit. I see this hexdump as a little subsystem that has the following facets: 1) a source of bytes 2) a converter to hex 3) a destination The converter is HexDump.Formatter, which converts and formats a subrange of byte[] to a String. Since the user can supply the Formatter function, the result String can contain any unicode character. Thus, the destination needs to handle any unicode character. It can be a Writer, which accepts String data. Or if you want it to write bytes, it can be an OutputStream, which raises the issue of encoding (charset). I would recommend against relying on the platform default charset, as this has been a source of subtle bugs. The preferred approach these days is to default to UTF-8 and provide an overload that takes an explicit charset. An alternative is PrintStream. (This overlaps somewhat with your recent exchange with Roger on this topic.) PrintStream also does charset encoding, and the charset it uses depends on how it's created. I think the same approach should be applied as I described above with OutputStream, namely avoid the platform default charset; default to UTF-8; and provide an overload that takes an explicit charset. I'm not sure which of these is the right thing. You should decide which is the most convenient for the use cases you expect to see. However, the solution needs to handle charset encoding. (And it should also properly deal with I/O exceptions, per my previous message.) ** ISO 8859-1 comes up in a different place. The toPrintableString() method (used by the default formatter) considers a byte "printable" if it encodes a valid ISO 8859-1 character. The byte is properly decoded to a String, so this is ok. Note this is a distinct issue from the encoding of the OutputStream or PrintStream as described above. (As an aside I think that the encoding of ISO 8859-1 matches the corresponding code units of UTF-16, so you don't have to do the new String(..., ISO_8859_1) jazz. You can just cast the byte to a char and append it to the StringBuilder.) s'marks From merkel05 at gmail.com Tue Dec 11 06:27:43 2018 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Tue, 11 Dec 2018 07:27:43 +0100 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: <707b29c2-630b-6d47-425a-1ea745a78f7f@oracle.com> References: <707b29c2-630b-6d47-425a-1ea745a78f7f@oracle.com> Message-ID: Hi David, Thanks for checking it, I'll continue working on it then. Just wondering if you have any thoughts on how fix would look like. Regards, Sergei On Tue, 11 Dec 2018 at 02:34, David Holmes wrote: > Hi Sergey, > > I've had a look and I don't think this issue is relevant to JDK-8171335. > The problem seems to occur when you have a "hidden" enclosing context > for the type, and that doesn't change with JDK-8171335. > > David > > On 9/12/2018 6:04 am, Sergey wrote: > > Hi David, > > > > Thanks for pointing that out! > > > > >We need to see how this example work in that case. > > > > I guess anyone involved could have straight away two > > test cases: one from the bug itself and another from the > > observation above. > > > > In any case. looking forward for that being fixed. I would > > also be happy to be able to help with anything if needed. > > > > Thanks and regards, > > Sergei > > > > On Sat, 8 Dec 2018 at 12:03, David Holmes > > wrote: > > > > Hi Sergey, > > > > Just FYI we're in the process of moving away from using anonymous > > classes for lambda's to using an extended Lookup.defineClass API - > see: > > > > https://bugs.openjdk.java.net/browse/JDK-8171335 > > > > this is being done under Project Valhalla, with current work in the > > nestmates branch. > > > > We need to see how this example work in that case. > > > > Cheers, > > David > > From david.holmes at oracle.com Tue Dec 11 07:19:56 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 17:19:56 +1000 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: References: <707b29c2-630b-6d47-425a-1ea745a78f7f@oracle.com> Message-ID: <23a18f59-b3f9-4d6a-1e74-39f5ef87d57c@oracle.com> On 11/12/2018 4:27 pm, Sergei Ustimenko wrote: > Hi David, > > Thanks for checking it, I'll continue working on it then. > Just wondering if you have any thoughts on how fix would > look like. No. I tried tracking through the Java code to see how this works but the path is too long and convoluted :( The information is correct in the classfile, but somewhere along the way the nature of the enclosing type affects the answer that is produced. See ParameterizedTypeImpl and how it gets created by CoreReflectionFactory. BTW as far as I can see it is not allowed for that method to produce null: the type array can be empty, or creating it can throw an exception, but otherwise the entries cannot be null. Cheers, David > Regards, > Sergei > > On Tue, 11 Dec 2018 at 02:34, David Holmes > wrote: > > Hi Sergey, > > I've had a look and I don't think this issue is relevant to > JDK-8171335. > The problem seems to occur when you have a "hidden" enclosing context > for the type, and that doesn't change with JDK-8171335. > > David > > On 9/12/2018 6:04 am, Sergey wrote: > > Hi David, > > > > Thanks for pointing that out! > > > >? >We need to see how this example work in that case. > > > > I guess anyone involved could have straight away two > > test cases: one from the bug itself and another from the > > observation above. > > > > In any case. looking forward for that being fixed. I would > > also be happy to be able to help with anything if needed. > > > > Thanks and regards, > > Sergei > > > > On Sat, 8 Dec 2018 at 12:03, David Holmes > > > >> wrote: > > > >? ? ?Hi Sergey, > > > >? ? ?Just FYI we're in the process of moving away from using anonymous > >? ? ?classes for lambda's to using an extended Lookup.defineClass > API - see: > > > > https://bugs.openjdk.java.net/browse/JDK-8171335 > > > >? ? ?this is being done under Project Valhalla, with current work > in the > >? ? ?nestmates branch. > > > >? ? ?We need to see how this example work in that case. > > > >? ? ?Cheers, > >? ? ?David > From volker.simonis at gmail.com Tue Dec 11 07:52:59 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Dec 2018 08:52:59 +0100 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> <8993984c04d14dcca306993a96bbb82f@sap.com> Message-ID: Hi Roger, just to clarify - do you want us to push the last version [1] which adds "|| forceNullOutputStream)" to the Solaris version as well? Thank you and best regards, Volker [1] http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ On Mon, Dec 10, 2018 at 6:30 PM Roger Riggs wrote: > > Hi, > > The change looks fine and passes the current tests. > So ok to push. > > I think the test isn't correct, but I have not yet worked up a revised test. > > Thanks, Roger > > On 12/10/2018 09:00 AM, Lindenmaier, Goetz wrote: > > Hi Steve, > > > > I will push it once Roger gives his ok. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Steve Groeger > >> Sent: Montag, 10. Dezember 2018 14:42 > >> To: Lindenmaier, Goetz > >> Cc: core-libs-dev at openjdk.java.net; Roger Riggs > >> Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created > >> processes does not work. > >> > >> Hi Goetz, > >> > >> It is good that the tests you ran passed. What needs to be done now to get > >> this change pushed into the main code? > >> > >> Thanks > >> Steve Groeger > >> IBM Runtime Technologies > >> Hursley, Winchester > >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > >> Fax (44) 1962 816800 > >> Lotus Notes: Steve Groeger/UK/IBM > >> Internet: groeges at uk.ibm.com > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >> 3AU > >> > >> > >> > >> From: "Lindenmaier, Goetz" > >> To: Steve Groeger , Roger Riggs > >> > >> Cc: "core-libs-dev at openjdk.java.net" > >> Date: 10/12/2018 10:06 > >> Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created > >> processes does not work. > >> > >> ________________________________ > >> > >> > >> > >> > >> Hi, > >> > >> I ran the fix through our tests. There are no new regressions, and the > >> addressed test works. > >> > >> So reviewed from my side. > >> > >> I increased the bug to P3 so we can push it to jdk12 in case we > >> miss Thursday. > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: core-libs-dev On Behalf > >> Of > >>> Steve Groeger > >>> Sent: Freitag, 7. Dezember 2018 19:08 > >>> To: Roger Riggs > >>> Cc: core-libs-dev at openjdk.java.net > >>> Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created > >>> processes does not work. > >>> > >>> Hi Roger, > >>> > >>> I have made the same change to the Solaris code and also removed the test > >>> from the ProblemList.txt > >>> I have created a webrev here: > >>> http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ > >> > >>> Hope you can now test t > >>> > >>> Thanks > >>> Steve Groeger > >>> IBM Runtime Technologies > >>> Hursley, Winchester > >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > >>> Fax (44) 1962 816800 > >>> Lotus Notes: Steve Groeger/UK/IBM > >>> Internet: groeges at uk.ibm.com > >>> > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > >> number > >>> 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >>> 3AU > >>> > >>> > >>> > >>> From: Roger Riggs > >>> To: core-libs-dev at openjdk.java.net > >>> Date: 07/12/2018 14:55 > >>> Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between > >>> created processes does not work. > >>> Sent by: "core-libs-dev" > >>> > >>> > >>> > >>> Hi, > >>> > >>> I notice that the Solaris case also does not include "|| > >>> forceNullOutputStream". > >>> I'll have to investigate why the Pipeline test didn't fail on Solaris. > >>> > >>> Please add that to the patch and I'll run it through our tests. > >>> > >>> Thanks, Roger > >>> > >>> On 12/07/2018 03:05 AM, Volker Simonis wrote: > >>>> Hi Steve, > >>>> > >>>> thanks a lot for this fix. I'm forwarding this to core-libs-dev as > >>>> well, because that's where the review has to take place. The > >>>> "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > >>>> get their attention on relevant changes (so cross-posting is fine in > >>>> this case :) > >>>> > >>>> On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger > >>> wrote: > >>>>> Hi all, > >>>>> > >>>>> I have been investigating the issue > >>> https://bugs.openjdk.java.net/browse/JDK-8211844 > >> > >>> raised by Goetz Lindenmaier which is related to the > >>>>> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on > >>> AIX. Having done some investigation I have a potential fix fore the issue: > >>>>> > >>>>> diff -r 9501a7b59111 > >>> src/java.base/unix/classes/java/lang/ProcessImpl.java > >>>>> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec > >>> 03 14:28:19 2018 +0300 > >>>>> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec > >>> 06 15:01:03 2018 +0000 > >>>>> @@ -446,7 +446,7 @@ > >>>>> ProcessBuilder.NullOutputStream.INSTANCE : > >>>>> new ProcessPipeOutputStream(fds[0]); > >>>>> > >>>>> - stdout = (fds[1] == -1) ? > >>>>> + stdout = (fds[1] == -1 || forceNullOutputStream) ? > >>>>> ProcessBuilder.NullInputStream.INSTANCE : > >>>>> new > >>> DeferredCloseProcessPipeInputStream(fds[1]); > >>>> Your change looks good and I can sponsor it. Just as a hint for other > >>>> reviewers I'd like to mention that this change, albeit in a shared > >>>> Java file, is still AIX-only because it is in the "AIX" case of a > >>>> switch statement. > >>>> > >>>> @Steve: can you please verify, that your change introduces no > >>>> regression by running the complete jtreg test suite. > >>>> > >>>> Thank you and best regards, > >>>> Volker > >>>> > >>>>> I would appreciate any feedback please, and for someone to be a > >> sponsor > >>> for this and to contributute it to OpenJDK. > >>>>> Steve Groeger > >>>>> IBM Runtime Technologies > >>>>> Hursley, Winchester > >>>>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > >>>>> Fax (44) 1962 816800 > >>>>> Lotus Notes: Steve Groeger/UK/IBM > >>>>> Internet: groeges at uk.ibm.com > >>>>> > >>>>> Unless stated otherwise above: > >>>>> IBM United Kingdom Limited - Registered in England and Wales with > >>> number 741598. > >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >> PO6 > >>> 3AU > >>>>> Unless stated otherwise above: > >>>>> IBM United Kingdom Limited - Registered in England and Wales with > >>> number 741598. > >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >> PO6 > >>> 3AU > >>> > >>> > >>> > >>> > >>> > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > >> number > >>> 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >>> 3AU > >> > >> > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >> 3AU > From peter.levart at gmail.com Tue Dec 11 09:02:24 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Dec 2018 10:02:24 +0100 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: References: Message-ID: <5380274d-e2d4-0582-76f2-05c8f3babfd5@gmail.com> Hi Claes, Haven't checked all changes yet, although it looks like a straightforward swap of Properties for HashMap for intermediary result, but I noticed the following in SystemProps: ?265???????????? var cmdProps = new HashMap((vmProps.length / 2) + Raw.FIXED_LENGTH); The HashMap(int) constructor is different from Properties(int) in that for the former, the argument represents the lower bound on the initial size of the table (which is just a rounding of this parameter up to the nearest power of 2). The threshold where the table is resized is calculated as (initialCapacity rounded up to nearest power of 2) * loadFactor. The default load factor is 0.75 which means that the table will be resized in worst case after 3/4 * initialCapacity of elements are inserted into it. In order to guarantee that the table is not resized you have to pass (size * 4 + 2) / 3 to the HashMap constructor, where size is the number of elements added... I hope I'm not misleading you, I just think this is how HashMap has been from the beginning. Peeking at HashMap code (line 693) it seems that it is doing that: ??????????? float ft = (float)newCap * loadFactor; ??????????? newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ? ????????????????????? (int)ft : Integer.MAX_VALUE); newCap above is holding the initialCapacity constructor parameter rounded up to the nearest power of 2. newThr is the threshold at which the resize occurs. The Properties(int) constuctor behaves differently as it passes the parameter directly to the underlying ConcurrentHashMap, which says: ???? * @param initialCapacity The implementation performs internal ???? * sizing to accommodate this many elements. Regards, Peter On 12/10/18 10:17 PM, Claes Redestad wrote: > Hi, > > by inverting the order in which the internal property maps are created, > we avoid some classloading and get a slightly more efficient code > execution profile in System.initPhase1. > > Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 > > This reduces bytecode executed in initPhase1 from ~48k to ~36k. Not > much by any measure, but minimizing System.initPhase1 is important since > certain parts of the VM (JIT etc) are blocked from initializing until > it's done. > > Thanks! > > /Claes From claes.redestad at oracle.com Tue Dec 11 09:29:48 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 11 Dec 2018 10:29:48 +0100 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: <5380274d-e2d4-0582-76f2-05c8f3babfd5@gmail.com> References: <5380274d-e2d4-0582-76f2-05c8f3babfd5@gmail.com> Message-ID: <93089664-d244-e33a-f032-bf5143cca769@oracle.com> Hi Peter, On 2018-12-11 10:02, Peter Levart wrote: > Hi Claes, > > Haven't checked all changes yet, although it looks like a > straightforward swap of Properties for HashMap for intermediary result, > but I noticed the following in SystemProps: > > ?265???????????? var cmdProps = new HashMap String>((vmProps.length / 2) + Raw.FIXED_LENGTH); > > The HashMap(int) constructor is different from Properties(int) in that > for the former, the argument represents the lower bound on the initial > size of the table (which is just a rounding of this parameter up to the > nearest power of 2). The threshold where the table is resized is > calculated as (initialCapacity rounded up to nearest power of 2) * > loadFactor. The default load factor is 0.75 which means that the table > will be resized in worst case after 3/4 * initialCapacity of elements > are inserted into it. In order to guarantee that the table is not > resized you have to pass (size * 4 + 2) / 3 to the HashMap constructor, > where size is the number of elements added... > > I hope I'm not misleading you, I just think this is how HashMap has been > from the beginning. Peeking at HashMap code (line 693) it seems that it > is doing that: > > ??????????? float ft = (float)newCap * loadFactor; > ??????????? newThr = (newCap < MAXIMUM_CAPACITY && ft < > (float)MAXIMUM_CAPACITY ? > ????????????????????? (int)ft : Integer.MAX_VALUE); > > newCap above is holding the initialCapacity constructor parameter > rounded up to the nearest power of 2. newThr is the threshold at which > the resize occurs. > > The Properties(int) constuctor behaves differently as it passes the > parameter directly to the underlying ConcurrentHashMap, which says: > > ???? * @param initialCapacity The implementation performs internal > ???? * sizing to accommodate this many elements. Fun story, but I noticed this unfortunate difference when I was working on this very patch and brought it up in the team. I think most agrees the CHM behavior is the more intuitive and would have loved to consolidate to that behavior, but the message I've gotten is that it's probably too late to fix: Whichever way you go you get lots of little subtle changes to sizes that may lead to incompabilities in applications/tests that inadvertedly depend on the iteration order or HashMap etc.. That said: Raw typically contains quite a few empty/null values that'll never be put in the map. Enough so that for the applications I've looked at the initialCapacity is already a fair bit higher than it needs to be to avoid resizing. Thus it made little sense to take the maximum possible size and adjust it up even further by factoring in the default load factor. (Unless you have a *lot* of properties coming in via command line, but I think we should optimize for the common cases...) Thanks! /Claes > > Regards, Peter > > On 12/10/18 10:17 PM, Claes Redestad wrote: >> Hi, >> >> by inverting the order in which the internal property maps are created, >> we avoid some classloading and get a slightly more efficient code >> execution profile in System.initPhase1. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 >> >> This reduces bytecode executed in initPhase1 from ~48k to ~36k. Not >> much by any measure, but minimizing System.initPhase1 is important since >> certain parts of the VM (JIT etc) are blocked from initializing until >> it's done. >> >> Thanks! >> >> /Claes > From dmitry.chuyko at bell-sw.com Tue Dec 11 11:30:07 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 11 Dec 2018 14:30:07 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> Message-ID: On 12/11/18 4:03 AM, David Holmes wrote: > Hi Dmitry, > > On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >> Hello, >> >> Please review a small fix in java_md_solinux.c: continuation is not >> truly compatible with pthread_create start_routine's signature but we >> control what actually happens. So it makes sense to add intermediate >> void* cast to silence the error. > > I'd be tempted to fix the signature and get rid of all the casts. David, the signature is a signature of int JNICALL JavaMain(void * _args) It would be fun to change it. But still on Windows it is correctly passed to _beginthreadex() and then return code is extracted with GetExitCodeThread(). In case we want it to return void* the cast will move there. -Dmitry > > Cheers, > David > >> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >> testing: submit repo >> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >> >> -Dmitry >> From martin.doerr at sap.com Tue Dec 11 11:30:40 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 Dec 2018 11:30:40 +0000 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: <8f0a6226-d0b1-8c19-fb36-b620f6ee0819@oracle.com> References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 <8f0a6226-d0b1-8c19-fb36-b620f6ee0819@oracle.com> Message-ID: Hi Michihiro, the shared code looks good to me, now. Looks like the PPC64 is not consistent any more. Where do you enable UseCharacterCompareIntrinsics on PPC64? Why aren't you using it for match_rule_supported in the ad file? I think has_darn could be used to enable it in vm_version_ppc. Best regards, Martin -----Original Message----- From: Vladimir Kozlov Sent: Montag, 10. Dezember 2018 20:33 To: Michihiro Horie ; Gustavo Romero Cc: core-libs-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; Doerr, Martin ; Roger Riggs ; Simonis, Volker Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace On 12/9/18 5:28 PM, Michihiro Horie wrote: > Hi Vladimir, > > Thanks a lot for your review. I also fixed the copyright in intrinsicnode.hpp. > > >Did you look on code generated by C2 with your latest changes? > Yes,I usually check generated code with Oprofile and they were as expected like: > : > 90 0.0905 : 3fff64c27654: rlwinm r12,r9,24,8,31 > 12 0.0121 : 3fff64c27658: li r11,14640 > 15 0.0151 : 3fff64c2765c: cmprb cr5,0,r31,r11 > 5527 5.5587 : 3fff64c27660: setb r11,cr5 > 36010 36.2164 : 3fff64c27664: stb r11,16(r15) Good. > : > > I found a CSR FAQ that mentions adding a diagnostic flag do not need CSR process. This time I do not need CSR. > https://wiki.openjdk.java.net/display/csr/CSR+FAQs Thank is correct. > > Hi Gustavo, > Could I ask you to sponsor the latest change webrev.05? I would like you to test it on your P9 node too. Thanks, Vladimir > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Vladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > To: RogerVladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov To: Roger Riggs > , Michihiro Horie > > From: Vladimir Kozlov > To: Roger Riggs , Michihiro Horie > Cc: core-libs-dev at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, volker.simonis at sap.com > Date: 2018/12/08 03:48 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------------------------------------------------------ > > > > Hi Michihiro, > > Hotspot changes looks fine. > Did you look on code generated by C2 with your latest changes? > > And Copyright year change in intrinsicnode.hpp is incorrect: > > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > > Should be > > * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > > > Thanks, > Vladimir > > On 12/7/18 10:08 AM, Roger Riggs wrote: > > Hi Michihiro, > > > > Looks fine with the updates. > > > > Its great that the change to isDigit is beneficial on other platforms too. > > > > A very small editorial: > > ?? There should be a comma? "," after the 2018 in the copyright of: > > ?? test/micro/org/openjdk/bench/java/lang/Characters.java > > > > Thanks, Roger > > > > > > On 12/07/2018 03:13 AM, Michihiro Horie wrote: > >> > >> Hi Roger, > >> > >> I updated my webrev. > >> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ > >> > >> > >> >0x80 might be a good choice or 0xff. > >> I agree,thanks. > >> > >> >I was wondering about the performance without the PPC specific intrinsic but with the > >> >CharacterDataLatin1.java.template code for isDigit being: > >> >??? ??? return '0' <= ch && ch <= '9'; > >> I now understand your point,thanks for your explanation. Both on Power9 and Skylake, the > >> isDigit(ch)using ?0???9?explicitly in CharacterDataLatin1.java.template without PPC specific > >> intrinsicwas around 15% faster than the original code that does not include my changes. I fixed my > >> change using ?0???9?for this isDigit(ch). > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 > >> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 > >> AM, Michihiro Horie wrote: > >> > >> From: Roger Riggs > >> To: Michihiro Horie > >> Cc: core-libs-dev at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net, martin.doerr at sap.com, > >> vladimir.kozlov at oracle.com, volker.simonis at sap.com > >> Date: 2018/12/07 01:23 > >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> ---------------------------------------------------------------------------------------------------- > >> > >> > >> > >> Hi Michihiro, > >> > >> On 12/06/2018 02:38 AM, Michihiro Horie wrote: > >> > >> ? ? ? ? Hi Roger, > >> > >> ? ? ? ? Thank you for your helpful comments. I updated new webrev, adding a parameter in the jmh > >> ? ? ? ? test to measure ?other? characters and moving the file to an appropriate location, also > >> ? ? ? ? fixing the indents and copyright year._ > >> > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.03_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=aKLGn7JZawWsl9UR7H-PyYoTpBc23BAKMqGScywbC5U&e= > >> ? ? ? ? > >> > >> The choice of 256 for other is outside the range of Latin1 which is 0..255. > >> 0x80 might be a good choice or 0xff. > >> > >> > >> ? ? ? ? >Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' > >> ? ? ? ? >in CharacterDataLatin1.java.template?? The performance would need to be measured and > >> ? ? ? ? compared. > >> ? ? ? ? Yes, there is an opportunity: intrinsic performed 25% better than the original on Power9. > >> > >> I was wondering about the performance without the PPC specific intrinsic but with the > >> CharacterDataLatin1.java.template code for isDigit being: > >> ??? ??? return '0' <= ch && ch <= '9'; > >> > >> > >> ? ? ? ? >Is the profile of in-lining methods changed in any measurable way now that > >> ? ? ? ? >there is an extra level of method invocation? > >> ? ? ? ? > ?? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == > >> ? ? ? ? LOWERCASE_LETTER; > >> ? ? ? ? > > >> ? ? ? ? >instead of: > >> ? ? ? ? >??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > >> ? ? ? ? I missed this point, thanks. I tried jstack but could not find additional level. > >> > >> ? ? ? ? LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled in c1: > >> ? ? ? ? >> ? ? ? ? address='0x00003fff5911cb90' relocation_offset='344' insts_offset='368' stub_offset='1136' > >> ? ? ? ? scopes_data_offset='1248' scopes_pcs_offset='1336' dependencies_offset='1448' > >> ? ? ? ? nul_chk_table_offset='1456' oops_offset='1184' metadata_offset='1192' > >> ? ? ? ? method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' bytes='15' count='1024' > >> ? ? ? ? iicount='1025' stamp='0.058'/> > >> > >> Supposing some existing complex code was already taking advantage of the full allowed inline depth. > >> Then adding an extra level might change the inlining behavior. > >> > >> > >> ? ? ? ? Existing methods in CharacterDataLatin1.java.template etc. directly invoke > >> ? ? ? ? getProperties(ch), so isLowerCase(ch) would be more aligned with other methods if it looks > >> ? ? ? ? like as follows? > >> ? ? ? ? + @HotSpotIntrinsicCandidate > >> ? ? ? ? + boolean isLowerCase(int ch) { > >> ? ? ? ? + int props = getProperties(ch); > >> ? ? ? ? + return (props & $$maskType) == Character.LOWERCASE_LETTER; > >> ? ? ? ? + } > >> > >> Yes, that would alleviate my concern. > >> > >> Thanks, Roger > >> > >> > >> > >> ? ? ? ? Best regards, > >> ? ? ? ? -- > >> ? ? ? ? Michihiro, > >> ? ? ? ? IBM Research - Tokyo > >> > >> ? ? ? ? Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 > >> ? ? ? ? 07:21 AM, Michihiro Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On > >> ? ? ? ? 12/05/2018 07:21 AM, Michihiro Horie wrote: > >> > >> ? ? ? ? From: Roger Riggs __ > >> ? ? ? ? To: Michihiro Horie __ , > >> ? ? ? ? _vladimir.kozlov at oracle.com_ > >> ? ? ? ? Cc: _core-libs-dev at openjdk.java.net_ , > >> ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ , > >> ? ? ? ? _martin.doerr at sap.com_ , _volker.simonis at sap.com_ > >> ? ? ? ? > >> ? ? ? ? Date: 2018/12/06 05:09 > >> ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ---------------------------------------------------------------------------------------------------- > >> > >> > >> > >> ? ? ? ? Hi Michihiro, > >> > >> ? ? ? ? On 12/05/2018 07:21 AM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? >There are a few JMH tests for upper and lower in the > >> ? ? ? ? ? ? ? ? ? ? ? ? jmh-jdk-microbenchmarks repo. [1] > >> ? ? ? ? ? ? ? ? ? ? ? ? Here is a jmh webrev for the Character methods._ > >> > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_jmh-2Dwebrev.00_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=v22au5r5gvv48ufyda1poelXBjJWwuotSFrv-M2AlRY&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? Please include at least one > character value that is not a member of any of the classes. > >> ? ? ? ? The performance impact for 'other' characters is important also. > >> > >> ? ? ? ? The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: > >> ? ? ? ? ?? test/micro/org/openjdk/bench/java/lang/ > >> > >> ? ? ? ? Now that they are in that repo, they can be included with the rest of the changeset. > >> ? ? ? ? ? ? ? ? ? ? ? ? Also, I updated C2 changes in the latest webrev. (Thank you for giving > >> ? ? ? ? ? ? ? ? ? ? ? ? valuable comments off-list, Vladimir and Martin!) > >> ? ? ? ? ? ? ? ? ? ? ? ? With the change in is_disabled_by_flags, I added a JVM flag that will need > >> ? ? ? ? ? ? ? ? ? ? ? ? another review request. I would proceed for it if this RFR is accepted._ > >> > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.02_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=UXQByb5dFxfAwCCppkizqG_-RWf6DhE_PFkr9TsyzKo&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? The indent in the Java code should > be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 > >> ? ? ? ? spaces) > >> > >> ? ? ? ? Please update the copyrights to include 2018. > >> > >> ? ? ? ? Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' > >> ? ? ? ? in CharacterDataLatin1.java.template?? The performance would need to be measured and compared. > >> > >> ? ? ? ? Is the profile of in-lining methods changed in any measurable way now that > >> ? ? ? ? there is an extra level of method invocation? > >> ? ? ? ? ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == > >> ? ? ? ? LOWERCASE_LETTER; > >> > >> ? ? ? ? instead of: > >> ? ? ? ? ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > >> > >> ? ? ? ? Regards, Roger > >> ? ? ? ? ? ? ? ? ? ? ? ? I need a review on changes in the class library, anyway. Would be grateful > >> ? ? ? ? ? ? ? ? ? ? ? ? if I could have one. > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? -- > >> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? ----- Original message ----- > >> ? ? ? ? ? ? ? ? ? ? ? ? From: Michihiro Horie/Japan/IBM > >> ? ? ? ? ? ? ? ? ? ? ? ? To: Vladimir Kozlov __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , Roger Riggs __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? Date: Fri, Nov 30, 2018 1:01 PM > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Hi Vladimir, > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Thank you for your further comments. I fixed my code, but I?m afraid > >> ? ? ? ? ? ? ? ? ? ? ? ? discussing such a basic topic involving the two big mailing lists is not > >> ? ? ? ? ? ? ? ? ? ? ? ? good. Please let me have a chance to talk on this off-list. > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? -- > >> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not > >> ? ? ? ? ? ? ? ? ? ? ? ? understand which Region node you are swapping. Where it is coming from? > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? From: Vladimir Kozlov __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? To: Michihiro Horie __ , Roger > >> ? ? ? ? ? ? ? ? ? ? ? ? Riggs __ > >> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? Date: 2018/11/30 03:01 > >> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> > ---------------------------------------------------------------------------------------------------- > >> > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Hi Michihiro, > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? I still do not understand which Region node you are swapping. Where it is > >> ? ? ? ? ? ? ? ? ? ? ? ? coming from? > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? Regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? On 11/28/18 10:31 PM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir,Roger, > >> ? ? ? ? ? ? ? ? ? ? ? ? > Thank you so much for your responses. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir, > >> ? ? ? ? ? ? ? ? ? ? ? ? > Regarding the hotspot change,I?m new in changing around > >> ? ? ? ? ? ? ? ? ? ? ? ? library_call.cpp,so your comments are very helpful. I will fix > >> ? ? ? ? ? ? ? ? ? ? ? ? > my code,especially inline_character_compare()would be like: > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ > >> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* old_rgn = control()->as_Region(); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* new_rgn = new RegionNode(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + record_for_igvn(new_rgn); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one > >> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* new_ctrl = old_rgn->in(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + old_rgn->del_req(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + new_rgn->add_req(new_ctrl); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + set_control(_gvn.transform(new_rgn)); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + // argument(0)is receiver > >> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* codePoint = argument(1); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* n = NULL; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + switch (id){ > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isDigit_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? DigitCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isLowerCase_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? LowerCaseCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isUpperCase_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? UpperCaseCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isWhitespace_c : n = new > >> ? ? ? ? ? ? ? ? ? ? ? ? WhitespaceCNode(control(),codePoint);break; > >> ? ? ? ? ? ? ? ? ? ? ? ? > + default: > >> ? ? ? ? ? ? ? ? ? ? ? ? > + fatal_unexpected_iid(id); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + } > >> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ? ? ? ? ? ? ? ? ? ? ? ? > + set_result(_gvn.transform(n)); > >> ? ? ? ? ? ? ? ? ? ? ? ? > + return true; > >> ? ? ? ? ? ? ? ? ? ? ? ? > +} > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Microbenchmark showed ~40% improvements. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Roger, > >> ? ? ? ? ? ? ? ? ? ? ? ? > I would wait foryour review,thanks. I understood the discussion had not > >> ? ? ? ? ? ? ? ? ? ? ? ? been recognized from people in core-libs-dev,and > >> ? ? ? ? ? ? ? ? ? ? ? ? > checked it was not actually archived there?. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll > >> ? ? ? ? ? ? ? ? ? ? ? ? look at it on Thursday.Roger Riggs ---2018/11/29 > >> ? ? ? ? ? ? ? ? ? ? ? ? > 11:21:26---Hi, I'll look at it on Thursday. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > From: Roger Riggs __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > To: Vladimir Kozlov __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , Michihiro Horie __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _core-libs-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > Cc: _volker.simonis at sap.com_ , > >> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > Date: 2018/11/29 11:21 > >> ? ? ? ? ? ? ? ? ? ? ? ? > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > ------------------------------------------------------------------------------------------------------------------------ > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > Hi, > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > I'll look at it on Thursday. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > In spite of it looking like the email was sent to core-lib-dev, I have > >> ? ? ? ? ? ? ? ? ? ? ? ? > not seen it before > >> ? ? ? ? ? ? ? ? ? ? ? ? > and its not in the core-libs-dev archive. > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > $.02, Roger > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You still need review from core-libs. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> About your hotspot changes. You need to add intrinsics to > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> is_disabled_by_flags() to be able switch them off. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Note, match_rule_supported() calls in > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> are registered. So they will not be available if they are not > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> supported. match_rule_supported() checks in > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() are not needed. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> I don't get what you code in > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() is doing. Why you check > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Region node at the beginning and why you add Region and Phi at the end > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> if you have only one path? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You are creating code for whole method which should return boolean result > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?boolean isDigit(int ch) { > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?} > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> but your code produce TypeInt::CHAR. why? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> An finally. Did you compare code generated by default and with you > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> changes? what improvement you see? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Thanks, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Vladimir > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Is there any response from core-libs-dev? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Vladimir, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Could you give your suggestion on how to proceed? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"hotspot-compiler-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Thu, Nov 22, 2018 11:28 AM > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Yes, we should wait for the feedback on class library change. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Btw. I think you can further simplify the code in library_call.cpp > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for pointing out it, I think I understand how to simplify > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> code. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Hi Michi, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> >Please note that we don?t have a machine, yet. So other people > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> will have to test. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> I think Gustavo can help testing this change when its' ready. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Sure :) > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Gustavo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you, Gustavo. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, thanks. This proposal makes the javacode much"Doerr, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> makes the java code much moreintrinsics friendly. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie __ , > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: _"hotspot-compiler-dev at openjdk.java.net"_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ > >> ? ? ? ? ? ? ? ? ? ? ? ? , "Simonis, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Volker"__ , > >> ? ? ? ? ? ? ? ? ? ? ? ? Gustavo Romero > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/22 01:33 > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > ------------------------------------------------------------------------------------------------------------------------ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> thanks. This proposal makes the java code much more intrinsics friendly. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> We should wait for feedback from the core lib folks. Maybe they have > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> some requirements or other proposals. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think these intrinsics should be interesting for Oracle, Intel and > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> others, too. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Btw. I think you can further simplify the code in library_call.cpp > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie __ * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> __ ; Gustavo > >> ? ? ? ? ? ? ? ? ? ? ? ? Romero__ * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I send this RFR to core-libs-dev too, because it changes the class > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> library. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Through trial and error, I separated Latin1 block as in the _ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > ___https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.01-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=co8xQFD19i2JBuYtSh2KKr-qUmwPdt6MEpJErzBfsd0&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.01-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=w78kALiRtp6DIYAfslpK_TGpubqajF0h32O_z_ITAF4&e=>_/_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I followed the coding way of Character.isWhitespace() that invokes > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase(), and isUpperCase(). > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think this change is also useful on x86, using STTNI. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> > <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Wed, Nov 21, 2018 1:53 AM > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for giving your helpful comments. I did not recognize > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static? prevents anyoptimizations, but I now > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> checked it actually degraded the performance, thanks. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Please note that we don?t have a machine, yet. So other people will > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> have to test. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think Gustavo can help testing this change when its' ready. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Would it be possible to introduce more fine-grained intrinsics such > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Maybe you can factor out as in the following example? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>if (latin1) return isLatin1Digit(codePoint); > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thanks for an example, please let me try to separate the Latin block > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> from other blocks for some time. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, first of all, thanks for working onPower9 opt"Doerr, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for working on Power9optimizations. Please note that we don't ha > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_>" > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/20 01:55 > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > ------------------------------------------------------------------------------------------------------------------------ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first of all, thanks for working on Power9 optimizations. Please note > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that we don?t have a machine, yet. So other peoplewill have to test. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think it may be problematic to insert a slow path by > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static?. This may be a performancedisadvantage > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for some users of other encodings because your intrinsics prevent > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> inlining and further optimizations. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would it be possible to introduce more fine-grained intrinsics such > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Maybe you can factor out as in the following example? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> if (latin1) return isLatin1Digit(codePoint); > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I can?t judge if this is needed, but I think this should be discussed > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first before going into the details. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:HORIE at jp.ibm.com_>>* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Freitag, 16. November 2018 12:53* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_>>; > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_ <_mailto:gromero at linux.vnet.ibm.com_>>* > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Dear all, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would you please review following change? > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Bug: > >> ? ? ? ? ? ? ? ? ? ? ? ? > > __https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=yTUTl4D2EPdboqkkAHXYtHx5KijWhAzXOXPBqwME0iQ&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Webrev: > >> ? ? ? ? ? ? ? ? ? ? ? ? > > __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.00-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=88Ms75RO8511eAgWMsvWrTDLmRRcxcKiEs_DkSZmVlc&e= > >> ? ? ? ? ? ? ? ? ? ? ? ? > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=zZl2pxTY0Dn-5RZHkTZSnIRpYzb-w9T_4d8cV7gU3iw&e=> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> This change includes the intrinsics of Character isDigit, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compare a character with 1 or 2 rangedbytes, while the cmpeqb > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compares one with 1 to 8 values. Simple micro benchmark attached > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> showed improvements by 20-40%. > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> / > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> //(See attached file: Latin1Test.java)/ > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ? ? ? ? ? ? ? ? ? ? ? ? > > >> > >> > >> > >> > >> > >> > > > > > > From rachel at strangenoises.org Tue Dec 11 12:55:31 2018 From: rachel at strangenoises.org (Rachel Greenham) Date: Tue, 11 Dec 2018 12:55:31 +0000 Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> Message-ID: Although I do understand the reasoning (non-repeatability of streams), Stream not implementing Iterable is a minor but frequent annoyance for this precise reason. Using forEach() instead isn't always an option. Maybe Iterable can have a superinterface IterableOnce with the methods moved up to there, and iterator() specified to throw IllegalStateException if called twice, and which enhanced-for recognises, then Stream can implement that? (Ducks and runs...) Or enhanced-for can also take Supplier, so we can do 'for (Thing e : stream::iterator)' instead of 'for (Thing e : (Iterable)stream::iterator)' (runs faster...) -- Rachel On 10/12/2018 22:11, Rob Griffin (rgriffin) wrote: > Hi Remi, > > There are certainly places where we could do this when we are simply iterating over the results but that is not always the case. However I was disappointed to find that the enhanced for loop can't iterate over a stream so if callers of your example methods where doing something like this > > for (Employee emp : getAllEmployee()) { > ... > } > > then it would have to change to a forEach call if getAllEmployee returned a Stream. > > Regards, > > Rob Griffin > Software Analyst, Spotlight on SQL Server > Quest | R&D > rob.griffin at quest.com > Office +613-9811-8021 > > -----Original Message----- > From: Remi Forax > Sent: Tuesday, 11 December 2018 4:26 AM > To: Rob Griffin (rgriffin) > Cc: core-libs-dev ; Brian Goetz > Subject: Re: Add convenience collect methods to the Stream interface > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi Rob, > i will add to the answer of Brian that if you have too many .collect(toList()), it's perhaps your application perhaps suffers of the equivalent of the n + 1 select query you have with SQL but with the Stream API. > > You should try to see if returning a Stream instead of a List for some of methods is not a better option: > public List getAllEmployee() { > return employees.stream().filter(Employee::isActive).collect(toList()); > } > public List getManager(List list) { > return list.stream().filter(Employee::isManager).collect(toList()); > } > ... > getManager(getAllEmployee()); > > should be: > public Stream getAllEmployee() { > return employees.stream().filter(Employee::isActive); > } > public Stream getManager(Stream stream) { > return stream.filter(Employee::isManager); > } > ... > getManager(getAllEmployee()).collect(toList()); > > > regards, > R?mi > > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Rob Griffin (rgriffin)" , "core-libs-dev" >> >> Envoy?: Lundi 10 D?cembre 2018 17:14:41 >> Objet: Re: Add convenience collect methods to the Stream interface >> As will surprise no one, this was extensively discussed during the >> development of the Streams API. (Our default position on "convenience >> methods" is hostile. While everyone sees the benefit of convenience >> methods (it's convenient!), most people don't see the cost, which >> includes the complexity for users to understand the model by looking >> at the API; having lots of ad-hoc convenience method obscures the >> underlying model, making it harder for everyone to learn or reason >> about. That default position seems to stand up pretty well here, as >> the stream API is pretty well factored.) >> >> Let's be honest: the "convenience" or concision of being able to say >> .toList() instead of .collect(toList()) is really small. I don't >> think you'll be able to justify it by saying "but we do it a lot." >> (Digression: to whoever is about to say "then why `toArray()`? Arrays >> are different; for better or worse, they're part of the language, and >> they lend themselves particularly poorly to the Collector API, and >> there are particular parallelization optimizations that are possible >> for arrays that can't be accessed through Collector. End digression.) >> >> It is possible, however, that one could justify `toList()` on the >> basis of _discoverability_. (Though I'm having a hard time seeing any >> world where `toSet()` makes the cut.) New users who approach streams >> will not easily be able to figure out how to materialize a list from a >> stream, even though this is an entirely reasonable and quite common >> thing to want to do. Having to learn about `collect()` first is >> asking a lot of users who are still wrapping their heads around >> streams. Not only would `toList()` be more discoverable, it would >> provide a path to discovery of the rest of the `collect()` API. This is a point in its favor. >> >> A significant downside of adding `toList()` is that by diluting the >> orthogonality of the existing API, it provides both incentive and >> justification for further dilution, leading to someplace we don't want >> to be. (And, the cost of that falls heavily on the stewards, which in >> turn takes time away from far more valuable activities.) >> >> Put it this way: imagine we have a budget of one convenience method in >> Stream for every five years. Is this the one we want to spend the >> next five year's budget on? (And, who of the proponents will >> volunteer to answer the next 200 "I have an idea for a stream method" >> mails, explaining that the budget is spent?) >> >> >> So, summary: >> >> - I won't outright veto `toList`, as I would for almost all other >> "convenience" streams additions, because this one actually has a valid >> non-convenience argument; >> - But, it's still not a slam dunk. >> >> >> On 12/9/2018 5:44 PM, Rob Griffin (rgriffin) wrote: >>> Hi, >>> >>> I have raised an enhancement request (Incident Report 913453) about >>> adding some convenience methods to the Stream interface that collect >>> the stream and Pallavi Sonal asked me to start a thread here about that. >>> >>> More than 50% of our Stream collect calls use Collectors.toList() or >>> Collectors.toSet() as arguments so I think it would be very handy if >>> the Stream interface had default collectToList and collectToList and collectToMap methods. >>> >>> The advantages are: >>> it would be easier to use code completion in IDEs. There are lot of classes >>> starting with Collect so finding the Collectors class is a bit of a pain. >>> one less method call in what is usually a long chain of calls. >>> >>> Regards, >>> >>> Rob Griffin >>> Software Analyst, Spotlight on SQL Server Quest | R&D >>> rob.griffin at quest.com From Alan.Bateman at oracle.com Tue Dec 11 13:04:24 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Dec 2018 13:04:24 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> Message-ID: <3cb00752-54f9-4b8e-376c-69ab0b47cd60@oracle.com> On 08/12/2018 01:18, Vincent Ryan wrote: > Here?s the latest version that addresses all the current open issues: > > webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ > javadoc: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html > > CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 > I read through the latest javadoc corresponding to webrev.07. Overall I think it looks very good except for dumpAsStream(ByteBuffer, fromIndex, toIndex, chunkSize, Formatter) as it's not clear if fromIndex is from the buffer position or an absolute index. If the former then there are a couple of other issues. I see Roger has touched on the advancement of the buffer position to its limit which isn't right unless all remaining bytes in the? buffer are consumer. There is also an issue with the exception as attempting to consume beyond the limit is a BufferUnderflowException. It might be simpler to replace this method with a dumpAsStream(ByteBuffer, chunkSize, Formatter) that can lazily (rather than eagerly) consume the remaining bytes. Additional overloads could be added in the future if needed. dumpAsStream(InputStream) specifies "On return, the input stream will be at end-of-stream" but I assume this isn't right as the method is lazy. The 3-arg dumpAsStream doesn't specify the exception/behavior for when chunkSize is <= 0. fromString(CharSequence) may need clarification on how it behaves when the CS is a CharBuffer. Does it consume all the remaining chars in the buffer so its position be advanced to the limit? The 3-arg version is also not clear on this point. In Formatter interface it may be useful to expand the description of the "offset" parameter as readers may not immediately understand that it's just an input for the formatted string rather than a real offset, an example might help. It also doesn't say if the offset can be specified as <= 0L or not. A minor comment is that several places refer to a byte array as a "byte buffers. Is this deliberate or can these be replaced with "byte array" to avoid confusion. Another minor comment is that one of the dumpAsStream methods is missing @throws NPE - maybe they should all be removed and replaced with a statement in the class description. -Alan From peter.levart at gmail.com Tue Dec 11 13:42:51 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Dec 2018 14:42:51 +0100 Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> Message-ID: <623e76d6-c444-bbbd-e067-7eba19ce9170@gmail.com> Hi Rob, On 12/10/18 11:11 PM, Rob Griffin (rgriffin) wrote: > Hi Remi, > > There are certainly places where we could do this when we are simply iterating over the results but that is not always the case. However I was disappointed to find that the enhanced for loop can't iterate over a stream so if callers of your example methods where doing something like this > > for (Employee emp : getAllEmployee()) { > ... > } > > then it would have to change to a forEach call if getAllEmployee returned a Stream. You can also get an Iterator from a Stream, so if you need external iteration over elements of a Stream you don't have to collect it 1st to some Collection: ??? Stream names() { ??????? return Stream.of("John", "Jil", "Jack"); ??? } ...and then... ??????? for (String name : (Iterable) names()::iterator) { ??????????? System.out.println(name); ??????? } This is hack-ish as it relies on the fact that enhanced for loop calls Iterable.iterator() method only once, but is the only way to do it if you already have a reference to Stream at hand. This would be more correct way of doing it if you can call a factory for Stream: ??????? for (String name : (Iterable) () -> names().iterator()) { ??????????? System.out.println(name); ??????? } Regards, Peter P.S. I wonder why the enhanced for loop doesn't establish a context where the type of expression after the colon could be inferred, so no cast would be necessary. Perhaps because that type could either be an Iterable or a T[] ? From sverre.moe at gmail.com Tue Dec 11 14:00:47 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 11 Dec 2018 15:00:47 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <515eb41d-303d-7820-486c-a736519b5dcb@oracle.com> References: <3f21f7a3-6021-5120-e00f-89d5e64d2ffd@oracle.com> <515eb41d-303d-7820-486c-a736519b5dcb@oracle.com> Message-ID: The help output of jpackager should mention how to set the classpath for the various bundle resource files. I have not found a working solution how to set the classpath. jpackager -classpath build/deploy/ jpackager -cp build/deploy/ DEB Using default package resource [menu icon] (add package/linux/application.png to the class path to customize) Using default package resource [Menu shortcut descriptor] (add package/linux/application.desktop to the class path to customize) Using default package resource [DEB control file] (add package/linux/control to the class path to customize) RPM Using default package resource [menu icon] (add package/linux/application.png to the class path to customize) Using default package resource [Menu shortcut descriptor] (add package/linux/application.desktop to the class path to customize) Using default package resource [RPM spec file] (add package/linux/application.spec to the class path to customize) The application image can be set with the --icon argument. --icon build/deploy/package/linux/application.png Using custom package resource [menu icon] (loaded from file /home/user/workspace/application/build/deploy/package/linux/application.png) Perhaps jpackager should have an package directory argument --package-dir build/deploy /Sverre Den tor. 15. nov. 2018 kl. 15:05 skrev Andy Herrick : > > On 11/10/2018 8:12 AM, Sverre Moe wrote: > > I have been using the jpackager that Johan Vos backported for OpenJDK 11. > For this I have some points of improvement I would like to mention. > > 1) > The control file for debian package does not set correct description > > --name test > --description This is a Test Application > > /tmp/jdk.packager607148779833718376/linux/control > Package: test > Description: test > > The RPM gets it correctly > Summary : test > Description : > This is a Test Application > > > 2) > Category is not set on either DEB or RPM > --category > Category or group of the application. > --category "Some/Category/Application" > Group: Unspecified > Section: unknown > > 3) > The jpackager command line should have the flag --release in addition to > --version. The only way to set a different release than "1" is to supply a > custom spec file for RPM and control file for DEB. > package/linux/test.spec > Version: 1.0.0 > Release: RC1 > package/linux/control > Version: 1.0.0-RC1 > > I have filed issue JDK-8213941 > and we will be looking > into it. > > Thanks. > > /Andy > > > /Sverre > > From brian.goetz at oracle.com Tue Dec 11 14:05:01 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Dec 2018 09:05:01 -0500 Subject: Add convenience collect methods to the Stream interface In-Reply-To: References: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> Message-ID: <65a9d13a-f43d-30f6-a2ce-c55e3d733b02@oracle.com> You say it jokingly, but we've explored this.? (The exact way you phrase it (the supertype specified to throw if called more than once) means that Iterable can't extend IterableOnce, because then Iterable does not conform to the superclass contract, but there are other ways to stack it.)? It's not completely unworkable, but as you've observed, it's not so clean. In the JSR-335 EG, we also explored (and rejected, because it felt like the library tail wagging the language dog) the route of adding language support for more kinds of things on the RHS of the for-each loop. (Zooming out: the main reason this is irritating is the limitations of what you can do in a method like .forEach() vs the foreach loop -- exception transparency, nonlocal return, up-scope local mutation.? Though it is unlikely that we'll have great solutions for these all that soon, so its reasonable to consider library-based solutions in the meantime.) On 12/11/2018 7:55 AM, Rachel Greenham wrote: > Although I do understand the reasoning (non-repeatability of streams), > Stream not implementing Iterable is a minor but frequent annoyance for > this precise reason. Using forEach() instead isn't always an option. > > Maybe Iterable can have a superinterface IterableOnce with the methods > moved up to there, and iterator() specified to throw > IllegalStateException if called twice, and which enhanced-for > recognises, then Stream can implement that? (Ducks and runs...) > > Or enhanced-for can also take Supplier, so we can do 'for > (Thing e : stream::iterator)' instead of 'for (Thing e : > (Iterable)stream::iterator)' > > (runs faster...) > From forax at univ-mlv.fr Tue Dec 11 14:18:24 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 11 Dec 2018 15:18:24 +0100 (CET) Subject: Add convenience collect methods to the Stream interface In-Reply-To: <623e76d6-c444-bbbd-e067-7eba19ce9170@gmail.com> References: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> <623e76d6-c444-bbbd-e067-7eba19ce9170@gmail.com> Message-ID: <2022347345.395752.1544537904249.JavaMail.zimbra@u-pem.fr> Hi Rob, Hi Petter, we (the lambda EG) have decided against implementing Iterable (see the answer of Brian), so for consistency we have also not enable the right hand side of a enhanced for loop to be a poly-expression (that enables the lambda conversion), hence the mandatory cast. R?mi ----- Mail original ----- > De: "Peter Levart" > ?: "Rob Griffin, rgriffin" , "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Mardi 11 D?cembre 2018 14:42:51 > Objet: Re: Add convenience collect methods to the Stream interface > Hi Rob, > > On 12/10/18 11:11 PM, Rob Griffin (rgriffin) wrote: >> Hi Remi, >> >> There are certainly places where we could do this when we are simply iterating >> over the results but that is not always the case. However I was disappointed to >> find that the enhanced for loop can't iterate over a stream so if callers of >> your example methods where doing something like this >> >> for (Employee emp : getAllEmployee()) { >> ... >> } >> >> then it would have to change to a forEach call if getAllEmployee returned a >> Stream. > > You can also get an Iterator from a Stream, so if you need external > iteration over elements of a Stream you don't have to collect it 1st to > some Collection: > > ??? Stream names() { > ??????? return Stream.of("John", "Jil", "Jack"); > ??? } > > ...and then... > > ??????? for (String name : (Iterable) names()::iterator) { > ??????????? System.out.println(name); > ??????? } > > This is hack-ish as it relies on the fact that enhanced for loop calls > Iterable.iterator() method only once, but is the only way to do it if > you already have a reference to Stream at hand. This would be more > correct way of doing it if you can call a factory for Stream: > > ??????? for (String name : (Iterable) () -> names().iterator()) { > ??????????? System.out.println(name); > ??????? } > > Regards, Peter > > P.S. I wonder why the enhanced for loop doesn't establish a context > where the type of expression after the colon could be inferred, so no > cast would be necessary. Perhaps because that type could either be an > Iterable or a T[] ? From Roger.Riggs at oracle.com Tue Dec 11 14:17:31 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 09:17:31 -0500 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: <3f9a0ea0-0d8b-89bb-f043-5725c803c6ab@oracle.com> <8993984c04d14dcca306993a96bbb82f@sap.com> Message-ID: <47fd5ee5-6d57-0d3c-b921-a39899770933@oracle.com> Yes please, with the Solaris update. Thanks, Roger On 12/11/2018 02:52 AM, Volker Simonis wrote: > Hi Roger, > > just to clarify - do you want us to push the last version [1] which > adds "|| forceNullOutputStream)" to the Solaris version as well? > > Thank you and best regards, > Volker > > [1] http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ > On Mon, Dec 10, 2018 at 6:30 PM Roger Riggs wrote: >> Hi, >> >> The change looks fine and passes the current tests. >> So ok to push. >> >> I think the test isn't correct, but I have not yet worked up a revised test. >> >> Thanks, Roger >> >> On 12/10/2018 09:00 AM, Lindenmaier, Goetz wrote: >>> Hi Steve, >>> >>> I will push it once Roger gives his ok. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Steve Groeger >>>> Sent: Montag, 10. Dezember 2018 14:42 >>>> To: Lindenmaier, Goetz >>>> Cc: core-libs-dev at openjdk.java.net; Roger Riggs >>>> Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created >>>> processes does not work. >>>> >>>> Hi Goetz, >>>> >>>> It is good that the tests you ran passed. What needs to be done now to get >>>> this change pushed into the main code? >>>> >>>> Thanks >>>> Steve Groeger >>>> IBM Runtime Technologies >>>> Hursley, Winchester >>>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>>> Fax (44) 1962 816800 >>>> Lotus Notes: Steve Groeger/UK/IBM >>>> Internet: groeges at uk.ibm.com >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>>> 3AU >>>> >>>> >>>> >>>> From: "Lindenmaier, Goetz" >>>> To: Steve Groeger , Roger Riggs >>>> >>>> Cc: "core-libs-dev at openjdk.java.net" >>>> Date: 10/12/2018 10:06 >>>> Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created >>>> processes does not work. >>>> >>>> ________________________________ >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> I ran the fix through our tests. There are no new regressions, and the >>>> addressed test works. >>>> >>>> So reviewed from my side. >>>> >>>> I increased the bug to P3 so we can push it to jdk12 in case we >>>> miss Thursday. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: core-libs-dev On Behalf >>>> Of >>>>> Steve Groeger >>>>> Sent: Freitag, 7. Dezember 2018 19:08 >>>>> To: Roger Riggs >>>>> Cc: core-libs-dev at openjdk.java.net >>>>> Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created >>>>> processes does not work. >>>>> >>>>> Hi Roger, >>>>> >>>>> I have made the same change to the Solaris code and also removed the test >>>>> from the ProblemList.txt >>>>> I have created a webrev here: >>>>> http://cr.openjdk.java.net/~sgroeger/jtreg/8211844/webrev.01/ >>>> >>>>> Hope you can now test t >>>>> >>>>> Thanks >>>>> Steve Groeger >>>>> IBM Runtime Technologies >>>>> Hursley, Winchester >>>>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>>>> Fax (44) 1962 816800 >>>>> Lotus Notes: Steve Groeger/UK/IBM >>>>> Internet: groeges at uk.ibm.com >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number >>>>> 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>>>> 3AU >>>>> >>>>> >>>>> >>>>> From: Roger Riggs >>>>> To: core-libs-dev at openjdk.java.net >>>>> Date: 07/12/2018 14:55 >>>>> Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between >>>>> created processes does not work. >>>>> Sent by: "core-libs-dev" >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I notice that the Solaris case also does not include "|| >>>>> forceNullOutputStream". >>>>> I'll have to investigate why the Pipeline test didn't fail on Solaris. >>>>> >>>>> Please add that to the patch and I'll run it through our tests. >>>>> >>>>> Thanks, Roger >>>>> >>>>> On 12/07/2018 03:05 AM, Volker Simonis wrote: >>>>>> Hi Steve, >>>>>> >>>>>> thanks a lot for this fix. I'm forwarding this to core-libs-dev as >>>>>> well, because that's where the review has to take place. The >>>>>> "ppc-aix-port-dev" list is mostly a marker for the port maintainers to >>>>>> get their attention on relevant changes (so cross-posting is fine in >>>>>> this case :) >>>>>> >>>>>> On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger >>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I have been investigating the issue >>>>> https://bugs.openjdk.java.net/browse/JDK-8211844 >>>> >>>>> raised by Goetz Lindenmaier which is related to the >>>>>>> jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on >>>>> AIX. Having done some investigation I have a potential fix fore the issue: >>>>>>> diff -r 9501a7b59111 >>>>> src/java.base/unix/classes/java/lang/ProcessImpl.java >>>>>>> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec >>>>> 03 14:28:19 2018 +0300 >>>>>>> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec >>>>> 06 15:01:03 2018 +0000 >>>>>>> @@ -446,7 +446,7 @@ >>>>>>> ProcessBuilder.NullOutputStream.INSTANCE : >>>>>>> new ProcessPipeOutputStream(fds[0]); >>>>>>> >>>>>>> - stdout = (fds[1] == -1) ? >>>>>>> + stdout = (fds[1] == -1 || forceNullOutputStream) ? >>>>>>> ProcessBuilder.NullInputStream.INSTANCE : >>>>>>> new >>>>> DeferredCloseProcessPipeInputStream(fds[1]); >>>>>> Your change looks good and I can sponsor it. Just as a hint for other >>>>>> reviewers I'd like to mention that this change, albeit in a shared >>>>>> Java file, is still AIX-only because it is in the "AIX" case of a >>>>>> switch statement. >>>>>> >>>>>> @Steve: can you please verify, that your change introduces no >>>>>> regression by running the complete jtreg test suite. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>>> I would appreciate any feedback please, and for someone to be a >>>> sponsor >>>>> for this and to contributute it to OpenJDK. >>>>>>> Steve Groeger >>>>>>> IBM Runtime Technologies >>>>>>> Hursley, Winchester >>>>>>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>>>>>> Fax (44) 1962 816800 >>>>>>> Lotus Notes: Steve Groeger/UK/IBM >>>>>>> Internet: groeges at uk.ibm.com >>>>>>> >>>>>>> Unless stated otherwise above: >>>>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>> number 741598. >>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 >>>>> 3AU >>>>>>> Unless stated otherwise above: >>>>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>> number 741598. >>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 >>>>> 3AU >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number >>>>> 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>>>> 3AU >>>> >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>>> 3AU From forax at univ-mlv.fr Tue Dec 11 14:24:10 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 11 Dec 2018 15:24:10 +0100 (CET) Subject: Add convenience collect methods to the Stream interface In-Reply-To: <2022347345.395752.1544537904249.JavaMail.zimbra@u-pem.fr> References: <1086834582.202210.1544462778427.JavaMail.zimbra@u-pem.fr> <623e76d6-c444-bbbd-e067-7eba19ce9170@gmail.com> <2022347345.395752.1544537904249.JavaMail.zimbra@u-pem.fr> Message-ID: <1246555250.397250.1544538250429.JavaMail.zimbra@u-pem.fr> And i've forgotten to add that currently calling stream.iterator() is sloooow, i don't know if it's just because the implementation of this method did not get some love or it's a more fundamental issue because a spliterator is push while an iterator is pull so the implementation needs an intermediary memory to store the element in between. R?mi ----- Mail original ----- > De: "Remi Forax" > ?: "Peter Levart" > Cc: "Rob Griffin, rgriffin" , "core-libs-dev" > Envoy?: Mardi 11 D?cembre 2018 15:18:24 > Objet: Re: Add convenience collect methods to the Stream interface > Hi Rob, Hi Petter, > we (the lambda EG) have decided against implementing Iterable (see the answer of > Brian), so for consistency we have also not enable the right hand side of a > enhanced for loop to be a poly-expression (that enables the lambda conversion), > hence the mandatory cast. > > R?mi > > ----- Mail original ----- >> De: "Peter Levart" >> ?: "Rob Griffin, rgriffin" , "Remi Forax" >> >> Cc: "core-libs-dev" >> Envoy?: Mardi 11 D?cembre 2018 14:42:51 >> Objet: Re: Add convenience collect methods to the Stream interface > >> Hi Rob, >> >> On 12/10/18 11:11 PM, Rob Griffin (rgriffin) wrote: >>> Hi Remi, >>> >>> There are certainly places where we could do this when we are simply iterating >>> over the results but that is not always the case. However I was disappointed to >>> find that the enhanced for loop can't iterate over a stream so if callers of >>> your example methods where doing something like this >>> >>> for (Employee emp : getAllEmployee()) { >>> ... >>> } >>> >>> then it would have to change to a forEach call if getAllEmployee returned a >>> Stream. >> >> You can also get an Iterator from a Stream, so if you need external >> iteration over elements of a Stream you don't have to collect it 1st to >> some Collection: >> >> ??? Stream names() { >> ??????? return Stream.of("John", "Jil", "Jack"); >> ??? } >> >> ...and then... >> >> ??????? for (String name : (Iterable) names()::iterator) { >> ??????????? System.out.println(name); >> ??????? } >> >> This is hack-ish as it relies on the fact that enhanced for loop calls >> Iterable.iterator() method only once, but is the only way to do it if >> you already have a reference to Stream at hand. This would be more >> correct way of doing it if you can call a factory for Stream: >> >> ??????? for (String name : (Iterable) () -> names().iterator()) { >> ??????????? System.out.println(name); >> ??????? } >> >> Regards, Peter >> >> P.S. I wonder why the enhanced for loop doesn't establish a context >> where the type of expression after the colon could be inferred, so no >> cast would be necessary. Perhaps because that type could either be an > > Iterable or a T[] ? From magnus.ihse.bursie at oracle.com Tue Dec 11 14:34:51 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Dec 2018 15:34:51 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> Message-ID: <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> On 2018-12-11 00:23, David Holmes wrote: > Hi Magnus, > > On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >> I propose that we introduce a new define, available to all JDK native >> files (Hotspot included), called JDK_EXPORT. The behavior of this >> symbol will be very similar (as of now, in fact identical) to >> JNIEXPORT; however, the semantics will not. >> >> Currently, we "mis-use" the JNIEXPORT define to mark a function for >> exporting from the library. The problem with this is that JNIEXPORT >> is part of the JNI interface, and is supposed to be used when C >> programs interact with Java. And, when doing this, the function >> should be fully decorated like this: "JNIEXPORT foo JNICALL". > > I've seen a lot of the emails on this issue and I don't fully > understand what has been going wrong. But the intent is obviously the > JNIEXPORT represents what is needed to export this function for use by > JNI, while JNICALL defines the calling convention. I agree there may > be some mistmatch when functions are actually not intended for general > export outside the JDK but are only for internal JDK use. > >> We do have many such JNI exports in our native libraries, but we also >> have a lot of other, non-JNI exports, where one native library just >> provides an interface to other libraries. In these cases, we have >> still used JNIEXPORT for the functionality of getting the function >> exported, but we have not been consistent in our use of JNICALL. This >> has caused us way too much trouble for something that should Just >> Work. > > Are you suggesting that the interface between different libraries in > the JDK should not be a JNI interface? Is this because you think the > functions in these libraries are only for JDK internal use or ... ?? > >> I therefore propose that we define "JDK_EXPORT", with the same >> behavior as JNIEXPORT (that is, flagging the function for external >> visibility in the resulting native library), but which is *not* >> supposed to be exported to Java code using JNI, nor supposed to be >> decorated with > > Just a clarification there. JNI functions are not exported to Java > code, they are exported to native code. Java code can declare native > methods and those native methods must be written as JNI functions, but > that's not what we are discussing. Libraries expose a JNI interface (a > set of functions in the library) that can be called by application > native code, using JNI. We're apparently looking at "JNI" and "exporting" from two opposite sides here. :-) Just to make everything clear: If I have a Java class class MyClass { public static void native myNativeFunc(); } then I have one half of the JNI function, the Java half. This must be matched by a corresponding implementation in native, like this: JNIEXPORT void JNICALL Java_MyClass_myNativeFunc(void) { // ... do stuff } And this is the native half of the JNI function. Right? Let's leave aside which side is "exporting" to the other for now. :-) This way of setting up native functions that can be called from Java is what I refer to as JNI. And when you declare a native JNI function, you *must* use both JNIEXPORT and JNICALL. Alright? We do have a lot of those functions in our native libraries. And they are correct just the way they are. However, we also have *other* native functions, that are exported, not as JNI functions that should be called from Java, but as normal native library functions that should be called by other native code. Okay so far? And *those* functions have been problematic in how we decorate them. My proposal is that we *refrain* from using JNIEXPORT for those functions, and instead use JDK_EXPORT as name for the macro that decorates them as exported. That way, we can clearly see that a function like this: JDK_EXPORT void JLI_ReadEnv(char* env); is correctly declared, and will be exported to other native libraries, but not to Java. Just to clarify, this has nothing to do with if this is a officially supported API or not. In general though, I assume that most (if not all?) of our exported functions (apart from the JNI_* stuff) is supposed to be consumed by other libraries in the JDK, and is not a public API. /Magnus > >> JNICALL. All current instances of JNIEXPORT which is not pure JNI >> native functions should be changed to use JDK_EXPORT instead. >> >> I further propose that this macro should reside in a new file >> "jdk.h", placed in the new directory >> src/java.base/share/native/include/internal. This header file path >> will automatically be provided to all native libraries, but not >> copied to the JDK being built. (The existence of a "include/internal" >> directory with this behavior has been discussed before. There are >> more files that ought to be moved there, if/when it is created.) I >> believe in many cases the #include "jni.h" can be just modified to >> #include "#jdk.h", since most native code will not require "jni.h" >> unless actually doing JNI calls -- most have included this file to >> get the JNIEXPORT macro, which would explain the pervasive use of >> #include "jni.h" in our code base. > > jni.h also defines all of the types used by the JNI. Those types are > pervsive to the native code used throughout the JDK. > >> Thoughts? > > I think we need to understand the problems on Windows that prompted > all this. Then I think we need to look at exactly how jni.h and > JNIEXPORT etc are being used and understand whether this is truly an > exported interface or not. > > Cheers, > David > >> /Magnus >> From naoto.sato at oracle.com Tue Dec 11 14:51:57 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 11 Dec 2018 06:51:57 -0800 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect Message-ID: Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8215194 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ This one line fix is for the correctness of the initial map size of Character.UnicodeBlock. Naoto From adam.farley at uk.ibm.com Tue Dec 11 15:03:57 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 11 Dec 2018 15:03:57 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words Message-ID: Hey All, I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 I've created a webrev and attached to the bug. Also, I've mentioned in the bug that there are additional swears in more excusable locations. It would be good to get the community's take on those. Reviews and opinions welcome. :) Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alexey.ivanov at oracle.com Tue Dec 11 15:05:37 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 11 Dec 2018 15:05:37 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: Hi everyone, I came up with the following patch: http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ It specifically addresses the problem in JDK-8214122 where on 32 bit Windows jdwpTransport_OnLoad can exported with its plain and __stdcall-mangled name. I used conditional compilation so that for other platforms the code remains as it is now. jshell starts successfully with this fix; an IDE debugger works as well. Regards, Alexey https://bugs.openjdk.java.net/browse/JDK-8214122 On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >> Since removing JNICALL is not an option, there are only two options: >> >> 1. Add |/export| option to the Makefile or pragma-comment to the >> source file; >> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >> with fallback to undecorated one. > Yes. > > I think the correct solution here is 2. From volker.simonis at gmail.com Tue Dec 11 15:22:11 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Dec 2018 16:22:11 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> Message-ID: On Tue, Dec 11, 2018 at 3:35 PM Magnus Ihse Bursie wrote: > > > > On 2018-12-11 00:23, David Holmes wrote: > > Hi Magnus, > > > > On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >> I propose that we introduce a new define, available to all JDK native > >> files (Hotspot included), called JDK_EXPORT. The behavior of this > >> symbol will be very similar (as of now, in fact identical) to > >> JNIEXPORT; however, the semantics will not. > >> > >> Currently, we "mis-use" the JNIEXPORT define to mark a function for > >> exporting from the library. The problem with this is that JNIEXPORT > >> is part of the JNI interface, and is supposed to be used when C > >> programs interact with Java. And, when doing this, the function > >> should be fully decorated like this: "JNIEXPORT foo JNICALL". > > > > I've seen a lot of the emails on this issue and I don't fully > > understand what has been going wrong. But the intent is obviously the > > JNIEXPORT represents what is needed to export this function for use by > > JNI, while JNICALL defines the calling convention. I agree there may > > be some mistmatch when functions are actually not intended for general > > export outside the JDK but are only for internal JDK use. > > > >> We do have many such JNI exports in our native libraries, but we also > >> have a lot of other, non-JNI exports, where one native library just > >> provides an interface to other libraries. In these cases, we have > >> still used JNIEXPORT for the functionality of getting the function > >> exported, but we have not been consistent in our use of JNICALL. This > >> has caused us way too much trouble for something that should Just > >> Work. > > > > Are you suggesting that the interface between different libraries in > > the JDK should not be a JNI interface? Is this because you think the > > functions in these libraries are only for JDK internal use or ... ?? > > > >> I therefore propose that we define "JDK_EXPORT", with the same > >> behavior as JNIEXPORT (that is, flagging the function for external > >> visibility in the resulting native library), but which is *not* > >> supposed to be exported to Java code using JNI, nor supposed to be > >> decorated with > > > > Just a clarification there. JNI functions are not exported to Java > > code, they are exported to native code. Java code can declare native > > methods and those native methods must be written as JNI functions, but > > that's not what we are discussing. Libraries expose a JNI interface (a > > set of functions in the library) that can be called by application > > native code, using JNI. > We're apparently looking at "JNI" and "exporting" from two opposite > sides here. :-) Just to make everything clear: If I have a Java class > class MyClass { > public static void native myNativeFunc(); > } > > then I have one half of the JNI function, the Java half. This must be > matched by a corresponding implementation in native, like this: > JNIEXPORT void JNICALL > Java_MyClass_myNativeFunc(void) { > // ... do stuff > } > > And this is the native half of the JNI function. Right? Let's leave > aside which side is "exporting" to the other for now. :-) > > This way of setting up native functions that can be called from Java is > what I refer to as JNI. And when you declare a native JNI function, you > *must* use both JNIEXPORT and JNICALL. Alright? > > We do have a lot of those functions in our native libraries. And they > are correct just the way they are. > > However, we also have *other* native functions, that are exported, not > as JNI functions that should be called from Java, but as normal native > library functions that should be called by other native code. Okay so > far? And *those* functions have been problematic in how we decorate > them. My proposal is that we *refrain* from using JNIEXPORT for those > functions, and instead use JDK_EXPORT as name for the macro that > decorates them as exported. That way, we can clearly see that a function > like this: > > JDK_EXPORT void > JLI_ReadEnv(char* env); > > is correctly declared, and will be exported to other native libraries, > but not to Java. > Hi Magnus, I agree with your explanation and I think your proposal is sound. Have you checked how many of the occurrences of "#include "jni.h"" can really be replaced by "#include "jdk.h""? I think native code also "misuses" jni.h in order to agree on common types like jint, jlong, etc.. across different native libraries. We could of course also define such common types in "jdk.h", but I'm not sure if it's worth the effort? Regards, Volker > Just to clarify, this has nothing to do with if this is a officially > supported API or not. In general though, I assume that most (if not > all?) of our exported functions (apart from the JNI_* stuff) is supposed > to be consumed by other libraries in the JDK, and is not a public API. > > /Magnus > > > > > > >> JNICALL. All current instances of JNIEXPORT which is not pure JNI > >> native functions should be changed to use JDK_EXPORT instead. > >> > >> I further propose that this macro should reside in a new file > >> "jdk.h", placed in the new directory > >> src/java.base/share/native/include/internal. This header file path > >> will automatically be provided to all native libraries, but not > >> copied to the JDK being built. (The existence of a "include/internal" > >> directory with this behavior has been discussed before. There are > >> more files that ought to be moved there, if/when it is created.) I > >> believe in many cases the #include "jni.h" can be just modified to > >> #include "#jdk.h", since most native code will not require "jni.h" > >> unless actually doing JNI calls -- most have included this file to > >> get the JNIEXPORT macro, which would explain the pervasive use of > >> #include "jni.h" in our code base. > > > > jni.h also defines all of the types used by the JNI. Those types are > > pervsive to the native code used throughout the JDK. > > > >> Thoughts? > > > > I think we need to understand the problems on Windows that prompted > > all this. Then I think we need to look at exactly how jni.h and > > JNIEXPORT etc are being used and understand whether this is truly an > > exported interface or not. > > > > Cheers, > > David > > > >> /Magnus > >> > From Alan.Bateman at oracle.com Tue Dec 11 15:32:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Dec 2018 15:32:31 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: On 11/12/2018 15:03, Adam Farley8 wrote: > Hey All, > > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > I've created a webrev and attached to the bug. > > Also, I've mentioned in the bug that there are additional swears in more > excusable locations. It would be good to get the community's take on > those. > > Reviews and opinions welcome. :) "Where's that damn torpedo?" might be from Star Trek. From matthias.baesken at sap.com Tue Dec 11 15:38:43 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Dec 2018 15:38:43 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> Message-ID: > File paths are, in general, always something that demands extra scrutiny > as it can be the source of security issues (privacy leaks, traversal > attacks, etc). It's not just me that thinks that way, you can do a > search on the Internet and find lots of references. ... > > It might be perfectly fine and your usage might be ok too. But I'll need > some time to evaluate it further. I am not familiar with the code in > this part of the JDK. > > I would also see if you can think about the security issues as well. > Where do these paths come from? What are the application use cases that > invoke these lower methods? From application code or elsewhere? Are > relative paths used? Are paths containing ".." canonicalized? Are they > arbitrary paths or a fixed set of paths? Do they ever contain sensitive > information like home directory user names, etc? > > Once we understand if there are any security issues, then we can decide > if allowing that via a system property is acceptable or not, and if so > the security risks that we would have to document for that property. > Hello, the file paths potentially printed in the enhanced exceptions in *canonicalize0, *createFileExclusively, Java_java_io_WinNTFileSystem_canonicalizeWithPrefix0 could potentially come from more or less arbitrary paths. This means, in some cases, there is a chance that information (like user-ids/user-names often found in paths below HOME dirs ) might be in the printed paths that people do not want to have in log files or other output containing the exception messages. For such potentially sensitive info in exception messages, we have already the jdk.includeInExceptions security property, see the java.security file : 1064 # Enhanced exception message information 1065 # 1066 # By default, exception messages should not include potentially sensitive 1067 # information such as file names, host names, or port numbers. This property 1068 # accepts one or more comma separated values, each of which represents a 1069 # category of enhanced exception message information to enable. Values are 1070 # case-insensitive. Leading and trailing whitespaces, surrounding each value, 1071 # are ignored. Unknown values are ignored. I think this approach fits well for 8211752 (and is used already for some other categories). I created an updated webrev, it uses the jdk.includeInExceptions security property (had to do it via JNI because it did not work from the static class initializers of UnixFileSystem/WinNTFileSystem) : http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.2/ Best regards, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Donnerstag, 8. November 2018 20:36 > To: Baesken, Matthias ; Langer, Christoph > ; Alan Bateman ; > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > On 11/7/18 3:52 AM, Baesken, Matthias wrote: > >> Sorry, I haven't had time to look at this in more detail yet. But, let's > >> take a step back first. Can you or Matthias explain in more detail why > >> this fix is necessary? What are the use cases and motivation? > > > > Hello, > > adding paths (or maybe more details) to exception messages just > makes analyzing errors easier. > > You do not get just "Bad path", but also the real bad path which gives you a > hint where to look and analyze further . > > File paths are, in general, always something that demands extra scrutiny > as it can be the source of security issues (privacy leaks, traversal > attacks, etc). It's not just me that thinks that way, you can do a > search on the Internet and find lots of references. > > > That's why we introduced it in our JVM ages ago. > > I have to agree that additionally printing cwd / user.dir is a bit special, so I > omit that from this revision of the patch. > > This makes the patch more simple. > > New revision : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.1/ > > > > > > Unfortunately the usage of sun.security.util.SecurityProperties (which was > considered) in the static { ... } > > class initializers (e.g. UnixFileSystem.java) just does not work. > > It fails with already in the build (!) with : > > > > Error occurred during initialization of boot layer > > java.lang.ExceptionInInitializerError > > Caused by: java.lang.NullPointerException > > > > (seems it is too early in the game for SecurityProperties). > > (btw. this is another NOT very helpful exception error message) > > > > > > So I unfortunately had to go back to using system properties. > > > > > > Btw. another question regarding path output in exceptions : > > you seem to consider it a bad thing to (unconditionally) print paths in the > exception messages, > > but then on the other hand we have it already in OpenJDK > UnixFileSystem_md.c : > > > > 269 JNIEXPORT jboolean JNICALL > > 270 Java_java_io_UnixFileSystem_createFileExclusively(JNIEnv *env, > jclass cls, > > 271 jstring pathname) > > 272 { > > ....... > > 277 /* The root directory always exists */ > > 278 if (strcmp (path, "/")) { > > 279 fd = handleOpen(path, O_RDWR | O_CREAT | O_EXCL, 0666); > > 280 if (fd < 0) { > > 281 if (errno != EEXIST) > > 282 JNU_ThrowIOExceptionWithLastError(env, path); > > 283 } else { > > 284 if (close(fd) == -1) > > 285 JNU_ThrowIOExceptionWithLastError(env, path); > > > > > > Why is it fine here for a long time , but considered harmful at the other > places ? > > If we want to be consistent, we should then write "Bad path" here (or > allow the path output at the other places too ). > > It might be perfectly fine and your usage might be ok too. But I'll need > some time to evaluate it further. I am not familiar with the code in > this part of the JDK. > > I would also see if you can think about the security issues as well. > Where do these paths come from? What are the application use cases that > invoke these lower methods? From application code or elsewhere? Are > relative paths used? Are paths containing ".." canonicalized? Are they > arbitrary paths or a fixed set of paths? Do they ever contain sensitive > information like home directory user names, etc? > > Once we understand if there are any security issues, then we can decide > if allowing that via a system property is acceptable or not, and if so > the security risks that we would have to document for that property. > > Thanks, > Sean > From adam.farley at uk.ibm.com Tue Dec 11 15:40:27 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 11 Dec 2018 15:40:27 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: Alan Bateman wrote on 11/12/2018 15:32:31: > From: Alan Bateman > To: Adam Farley8 , core-libs-dev dev at openjdk.java.net> > Date: 11/12/2018 15:33 > Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words > > On 11/12/2018 15:03, Adam Farley8 wrote: > > Hey All, > > > > I've spotted 12 instances of swear words in OpenJDK source comments, and > > it seems appropriate to remove them. > > > > Bug: INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8215217&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=qU1GS7jvxOg5rsMfdgT3_qee4ZirvY2cajsOhIza2y8&s=R4gzHBoqzCQdmJLCSmPyLfRrHH-5xtvUArpwaaXk2Ck&e= > > > > I've created a webrev and attached to the bug. > > > > Also, I've mentioned in the bug that there are additional swears in more > > excusable locations. It would be good to get the community's take on > > those. > > > > Reviews and opinions welcome. :) > "Where's that damn torpedo?" might be from Star Trek. > Yep, Kirk said it. Perhaps "d**n" or "darn" would better preserve the quote? - Adam Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From volker.simonis at gmail.com Tue Dec 11 15:46:44 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Dec 2018 16:46:44 +0100 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: Hi Adam, in order to prevent me from using swear words, could you please upload your webrev to cr.openjdk.java.net :) As you may have realized webrevs are a collection of HTML files and it makes no big sense to provide them as a zip file. Thank you and best regards, Volker On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8 wrote: > > Hey All, > > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > I've created a webrev and attached to the bug. > > Also, I've mentioned in the bug that there are additional swears in more > excusable locations. It would be good to get the community's take on > those. > > Reviews and opinions welcome. :) > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From pavel.rappo at oracle.com Tue Dec 11 15:48:49 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 11 Dec 2018 15:48:49 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: <167C68D2-F21A-4D83-BE09-6648358A4CB7@oracle.com> Sweet! Learning English with the OpenJDK community. You sir, probably, have a degree in public relations and/or marketing. This was *the best* way to draw attention to those swear words. Had these words stayed unexposed, no one would have been bothered by them. I guess... On a serious note, I wouldn't change cave art just because we might find it inappropriate, it's history now. > On 11 Dec 2018, at 15:32, Alan Bateman wrote: > > On 11/12/2018 15:03, Adam Farley8 wrote: >> Hey All, >> >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 >> >> I've created a webrev and attached to the bug. >> >> Also, I've mentioned in the bug that there are additional swears in more >> excusable locations. It would be good to get the community's take on >> those. >> >> Reviews and opinions welcome. :) > "Where's that damn torpedo?" might be from Star Trek. From Roger.Riggs at oracle.com Tue Dec 11 15:57:23 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 10:57:23 -0500 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: References: Message-ID: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> Hi Naoto, Since the value changes from time to time, it would give it some visibility if it were defined using a private final int? (or float) ???? private final int MAP_CAPACITY = 667; Though I suppose the test can't use the value without using reflection. But it would lower the maintenance in the long term. $.02, Roger On 12/11/2018 09:51 AM, Naoto Sato wrote: > Hi, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8215194 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ > > This one line fix is for the correctness of the initial map size of > Character.UnicodeBlock. > > Naoto From gromero at linux.vnet.ibm.com Tue Dec 11 15:59:35 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 11 Dec 2018 13:59:35 -0200 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: <5b42c2e000be4c05b3e175be519c1fd7@sap.com> References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 <5b42c2e000be4c05b3e175be519c1fd7@sap.com> Message-ID: <6f36aa76-190c-b496-c562-b72b80ee1c1f@linux.vnet.ibm.com> Hi Martin, On 12/11/2018 01:30 PM, Doerr, Martin wrote: > thanks for updating. I think it can get shipped when Gustavo is fine with it and jdk/submit tests have passed. Yep, I'm working on that right now. I'll update soon. So I have to push to jdk/submit, wait the test results and if it's fine I'll push to jdk/jdk after, right? > Note that changes pushed before Thursday 16:00 UTC will go into jdk12. Got it. Thank you. Best regards, Gustavo > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Dienstag, 11. Dezember 2018 14:08 > *To:* Doerr, Martin > *Cc:* core-libs-dev at openjdk.java.net; Gustavo Romero ; hotspot-compiler-dev at openjdk.java.net; Roger Riggs ; Vladimir Kozlov ; Simonis, Volker > *Subject:* RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > Hi Martin, > > Thank you so much for your review and pointing out the issue on flag enablement on PPC64. > > Latest webrev enables the flag on PPC64 using has_darn in vm_version_ppc and it is used in match_rule_supported in the ad file. > http://cr.openjdk.java.net/~mhorie/8213754/webrev.06/ > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for "Doerr, Martin" ---2018/12/11 20:31:40---Hi Michihiro, the shared code looks good to me, now."Doerr, Martin" ---2018/12/11 20:31:40---Hi Michihiro, the shared code looks good to me, now. > > From: "Doerr, Martin" > > To: Vladimir Kozlov >, Michihiro Horie >, Gustavo Romero > > Cc: "core-libs-dev at openjdk.java.net " >, "hotspot-compiler-dev at openjdk.java.net " >, Roger Riggs >, "Simonis, Volker" > > Date: 2018/12/11 20:31 > Subject: RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > Hi Michihiro, > > the shared code looks good to me, now. > > Looks like the PPC64 is not consistent any more. > Where do you enable UseCharacterCompareIntrinsics on PPC64? > Why aren't you using it for match_rule_supported in the ad file? > I think has_darn could be used to enable it in vm_version_ppc. > > Best regards, > Martin > > > -----Original Message----- > From: Vladimir Kozlov > > Sent: Montag, 10. Dezember 2018 20:33 > To: Michihiro Horie >; Gustavo Romero > > Cc: core-libs-dev at openjdk.java.net ; hotspot-compiler-dev at openjdk.java.net ; Doerr, Martin >; Roger Riggs >; Simonis, Volker > > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > On 12/9/18 5:28 PM, Michihiro Horie wrote: >> Hi Vladimir, >> >> Thanks a lot for your review. I also fixed the copyright in intrinsicnode.hpp. >> >> ?>Did you look on code generated by C2 with your latest changes? >> Yes,I usually check generated code with Oprofile and they were as expected like: >> : >> 90 0.0905 : 3fff64c27654: rlwinm r12,r9,24,8,31 >> 12 0.0121 : 3fff64c27658: li r11,14640 >> 15 0.0151 : 3fff64c2765c: cmprb cr5,0,r31,r11 >> 5527 5.5587 : 3fff64c27660: setb r11,cr5 >> 36010 36.2164 : 3fff64c27664: stb r11,16(r15) > > Good. > >> : >> >> I found a CSR FAQ that mentions adding a diagnostic flag do not need CSR process. This time I do not need CSR. >> https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > Thank is correct. > >> >> Hi Gustavo, >> Could I ask you to sponsor the latest change webrev.05? I would like you to test it on your P9 node too. > > Thanks, > Vladimir > >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> >> Inactive hide details for Vladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > >> To: RogerVladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > To: Roger Riggs >> >, Michihiro Horie > >> >> From: Vladimir Kozlov > >> To: Roger Riggs >, Michihiro Horie > >> Cc: core-libs-dev at openjdk.java.net , hotspot-compiler-dev at openjdk.java.net , martin.doerr at sap.com , volker.simonis at sap.com >> Date: 2018/12/08 03:48 >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> >> >> Hi Michihiro, >> >> Hotspot changes looks fine. >> Did you look on code generated by C2 with your latest changes? >> >> And Copyright year change in intrinsicnode.hpp is incorrect: >> >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. >> >> Should be >> >> * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. >> >> >> Thanks, >> Vladimir >> >> On 12/7/18 10:08 AM, Roger Riggs wrote: >> ?> Hi Michihiro, >> ?> >> ?> Looks fine with the updates. >> ?> >> ?> Its great that the change to isDigit is beneficial on other platforms too. >> ?> >> ?> A very small editorial: >> ?> ?? There should be a comma? "," after the 2018 in the copyright of: >> ?> ?? test/micro/org/openjdk/bench/java/lang/Characters.java >> ?> >> ?> Thanks, Roger >> ?> >> ?> >> ?> On 12/07/2018 03:13 AM, Michihiro Horie wrote: >> ?>> >> ?>> Hi Roger, >> ?>> >> ?>> I updated my webrev. >> ?>> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ ? >> ?>> >> ?>> >> ?>> >0x80 might be a good choice or 0xff. >> ?>> I agree,thanks. >> ?>> >> ?>> >I was wondering about the performance without the PPC specific intrinsic but with the >> ?>> >CharacterDataLatin1.java.template code for isDigit being: >> ?>> >??? ??? return '0' <= ch && ch <= '9'; >> ?>> I now understand your point,thanks for your explanation. Both on Power9 and Skylake, the >> ?>> isDigit(ch)using ?0???9?explicitly in CharacterDataLatin1.java.template without PPC specific >> ?>> intrinsicwas around 15% faster than the original code that does not include my changes. I fixed my >> ?>> change using ?0???9?for this isDigit(ch). >> ?>> >> ?>> >> ?>> Best regards, >> ?>> -- >> ?>> Michihiro, >> ?>> IBM Research - Tokyo >> ?>> >> ?>> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 >> ?>> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 >> ?>> AM, Michihiro Horie wrote: >> ?>> >> ?>> From: Roger Riggs > >> ?>> To: Michihiro Horie > >> ?>> Cc: core-libs-dev at openjdk.java.net , hotspot-compiler-dev at openjdk.java.net , martin.doerr at sap.com , >> ?>> vladimir.kozlov at oracle.com , volker.simonis at sap.com >> ?>> Date: 2018/12/07 01:23 >> ?>> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> >> ?>> ---------------------------------------------------------------------------------------------------- >> ?>> >> ?>> >> ?>> >> ?>> Hi Michihiro, >> ?>> >> ?>> On 12/06/2018 02:38 AM, Michihiro Horie wrote: >> ?>> >> ?>> ? ? ? ? Hi Roger, >> ?>> >> ?>> ? ? ? ? Thank you for your helpful comments. I updated new webrev, adding a parameter in the jmh >> ?>> ? ? ? ? test to measure ?other? characters and moving the file to an appropriate location, also >> ?>> ? ? ? ? fixing the indents and copyright year._ >> ?>> >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.03_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=aKLGn7JZawWsl9UR7H-PyYoTpBc23BAKMqGScywbC5U&e= >> ?>> ? ? ? ? >> ?>> >> ?>> The choice of 256 for other is outside the range of Latin1 which is 0..255. >> ?>> 0x80 might be a good choice or 0xff. >> ?>> >> ?>> >> ?>> ? ? ? ? >Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' >> ?>> ? ? ? ? >in CharacterDataLatin1.java.template?? The performance would need to be measured and >> ?>> ? ? ? ? compared. >> ?>> ? ? ? ? Yes, there is an opportunity: intrinsic performed 25% better than the original on Power9. >> ?>> >> ?>> I was wondering about the performance without the PPC specific intrinsic but with the >> ?>> CharacterDataLatin1.java.template code for isDigit being: >> ?>> ??? ??? return '0' <= ch && ch <= '9'; >> ?>> >> ?>> >> ?>> ? ? ? ? >Is the profile of in-lining methods changed in any measurable way now that >> ?>> ? ? ? ? >there is an extra level of method invocation? >> ?>> ? ? ? ? > ?? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == >> ?>> ? ? ? ? LOWERCASE_LETTER; >> ?>> ? ? ? ? > >> ?>> ? ? ? ? >instead of: >> ?>> ? ? ? ? >??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; >> ?>> ? ? ? ? I missed this point, thanks. I tried jstack but could not find additional level. >> ?>> >> ?>> ? ? ? ? LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled in c1: >> ?>> ? ? ? ? > ?>> ? ? ? ? address='0x00003fff5911cb90' relocation_offset='344' insts_offset='368' stub_offset='1136' >> ?>> ? ? ? ? scopes_data_offset='1248' scopes_pcs_offset='1336' dependencies_offset='1448' >> ?>> ? ? ? ? nul_chk_table_offset='1456' oops_offset='1184' metadata_offset='1192' >> ?>> ? ? ? ? method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' bytes='15' count='1024' >> ?>> ? ? ? ? iicount='1025' stamp='0.058'/> >> ?>> >> ?>> Supposing some existing complex code was already taking advantage of the full allowed inline depth. >> ?>> Then adding an extra level might change the inlining behavior. >> ?>> >> ?>> >> ?>> ? ? ? ? Existing methods in CharacterDataLatin1.java.template etc. directly invoke >> ?>> ? ? ? ? getProperties(ch), so isLowerCase(ch) would be more aligned with other methods if it looks >> ?>> ? ? ? ? like as follows? >> ?>> ? ? ? ? + @HotSpotIntrinsicCandidate >> ?>> ? ? ? ? + boolean isLowerCase(int ch) { >> ?>> ? ? ? ? + int props = getProperties(ch); >> ?>> ? ? ? ? + return (props & $$maskType) == Character.LOWERCASE_LETTER; >> ?>> ? ? ? ? + } >> ?>> >> ?>> Yes, that would alleviate my concern. >> ?>> >> ?>> Thanks, Roger >> ?>> >> ?>> >> ?>> >> ?>> ? ? ? ? Best regards, >> ?>> ? ? ? ? -- >> ?>> ? ? ? ? Michihiro, >> ?>> ? ? ? ? IBM Research - Tokyo >> ?>> >> ?>> ? ? ? ? Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 >> ?>> ? ? ? ? 07:21 AM, Michihiro Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On >> ?>> ? ? ? ? 12/05/2018 07:21 AM, Michihiro Horie wrote: >> ?>> >> ?>> ? ? ? ? From: Roger Riggs _>_ >> ?>> ? ? ? ? To: Michihiro Horie _>_ , >> ?>> _vladimir.kozlov at oracle.com_ >> ?>> ? ? ? ? Cc: _core-libs-dev at openjdk.java.net_ , >> ?>> _hotspot-compiler-dev at openjdk.java.net_ , >> ?>> _martin.doerr at sap.com_ , _volker.simonis at sap.com_ >> ?>> ? ? ? ? >> ?>> ? ? ? ? Date: 2018/12/06 05:09 >> ?>> ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ---------------------------------------------------------------------------------------------------- >> ?>> >> ?>> >> ?>> >> ?>> ? ? ? ? Hi Michihiro, >> ?>> >> ?>> ? ? ? ? On 12/05/2018 07:21 AM, Michihiro Horie wrote: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >There are a few JMH tests for upper and lower in the >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? jmh-jdk-microbenchmarks repo. [1] >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Here is a jmh webrev for the Character methods._ >> ?>> >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_jmh-2Dwebrev.00_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=v22au5r5gvv48ufyda1poelXBjJWwuotSFrv-M2AlRY&e= >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Please include at least one >> character value that is not a member of any of the classes. >> ?>> ? ? ? ? The performance impact for 'other' characters is important also. >> ?>> >> ?>> ? ? ? ? The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: >> ?>> ? ? ? ? ?? test/micro/org/openjdk/bench/java/lang/ >> ?>> >> ?>> ? ? ? ? Now that they are in that repo, they can be included with the rest of the changeset. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Also, I updated C2 changes in the latest webrev. (Thank you for giving >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? valuable comments off-list, Vladimir and Martin!) >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? With the change in is_disabled_by_flags, I added a JVM flag that will need >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? another review request. I would proceed for it if this RFR is accepted._ >> ?>> >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.02_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=UXQByb5dFxfAwCCppkizqG_-RWf6DhE_PFkr9TsyzKo&e= >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? The indent in the Java code should >> be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 >> ?>> ? ? ? ? spaces) >> ?>> >> ?>> ? ? ? ? Please update the copyrights to include 2018. >> ?>> >> ?>> ? ? ? ? Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' >> ?>> ? ? ? ? in CharacterDataLatin1.java.template?? The performance would need to be measured and compared. >> ?>> >> ?>> ? ? ? ? Is the profile of in-lining methods changed in any measurable way now that >> ?>> ? ? ? ? there is an extra level of method invocation? >> ?>> ? ? ? ? ??? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == >> ?>> ? ? ? ? LOWERCASE_LETTER; >> ?>> >> ?>> ? ? ? ? instead of: >> ?>> ? ? ? ? ??? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; >> ?>> >> ?>> ? ? ? ? Regards, Roger >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? I need a review on changes in the class library, anyway. Would be grateful >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? if I could have one. >> ?>> >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo >> ?>> >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? ----- Original message ----- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? From: Michihiro Horie/Japan/IBM >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? To: Vladimir Kozlov _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , >> ?>> _hotspot-compiler-dev at openjdk.java.net_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , Roger Riggs _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Date: Fri, Nov 30, 2018 1:01 PM >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Hi Vladimir, >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Thank you for your further comments. I fixed my code, but I?m afraid >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? discussing such a basic topic involving the two big mailing lists is not >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? good. Please let me have a chance to talk on this off-list. >> ?>> >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? understand which Region node you are swapping. Where it is coming from? >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? From: Vladimir Kozlov _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? To: Michihiro Horie _>_ , Roger >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Riggs _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , >> ?>> _hotspot-compiler-dev at openjdk.java.net_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Date: 2018/11/30 03:01 >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> >> ---------------------------------------------------------------------------------------------------- >> ?>> >> ?>> >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Hi Michihiro, >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? I still do not understand which Region node you are swapping. Where it is >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? coming from? >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir >> ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? On 11/28/18 10:31 PM, Michihiro Horie wrote: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir,Roger, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Thank you so much for your responses. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Regarding the hotspot change,I?m new in changing around >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? library_call.cpp,so your comments are very helpful. I will fix >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > my code,especially inline_character_compare()would be like: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* old_rgn = control()->as_Region(); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* new_rgn = new RegionNode(1); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + record_for_igvn(new_rgn); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* new_ctrl = old_rgn->in(1); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + old_rgn->del_req(1); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + new_rgn->add_req(new_ctrl); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + set_control(_gvn.transform(new_rgn)); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + // argument(0)is receiver >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* codePoint = argument(1); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* n = NULL; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + switch (id){ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isDigit_c : n = new >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? DigitCNode(control(),codePoint);break; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isLowerCase_c : n = new >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? LowerCaseCNode(control(),codePoint);break; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isUpperCase_c : n = new >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? UpperCaseCNode(control(),codePoint);break; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isWhitespace_c : n = new >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? WhitespaceCNode(control(),codePoint);break; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + default: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + fatal_unexpected_iid(id); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + } >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + set_result(_gvn.transform(n)); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + return true; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > +} >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Microbenchmark showed ~40% improvements. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Roger, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > I would wait foryour review,thanks. I understood the discussion had not >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? been recognized from people in core-libs-dev,and >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > checked it was not actually archived there?. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > IBM Research - Tokyo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? look at it on Thursday.Roger Riggs ---2018/11/29 >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > 11:21:26---Hi, I'll look at it on Thursday. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > From: Roger Riggs _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > To: Vladimir Kozlov _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , Michihiro Horie _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _core-libs-dev at openjdk.java.net_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Cc: _volker.simonis at sap.com_ , >> ?>> _hotspot-compiler-dev at openjdk.java.net_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Date: 2018/11/29 11:21 >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> >> ------------------------------------------------------------------------------------------------------------------------ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Hi, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > I'll look at it on Thursday. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > In spite of it looking like the email was sent to core-lib-dev, I have >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > not seen it before >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > and its not in the core-libs-dev archive. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > $.02, Roger >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You still need review from core-libs. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> About your hotspot changes. You need to add intrinsics to >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> is_disabled_by_flags() to be able switch them off. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Note, match_rule_supported() calls in >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> are registered. So they will not be available if they are not >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> supported. match_rule_supported() checks in >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() are not needed. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> I don't get what you code in >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() is doing. Why you check >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Region node at the beginning and why you add Region and Phi at the end >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> if you have only one path? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You are creating code for whole method which should return boolean result >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?boolean isDigit(int ch) { >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?} >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> but your code produce TypeInt::CHAR. why? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> An finally. Did you compare code generated by default and with you >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> changes? what improvement you see? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Thanks, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Vladimir >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Is there any response from core-libs-dev? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Vladimir, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Could you give your suggestion on how to proceed? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"hotspot-compiler-dev at openjdk.java.net "_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net "_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Thu, Nov 22, 2018 11:28 AM >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Yes, we should wait for the feedback on class library change. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Btw. I think you can further simplify the code in library_call.cpp >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for pointing out it, I think I understand how to simplify >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> code. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Hi Michi, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> >Please note that we don?t have a machine, yet. So other people >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> will have to test. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> I think Gustavo can help testing this change when its' ready. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Sure :) >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Gustavo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you, Gustavo. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, thanks. This proposal makes the javacode much"Doerr, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> makes the java code much moreintrinsics friendly. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie _>_ , >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net "_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: _"hotspot-compiler-dev at openjdk.java.net "_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , "Simonis, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Volker"_>_ , >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Gustavo Romero >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/22 01:33 >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> >> ------------------------------------------------------------------------------------------------------------------------ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> thanks. This proposal makes the java code much more intrinsics friendly. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> We should wait for feedback from the core lib folks. Maybe they have >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> some requirements or other proposals. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think these intrinsics should be interesting for Oracle, Intel and >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> others, too. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Btw. I think you can further simplify the code in library_call.cpp >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie _>_ * >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ * >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ ; Gustavo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Romero_>_ * >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I send this RFR to core-libs-dev too, because it changes the class >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> library. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Through trial and error, I separated Latin1 block as in the _ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ___https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.01-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=co8xQFD19i2JBuYtSh2KKr-qUmwPdt6MEpJErzBfsd0&e= >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.01-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=w78kALiRtp6DIYAfslpK_TGpubqajF0h32O_z_ITAF4&e=>_/_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I followed the coding way of Character.isWhitespace() that invokes >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase(), and isUpperCase(). >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think this change is also useful on x86, using STTNI. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_ >> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> >> <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_ >> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_> " >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_ >>, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_> " >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_ >> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Wed, Nov 21, 2018 1:53 AM >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for giving your helpful comments. I did not recognize >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static? prevents anyoptimizations, but I now >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> checked it actually degraded the performance, thanks. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Please note that we don?t have a machine, yet. So other people will >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> have to test. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think Gustavo can help testing this change when its' ready. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Would it be possible to introduce more fine-grained intrinsics such >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Maybe you can factor out as in the following example? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>if (latin1) return isLatin1Digit(codePoint); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thanks for an example, please let me try to separate the Latin block >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> from other blocks for some time. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, first of all, thanks for working onPower9 opt"Doerr, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for working on Power9optimizations. Please note that we don't ha >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_ >>, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_> " >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_ >>, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_> " >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_ >> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/20 01:55 >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> >> ------------------------------------------------------------------------------------------------------------------------ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first of all, thanks for working on Power9 optimizations. Please note >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that we don?t have a machine, yet. So other peoplewill have to test. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think it may be problematic to insert a slow path by >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static?. This may be a performancedisadvantage >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for some users of other encodings because your intrinsics prevent >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> inlining and further optimizations. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would it be possible to introduce more fine-grained intrinsics such >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Maybe you can factor out as in the following example? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> if (latin1) return isLatin1Digit(codePoint); >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I can?t judge if this is needed, but I think this should be discussed >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first before going into the details. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:HORIE at jp.ibm.com_>>* >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Freitag, 16. November 2018 12:53* >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_ >>; >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_ <_mailto:gromero at linux.vnet.ibm.com_ >>* >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Dear all, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would you please review following change? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Bug: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> __https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=yTUTl4D2EPdboqkkAHXYtHx5KijWhAzXOXPBqwME0iQ&e= >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Webrev: >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.00-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=88Ms75RO8511eAgWMsvWrTDLmRRcxcKiEs_DkSZmVlc&e= >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=zZl2pxTY0Dn-5RZHkTZSnIRpYzb-w9T_4d8cV7gU3iw&e=> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> This change includes the intrinsics of Character isDigit, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compare a character with 1 or 2 rangedbytes, while the cmpeqb >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compares one with 1 to 8 values. Simple micro benchmark attached >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> showed improvements by 20-40%. >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> / >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> //(See attached file: Latin1Test.java)/ >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> >> ?>> >> ?>> >> ?>> >> ?>> >> ?>> >> ?> >> >> >> >> > > > From jeff.dinkins at oracle.com Tue Dec 11 16:11:43 2018 From: jeff.dinkins at oracle.com (Jeff Dinkins) Date: Tue, 11 Dec 2018 10:11:43 -0600 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: <90140256-DA6D-4461-9016-331FC5F27786@oracle.com> ! // these icons are pretty crappy to use in Mac OS X since // they really are interactive but we have to return a static // icon for now. -> ! // these icons are difficult to use in Mac OS X since // they really are interactive but we have to return a static // icon for now. Crappy != Difficult, it changes the semantics of the comment. ?unfortunate? or maybe ?a poor substitute? would be a better replacement. -jeff > On Dec 11, 2018, at 9:03 AM, Adam Farley8 wrote: > > Hey All, > > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > I've created a webrev and attached to the bug. > > Also, I've mentioned in the bug that there are additional swears in more > excusable locations. It would be good to get the community's take on > those. > > Reviews and opinions welcome. :) > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Tue Dec 11 16:11:48 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 11:11:48 -0500 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: Hi, And the patch by itself is sufficient, inline or attached to the issue or the email. No need to carry around the whole webrev. And it is very handy to have an quick link to cr.openjdk.java.net $.02, Roger On 12/11/2018 10:46 AM, Volker Simonis wrote: > Hi Adam, > > in order to prevent me from using swear words, could you please upload > your webrev to cr.openjdk.java.net :) > > As you may have realized webrevs are a collection of HTML files and it > makes no big sense to provide them as a zip file. > > Thank you and best regards, > Volker > On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8 wrote: >> Hey All, >> >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 >> >> I've created a webrev and attached to the bug. >> >> Also, I've mentioned in the bug that there are additional swears in more >> excusable locations. It would be good to get the community's take on >> those. >> >> Reviews and opinions welcome. :) >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From martinrb at google.com Tue Dec 11 16:28:58 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Dec 2018 08:28:58 -0800 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: <93089664-d244-e33a-f032-bf5143cca769@oracle.com> References: <5380274d-e2d4-0582-76f2-05c8f3babfd5@gmail.com> <93089664-d244-e33a-f032-bf5143cca769@oracle.com> Message-ID: HashMap sizing was a terrible design mistake, but too much software depends on it, e.g. https://google.github.io/guava/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- On Tue, Dec 11, 2018 at 1:26 AM Claes Redestad wrote: > Hi Peter, > > On 2018-12-11 10:02, Peter Levart wrote: > > Hi Claes, > > > > Haven't checked all changes yet, although it looks like a > > straightforward swap of Properties for HashMap for intermediary result, > > but I noticed the following in SystemProps: > > > > 265 var cmdProps = new HashMap > String>((vmProps.length / 2) + Raw.FIXED_LENGTH); > > > > The HashMap(int) constructor is different from Properties(int) in that > > for the former, the argument represents the lower bound on the initial > > size of the table (which is just a rounding of this parameter up to the > > nearest power of 2). The threshold where the table is resized is > > calculated as (initialCapacity rounded up to nearest power of 2) * > > loadFactor. The default load factor is 0.75 which means that the table > > will be resized in worst case after 3/4 * initialCapacity of elements > > are inserted into it. In order to guarantee that the table is not > > resized you have to pass (size * 4 + 2) / 3 to the HashMap constructor, > > where size is the number of elements added... > > > > I hope I'm not misleading you, I just think this is how HashMap has been > > from the beginning. Peeking at HashMap code (line 693) it seems that it > > is doing that: > > > > float ft = (float)newCap * loadFactor; > > newThr = (newCap < MAXIMUM_CAPACITY && ft < > > (float)MAXIMUM_CAPACITY ? > > (int)ft : Integer.MAX_VALUE); > > > > newCap above is holding the initialCapacity constructor parameter > > rounded up to the nearest power of 2. newThr is the threshold at which > > the resize occurs. > > > > The Properties(int) constuctor behaves differently as it passes the > > parameter directly to the underlying ConcurrentHashMap, which says: > > > > * @param initialCapacity The implementation performs internal > > * sizing to accommodate this many elements. > > Fun story, but I noticed this unfortunate difference when I was working > on this very patch and brought it up in the team. I think most agrees > the CHM behavior is the more intuitive and would have loved to > consolidate to that behavior, but the message I've gotten is that it's > probably too late to fix: Whichever way you go you get lots of little > subtle changes to sizes that may lead to incompabilities in > applications/tests that inadvertedly depend on the iteration order or > HashMap etc.. > > That said: Raw typically contains quite a few empty/null values that'll > never be put in the map. Enough so that for the applications I've looked > at the initialCapacity is already a fair bit higher than it needs to be > to avoid resizing. Thus it made little sense to take the maximum > possible size and adjust it up even further by factoring in the default > load factor. > > (Unless you have a *lot* of properties coming in via command line, but I > think we should optimize for the common cases...) > > Thanks! > > /Claes > > > > > Regards, Peter > > > > On 12/10/18 10:17 PM, Claes Redestad wrote: > >> Hi, > >> > >> by inverting the order in which the internal property maps are created, > >> we avoid some classloading and get a slightly more efficient code > >> execution profile in System.initPhase1. > >> > >> Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 > >> > >> This reduces bytecode executed in initPhase1 from ~48k to ~36k. Not > >> much by any measure, but minimizing System.initPhase1 is important since > >> certain parts of the VM (JIT etc) are blocked from initializing until > >> it's done. > >> > >> Thanks! > >> > >> /Claes > > > From vincent.x.ryan at oracle.com Tue Dec 11 16:34:32 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Dec 2018 16:34:32 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <93c7eb10-4716-6f92-1622-39f0af54c1e5@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> <93c7eb10-4716-6f92-1622-39f0af54c1e5@oracle.com> Message-ID: <28BBEA82-5839-4AC7-BF72-697ED9B7B6BA@oracle.com> Responses in-line. > On 10 Dec 2018, at 21:38, Roger Riggs wrote: > > Hi Vincent, > > On 12/10/2018 03:59 PM, Vincent Ryan wrote: >> Comments in-line. >> Thanks. >> >>> On 10 Dec 2018, at 16:59, Roger Riggs > wrote: >>> >>> Hi, >>> >>> Looks good, though some points to clarify. >>> >>> - The methods that use ByteBuffers should be clear that accesses to the ByteBuffers >>> are relative and use and modify the position and ByteBuffer exceptions may be thrown. >> >> Added the line: >> 'Access to the ByteBuffer is relative and its position gets set to the buffer's limit.' > ok >> >>> >>> - The methods that write output (Strings) to an output stream might be more general >>> if the argument was a PrintStream, allowing the hex formatted output to be >>> assembled with other localized output. >>> I do see that as long as HexFormat is only writing hex digits, the effect would be almost the same. >>> (It would also eliminate, the inefficient code in getPrintStream that creates a PrintStream on demand). >> >> I had wanted to provide flexibility by favouring OutputStream over PrintStream. >> It is convenient for the common case of dumping to a file using 'new FileOutputStream?. >> As you note it complicates assembly with other output. >> >> I guess it?s fine to change the OutputStream args to PrintStream. > ok, if the caller has a direct OutputStream, a PrintStream could be created. > But I think the PrintStream is more common. >> >> >>> >>> - toString(byte[], from, to) and other methods there's no need for parens around the note about fromIndex==toIndex. >> >> OK >> >>> >>> - fromString methods: The optional prefix of "0x": add the phrase "is ignored". >>> The IAE, does not mention the optional prefix, I'm not sure if that allows some confusion. >> >> Added the line: >> 'The optional prefix of {@code "0x"} is ignored.' > ok >> >>> >>> - dumpAsStream(InputStream) does not have a throws NPE for in == null. >>> A catch all in the class javadoc could cover that. >>> " Unless otherwise noted, passing a null argument to a constructor or method in any class or >>> interface in this package will cause a NullPointerException to be thrown. ? >> >> Added an @throws to the method. > ok >> >>> >>> - dumpAsStream methods, the formatter argument is described as being used "if present"; >>> it might be clearer as "if not null?. >> >> OK >> Its really nice/necessary that examples can be copy/pasted and compile. >>> >>> >>> - dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be confusing because it >>> is using the relative methods of ByteBuffer, but the from and to offsets are within >>> the position .. limit buffer. That should be explicit. >>> (Or consider switching to the absolute accesses in the ByteBuffer and not affect the position) >> >> Is the additional javadoc line added earlier sufficient? > I would bear some reinforcing that the entire remainder of the buffer is read > and the from and to are indexes within that remainder. > And I'm not sure that's the desirable semantics. > > It would make more sense if the from bytes from the buffer are skipped > and only the (to - from) bytes are dumped. That leaves the ByteBuffer > reading only the requested bytes. A natural usage such as: > dumpAsStream?(ByteBuffer buffer, 0, 256, 16, formatter) > would dump the next 256bytes of the ByteBuffer and position would be > moved by 256. [As suggested by Alan] How about dropping the fromIndex and toIndex parameters and requiring the caller to provide a suitably sized buffer? public static Stream dumpAsStream(ByteBuffer buffer, int chunkSize, Formatter formatter) { > >> >> >>> >>> - dump(byte[], OutputStream) - I don't think the example is correct, there is no reference >>> to a stream, only the PrintStream::println method, which is not static. >> >> The code is just illustrative. Real values would have to be supplied for the input bytes and the >> chosen print method on the output stream. Typically, that print method will be System.out::println > Examples that don't compile are really confusing and annoying. Updated the ?as if? code to: * byte[] bytes = ... * PrintStream out = ... * HexFormat.dumpAsStream(bytes, 16, * (offset, chunk, from, to) -> * String.format("%08x %s |%s|", * offset, * HexFormat.toFormattedString(chunk, from, to), * HexFormat.toPrintableString(chunk, from, to))) * .forEachOrdered(out::println); > > Thanks, Roger > >> >> >>> >>> Regards, Roger >>> >>> >>> >>> On 12/07/2018 08:18 PM, Vincent Ryan wrote: >>>> Here?s the latest version that addresses all the current open issues: >>>> >>>> webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ >>>> javadoc: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 >>>> >>>> >>>>> On 7 Dec 2018, at 19:51, Vincent Ryan wrote: >>>>> >>>>> Even shorter. I?ll add that instead. >>>>> Thanks. >>>>> >>>>>> On 7 Dec 2018, at 19:04, Roger Riggs wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I don't think this is performance sensitive and less code is better. >>>>>> >>>>>> Use java.lang.Character.digit(ch, 16) to convert the char to an int. >>>>>> >>>>>> Roger >>>>>> >>>>>> On 12/07/2018 01:49 PM, Kasper Nielsen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I don't know if performance is an issue. But if it is, I think it world >>>>>>> make sense to use a precompute array. And replace >>>>>>> >>>>>>> private static int hexToBinary(char ch) { >>>>>>> if ('0' <= ch && ch <= '9') { >>>>>>> return ch - '0'; >>>>>>> } >>>>>>> if ('A' <= ch && ch <= 'F') { >>>>>>> return ch - 'A' + 10; >>>>>>> } >>>>>>> if ('a' <= ch && ch <= 'f') { >>>>>>> return ch - 'a' + 10; >>>>>>> } >>>>>>> return -1; >>>>>>> } >>>>>>> >>>>>>> with >>>>>>> >>>>>>> private static int hexToBinary(char ch) { >>>>>>> return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >>>>>>> } >>>>>>> >>>>>>> where int[] staticPrecomputedArray is computed in a static initializer >>>>>>> block. >>>>>>> >>>>>>> /Kasper >>>>>>> >>>>>>> On Fri, 23 Nov 2018 at 14:51, Vincent Ryan >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this proposal for a new API to conveniently generate and >>>>>>>> display binary data using hexadecimal string representation. >>>>>>>> It supports both bulk and stream operations and it can also generate the >>>>>>>> well-known hexdump format [1]. >>>>>>>> >>>>>>>> This latest revision addresses review comments provided earlier. >>>>>>>> These include adding methods to support for data supplied in a >>>>>>>> ByteBuffer, exposing the default formatter implementation as a public >>>>>>>> static and dropping the superfluous 'Hex' term from several method names. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>>>>>>> API: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.html >>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.06/ >>>>>>>> >>>>>>>> >>>>>>>> ____ >>>>>>>> [1] https://docs.oracle.com/cd/E88353_01/html/E37839/hexdump-1.html >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From stooke at redhat.com Tue Dec 11 16:43:19 2018 From: stooke at redhat.com (Simon Tooke) Date: Tue, 11 Dec 2018 11:43:19 -0500 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: > Hi everyone, > > I came up with the following patch: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ > > It specifically addresses the problem in JDK-8214122 where on 32 bit > Windows jdwpTransport_OnLoad can exported with its plain and > __stdcall-mangled name. I used conditional compilation so that for > other platforms the code remains as it is now. > > jshell starts successfully with this fix; an IDE debugger works as well. > I am not a reviewer, but this patch only works for the specific case under discussion; the '@16' refers to the reserved stack size in the Pascal calling convention.? So, the patch only works for 16 bytes of parameters.? To be generic, the routine needs to have the stack size passed in by the caller.? If a generic fix isn't desired (and I hope it is), I'd prefer to see the caller simply pass the decorated or undecorated name depending on the Win32/64 defines. #if defined(_WIN32) && !defined(_WIN64) onLoad = (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif Thanks, -Simon > > Regards, > Alexey > > https://bugs.openjdk.java.net/browse/JDK-8214122 > > On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>> Since removing JNICALL is not an option, there are only two options: >>> >>> 1. Add |/export| option to the Makefile or pragma-comment to the >>> source file; >>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>> with fallback to undecorated one. >> Yes. >> >> I think the correct solution here is 2. > From adam.farley at uk.ibm.com Tue Dec 11 16:45:14 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 11 Dec 2018 16:45:14 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: Sure thing: http://cr.openjdk.java.net/~afarley/8215217/webrev/ Best Regards Adam Farley IBM Runtimes Volker Simonis wrote on 11/12/2018 15:46:44: > From: Volker Simonis > To: adam.farley at uk.ibm.com > Cc: Java Core Libs > Date: 11/12/2018 15:47 > Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words > > Hi Adam, > > in order to prevent me from using swear words, could you please upload > your webrev to cr.openjdk.java.net :) > > As you may have realized webrevs are a collection of HTML files and it > makes no big sense to provide them as a zip file. > > Thank you and best regards, > Volker > On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8 wrote: > > > > Hey All, > > > > I've spotted 12 instances of swear words in OpenJDK source comments, and > > it seems appropriate to remove them. > > > > Bug: INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8215217&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=GfAb5QlDParO6DVrhdvPZTSafShnFACNF3JgqF- > _RkM&s=Qscaf2tTpPcZKpIelJ6SrP0uRYSFoKaCNATns0FX7_Y&e= > > > > I've created a webrev and attached to the bug. > > > > Also, I've mentioned in the bug that there are additional swears in more > > excusable locations. It would be good to get the community's take on > > those. > > > > Reviews and opinions welcome. :) > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Tue Dec 11 16:45:07 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 11:45:07 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> Message-ID: <70b0bd37-8aa3-cf40-236d-bdd45f7cf7a3@oracle.com> Hi Stuart, The APIs for streams of characters bifurcated a bit between PrintStream and Writers. Many common use cases would like to direct the output to System.out/err which are PrintStreams.? Hence, I lean toward PrintStream that can be used directly. $.02, Roger On 12/10/2018 09:11 PM, Stuart Marks wrote: > On 12/7/18 10:22 AM, Vincent Ryan wrote: >>> I'm not convinced that the overloads that send output to an >>> OutputStream pull their weight. They basically wrap the OutputStream >>> in a PrintStream, which conveniently doesn't declare IOException, >>> making it easy to use from a lambda passed to forEachOrdered(). If >>> an error writing the output occurs, this is recorded by the >>> PrintStream wrapper; however, the wrapper is then thrown away, >>> making it impossible for the caller to check its error status. >> The intent is to support a trivial convenience method call that >> generates the well-known hexdump format. >> Especially for users that are interested in the hexdump data rather >> than the low-level details of how to terminate a stream. >> The dumpAsStream methods are available to support cases that differ >> from that format. >> >> Have you a suggestion to improve the dump() methods, or you?d like to >> see them omitted? >> >>> The PrintStream wrapper also uses the platform default charset, and >>> doesn't provide any way for the caller to override the charset. >> Is there a need for that? Originally the requirement was driven by >> the hexdump format which is ASCII-only. >> Recently the class has been enhanced to also support the printable >> characters from ISO 8859-1. >> A custom formatter be supplied to dumpAsStream() to cater for all >> other cases? > > OK, let's step back from this a bit. I see this hexdump as a little > subsystem that has the following facets: > > 1) a source of bytes > 2) a converter to hex > 3) a destination > > The converter is HexDump.Formatter, which converts and formats a > subrange of byte[] to a String. Since the user can supply the > Formatter function, the result String can contain any unicode > character. Thus, the destination needs to handle any unicode > character. It can be a Writer, which accepts String data. Or if you > want it to write bytes, it can be an OutputStream, which raises the > issue of encoding (charset). I would recommend against relying on the > platform default charset, as this has been a source of subtle bugs. > The preferred approach these days is to default to UTF-8 and provide > an overload that takes an explicit charset. > > An alternative is PrintStream. (This overlaps somewhat with your > recent exchange with Roger on this topic.) PrintStream also does > charset encoding, and the charset it uses depends on how it's created. > I think the same approach should be applied as I described above with > OutputStream, namely avoid the platform default charset; default to > UTF-8; and provide an overload that takes an explicit charset. > > I'm not sure which of these is the right thing. You should decide > which is the most convenient for the use cases you expect to see. > However, the solution needs to handle charset encoding. (And it should > also properly deal with I/O exceptions, per my previous message.) > > ** > > ISO 8859-1 comes up in a different place. The toPrintableString() > method (used by the default formatter) considers a byte "printable" if > it encodes a valid ISO 8859-1 character. The byte is properly decoded > to a String, so this is ok. Note this is a distinct issue from the > encoding of the OutputStream or PrintStream as described above. > > (As an aside I think that the encoding of ISO 8859-1 matches the > corresponding code units of UTF-16, so you don't have to do the new > String(..., ISO_8859_1) jazz. You can just cast the byte to a char and > append it to the StringBuilder.) > > s'marks From t.linkowski at gmail.com Tue Dec 11 16:47:56 2018 From: t.linkowski at gmail.com (Tomasz Linkowski) Date: Tue, 11 Dec 2018 17:47:56 +0100 Subject: RFR - JDK-8203442 String::transform (Code Review) In-Reply-To: <1372178369.83668.1537526546968.JavaMail.zimbra@u-pem.fr> References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com> <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com> <1372178369.83668.1537526546968.JavaMail.zimbra@u-pem.fr> Message-ID: Alan, R?mi, If you're still interested in providing transform-like behavior for CharSequence, there's a fairly neat (I hope) way to do that. The idea is to use the following helper functional interface for forwarding to the already added String.transform: @FunctionalInterface interface Transformer { R by(Function f); } public interface CharSequence extends Transformable { // ... Transformer transformed(); // ... } public final class String implements /*...*/ CharSequence { // ... @Override public Transformer transformed() { return this::transform; } // ... } Usage: CharSequence transformed = charSeq .transformed().by(s -> StringUtils.defaultIfBlank('0')) // sample Function .transformed().by(...) .transformed().by(...); If you find it interesting, it's described in detail in my blog post: https://blog.tlinkowski.pl/2018/transformer-pattern/ Regards, Tomasz Linkowski On Fri, Sep 21, 2018 at 12:42 PM Remi Forax wrote: > ----- Mail original ----- > > De: "Alan Bateman" > > ?: "Jim Laskey" , "core-libs-dev" < > core-libs-dev at openjdk.java.net> > > Envoy?: Vendredi 21 Septembre 2018 12:22:42 > > Objet: Re: RFR - JDK-8203442 String::transform (Code Review) > > > On 18/09/2018 18:52, Jim Laskey wrote: > >> Please review the code for String::transform. The goal is to provide a > String > >> instance method to allow function application of custom transformations > applied > >> to an instance of String. > >> > >> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html > >> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442 > >> csr: https://bugs.openjdk.java.net/browse/JDK-8203703 > > I hate to bring up naming but if I have a Stream or > > Optional then I'll use the "map" method to apply the mapping > > function. Has this already been through the naming bike shed and it > > settled on "transform"? Maybe a different name was chosen after looking > > at code that would use it in stream operations? Maybe "transform" was > > used as the argument to the function is always text? I'm not interested > > in re-opening any discussions, just trying to see if options are > > captured in a mail somewhere. > > > > I'm also wondering if this is general enough to be defined by > > CharSequence. Retrofitting CharSequence is always problematic and never > > done lightly but I'm just wondering if it has been discussed and > > dismissed. I don't think it could be done at a later time, at least not > > without changing the input type parameter so that the mapping function > > is Function rather than Function. > > the main issue is that a lot of utility methods take a String as > parameter, not a CharSequence :( > and Function is a supertype not a subtype of Function super CharSequence, R>. > > > > > -Alan > > R?mi > -- Pozdrawiam, Tomasz Linkowski From rachna.goel at oracle.com Tue Dec 11 16:49:06 2018 From: rachna.goel at oracle.com (Rachna Goel) Date: Tue, 11 Dec 2018 22:19:06 +0530 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: References: Message-ID: <800dea41-f761-26f2-4209-752de6a1d516@oracle.com> Hi Naoto, Thanks for fixing this. Your fix looks good to me. Thanks, Rachna On 12/11/18 8:21 PM, Naoto Sato wrote: > Hi, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8215194 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ > > This one line fix is for the correctness of the initial map size of > Character.UnicodeBlock. > > Naoto -- Thanks, Rachna From Roger.Riggs at oracle.com Tue Dec 11 16:54:21 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 11:54:21 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <28BBEA82-5839-4AC7-BF72-697ED9B7B6BA@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> <93c7eb10-4716-6f92-1622-39f0af54c1e5@oracle.com> <28BBEA82-5839-4AC7-BF72-697ED9B7B6BA@oracle.com> Message-ID: Ho Vincent, On 12/11/2018 11:34 AM, Vincent Ryan wrote: > Responses in-line. > >> >>> Its really nice/necessary that examples can be copy/pasted and compile. >>>> >>>> ?- dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be >>>> confusing because it >>>> ?? is using the relative methods of ByteBuffer, but the from and to >>>> offsets are within >>>> ?? the position .. limit buffer.? That should be explicit. >>>> ?? (Or consider switching to the absolute accesses in the >>>> ByteBuffer and not affect the position) >>> >>> Is the additional javadoc line added earlier sufficient? >> I would bear some reinforcing that the entire remainder of the buffer >> is read >> and the from and to are indexes within that remainder. >> And I'm not sure that's the desirable semantics. >> >> It would make more sense if the from bytes from the buffer are skipped >> and only the (to - from) bytes are dumped.? That leaves the ByteBuffer >> reading only the requested bytes.? A natural usage such as: >> ?dumpAsStream?(ByteBuffer buffer, 0, 256, 16, formatter) >> would dump the next 256bytes of the ByteBuffer and position would be >> moved by 256. > > [As suggested by Alan] > How about dropping the fromIndex and toIndex parameters and requiring > the caller > to provide a suitably sized buffer? > > public?static?Stream dumpAsStream(ByteBuffer > buffer,?int?chunkSize, Formatter formatter) { > I'd go the other direction and make dump use absolute offset and limit. The current values for position and limit are readily available from the buffer. If the dumping code is being added to perform some diagnostics then it would not modify the position and not disturb the existing code that is using the buffer. Absolute is simpler to explain and implement and has fewer side effects. > >> >>> >>> >>>> >>>> - dump(byte[], OutputStream) - I don't think the example?is >>>> correct, there is no reference >>>> ? to a stream, only the PrintStream::println method,?which is not >>>> static. >>> >>> The code is just illustrative. Real values would have to?be supplied >>> for the input bytes and the >>> chosen print method on the output stream. Typically, that?print >>> method will be System.out::println >> Examples that don't compile are really confusing and annoying. > > Updated the ?as if? code to: > > ? ? ?*?? ??byte[] bytes = ... > ? ? ?*?? ??PrintStream out = ... > ? ? ?*?? ??HexFormat.dumpAsStream(bytes, 16, > ? ? ?*?? ? ? ??(offset, chunk, from, to) -> > ? ? ?*?? ? ? ? ? ??String.format("%08x??%s??|%s|", > ? ? ?*?? ? ? ? ? ? ? ??offset, > ? ? ?*?? ? ? ? ? ? ? ??HexFormat.toFormattedString(chunk, from, to), > ? ? ?*?? ? ? ? ? ? ? ??HexFormat.toPrintableString(chunk, from, to))) > ? ? ?*?? ? ? ??.forEachOrdered(out::println); > > Looks fine, thanks From alexey.ivanov at oracle.com Tue Dec 11 17:16:19 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 11 Dec 2018 17:16:19 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: Hi Simon, Thank you for your comments. The updated webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Indeed, it looks much cleaner. Regards, Alexey On 11/12/2018 16:43, Simon Tooke wrote: > On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >> Hi everyone, >> >> I came up with the following patch: >> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >> >> It specifically addresses the problem in JDK-8214122 where on 32 bit >> Windows jdwpTransport_OnLoad can exported with its plain and >> __stdcall-mangled name. I used conditional compilation so that for >> other platforms the code remains as it is now. >> >> jshell starts successfully with this fix; an IDE debugger works as well. >> > I am not a reviewer, but this patch only works for the specific case > under discussion; the '@16' refers to the reserved stack size in the > Pascal calling convention.? So, the patch only works for 16 bytes of > parameters.? To be generic, the routine needs to have the stack size > passed in by the caller.? If a generic fix isn't desired (and I hope it > is), I'd prefer to see the caller simply pass the decorated or > undecorated name depending on the Win32/64 defines. > > #if defined(_WIN32) && !defined(_WIN64) onLoad = > (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, > "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) > dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif > > > Thanks, > -Simon > >> Regards, >> Alexey >> >> https://bugs.openjdk.java.net/browse/JDK-8214122 >> >> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>> Since removing JNICALL is not an option, there are only two options: >>>> >>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>> source file; >>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>> with fallback to undecorated one. >>> Yes. >>> >>> I think the correct solution here is 2. From bob.vandette at oracle.com Tue Dec 11 17:22:26 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 11 Dec 2018 12:22:26 -0500 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad functions. Perhaps you should just follow the same procedure for the debug library. #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad at 8", "JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"} #define JVM_ONLOAD_SYMBOLS {"_JVM_OnLoad at 12", "JVM_OnLoad"} #define AGENT_ONLOAD_SYMBOLS {"_Agent_OnLoad at 12", "Agent_OnLoad"} #define AGENT_ONUNLOAD_SYMBOLS {"_Agent_OnUnload at 4", "Agent_OnUnload"} #define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach at 12", ?Agent_OnAttach?} Bob. > On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote: > > On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >> Hi everyone, >> >> I came up with the following patch: >> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >> >> It specifically addresses the problem in JDK-8214122 where on 32 bit >> Windows jdwpTransport_OnLoad can exported with its plain and >> __stdcall-mangled name. I used conditional compilation so that for >> other platforms the code remains as it is now. >> >> jshell starts successfully with this fix; an IDE debugger works as well. >> > I am not a reviewer, but this patch only works for the specific case > under discussion; the '@16' refers to the reserved stack size in the > Pascal calling convention. So, the patch only works for 16 bytes of > parameters. To be generic, the routine needs to have the stack size > passed in by the caller. If a generic fix isn't desired (and I hope it > is), I'd prefer to see the caller simply pass the decorated or > undecorated name depending on the Win32/64 defines. > > #if defined(_WIN32) && !defined(_WIN64) onLoad = > (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, > "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) > dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif > > > Thanks, > -Simon > >> >> Regards, >> Alexey >> >> https://bugs.openjdk.java.net/browse/JDK-8214122 >> >> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>> Since removing JNICALL is not an option, there are only two options: >>>> >>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>> source file; >>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>> with fallback to undecorated one. >>> Yes. >>> >>> I think the correct solution here is 2. >> > From mandy.chung at oracle.com Tue Dec 11 17:41:03 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Dec 2018 09:41:03 -0800 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: References: Message-ID: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> On 12/10/18 1:17 PM, Claes Redestad wrote: > Hi, > > by inverting the order in which the internal property maps are created, > we avoid some classloading and get a slightly more efficient code > execution profile in System.initPhase1. > > Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 > This change looks okay to me. ModuleBootstrap also removes some `jdk.module.*` private system properties during module system initialization but they are only set if module-related command-line options are set.?? These properties are not present in the common cases.?? These private system properties are the interface between VM and libraries.?? There is other mechanism that we can look into to replace using system properties in the future. Mandy From philip.race at oracle.com Tue Dec 11 17:44:36 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 11 Dec 2018 09:44:36 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: 1) Thanks for uploading the webrev. much better for one person to do this than make everyone who wants to look at it go through a tedious and off-putting set of steps. 2) I've added some client lists since you are touching UI client files, not just core-libs. ?? To me the client ones look OK, one looks more like it was a typo than anything intentional, ?? and the other was pretty mild. 3) Regarding the comment in the bug report about hb-private.hh and the use of /* CRAP pool: Common Region for Access Protection. */ since it not only is in an upstream library, but also used 14 times in variable names, then I can't possibly agree with your comment that an argument for leaving them would be "shaky". Take this up with the upstream library ... I have no interest in renaming these every time we upgrade this library. -phil. On 12/11/18 8:45 AM, Adam Farley8 wrote: > Sure thing: > > http://cr.openjdk.java.net/~afarley/8215217/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > > Volker Simonis wrote on 11/12/2018 15:46:44: > >> From: Volker Simonis >> To: adam.farley at uk.ibm.com >> Cc: Java Core Libs >> Date: 11/12/2018 15:47 >> Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words >> >> Hi Adam, >> >> in order to prevent me from using swear words, could you please upload >> your webrev to cr.openjdk.java.net :) >> >> As you may have realized webrevs are a collection of HTML files and it >> makes no big sense to provide them as a zip file. >> >> Thank you and best regards, >> Volker >> On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8 > wrote: >>> Hey All, >>> >>> I've spotted 12 instances of swear words in OpenJDK source comments, > and >>> it seems appropriate to remove them. >>> >>> Bug: INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8215217&d=DwIBaQ&c=jf_iaSHvJObTbx- >> siA1ZOg&r=P5m8KWUXJf- >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=GfAb5QlDParO6DVrhdvPZTSafShnFACNF3JgqF- >> _RkM&s=Qscaf2tTpPcZKpIelJ6SrP0uRYSFoKaCNATns0FX7_Y&e= >>> I've created a webrev and attached to the bug. >>> >>> Also, I've mentioned in the bug that there are additional swears in > more >>> excusable locations. It would be good to get the community's take on >>> those. >>> >>> Reviews and opinions welcome. :) >>> >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From naoto.sato at oracle.com Tue Dec 11 17:59:09 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 11 Dec 2018 09:59:09 -0800 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> Message-ID: Hi Roger, Thanks. I updated it as suggested (incl. test using reflection): http://cr.openjdk.java.net/~naoto/8215194/webrev.01/ Naoto On 12/11/18 7:57 AM, Roger Riggs wrote: > Hi Naoto, > > Since the value changes from time to time, it would give it some visibility > if it were defined using a private final int? (or float) > ???? private final int MAP_CAPACITY = 667; > > Though I suppose the test can't use the value without using reflection. > But it would lower the maintenance in the long term. > > $.02, Roger > > On 12/11/2018 09:51 AM, Naoto Sato wrote: >> Hi, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8215194 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ >> >> This one line fix is for the correctness of the initial map size of >> Character.UnicodeBlock. >> >> Naoto > From claes.redestad at oracle.com Tue Dec 11 18:13:17 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 11 Dec 2018 19:13:17 +0100 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> References: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> Message-ID: <91d0180c-ceba-1fb5-b40e-58b83943229f@oracle.com> On 2018-12-11 18:41, Mandy Chung wrote: > > > On 12/10/18 1:17 PM, Claes Redestad wrote: >> Hi, >> >> by inverting the order in which the internal property maps are created, >> we avoid some classloading and get a slightly more efficient code >> execution profile in System.initPhase1. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 >> > > This change looks okay to me. Thanks! > > ModuleBootstrap also removes some `jdk.module.*` private system > properties during > module system initialization but they are only set if module-related > command-line > options are set.?? These properties are not present in the common > cases.?? These > private system properties are the interface between VM and libraries. > There is > other mechanism that we can look into to replace using system properties > in the > future. Right, as we've discussed a bit off-list there are further improvements that could be made. For one we'd probably be better off without the internal VM.savedProps map altogether, but usage has snuck into some weird places. Something for another day. :-) /Claes > > Mandy From Roger.Riggs at oracle.com Tue Dec 11 18:08:01 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 13:08:01 -0500 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> References: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> Message-ID: Hi Claes, SystemProps.java: ? - the import of Collections isn't used. VM.java: ?- line 180:? The savedProps doesn't need to be (and was not previously) unmodifiable. ?? Seems safer this way though since the map at the bottom is not ConcurrentHashMap. ?? Its not entirely clear who calls getSavedProperties(). ?? Would it be more efficient for savedProps to be the unmodifiable map and not create ?? one on every call to getSavedProperties. VersionProps.java.template: ?- The version properties don't need to be in the savedProps map and could be put only in the Properties. ?? (save a few cycles and entries). System.java: ?- swap lines 805/806 if you decide not to put version props in the map. ?- and call VerionProps.init() after the call to createProperties(). Regards, Roger On 12/11/2018 12:41 PM, Mandy Chung wrote: > > > On 12/10/18 1:17 PM, Claes Redestad wrote: >> Hi, >> >> by inverting the order in which the internal property maps are created, >> we avoid some classloading and get a slightly more efficient code >> execution profile in System.initPhase1. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 >> > > This change looks okay to me. > > ModuleBootstrap also removes some `jdk.module.*` private system > properties during > module system initialization but they are only set if module-related > command-line > options are set.?? These properties are not present in the common > cases.?? These > private system properties are the interface between VM and > libraries.?? There is > other mechanism that we can look into to replace using system > properties in the > future. > > Mandy From Roger.Riggs at oracle.com Tue Dec 11 18:12:52 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 13:12:52 -0500 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> Message-ID: Hi Naoto, Looks ok, I intended only the number of elements to be defined as a constant. The other factors can be hard coded. In the test, you will still have to edit the test when the number changes. I meant to avoid that edit.? Though then may be there is not need for the test at all. Roger On 12/11/2018 12:59 PM, Naoto Sato wrote: > Hi Roger, > > Thanks. I updated it as suggested (incl. test using reflection): > > http://cr.openjdk.java.net/~naoto/8215194/webrev.01/ > > Naoto > > On 12/11/18 7:57 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Since the value changes from time to time, it would give it some >> visibility >> if it were defined using a private final int? (or float) >> ????? private final int MAP_CAPACITY = 667; >> >> Though I suppose the test can't use the value without using reflection. >> But it would lower the maintenance in the long term. >> >> $.02, Roger >> >> On 12/11/2018 09:51 AM, Naoto Sato wrote: >>> Hi, >>> >>> Please review the fix for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8215194 >>> >>> The proposed fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ >>> >>> This one line fix is for the correctness of the initial map size of >>> Character.UnicodeBlock. >>> >>> Naoto >> From naoto.sato at oracle.com Tue Dec 11 18:33:06 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 11 Dec 2018 10:33:06 -0800 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> Message-ID: <796472e0-f203-f554-3873-2afd64bef765@oracle.com> Hi Roger, On 12/11/18 10:12 AM, Roger Riggs wrote: > Hi Naoto, > > Looks ok, > > I intended only the number of elements to be defined as a constant. > The other factors can be hard coded. OK, I revised it again: http://cr.openjdk.java.net/~naoto/8215194/webrev.02/ > > In the test, you will still have to edit the test when the number changes. > I meant to avoid that edit.? Though then may be there is not need for > the test at all. Yes, if we just reflectively use the constant in Character.UnicodeBlock in the test, it is guaranteed to succeed no matter what. Thus I added the assertion. Still, the test ofHashMap() succeeds till the block additions surpasses that 1024 capacity (thus this was overlooked on Unicode 11 upgrade). Naoto > > Roger > > > On 12/11/2018 12:59 PM, Naoto Sato wrote: >> Hi Roger, >> >> Thanks. I updated it as suggested (incl. test using reflection): >> >> http://cr.openjdk.java.net/~naoto/8215194/webrev.01/ >> >> Naoto >> >> On 12/11/18 7:57 AM, Roger Riggs wrote: >>> Hi Naoto, >>> >>> Since the value changes from time to time, it would give it some >>> visibility >>> if it were defined using a private final int? (or float) >>> ????? private final int MAP_CAPACITY = 667; >>> >>> Though I suppose the test can't use the value without using reflection. >>> But it would lower the maintenance in the long term. >>> >>> $.02, Roger >>> >>> On 12/11/2018 09:51 AM, Naoto Sato wrote: >>>> Hi, >>>> >>>> Please review the fix for the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8215194 >>>> >>>> The proposed fix is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ >>>> >>>> This one line fix is for the correctness of the initial map size of >>>> Character.UnicodeBlock. >>>> >>>> Naoto >>> > From mandy.chung at oracle.com Tue Dec 11 18:35:26 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Dec 2018 10:35:26 -0800 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: References: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> Message-ID: <16c5550b-d65d-a6c3-773c-40094fd614cb@oracle.com> On 12/11/18 10:08 AM, Roger Riggs wrote: > > VM.java: > ?- line 180:? The savedProps doesn't need to be (and was not > previously) unmodifiable. > ?? Seems safer this way though since the map at the bottom is not > ConcurrentHashMap. > ?? Its not entirely clear who calls getSavedProperties(). > ?? Would it be more efficient for savedProps to be the unmodifiable > map and not create > ?? one on every call to getSavedProperties. > JVMCI and Graal depends on VM::getSavedProperties to determine if JVMCI is enabled and also to get other Graal-specific system properties set at startup. VM::getSavedProperties is not called in the common case and creating a unmodifiable map when getSavedProperties is called is reasonable. Mandy From claes.redestad at oracle.com Tue Dec 11 18:48:18 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 11 Dec 2018 19:48:18 +0100 Subject: RFR: 8215159: Improve initial setup of system Properties In-Reply-To: References: <0d244425-9fb2-8147-7480-17ca32f9237a@oracle.com> Message-ID: <3740452c-0ac3-c7d0-f010-bb9ce97cb31a@oracle.com> Hi, On 2018-12-11 19:08, Roger Riggs wrote: > Hi Claes, > > SystemProps.java: > ? - the import of Collections isn't used. will fix before push. > > VM.java: > ?- line 180:? The savedProps doesn't need to be (and was not > previously) unmodifiable. > ?? Seems safer this way though since the map at the bottom is not > ConcurrentHashMap. > ?? Its not entirely clear who calls getSavedProperties(). > ?? Would it be more efficient for savedProps to be the unmodifiable map > and not create > ?? one on every call to getSavedProperties. VM.getSavedProperties should be removed, but that requires some coordination that is out of scope for this improvement. There's only one caller, and they cache it in a static field. Not wrapping VM.savedProps marginally improves speed of VM.savedProperty which is more used during startup. > > VersionProps.java.template: > ?- The version properties don't need to be in the savedProps map and > could be put only in the Properties. > ?? (save a few cycles and entries). Good point. I have played with code that goes even further (no need to put any of the Raw properties in the savedProps map). We can save maybe another 6k executed bytecode in total, but as it gets unclear what can be found in VM.savedProperties and what can be found in the System properties I decided against it in this patch. Thanks! /Claes > > System.java: > ?- swap lines 805/806 if you decide not to put version props in the map. > ?- and call VerionProps.init() after the call to createProperties(). > > Regards, Roger > > > > On 12/11/2018 12:41 PM, Mandy Chung wrote: >> >> >> On 12/10/18 1:17 PM, Claes Redestad wrote: >>> Hi, >>> >>> by inverting the order in which the internal property maps are created, >>> we avoid some classloading and get a slightly more efficient code >>> execution profile in System.initPhase1. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215159 >>> >> >> This change looks okay to me. >> >> ModuleBootstrap also removes some `jdk.module.*` private system >> properties during >> module system initialization but they are only set if module-related >> command-line >> options are set.?? These properties are not present in the common >> cases.?? These >> private system properties are the interface between VM and >> libraries.?? There is >> other mechanism that we can look into to replace using system >> properties in the >> future. >> >> Mandy > From ivan.gerasimov at oracle.com Tue Dec 11 18:49:06 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 11 Dec 2018 10:49:06 -0800 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: <796472e0-f203-f554-3873-2afd64bef765@oracle.com> References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> <796472e0-f203-f554-3873-2afd64bef765@oracle.com> Message-ID: Hi Naoto! The fix looks good, thank you! I wonder if the test can be updated to also verify the optimal capacity of HashMap aliases; On 12/11/18 10:33 AM, Naoto Sato wrote: > Hi Roger, > > On 12/11/18 10:12 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Looks ok, >> >> I intended only the number of elements to be defined as a constant. >> The other factors can be hard coded. > > OK, I revised it again: > > http://cr.openjdk.java.net/~naoto/8215194/webrev.02/ > >> >> In the test, you will still have to edit the test when the number >> changes. >> I meant to avoid that edit. Though then may be there is not need for >> the test at all. > > Yes, if we just reflectively use the constant in > Character.UnicodeBlock in the test, it is guaranteed to succeed no > matter what. OptimalCapacity.ofHashMap uses the initialCapacity to verify that a HashMap created with that initialCapacity will not reallocate its internal array after inserting the factual number of elements. So, if one day the number of entities is increased, but the constant NUM_ENTITIES is not updated, then the test will catch it. With kind regards, Ivan > Thus I added the assertion. Still, the test ofHashMap() succeeds till > the block additions surpasses that 1024 capacity (thus this was > overlooked on Unicode 11 upgrade). > > Naoto > >> >> Roger >> >> >> On 12/11/2018 12:59 PM, Naoto Sato wrote: >>> Hi Roger, >>> >>> Thanks. I updated it as suggested (incl. test using reflection): >>> >>> http://cr.openjdk.java.net/~naoto/8215194/webrev.01/ >>> >>> Naoto >>> >>> On 12/11/18 7:57 AM, Roger Riggs wrote: >>>> Hi Naoto, >>>> >>>> Since the value changes from time to time, it would give it some >>>> visibility >>>> if it were defined using a private final int (or float) >>>> private final int MAP_CAPACITY = 667; >>>> >>>> Though I suppose the test can't use the value without using >>>> reflection. >>>> But it would lower the maintenance in the long term. >>>> >>>> $.02, Roger >>>> >>>> On 12/11/2018 09:51 AM, Naoto Sato wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8215194 >>>>> >>>>> The proposed fix is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ >>>>> >>>>> This one line fix is for the correctness of the initial map size >>>>> of Character.UnicodeBlock. >>>>> >>>>> Naoto >>>> >> > -- With kind regards, Ivan Gerasimov From naoto.sato at oracle.com Tue Dec 11 18:59:48 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 11 Dec 2018 10:59:48 -0800 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> <796472e0-f203-f554-3873-2afd64bef765@oracle.com> Message-ID: <736afbf9-06f9-100c-50f5-2d00c75f111d@oracle.com> Hi Ivan, Thank you for the review. On 12/11/18 10:49 AM, Ivan Gerasimov wrote: > OptimalCapacity.ofHashMap uses the initialCapacity to verify that a > HashMap created with that initialCapacity will not reallocate its > internal array after inserting the factual number of elements. > > So, if one day the number of entities is increased, but the constant > NUM_ENTITIES is not updated, then the test will catch it. Actually the reason I am fixing it is that, the test did not detect the discrepancy with Unicode 11 upgrade, where it just increased the entry numbers by the true block increases (11 blocks), without adding their aliases. --- --- a/src/java.base/share/classes/java/lang/Character.java Wed Nov 14 13:15:54 2018 +0100 +++ b/src/java.base/share/classes/java/lang/Character.java Wed Nov 21 14:24:31 2018 +0530 @@ -43,7 +43,7 @@ * a character's category (lowercase letter, digit, etc.) and for converting * characters from uppercase to lowercase and vice versa. *

    - * Character information is based on the Unicode Standard, version 10.0.0. + * Character information is based on the Unicode Standard, version 11.0.0. *

    * The methods and data of class {@code Character} are defined by * the information in the UnicodeData file that is part of the @@ -681,11 +681,11 @@ */ public static final class UnicodeBlock extends Subset { /** - * 638 - the expected number of entities + * 649 - the expected number of entities * 0.75 - the default load factor of HashMap */ private static Map map = - new HashMap<>((int)(638 / 0.75f + 1.0f)); + new HashMap<>((int)(649 / 0.75f + 1.0f)); /** * Creates a UnicodeBlock with the given identifier name. --- However, the HashMap allocates the entry size to the nearest power of two number, i.e., 1024 for both numbers 649 and 667. Thus the test passes even if there is discrepancy. Naoto From Roger.Riggs at oracle.com Tue Dec 11 19:04:30 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 14:04:30 -0500 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: <796472e0-f203-f554-3873-2afd64bef765@oracle.com> References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> <796472e0-f203-f554-3873-2afd64bef765@oracle.com> Message-ID: <9f259a5f-97be-a48a-ee15-0482cc90579b@oracle.com> Looks fine. Thanks, Roger On 12/11/2018 01:33 PM, Naoto Sato wrote: > Hi Roger, > > On 12/11/18 10:12 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Looks ok, >> >> I intended only the number of elements to be defined as a constant. >> The other factors can be hard coded. > > OK, I revised it again: > > http://cr.openjdk.java.net/~naoto/8215194/webrev.02/ > >> >> In the test, you will still have to edit the test when the number >> changes. >> I meant to avoid that edit.? Though then may be there is not need for >> the test at all. > > Yes, if we just reflectively use the constant in > Character.UnicodeBlock in the test, it is guaranteed to succeed no > matter what. Thus I added the assertion. Still, the test ofHashMap() > succeeds till the block additions surpasses that 1024 capacity (thus > this was overlooked on Unicode 11 upgrade). > > Naoto > >> >> Roger >> >> >> On 12/11/2018 12:59 PM, Naoto Sato wrote: >>> Hi Roger, >>> >>> Thanks. I updated it as suggested (incl. test using reflection): >>> >>> http://cr.openjdk.java.net/~naoto/8215194/webrev.01/ >>> >>> Naoto >>> >>> On 12/11/18 7:57 AM, Roger Riggs wrote: >>>> Hi Naoto, >>>> >>>> Since the value changes from time to time, it would give it some >>>> visibility >>>> if it were defined using a private final int? (or float) >>>> ????? private final int MAP_CAPACITY = 667; >>>> >>>> Though I suppose the test can't use the value without using >>>> reflection. >>>> But it would lower the maintenance in the long term. >>>> >>>> $.02, Roger >>>> >>>> On 12/11/2018 09:51 AM, Naoto Sato wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8215194 >>>>> >>>>> The proposed fix is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ >>>>> >>>>> This one line fix is for the correctness of the initial map size >>>>> of Character.UnicodeBlock. >>>>> >>>>> Naoto >>>> >> From mvala at redhat.com Tue Dec 11 19:05:33 2018 From: mvala at redhat.com (Michal Vala) Date: Tue, 11 Dec 2018 20:05:33 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() Message-ID: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Hi, I've been looking into this bug in HashMap where resize() is called multiple times when putting whole map into another. I come up with following patch: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ I've tried to do it as little invasive as possible. New resize(int) method is called just from putMapEntries for now. Notice that method is called with size of the new map. I was experimenting with calling it with 'size()+s', but this leads to unwanted space allocation when inserted map rewrites a lot of existing keys. I've benchmarked this with adding 10millions elements into existing map and it gets ~50% improvement: unpatched Benchmark Mode Cnt Score Error Units MyBenchmark.testMethod thrpt 10 1.248 ? 0.058 ops/s patched Benchmark Mode Cnt Score Error Units MyBenchmark.testMethod thrpt 10 1.872 ? 0.109 ops/s public class MyBenchmark { static Map mapTocopy = IntStream.range(1, 10_000_000).boxed().collect(Collectors.toMap(k -> k, k -> k)); @Benchmark public int testMethod() { var map = new HashMap(); map.put(-5, -5); map.putAll(mapTocopy); return map.size(); } } Any ideas for missed corner-cases or some good tests? -- Michal Vala OpenJDK QE Red Hat Czech From sergei.tsypanov at yandex.ru Tue Dec 11 19:25:51 2018 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 11 Dec 2018 21:25:51 +0200 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> Message-ID: <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Hi Zheka and Tagir, @Override public void forEach(final Consumer action) { Objects.requireNonNull(action); for (int i = 0; i < this.n; i++) { action.accept(this.element); } } I think here we should extract this.element and this.n into a local vars, as Consumer may have interaction with volatile field inside (e.g. AtomicInteger::addAndGet) which would cause a load of consumed field at each iteration. See original post by Nitsan Wakart https://psy-lob-saw.blogspot.com/2014/08/the-volatile-read-suprise.html Regards, Sergey Tsypanov 07.12.2018, 15:22, "Zheka Kozlov" : > What about forEach()? > > @Override > public void forEach(final Consumer action) { > ????Objects.requireNonNull(action); > ????for (int i = 0; i < this.n; i++) { > ????????action.accept(this.element); > ????} > } > > I think this version has better chances to be faster than the default > implementation (did not measure though). > > ??, 4 ???. 2018 ?. ? 14:40, Tagir Valeev : > >> ?Hello! >> >> ?> In CopiesList.equals() please use eq() instead of Objects.equal() (see a >> ?comment at the line 5345). >> >> ?Ok >> >> ?> I think you should use iterator() instead of listIterator(). See the >> ?explanation here: >> ?http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html >> >> ?Ok. I wonder why this message received no attention. >> >> ?Here's updated webrev: >> ?http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r3/ >> >> ?With best regards, >> ?Tagir Valeev >> ?On Tue, Dec 4, 2018 at 1:10 PM Zheka Kozlov wrote: >> ?> >> ?> I think you should use iterator() instead of listIterator(). See the >> ?explanation here: >> ?http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html >> ?> >> ?> ??, 4 ???. 2018 ?. ? 12:23, Tagir Valeev : >> ?>> >> ?>> Hello! >> ?>> >> ?>> Thank you for your comments! >> ?>> >> ?>> Yes, deserialization will be broken if we assume that size is never 0. >> ?>> Also we'll introduce referential identity Collections.nCopies(0, x) == >> ?>> Collections.nCopies(0, y) which might introduce slight semantics >> ?>> change in existing programs. Once I suggested to wire Arrays.asList() >> ?>> (with no args) to Collections.emptyList(), but it was rejected for the >> ?>> same reason: no need to introduce a risk of possible semantics change. >> ?>> >> ?>> I updated webrev with equals implementation and test: >> ?>> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ >> ?>> Comparing two CopiesList is much faster now indeed. Also we can spare >> ?>> an iterator in the common case and hoist the null-check out of the >> ?>> loop. Not sure whether we can rely that JIT will always do this for >> ?>> us, but if you think that it's unnecessary, I can merge the loops >> ?>> back. Note that now copiesList.equals(arrayList) could be faster than >> ?>> arrayList.equals(copiesList). I don't think it's an issue. On the >> ?>> other hand we could keep simpler and delegate to super-implementation >> ?>> if the other object is not a CopiesList (like it's implemented in >> ?>> java.util.RegularEnumSet::equals for example). What do you think? >> ?>> >> ?>> With best regards, >> ?>> Tagir Valeev. >> ?>> On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks >> ?wrote: >> ?>> > >> ?>> > >> ?>> > >> I believe it makes sense to override CopiesList.equals() >> ?>> > > Also: contains(), iterator(), listIterator() >> ?>> > >> ?>> > equals(): sure >> ?>> > >> ?>> > contains() is already overridden. Not sure there's much benefit to >> ?overriding >> ?>> > the iterators. >> ?>> > >> ?>> > s'marks From sean.mullan at oracle.com Tue Dec 11 20:00:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Dec 2018 15:00:26 -0500 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> Message-ID: <73833f4b-6586-01a7-4654-ffdfaccf441b@oracle.com> On 12/11/18 10:38 AM, Baesken, Matthias wrote: >> File paths are, in general, always something that demands extra scrutiny >> as it can be the source of security issues (privacy leaks, traversal >> attacks, etc). It's not just me that thinks that way, you can do a >> search on the Internet and find lots of references. > ... >> >> It might be perfectly fine and your usage might be ok too. But I'll need >> some time to evaluate it further. I am not familiar with the code in >> this part of the JDK. >> >> I would also see if you can think about the security issues as well. >> Where do these paths come from? What are the application use cases that >> invoke these lower methods? From application code or elsewhere? Are >> relative paths used? Are paths containing ".." canonicalized? Are they >> arbitrary paths or a fixed set of paths? Do they ever contain sensitive >> information like home directory user names, etc? >> >> Once we understand if there are any security issues, then we can decide >> if allowing that via a system property is acceptable or not, and if so >> the security risks that we would have to document for that property. >> > > Hello, the file paths potentially printed in the enhanced exceptions in *canonicalize0, *createFileExclusively, > Java_java_io_WinNTFileSystem_canonicalizeWithPrefix0 could potentially come from more or less arbitrary paths. That to me, is an issue that warrants much more careful analysis before deciding whether to proceed with this fix. > This means, in some cases, there is a chance that information (like user-ids/user-names often found in paths below HOME dirs ) > might be in the printed paths that people do not want to have in log files or other output containing the exception messages. > > For such potentially sensitive info in exception messages, we have already the jdk.includeInExceptions > security property, see the java.security file : > > 1064 # Enhanced exception message information > 1065 # > 1066 # By default, exception messages should not include potentially sensitive > 1067 # information such as file names, host names, or port numbers. This property > 1068 # accepts one or more comma separated values, each of which represents a > 1069 # category of enhanced exception message information to enable. Values are > 1070 # case-insensitive. Leading and trailing whitespaces, surrounding each value, > 1071 # are ignored. Unknown values are ignored. > > I think this approach fits well for 8211752 (and is used already for some other categories). I am concerned that a single property controls whether or not potentially sensitive pathnames appear in Exceptions. > I created an updated webrev, it uses the jdk.includeInExceptions security property > (had to do it via JNI because it did not work from the static class initializers of UnixFileSystem/WinNTFileSystem) : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.2/ These exceptions are generated from a very low level part of the native JDK Windows or Unix FileSystem implementations. That is a concern. The previous usages of this property were more focused and confined to smaller parts of the code resulting in fewer code paths to analyze. I think we need to take a step back. I think we need to reconsider whether the jdk.includeInExceptions security property is appropriate for this type of enhancement. Therefore, I oppose this change as-is. I'm happy to participate in a more involved discussion where we start with use cases and motivation before jumping to solutions. Thanks, Sean From stefan.reich.maker.of.eye at googlemail.com Tue Dec 11 20:20:41 2018 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 11 Dec 2018 21:20:41 +0100 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: What is this, the thought police? Cheers Stefan BotCompany.de On Tue, 11 Dec 2018 at 20:47, Phil Race wrote: > 1) Thanks for uploading the webrev. much better for one person to do > this than make > everyone who wants to look at it go through a tedious and off-putting > set of steps. > > 2) I've added some client lists since you are touching UI client files, > not just core-libs. > To me the client ones look OK, one looks more like it was a typo > than anything intentional, > and the other was pretty mild. > > 3) Regarding the comment in the bug report about hb-private.hh and the > use of > /* CRAP pool: Common Region for Access Protection. */ > since it not only is in an upstream library, but also used 14 times in > variable names, > then I can't possibly agree with your comment that an argument for > leaving them > would be "shaky". Take this up with the upstream library ... I have no > interest in > renaming these every time we upgrade this library. > > -phil. > > On 12/11/18 8:45 AM, Adam Farley8 wrote: > > Sure thing: > > > > http://cr.openjdk.java.net/~afarley/8215217/webrev/ > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > Volker Simonis wrote on 11/12/2018 15:46:44: > > > >> From: Volker Simonis > >> To: adam.farley at uk.ibm.com > >> Cc: Java Core Libs > >> Date: 11/12/2018 15:47 > >> Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words > >> > >> Hi Adam, > >> > >> in order to prevent me from using swear words, could you please upload > >> your webrev to cr.openjdk.java.net :) > >> > >> As you may have realized webrevs are a collection of HTML files and it > >> makes no big sense to provide them as a zip file. > >> > >> Thank you and best regards, > >> Volker > >> On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8 > > wrote: > >>> Hey All, > >>> > >>> I've spotted 12 instances of swear words in OpenJDK source comments, > > and > >>> it seems appropriate to remove them. > >>> > >>> Bug: INVALID URI REMOVED > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8215217&d=DwIBaQ&c=jf_iaSHvJObTbx- > >> siA1ZOg&r=P5m8KWUXJf- > >> > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=GfAb5QlDParO6DVrhdvPZTSafShnFACNF3JgqF- > >> _RkM&s=Qscaf2tTpPcZKpIelJ6SrP0uRYSFoKaCNATns0FX7_Y&e= > >>> I've created a webrev and attached to the bug. > >>> > >>> Also, I've mentioned in the bug that there are additional swears in > > more > >>> excusable locations. It would be good to get the community's take on > >>> those. > >>> > >>> Reviews and opinions welcome. :) > >>> > >>> Best Regards > >>> > >>> Adam Farley > >>> IBM Runtimes > >>> > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > > number > >>> 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > -- Stefan Reich BotCompany.de // Java-based operating systems From vincent.x.ryan at oracle.com Tue Dec 11 21:21:20 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Dec 2018 21:21:20 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> Message-ID: <01C3CC6C-F645-40E3-A9FD-04017843F6F1@oracle.com> Thanks for your review Stuart. My preference is for PrintStream rather than Writer, for the same reason as Roger: it?s more convenient for handling System.out. Does that address your concern? I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte charset so some 0x8X characters Will trigger the multi-byte sequence and will end up being misinterpreted. Hence my rather awkward conversion to a String. Is there a better way? I?m not sure I?ve addressed your concern regarding IOExceptions - can you elaborate? BTW updated webrev/javadoc available: http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html > On 11 Dec 2018, at 02:11, Stuart Marks wrote: > > On 12/7/18 10:22 AM, Vincent Ryan wrote: >>> I'm not convinced that the overloads that send output to an OutputStream pull their weight. They basically wrap the OutputStream in a PrintStream, which conveniently doesn't declare IOException, making it easy to use from a lambda passed to forEachOrdered(). If an error writing the output occurs, this is recorded by the PrintStream wrapper; however, the wrapper is then thrown away, making it impossible for the caller to check its error status. >> The intent is to support a trivial convenience method call that generates the well-known hexdump format. >> Especially for users that are interested in the hexdump data rather than the low-level details of how to terminate a stream. >> The dumpAsStream methods are available to support cases that differ from that format. >> Have you a suggestion to improve the dump() methods, or you?d like to see them omitted? >>> The PrintStream wrapper also uses the platform default charset, and doesn't provide any way for the caller to override the charset. >> Is there a need for that? Originally the requirement was driven by the hexdump format which is ASCII-only. >> Recently the class has been enhanced to also support the printable characters from ISO 8859-1. >> A custom formatter be supplied to dumpAsStream() to cater for all other cases? > > OK, let's step back from this a bit. I see this hexdump as a little subsystem that has the following facets: > > 1) a source of bytes > 2) a converter to hex > 3) a destination > > The converter is HexDump.Formatter, which converts and formats a subrange of byte[] to a String. Since the user can supply the Formatter function, the result String can contain any unicode character. Thus, the destination needs to handle any unicode character. It can be a Writer, which accepts String data. Or if you want it to write bytes, it can be an OutputStream, which raises the issue of encoding (charset). I would recommend against relying on the platform default charset, as this has been a source of subtle bugs. The preferred approach these days is to default to UTF-8 and provide an overload that takes an explicit charset. > > An alternative is PrintStream. (This overlaps somewhat with your recent exchange with Roger on this topic.) PrintStream also does charset encoding, and the charset it uses depends on how it's created. I think the same approach should be applied as I described above with OutputStream, namely avoid the platform default charset; default to UTF-8; and provide an overload that takes an explicit charset. > > I'm not sure which of these is the right thing. You should decide which is the most convenient for the use cases you expect to see. However, the solution needs to handle charset encoding. (And it should also properly deal with I/O exceptions, per my previous message.) > > ** > > ISO 8859-1 comes up in a different place. The toPrintableString() method (used by the default formatter) considers a byte "printable" if it encodes a valid ISO 8859-1 character. The byte is properly decoded to a String, so this is ok. Note this is a distinct issue from the encoding of the OutputStream or PrintStream as described above. > > (As an aside I think that the encoding of ISO 8859-1 matches the corresponding code units of UTF-16, so you don't have to do the new String(..., ISO_8859_1) jazz. You can just cast the byte to a char and append it to the StringBuilder.) > > s'marks From vincent.x.ryan at oracle.com Tue Dec 11 21:21:24 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Dec 2018 21:21:24 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> <93c7eb10-4716-6f92-1622-39f0af54c1e5@oracle.com> <28BBEA82-5839-4AC7-BF72-697ED9B7B6BA@oracle.com> Message-ID: <86871952-7009-4036-9A54-448C2EDDE529@oracle.com> Thanks Roger. I believe that all but one of your concerns are addressed in this latest webrev/javadoc: http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html The remaining issue is how best to define the dumpAsStream() method that takes a ByteBuffer. The current approach has dropped the to/from parameters, consumes all the buffer and advances Its position to the buffer limit. This places the burden on the caller to size the buffer appropriately. However I also see the merit in a ?read-only? approach that does not advance the buffer position. Any further thoughts? > On 11 Dec 2018, at 16:54, Roger Riggs wrote: > > Ho Vincent, > > On 12/11/2018 11:34 AM, Vincent Ryan wrote: >> Responses in-line. >> >>> >>>> Its really nice/necessary that examples can be copy/pasted and compile. >>>>> >>>>> >>>>> - dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be confusing because it >>>>> is using the relative methods of ByteBuffer, but the from and to offsets are within >>>>> the position .. limit buffer. That should be explicit. >>>>> (Or consider switching to the absolute accesses in the ByteBuffer and not affect the position) >>>> >>>> Is the additional javadoc line added earlier sufficient? >>> I would bear some reinforcing that the entire remainder of the buffer is read >>> and the from and to are indexes within that remainder. >>> And I'm not sure that's the desirable semantics. >>> >>> It would make more sense if the from bytes from the buffer are skipped >>> and only the (to - from) bytes are dumped. That leaves the ByteBuffer >>> reading only the requested bytes. A natural usage such as: >>> dumpAsStream?(ByteBuffer buffer, 0, 256, 16, formatter) >>> would dump the next 256bytes of the ByteBuffer and position would be >>> moved by 256. >> >> [As suggested by Alan] >> How about dropping the fromIndex and toIndex parameters and requiring the caller >> to provide a suitably sized buffer? >> >> public static Stream dumpAsStream(ByteBuffer buffer, int chunkSize, Formatter formatter) { >> > I'd go the other direction and make dump use absolute offset and limit. > The current values for position and limit are readily available from the buffer. > > If the dumping code is being added to perform some diagnostics then it would not > modify the position and not disturb the existing code that is using the buffer. > > Absolute is simpler to explain and implement and has fewer side effects. > >> >>> >>>> >>>> >>>>> >>>>> - dump(byte[], OutputStream) - I don't think the example is correct, there is no reference >>>>> to a stream, only the PrintStream::println method, which is not static. >>>> >>>> The code is just illustrative. Real values would have to be supplied for the input bytes and the >>>> chosen print method on the output stream. Typically, that print method will be System.out::println >>> Examples that don't compile are really confusing and annoying. >> >> Updated the ?as if? code to: >> >> * byte[] bytes = ... >> * PrintStream out = ... >> * HexFormat.dumpAsStream(bytes, 16, >> * (offset, chunk, from, to) -> >> * String.format("%08x %s |%s|", >> * offset, >> * HexFormat.toFormattedString(chunk, from, to), >> * HexFormat.toPrintableString(chunk, from, to))) >> * .forEachOrdered(out::println); >> >> > Looks fine, thanks From vincent.x.ryan at oracle.com Tue Dec 11 21:21:22 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Dec 2018 21:21:22 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <3cb00752-54f9-4b8e-376c-69ab0b47cd60@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3cb00752-54f9-4b8e-376c-69ab0b47cd60@oracle.com> Message-ID: Thanks for your review Alan. I believe I?ve addressed your concerns in this latest webrev/javadoc: http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html > On 11 Dec 2018, at 13:04, Alan Bateman wrote: > > On 08/12/2018 01:18, Vincent Ryan wrote: >> Here?s the latest version that addresses all the current open issues: >> >> webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ >> javadoc: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html >> >> CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 >> > I read through the latest javadoc corresponding to webrev.07. > > Overall I think it looks very good except for dumpAsStream(ByteBuffer, fromIndex, toIndex, chunkSize, Formatter) as it's not clear if fromIndex is from the buffer position or an absolute index. If the former then there are a couple of other issues. I see Roger has touched on the advancement of the buffer position to its limit which isn't right unless all remaining bytes in the buffer are consumer. There is also an issue with the exception as attempting to consume beyond the limit is a BufferUnderflowException. It might be simpler to replace this method with a dumpAsStream(ByteBuffer, chunkSize, Formatter) that can lazily (rather than eagerly) consume the remaining bytes. Additional overloads could be added in the future if needed. > > dumpAsStream(InputStream) specifies "On return, the input stream will be at end-of-stream" but I assume this isn't right as the method is lazy. > > The 3-arg dumpAsStream doesn't specify the exception/behavior for when chunkSize is <= 0. > > fromString(CharSequence) may need clarification on how it behaves when the CS is a CharBuffer. Does it consume all the remaining chars in the buffer so its position be advanced to the limit? The 3-arg version is also not clear on this point. > > In Formatter interface it may be useful to expand the description of the "offset" parameter as readers may not immediately understand that it's just an input for the formatted string rather than a real offset, an example might help. It also doesn't say if the offset can be specified as <= 0L or not. > > A minor comment is that several places refer to a byte array as a "byte buffers. Is this deliberate or can these be replaced with "byte array" to avoid confusion. Another minor comment is that one of the dumpAsStream methods is missing @throws NPE - maybe they should all be removed and replaced with a statement in the class description. > > -Alan From david.holmes at oracle.com Tue Dec 11 21:44:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 07:44:31 +1000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: <9faaee57-ec26-b6ff-4845-fef2ec0d5a29@oracle.com> No issue with fixing F-bomb (though one comes from upstream sources I think) and the Pitch typo, but seriously "damn" is not a swear word. I have to suspect you ran a corporate word checker over the sources. David ----- damn /dam/ verb past participle: damned 1. (in Christian belief) be condemned by God to suffer eternal punishment in hell. "I treated her badly and I'll be damned to hell for it" be doomed to misfortune or failure. verb: damn; 3rd person present: damns; past tense: damned; gerund or present participle: damning "the enterprise was damned" 2. criticize strongly. "the book damns her husband" synonyms: condemn, censure, criticize, attack, denounce, deplore, decry, revile, inveigh against; blame, chastise, castigate, berate, upbraid, reprimand, rebuke, reprove, reprehend, take to task, find fault with, give someone/something a bad press; deprecate, disparage; informal: slam, hammer, lay into, cane, blast; informal: slate, slag off, have a go at; archaic: slash, reprobate; rare: excoriate, vituperate, arraign, objurgate, anathematize "we are certainly not going to damn a product just because it is non-traditional" antonyms: acclaim, praise curse (someone or something). "she cleared her throat, damning it for its huskiness" synonyms: curse, put a curse on, put the evil eye on, execrate, imprecate, hoodoo; More anathematize, excommunicate; hex; informal put a jinx on, jinx; rare accurse "if we did not believe in God, we would be damned" antonyms: bless exclamation informal exclamation: damn 1. expressing anger or frustration. "Damn! I completely forgot!" adjective informal adjective: damn 1. used for emphasis, especially to express anger or frustration. "turn that damn thing off!" Phrases ?? be damned used to express defiance or rejection of someone or something previously mentioned. "glory be damned!" damn all nothing at all. "there's damn all you can do about it" damn someone/thing with faint praise praise someone or something so unenthusiastically as to imply condemnation. "it was a wretched review, damning poor Lisa with faint praise" I'm damned if used to express a strong negative. "I'm damned if I know" not be worth a damn have no value at all. "your evidence isn't worth a damn" not give a damn not care at all. "people who don't give a damn about the environment" well I'll be damned used to express surprise. "Well, I'll be damned! What brings you here?" Origin On 12/12/2018 2:45 am, Adam Farley8 wrote: > Sure thing: > > http://cr.openjdk.java.net/~afarley/8215217/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > > Volker Simonis wrote on 11/12/2018 15:46:44: > >> From: Volker Simonis >> To: adam.farley at uk.ibm.com >> Cc: Java Core Libs >> Date: 11/12/2018 15:47 >> Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words >> >> Hi Adam, >> >> in order to prevent me from using swear words, could you please upload >> your webrev to cr.openjdk.java.net :) >> >> As you may have realized webrevs are a collection of HTML files and it >> makes no big sense to provide them as a zip file. >> >> Thank you and best regards, >> Volker >> On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8 > wrote: >>> >>> Hey All, >>> >>> I've spotted 12 instances of swear words in OpenJDK source comments, > and >>> it seems appropriate to remove them. >>> >>> Bug: INVALID URI REMOVED >> > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8215217&d=DwIBaQ&c=jf_iaSHvJObTbx- >> siA1ZOg&r=P5m8KWUXJf- >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=GfAb5QlDParO6DVrhdvPZTSafShnFACNF3JgqF- >> _RkM&s=Qscaf2tTpPcZKpIelJ6SrP0uRYSFoKaCNATns0FX7_Y&e= >>> >>> I've created a webrev and attached to the bug. >>> >>> Also, I've mentioned in the bug that there are additional swears in > more >>> excusable locations. It would be good to get the community's take on >>> those. >>> >>> Reviews and opinions welcome. :) >>> >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU >> > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From Roger.Riggs at oracle.com Tue Dec 11 21:49:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 16:49:27 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <86871952-7009-4036-9A54-448C2EDDE529@oracle.com> References: <5BF813FE.8060708@oracle.com> <22943f27-1e69-1bf8-4256-e6772091950e@oracle.com> <279BE820-659E-4C3F-9005-E72339061CA6@oracle.com> <3d5068a0-65ff-ea49-0d15-b6035594914e@oracle.com> <5BF78CEA-775E-421B-972A-80A95B815438@oracle.com> <93c7eb10-4716-6f92-1622-39f0af54c1e5@oracle.com> <28BBEA82-5839-4AC7-BF72-697ED9B7B6BA@oracle.com> <86871952-7009-4036-9A54-448C2EDDE529@oracle.com> Message-ID: <0333f963-6900-ab49-fc72-7a711f328f3e@oracle.com> Hi Vincent, I have no new inclinations about relative vs absolute, maybe someone else has use cases that will tip the balance. HexFormat.java: ?- line 264: I think you can safely just append the (char) (byte[i] & 0xff). (to avoid sign extension). ?? Creating a string for each char seems like a waste. - 759:? The getPrintStream(out) method can be removed since its always a PrintStream - 733: The exception containing the entire input hex string might be a bit daunting. ??? Can it return just the bad character and perhaps the offset? - The 'infinite' in the @return of two of the dumpAsStream methods could be removed. ? The bound on the stream depends on the input and its not important to say its infinite. Otherwise, looking very good. Thanks, Roger On 12/11/2018 04:21 PM, Vincent Ryan wrote: > Thanks Roger. > > I believe that all but one of your concerns are addressed in this > latest webrev/javadoc: > http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ > > http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html > > > The remaining issue is how best to define the dumpAsStream() method > that takes a ByteBuffer. > The current approach has dropped the to/from parameters, consumes all > the buffer and advances > Its position to the buffer limit. > This places the burden on the caller to size the buffer appropriately. > > However I also see the merit in a ?read-only? approach that does not > advance the buffer position. > > Any further thoughts? > > > >> On 11 Dec 2018, at 16:54, Roger Riggs > > wrote: >> >> Ho Vincent, >> >> On 12/11/2018 11:34 AM, Vincent Ryan wrote: >>> Responses in-line. >>> >>>> >>>>> Its really nice/necessary that examples can be copy/pasted and >>>>> compile. >>>>>> >>>>>> ?- dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be >>>>>> confusing because it >>>>>> ?? is using the relative methods of ByteBuffer, but the from and >>>>>> to offsets are within >>>>>> ?? the position .. limit buffer. That should be explicit. >>>>>> ?? (Or consider switching to the absolute accesses in the >>>>>> ByteBuffer and not affect the position) >>>>> >>>>> Is the additional javadoc line added earlier sufficient? >>>> I would bear some reinforcing that the entire remainder of the >>>> buffer is read >>>> and the from and to are indexes within that remainder. >>>> And I'm not sure that's the desirable semantics. >>>> >>>> It would make more sense if the from bytes from the buffer are skipped >>>> and only the (to - from) bytes are dumped.? That leaves the ByteBuffer >>>> reading only the requested bytes.? A natural usage such as: >>>> ?dumpAsStream?(ByteBuffer buffer, 0, 256, 16, formatter) >>>> would dump the next 256bytes of the ByteBuffer and position would be >>>> moved by 256. >>> >>> [As suggested by Alan] >>> How about dropping the fromIndex and toIndex parameters and >>> requiring the caller >>> to provide a suitably sized buffer? >>> >>> public?static?Stream dumpAsStream(ByteBuffer >>> buffer,?int?chunkSize, Formatter formatter) { >>> >> I'd go the other direction and make dump use absolute offset and limit. >> The current values for position and limit are readily available from >> the buffer. >> >> If the dumping code is being added to perform some diagnostics then >> it would not >> modify the position and not disturb the existing code that is using >> the buffer. >> >> Absolute is simpler to explain and implement and has fewer side effects. >> >>> >>>> >>>>> >>>>> >>>>>> >>>>>> - dump(byte[], OutputStream) - I don't think the example?is >>>>>> correct, there is no reference >>>>>> ? to a stream, only the PrintStream::println method,?which is not >>>>>> static. >>>>> >>>>> The code is just illustrative. Real values would have to?be >>>>> supplied for the input bytes and the >>>>> chosen print method on the output stream. Typically, that?print >>>>> method will be System.out::println >>>> Examples that don't compile are really confusing and annoying. >>> >>> Updated the ?as if? code to: >>> >>> ? ? ?* ??byte[] bytes = ... >>> ? ? ?*?? ??PrintStream out = ... >>> ? ? ?*?? ??HexFormat.dumpAsStream(bytes, 16, >>> ? ? ?*?? ? ? ??(offset, chunk, from, to) -> >>> ? ? ?*?? ? ? ? ? ??String.format("%08x??%s??|%s|", >>> ? ? ?*?? ? ? ? ? ? ? ??offset, >>> ? ? ?* ??HexFormat.toFormattedString(chunk, from, to), >>> ? ? ?* ??HexFormat.toPrintableString(chunk, from, to))) >>> ? ? ?*?? ? ? ??.forEachOrdered(out::println); >>> >>> >> Looks fine, thanks > From shade at redhat.com Tue Dec 11 21:48:58 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 11 Dec 2018 22:48:58 +0100 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <9faaee57-ec26-b6ff-4845-fef2ec0d5a29@oracle.com> References: <9faaee57-ec26-b6ff-4845-fef2ec0d5a29@oracle.com> Message-ID: <6878adc9-711b-2617-f4bf-0088b68aee83@redhat.com> On 12/11/18 10:44 PM, David Holmes wrote: > No issue with fixing F-bomb (though one comes from upstream sources I think) and the Pitch typo, > but seriously "damn" is not a swear word. Exactly my comment as well. Thanks, -Aleksey From mark.reinhold at oracle.com Tue Dec 11 21:52:13 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 Dec 2018 13:52:13 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: <20181211135213.665034978@eggemoggin.niobe.net> 2018/12/11 7:03:57 -0800, adam.farley at uk.ibm.com: > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > I've created a webrev and attached to the bug. > > Also, I've mentioned in the bug that there are additional swears in more > excusable locations. It would be good to get the community's take on > those. It also would be good to discuss the instances that you?ve proposed to change in your patch. I can certainly see removing the f-word, and other words of a sexual nature. Those are clearly inappropriate. Removing lesser words, and continuing to police their use henceforth, strikes me as overkill. What do other Committers think? - Mark From jonathan.gibbons at oracle.com Tue Dec 11 22:04:22 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Dec 2018 14:04:22 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <20181211135213.665034978@eggemoggin.niobe.net> References: <20181211135213.665034978@eggemoggin.niobe.net> Message-ID: <96941bee-e9f5-6344-88e0-9b3329207551@oracle.com> On 12/11/2018 01:52 PM, mark.reinhold at oracle.com wrote: > 2018/12/11 7:03:57 -0800, adam.farley at uk.ibm.com: >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > >> I've created a webrev and attached to the bug. >> >> Also, I've mentioned in the bug that there are additional swears in more >> excusable locations. It would be good to get the community's take on >> those. > It also would be good to discuss the instances that you?ve proposed > to change in your patch. > > I can certainly see removing the f-word, and other words of a sexual > nature. Those are clearly inappropriate. > > Removing lesser words, and continuing to police their use henceforth, > strikes me as overkill. > > What do other Committers think? > > - Mark The f-bombs in this file are from an upstream library: src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.js Are we committing to removing these words every time we update the library? -- Jon From david.holmes at oracle.com Tue Dec 11 22:07:06 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 08:07:06 +1000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <20181211135213.665034978@eggemoggin.niobe.net> References: <20181211135213.665034978@eggemoggin.niobe.net> Message-ID: On 12/12/2018 7:52 am, mark.reinhold at oracle.com wrote: > 2018/12/11 7:03:57 -0800, adam.farley at uk.ibm.com: >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > >> I've created a webrev and attached to the bug. >> >> Also, I've mentioned in the bug that there are additional swears in more >> excusable locations. It would be good to get the community's take on >> those. > > It also would be good to discuss the instances that you?ve proposed > to change in your patch. > > I can certainly see removing the f-word, and other words of a sexual > nature. Those are clearly inappropriate. > > Removing lesser words, and continuing to police their use henceforth, > strikes me as overkill. > > What do other Committers think? I completely agree. I was surprised to see the F-word but then somewhat relieved to see it came from external sources! I'd also advocate, as a matter of technical style, not using emotive commentary in the code, and avoiding colloquialisms. That should avoid any future issues. Cheers, David ----- > - Mark > From claes.redestad at oracle.com Tue Dec 11 22:31:21 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 11 Dec 2018 23:31:21 +0100 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: <736afbf9-06f9-100c-50f5-2d00c75f111d@oracle.com> References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> <796472e0-f203-f554-3873-2afd64bef765@oracle.com> <736afbf9-06f9-100c-50f5-2d00c75f111d@oracle.com> Message-ID: <03a60252-581e-6586-0d02-8e32562a560f@oracle.com> Hi Naoto, while the here fix looks good, I can't help wondering why the map isn't final? /Claes On 2018-12-11 19:59, Naoto Sato wrote: > Hi Ivan, > > Thank you for the review. > > On 12/11/18 10:49 AM, Ivan Gerasimov wrote: >> OptimalCapacity.ofHashMap uses the initialCapacity to verify that a >> HashMap created with that initialCapacity will not reallocate its >> internal array after inserting the factual number of elements. >> >> So, if one day the number of entities is increased, but the constant >> NUM_ENTITIES is not updated, then the test will catch it. > > Actually the reason I am fixing it is that, the test did not detect the > discrepancy with Unicode 11 upgrade, where it just increased the entry > numbers by the true block increases (11 blocks), without adding their > aliases. > > --- > > --- a/src/java.base/share/classes/java/lang/Character.java??? Wed Nov 14 > 13:15:54 2018 +0100 > +++ b/src/java.base/share/classes/java/lang/Character.java??? Wed Nov 21 > 14:24:31 2018 +0530 > @@ -43,7 +43,7 @@ > ? * a character's category (lowercase letter, digit, etc.) and for > converting > ? * characters from uppercase to lowercase and vice versa. > ? *

    > - * Character information is based on the Unicode Standard, version 10.0.0. > + * Character information is based on the Unicode Standard, version 11.0.0. > ? *

    > ? * The methods and data of class {@code Character} are defined by > ? * the information in the UnicodeData file that is part of the > @@ -681,11 +681,11 @@ > ????? */ > ???? public static final class UnicodeBlock extends Subset { > ???????? /** > -???????? * 638? - the expected number of entities > +???????? * 649? - the expected number of entities > ????????? * 0.75 - the default load factor of HashMap > ????????? */ > ???????? private static Map map = > -??????????????? new HashMap<>((int)(638 / 0.75f + 1.0f)); > +??????????????? new HashMap<>((int)(649 / 0.75f + 1.0f)); > > ???????? /** > ????????? * Creates a UnicodeBlock with the given identifier name. > --- > > However, the HashMap allocates the entry size to the nearest power of > two number, i.e., 1024 for both numbers 649 and 667. Thus the test > passes even if there is discrepancy. > > Naoto From naoto.sato at oracle.com Tue Dec 11 22:29:40 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 11 Dec 2018 14:29:40 -0800 Subject: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect In-Reply-To: <03a60252-581e-6586-0d02-8e32562a560f@oracle.com> References: <3101d21c-8744-9080-bb40-70fdbddbcb9c@oracle.com> <796472e0-f203-f554-3873-2afd64bef765@oracle.com> <736afbf9-06f9-100c-50f5-2d00c75f111d@oracle.com> <03a60252-581e-6586-0d02-8e32562a560f@oracle.com> Message-ID: <659187de-3151-a1d1-cf84-7da580bafe53@oracle.com> Hi Claes, I don't see any particular reason for that. In fact, I was wondering the same thing, but just left it as it was. Since I've already pushed the changeset, I will fix it on the next occasion. Naoto On 12/11/18 2:31 PM, Claes Redestad wrote: > Hi Naoto, > > while the here fix looks good, I can't help wondering why the map isn't > final? > > /Claes > > On 2018-12-11 19:59, Naoto Sato wrote: >> Hi Ivan, >> >> Thank you for the review. >> >> On 12/11/18 10:49 AM, Ivan Gerasimov wrote: >>> OptimalCapacity.ofHashMap uses the initialCapacity to verify that a >>> HashMap created with that initialCapacity will not reallocate its >>> internal array after inserting the factual number of elements. >>> >>> So, if one day the number of entities is increased, but the constant >>> NUM_ENTITIES is not updated, then the test will catch it. >> >> Actually the reason I am fixing it is that, the test did not detect >> the discrepancy with Unicode 11 upgrade, where it just increased the >> entry numbers by the true block increases (11 blocks), without adding >> their aliases. >> >> --- >> >> --- a/src/java.base/share/classes/java/lang/Character.java??? Wed Nov >> 14 13:15:54 2018 +0100 >> +++ b/src/java.base/share/classes/java/lang/Character.java??? Wed Nov >> 21 14:24:31 2018 +0530 >> @@ -43,7 +43,7 @@ >> ?? * a character's category (lowercase letter, digit, etc.) and for >> converting >> ?? * characters from uppercase to lowercase and vice versa. >> ?? *

    >> - * Character information is based on the Unicode Standard, version >> 10.0.0. >> + * Character information is based on the Unicode Standard, version >> 11.0.0. >> ?? *

    >> ?? * The methods and data of class {@code Character} are defined by >> ?? * the information in the UnicodeData file that is part of the >> @@ -681,11 +681,11 @@ >> ?????? */ >> ????? public static final class UnicodeBlock extends Subset { >> ????????? /** >> -???????? * 638? - the expected number of entities >> +???????? * 649? - the expected number of entities >> ?????????? * 0.75 - the default load factor of HashMap >> ?????????? */ >> ????????? private static Map map = >> -??????????????? new HashMap<>((int)(638 / 0.75f + 1.0f)); >> +??????????????? new HashMap<>((int)(649 / 0.75f + 1.0f)); >> >> ????????? /** >> ?????????? * Creates a UnicodeBlock with the given identifier name. >> --- >> >> However, the HashMap allocates the entry size to the nearest power of >> two number, i.e., 1024 for both numbers 649 and 667. Thus the test >> passes even if there is discrepancy. >> >> Naoto From david.holmes at oracle.com Tue Dec 11 22:47:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 08:47:31 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> Message-ID: <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: > > > On 2018-12-11 00:23, David Holmes wrote: >> Hi Magnus, >> >> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>> I propose that we introduce a new define, available to all JDK native >>> files (Hotspot included), called JDK_EXPORT. The behavior of this >>> symbol will be very similar (as of now, in fact identical) to >>> JNIEXPORT; however, the semantics will not. >>> >>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>> exporting from the library. The problem with this is that JNIEXPORT >>> is part of the JNI interface, and is supposed to be used when C >>> programs interact with Java. And, when doing this, the function >>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >> >> I've seen a lot of the emails on this issue and I don't fully >> understand what has been going wrong. But the intent is obviously the >> JNIEXPORT represents what is needed to export this function for use by >> JNI, while JNICALL defines the calling convention. I agree there may >> be some mistmatch when functions are actually not intended for general >> export outside the JDK but are only for internal JDK use. >> >>> We do have many such JNI exports in our native libraries, but we also >>> have a lot of other, non-JNI exports, where one native library just >>> provides an interface to other libraries. In these cases, we have >>> still used JNIEXPORT for the functionality of getting the function >>> exported, but we have not been consistent in our use of JNICALL. This >>> has caused us way too much trouble for something that should Just >>> Work. >> >> Are you suggesting that the interface between different libraries in >> the JDK should not be a JNI interface? Is this because you think the >> functions in these libraries are only for JDK internal use or ... ?? >> >>> I therefore propose that we define "JDK_EXPORT", with the same >>> behavior as JNIEXPORT (that is, flagging the function for external >>> visibility in the resulting native library), but which is *not* >>> supposed to be exported to Java code using JNI, nor supposed to be >>> decorated with >> >> Just a clarification there. JNI functions are not exported to Java >> code, they are exported to native code. Java code can declare native >> methods and those native methods must be written as JNI functions, but >> that's not what we are discussing. Libraries expose a JNI interface (a >> set of functions in the library) that can be called by application >> native code, using JNI. > We're apparently looking at "JNI" and "exporting" from two opposite > sides here. :-) Just to make everything clear: If I have a Java class > class MyClass { > ? public static void native myNativeFunc(); > } > > then I have one half of the JNI function, the Java half. This must be > matched by a corresponding implementation in native, like this: > JNIEXPORT void JNICALL > Java_MyClass_myNativeFunc(void) { > // ... do stuff > } > > And this is the native half of the JNI function. Right? Let's leave > aside which side is "exporting" to the other for now. :-) > > This way of setting up native functions that can be called from Java is > what I refer to as JNI. And when you declare a native JNI function, you > *must* use both JNIEXPORT and JNICALL. Alright? > > We do have a lot of those functions in our native libraries. And they > are correct just the way they are. Yep all well and good. A function declared native in Java must have an implementation as you describe. But not all native functions exist to provide the native-half of a Java native function! > However, we also have *other* native functions, that are exported, not > as JNI functions that should be called from Java, but as normal native > library functions that should be called by other native code. Okay so > far? And *those* functions have been problematic in how we decorate But there are again two cases. Those functions exported from a library that are expected to be called from external code using the JNI interface mechanism - such as all the JNI functions and JVM TI functions we export from the JVM - and those "exported" for access between libraries within the JDK (such as all the JVM_* functions in libjvm). I think it is only the second group that should be addressed by your JDK_EXPORT proposal - though I'm not completely clear exactly how to identify them. > them. My proposal is that we *refrain* from using JNIEXPORT for those > functions, and instead use JDK_EXPORT as name for the macro that > decorates them as exported. That way, we can clearly see that a function > like this: > > JDK_EXPORT void > JLI_ReadEnv(char* env); > > is correctly declared, and will be exported to other native libraries, > but not to Java. The issue is not whether it is "exported to Java"** but whether it is exported using the JNI mechanism such that other native code calls it using the JNI mechanism. ** There is no way to write a native method declaration in Java such that it would be linked to the JLI_ReadEnv function. The naming is all wrong, as is the signature. > Just to clarify, this has nothing to do with if this is a officially > supported API or not. In general though, I assume that most (if not > all?) of our exported functions (apart from the JNI_* stuff) is supposed > to be consumed by other libraries in the JDK, and is not a public API. I think it varies library by library. You may need native application code that can call directly into native JDK libraries. JLI is the Java Launcher Interface - I think it was introduced to make it easier for other launchers to be created. Native agents may need access to libmanagement or libjdwp functions. Native graphics code may need access to the JDK graphics library. Some of these accesses may be unsupported and undocumented, but I don't think you can just cut them all off. David > > /Magnus > > > >> >>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>> native functions should be changed to use JDK_EXPORT instead. >>> >>> I further propose that this macro should reside in a new file >>> "jdk.h", placed in the new directory >>> src/java.base/share/native/include/internal. This header file path >>> will automatically be provided to all native libraries, but not >>> copied to the JDK being built. (The existence of a "include/internal" >>> directory with this behavior has been discussed before. There are >>> more files that ought to be moved there, if/when it is created.) I >>> believe in many cases the #include "jni.h" can be just modified to >>> #include "#jdk.h", since most native code will not require "jni.h" >>> unless actually doing JNI calls -- most have included this file to >>> get the JNIEXPORT macro, which would explain the pervasive use of >>> #include "jni.h" in our code base. >> >> jni.h also defines all of the types used by the JNI. Those types are >> pervsive to the native code used throughout the JDK. >> >>> Thoughts? >> >> I think we need to understand the problems on Windows that prompted >> all this. Then I think we need to look at exactly how jni.h and >> JNIEXPORT etc are being used and understand whether this is truly an >> exported interface or not. >> >> Cheers, >> David >> >>> /Magnus >>> > From gromero at linux.vnet.ibm.com Tue Dec 11 22:57:09 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 11 Dec 2018 20:57:09 -0200 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: <5b42c2e000be4c05b3e175be519c1fd7@sap.com> References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 <5b42c2e000be4c05b3e175be519c1fd7@sap.com> Message-ID: Hi Michi and Martin, On 12/11/2018 01:30 PM, Doerr, Martin wrote: > thanks for updating. I think it can get shipped when Gustavo is fine with it and jdk/submit tests have passed. webrev.06 removed has_darn from match_rule_supported and the JVM now crashes with SIGILL (cmprb) on CPUs <= POWER8. I think that what we want is both UseCharacterCompareIntrinsics and has_darn in the predicate, so: diff -r 01b519fcb8a8 -r f3bd7a422a6c src/hotspot/cpu/ppc/ppc.ad --- a/src/hotspot/cpu/ppc/ppc.ad Tue Dec 11 11:01:02 2018 -0500 +++ b/src/hotspot/cpu/ppc/ppc.ad Tue Dec 11 12:29:41 2018 -0500 @@ -2257,6 +2257,11 @@ return SuperwordUseVSX; case Op_PopCountVI: return (SuperwordUseVSX && UsePopCountInstruction); + case Op_Digit: + case Op_LowerCase: + case Op_UpperCase: + case Op_Whitespace: + return (UseCharacterCompareIntrinsics && VM_Version::has_darn()); } Martin, is what you meant on your last comment about it? I tested the change on POWER9 and it looks good (from webrev.06 and also with webrev.06 + the fix above)! I think that the Opto assembly could be improved a little bit around 'done:' label, like: diff -r 89aab62d10cd src/hotspot/cpu/ppc/ppc.ad --- a/src/hotspot/cpu/ppc/ppc.ad Tue Dec 11 12:29:41 2018 -0500 +++ b/src/hotspot/cpu/ppc/ppc.ad Tue Dec 11 15:55:34 2018 -0500 @@ -12440,7 +12440,8 @@ "LIS $src2, (signed short)0xAAB5\n\t" "ORI $src2, $src2, 0xBABA\n\t" "INSRDI $src2, $src2, 32, 0\n\t" - "CMPEQB $crx, 1, $src1, $src2\n\t" + "CMPEQB $crx, 1, $src1, $src2\n" + "done:\n\t" "SETB $dst, $crx" %} size(48); @@ -12484,7 +12485,8 @@ "BGT $crx, done\n\t" "LIS $src2, (signed short)0xD6C0\n\t" "ORI $src2, $src2, 0xDED8\n\t" - "CMPRB $crx, 1, $src1, $src2\n\t" + "CMPRB $crx, 1, $src1, $src2\n" + "done:\n\t" "SETB $dst, $crx" %} so the output would be: 024 B2: # B5 B3 <- B1 Freq: 1 024 LI R14, 0x5A41 CMPRB CCR6, 0, R3, R14 BGT CCR6, done LIS R14, (signed short)0xD6C0 ORI R14, R14, 0xDED8 CMPRB CCR6, 1, R3, R14 done: SETB R15, CCR6 040 CMPWI CCR6, R15, #0 044 Beq CCR6, B5 P=0.000000 C=5377.000000 instead of: 024 B2: # B5 B3 <- B1 Freq: 1 024 LI R14, 0x5A41 CMPRB CCR6, 0, R3, R14 BGT CCR6, done LIS R14, (signed short)0xD6C0 ORI R14, R14, 0xDED8 CMPRB CCR6, 1, R3, R14 SETB R15, CCR6 040 CMPWI CCR6, R15, #0 044 Beq CCR6, B5 P=0.000000 C=5379.000000 If nobody opposes to that tiny enhancement I would like to keep it. ... and a nit: several trailing spaces here and there :) I generated a webrev with has_darn in match_rule_supported, with the change to the Opto asm, and with the trailing spaces removed. I uploaded it to: http://cr.openjdk.java.net/~gromero/8213754/webrev.07/ I pushed that same version to jdk/submit [1] not expecting any failure and once I get the fine results and if you, Martin are ok with the version in webrev.07 I'll push it to jdk/jdk. I'll update this thread a soon as I get the results back from jdk/submit repo. I think we have time until Thurday 16:00 UTC, even taking into account the 3+ different timezones working on that change :) Thank you and best regards, Gustavo [1] http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-December/004418.html > Note that changes pushed before Thursday 16:00 UTC will go into jdk12. > > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Dienstag, 11. Dezember 2018 14:08 > *To:* Doerr, Martin > *Cc:* core-libs-dev at openjdk.java.net; Gustavo Romero ; hotspot-compiler-dev at openjdk.java.net; Roger Riggs ; Vladimir Kozlov ; Simonis, Volker > *Subject:* RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > Hi Martin, > > Thank you so much for your review and pointing out the issue on flag enablement on PPC64. > > Latest webrev enables the flag on PPC64 using has_darn in vm_version_ppc and it is used in match_rule_supported in the ad file. > http://cr.openjdk.java.net/~mhorie/8213754/webrev.06/ > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for "Doerr, Martin" ---2018/12/11 20:31:40---Hi Michihiro, the shared code looks good to me, now."Doerr, Martin" ---2018/12/11 20:31:40---Hi Michihiro, the shared code looks good to me, now. > > From: "Doerr, Martin" > > To: Vladimir Kozlov >, Michihiro Horie >, Gustavo Romero > > Cc: "core-libs-dev at openjdk.java.net " >, "hotspot-compiler-dev at openjdk.java.net " >, Roger Riggs >, "Simonis, Volker" > > Date: 2018/12/11 20:31 > Subject: RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > Hi Michihiro, > > the shared code looks good to me, now. > > Looks like the PPC64 is not consistent any more. > Where do you enable UseCharacterCompareIntrinsics on PPC64? > Why aren't you using it for match_rule_supported in the ad file? > I think has_darn could be used to enable it in vm_version_ppc. > > Best regards, > Martin > > > -----Original Message----- > From: Vladimir Kozlov > > Sent: Montag, 10. Dezember 2018 20:33 > To: Michihiro Horie >; Gustavo Romero > > Cc: core-libs-dev at openjdk.java.net ; hotspot-compiler-dev at openjdk.java.net ; Doerr, Martin >; Roger Riggs >; Simonis, Volker > > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > On 12/9/18 5:28 PM, Michihiro Horie wrote: >> Hi Vladimir, >> >> Thanks a lot for your review. I also fixed the copyright in intrinsicnode.hpp. >> >> >Did you look on code generated by C2 with your latest changes? >> Yes,I usually check generated code with Oprofile and they were as expected like: >> : >> 90 0.0905 : 3fff64c27654: rlwinm r12,r9,24,8,31 >> 12 0.0121 : 3fff64c27658: li r11,14640 >> 15 0.0151 : 3fff64c2765c: cmprb cr5,0,r31,r11 >> 5527 5.5587 : 3fff64c27660: setb r11,cr5 >> 36010 36.2164 : 3fff64c27664: stb r11,16(r15) > > Good. > >> : >> >> I found a CSR FAQ that mentions adding a diagnostic flag do not need CSR process. This time I do not need CSR. >> https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > Thank is correct. > >> >> Hi Gustavo, >> Could I ask you to sponsor the latest change webrev.05? I would like you to test it on your P9 node too. > > Thanks, > Vladimir > >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> >> Inactive hide details for Vladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > >> To: RogerVladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > To: Roger Riggs >> >, Michihiro Horie > >> >> From: Vladimir Kozlov > >> To: Roger Riggs >, Michihiro Horie > >> Cc: core-libs-dev at openjdk.java.net , hotspot-compiler-dev at openjdk.java.net , martin.doerr at sap.com , volker.simonis at sap.com >> Date: 2018/12/08 03:48 >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> >> >> Hi Michihiro, >> >> Hotspot changes looks fine. >> Did you look on code generated by C2 with your latest changes? >> >> And Copyright year change in intrinsicnode.hpp is incorrect: >> >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. >> >> Should be >> >> * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. >> >> >> Thanks, >> Vladimir >> >> On 12/7/18 10:08 AM, Roger Riggs wrote: >> > Hi Michihiro, >> > >> > Looks fine with the updates. >> > >> > Its great that the change to isDigit is beneficial on other platforms too. >> > >> > A very small editorial: >> > There should be a comma "," after the 2018 in the copyright of: >> > test/micro/org/openjdk/bench/java/lang/Characters.java >> > >> > Thanks, Roger >> > >> > >> > On 12/07/2018 03:13 AM, Michihiro Horie wrote: >> >> >> >> Hi Roger, >> >> >> >> I updated my webrev. >> >> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ >> >> >> >> >> >> >0x80 might be a good choice or 0xff. >> >> I agree,thanks. >> >> >> >> >I was wondering about the performance without the PPC specific intrinsic but with the >> >> >CharacterDataLatin1.java.template code for isDigit being: >> >> > return '0' <= ch && ch <= '9'; >> >> I now understand your point,thanks for your explanation. Both on Power9 and Skylake, the >> >> isDigit(ch)using ?0???9?explicitly in CharacterDataLatin1.java.template without PPC specific >> >> intrinsicwas around 15% faster than the original code that does not include my changes. I fixed my >> >> change using ?0???9?for this isDigit(ch). >> >> >> >> >> >> Best regards, >> >> -- >> >> Michihiro, >> >> IBM Research - Tokyo >> >> >> >> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 >> >> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 >> >> AM, Michihiro Horie wrote: >> >> >> >> From: Roger Riggs > >> >> To: Michihiro Horie > >> >> Cc: core-libs-dev at openjdk.java.net , hotspot-compiler-dev at openjdk.java.net , martin.doerr at sap.com , >> >> vladimir.kozlov at oracle.com , volker.simonis at sap.com >> >> Date: 2018/12/07 01:23 >> >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace >> >> >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> >> >> >> >> Hi Michihiro, >> >> >> >> On 12/06/2018 02:38 AM, Michihiro Horie wrote: >> >> >> >> Hi Roger, >> >> >> >> Thank you for your helpful comments. I updated new webrev, adding a parameter in the jmh >> >> test to measure ?other? characters and moving the file to an appropriate location, also >> >> fixing the indents and copyright year._ >> >> >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.03_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=aKLGn7JZawWsl9UR7H-PyYoTpBc23BAKMqGScywbC5U&e= >> >> >> >> >> >> The choice of 256 for other is outside the range of Latin1 which is 0..255. >> >> 0x80 might be a good choice or 0xff. >> >> >> >> >> >> >Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' >> >> >in CharacterDataLatin1.java.template? The performance would need to be measured and >> >> compared. >> >> Yes, there is an opportunity: intrinsic performed 25% better than the original on Power9. >> >> >> >> I was wondering about the performance without the PPC specific intrinsic but with the >> >> CharacterDataLatin1.java.template code for isDigit being: >> >> return '0' <= ch && ch <= '9'; >> >> >> >> >> >> >Is the profile of in-lining methods changed in any measurable way now that >> >> >there is an extra level of method invocation? >> >> > Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == >> >> LOWERCASE_LETTER; >> >> > >> >> >instead of: >> >> > Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; >> >> I missed this point, thanks. I tried jstack but could not find additional level. >> >> >> >> LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled in c1: >> >> > >> address='0x00003fff5911cb90' relocation_offset='344' insts_offset='368' stub_offset='1136' >> >> scopes_data_offset='1248' scopes_pcs_offset='1336' dependencies_offset='1448' >> >> nul_chk_table_offset='1456' oops_offset='1184' metadata_offset='1192' >> >> method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' bytes='15' count='1024' >> >> iicount='1025' stamp='0.058'/> >> >> >> >> Supposing some existing complex code was already taking advantage of the full allowed inline depth. >> >> Then adding an extra level might change the inlining behavior. >> >> >> >> >> >> Existing methods in CharacterDataLatin1.java.template etc. directly invoke >> >> getProperties(ch), so isLowerCase(ch) would be more aligned with other methods if it looks >> >> like as follows? >> >> + @HotSpotIntrinsicCandidate >> >> + boolean isLowerCase(int ch) { >> >> + int props = getProperties(ch); >> >> + return (props & $$maskType) == Character.LOWERCASE_LETTER; >> >> + } >> >> >> >> Yes, that would alleviate my concern. >> >> >> >> Thanks, Roger >> >> >> >> >> >> >> >> Best regards, >> >> -- >> >> Michihiro, >> >> IBM Research - Tokyo >> >> >> >> Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 >> >> 07:21 AM, Michihiro Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On >> >> 12/05/2018 07:21 AM, Michihiro Horie wrote: >> >> >> >> From: Roger Riggs _>_ >> >> To: Michihiro Horie _>_ , >> >> _vladimir.kozlov at oracle.com_ >> >> Cc: _core-libs-dev at openjdk.java.net_ , >> >> _hotspot-compiler-dev at openjdk.java.net_ , >> >> _martin.doerr at sap.com_ , _volker.simonis at sap.com_ >> >> >> >> Date: 2018/12/06 05:09 >> >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> >> >> >> >> Hi Michihiro, >> >> >> >> On 12/05/2018 07:21 AM, Michihiro Horie wrote: >> >> >There are a few JMH tests for upper and lower in the >> >> jmh-jdk-microbenchmarks repo. [1] >> >> Here is a jmh webrev for the Character methods._ >> >> >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_jmh-2Dwebrev.00_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=v22au5r5gvv48ufyda1poelXBjJWwuotSFrv-M2AlRY&e= >> >> Please include at least one >> character value that is not a member of any of the classes. >> >> The performance impact for 'other' characters is important also. >> >> >> >> The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: >> >> test/micro/org/openjdk/bench/java/lang/ >> >> >> >> Now that they are in that repo, they can be included with the rest of the changeset. >> >> Also, I updated C2 changes in the latest webrev. (Thank you for giving >> >> valuable comments off-list, Vladimir and Martin!) >> >> With the change in is_disabled_by_flags, I added a JVM flag that will need >> >> another review request. I would proceed for it if this RFR is accepted._ >> >> >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.02_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=UXQByb5dFxfAwCCppkizqG_-RWf6DhE_PFkr9TsyzKo&e= >> >> The indent in the Java code should >> be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 >> >> spaces) >> >> >> >> Please update the copyrights to include 2018. >> >> >> >> Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' >> >> in CharacterDataLatin1.java.template? The performance would need to be measured and compared. >> >> >> >> Is the profile of in-lining methods changed in any measurable way now that >> >> there is an extra level of method invocation? >> >> Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == >> >> LOWERCASE_LETTER; >> >> >> >> instead of: >> >> Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; >> >> >> >> Regards, Roger >> >> I need a review on changes in the class library, anyway. Would be grateful >> >> if I could have one. >> >> >> >> >> >> Best regards, >> >> -- >> >> Michihiro, >> >> IBM Research - Tokyo >> >> >> >> >> >> ----- Original message ----- >> >> From: Michihiro Horie/Japan/IBM >> >> To: Vladimir Kozlov _>_ >> >> >> >> Cc: core-libs-dev _>_ >> >> , >> >> _hotspot-compiler-dev at openjdk.java.net_ >> >> , _martin.doerr at sap.com_ >> >> , Roger Riggs _>_ >> >> , _volker.simonis at sap.com_ >> >> >> >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> Date: Fri, Nov 30, 2018 1:01 PM >> >> >> >> Hi Vladimir, >> >> >> >> Thank you for your further comments. I fixed my code, but I?m afraid >> >> discussing such a basic topic involving the two big mailing lists is not >> >> good. Please let me have a chance to talk on this off-list. >> >> >> >> >> >> Best regards, >> >> -- >> >> Michihiro, >> >> IBM Research - Tokyo >> >> >> >> Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not >> >> understand which Region node you are swapping. Where it is coming from? >> >> >> >> From: Vladimir Kozlov _>_ >> >> >> >> To: Michihiro Horie _>_ , Roger >> >> Riggs _>_ >> >> Cc: core-libs-dev _>_ >> >> , >> >> _hotspot-compiler-dev at openjdk.java.net_ >> >> , _martin.doerr at sap.com_ >> >> , _volker.simonis at sap.com_ >> >> >> >> Date: 2018/11/30 03:01 >> >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> >> >> >> >> Hi Michihiro, >> >> >> >> I still do not understand which Region node you are swapping. Where it is >> >> coming from? >> >> >> >> > + // Swap current RegionNode with new one >> >> >> >> Regards, >> >> Vladimir >> >> >> >> On 11/28/18 10:31 PM, Michihiro Horie wrote: >> >> > Vladimir,Roger, >> >> > Thank you so much for your responses. >> >> > >> >> > Vladimir, >> >> > Regarding the hotspot change,I?m new in changing around >> >> library_call.cpp,so your comments are very helpful. I will fix >> >> > my code,especially inline_character_compare()would be like: >> >> > >> >> > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ >> >> > + RegionNode* old_rgn = control()->as_Region(); >> >> > + RegionNode* new_rgn = new RegionNode(1); >> >> > + record_for_igvn(new_rgn); >> >> > + >> >> > + // Swap current RegionNode with new one >> >> > + Node* new_ctrl = old_rgn->in(1); >> >> > + old_rgn->del_req(1); >> >> > + new_rgn->add_req(new_ctrl); >> >> > + >> >> > + set_control(_gvn.transform(new_rgn)); >> >> > + >> >> > + // argument(0)is receiver >> >> > + Node* codePoint = argument(1); >> >> > + Node* n = NULL; >> >> > + >> >> > + switch (id){ >> >> > + case vmIntrinsics::_isDigit_c : n = new >> >> DigitCNode(control(),codePoint);break; >> >> > + case vmIntrinsics::_isLowerCase_c : n = new >> >> LowerCaseCNode(control(),codePoint);break; >> >> > + case vmIntrinsics::_isUpperCase_c : n = new >> >> UpperCaseCNode(control(),codePoint);break; >> >> > + case vmIntrinsics::_isWhitespace_c : n = new >> >> WhitespaceCNode(control(),codePoint);break; >> >> > + default: >> >> > + fatal_unexpected_iid(id); >> >> > + } >> >> > + >> >> > + set_result(_gvn.transform(n)); >> >> > + return true; >> >> > +} >> >> > >> >> > Microbenchmark showed ~40% improvements. >> >> > >> >> > Roger, >> >> > I would wait foryour review,thanks. I understood the discussion had not >> >> been recognized from people in core-libs-dev,and >> >> > checked it was not actually archived there?. >> >> > >> >> > Best regards, >> >> > -- >> >> > Michihiro, >> >> > IBM Research - Tokyo >> >> > >> >> > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll >> >> look at it on Thursday.Roger Riggs ---2018/11/29 >> >> > 11:21:26---Hi, I'll look at it on Thursday. >> >> > >> >> > From: Roger Riggs _>_ >> >> > To: Vladimir Kozlov _>_ >> >> , Michihiro Horie _>_ >> >> , _core-libs-dev at openjdk.java.net_ >> >> >> >> > Cc: _volker.simonis at sap.com_ , >> >> _hotspot-compiler-dev at openjdk.java.net_ >> >> , _martin.doerr at sap.com_ >> >> >> >> > Date: 2018/11/29 11:21 >> >> > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for >> >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> >> > >> >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> > >> >> > >> >> > >> >> > Hi, >> >> > >> >> > I'll look at it on Thursday. >> >> > >> >> > In spite of it looking like the email was sent to core-lib-dev, I have >> >> > not seen it before >> >> > and its not in the core-libs-dev archive. >> >> > >> >> > $.02, Roger >> >> > >> >> > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: >> >> > > You still need review from core-libs. >> >> > > >> >> > > About your hotspot changes. You need to add intrinsics to >> >> > > is_disabled_by_flags() to be able switch them off. >> >> > > >> >> > > Note, match_rule_supported() calls in >> >> > > C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 >> >> > > are registered. So they will not be available if they are not >> >> > > supported. match_rule_supported() checks in >> >> > > LibraryCallKit::inline_character_compare() are not needed. >> >> > > >> >> > > I don't get what you code in >> >> > > LibraryCallKit::inline_character_compare() is doing. Why you check >> >> > > Region node at the beginning and why you add Region and Phi at the end >> >> > > if you have only one path? >> >> > > You are creating code for whole method which should return boolean result >> >> > > >> >> > > + boolean isDigit(int ch) { >> >> > > + return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; >> >> > > + } >> >> > > >> >> > > but your code produce TypeInt::CHAR. why? >> >> > > >> >> > > An finally. Did you compare code generated by default and with you >> >> > > changes? what improvement you see? >> >> > > >> >> > > Thanks, >> >> > > Vladimir >> >> > > >> >> > > On 11/28/18 3:07 PM, Michihiro Horie wrote: >> >> > >> Is there any response from core-libs-dev? >> >> > >> >> >> > >> Vladimir, >> >> > >> Could you give your suggestion on how to proceed? >> >> > >> >> >> > >> >> >> > >> Best regards, >> >> > >> -- >> >> > >> Michihiro, >> >> > >> IBM Research - Tokyo >> >> > >> >> >> > >> >> >> > >> ----- Original message ----- >> >> > >> From: "Michihiro Horie" _>_ >> >> > >> Sent by: "hotspot-compiler-dev" >> >> > >> _>_ >> >> >> >> > >> To: "Doerr, Martin" _>_ >> >> >> >> > >> Cc: "Simonis, Volker" _>_ >> >> , >> >> > >> _"hotspot-compiler-dev at openjdk.java.net "_ >> >> _>_ >> >> , >> >> > >> _"core-libs-dev at openjdk.java.net "_ >> >> _>_ >> >> >> >> > >> Subject: RE: 8213754: PPC64: Add Intrinsics for >> >> > >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> Date: Thu, Nov 22, 2018 11:28 AM >> >> > >> >> >> > >> Hi Martin, >> >> > >> >> >> > >> Yes, we should wait for the feedback on class library change. >> >> > >> >> >> > >> >Btw. I think you can further simplify the code in library_call.cpp >> >> > >> (no phi). But we can discuss details when thedirection regarding the >> >> > >> java classes is clear. >> >> > >> Thank you for pointing out it, I think I understand how to simplify >> >> > >> code. >> >> > >> >> >> > >> >Hi Michi, >> >> > >> > >> >> > >> >On 11/20/2018 02:52 PM, Michihiro Horie wrote: >> >> > >> >> >Please note that we don?t have a machine, yet. So other people >> >> > >> will have to test. >> >> > >> >> I think Gustavo can help testing this change when its' ready. >> >> > >> >Sure :) >> >> > >> > >> >> > >> >Best regards, >> >> > >> >Gustavo >> >> > >> Thank you, Gustavo. >> >> > >> >> >> > >> >> >> > >> Best regards, >> >> > >> -- >> >> > >> Michihiro, >> >> > >> IBM Research - Tokyo >> >> > >> >> >> > >> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi >> >> > >> Michihiro, thanks. This proposal makes the javacode much"Doerr, >> >> > >> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal >> >> > >> makes the java code much moreintrinsics friendly. >> >> > >> >> >> > >> From: "Doerr, Martin" _>_ >> >> >> >> > >> To: Michihiro Horie _>_ , >> >> > >> _"core-libs-dev at openjdk.java.net "_ >> >> _>_ >> >> >> >> > >> Cc: _"hotspot-compiler-dev at openjdk.java.net "_ >> >> >> >> > >> _>_ >> >> , "Simonis, >> >> > >> Volker"_>_ , >> >> Gustavo Romero >> >> > >> _>_ >> >> > >> Date: 2018/11/22 01:33 >> >> > >> Subject: RE: 8213754: PPC64: Add Intrinsics for >> >> > >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> >> >> > >> >> >> > >> >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> Hi Michihiro, >> >> > >> >> >> > >> thanks. This proposal makes the java code much more intrinsics friendly. >> >> > >> We should wait for feedback from the core lib folks. Maybe they have >> >> > >> some requirements or other proposals. >> >> > >> >> >> > >> I think these intrinsics should be interesting for Oracle, Intel and >> >> > >> others, too. >> >> > >> >> >> > >> Btw. I think you can further simplify the code in library_call.cpp >> >> > >> (no phi). But we can discuss details when thedirection regarding the >> >> > >> java classes is clear. >> >> > >> >> >> > >> Best regards, >> >> > >> Martin >> >> > >> >> >> > >> * >> >> > >> **From:*Michihiro Horie _>_ * >> >> > >> **Sent:*Mittwoch, 21. November 2018 17:14* >> >> > >> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin >> >> > >> _>_ * >> >> > >> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker >> >> > >> _>_ ; Gustavo >> >> Romero_>_ * >> >> > >> **Subject:*RE: 8213754: PPC64: Add Intrinsics for >> >> > >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> >> >> > >> Hi Martin, >> >> > >> >> >> > >> I send this RFR to core-libs-dev too, because it changes the class >> >> > >> library. >> >> > >> >> >> > >> Through trial and error, I separated Latin1 block as in the _ >> >> > >> >> >> > >> ___https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.01-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=co8xQFD19i2JBuYtSh2KKr-qUmwPdt6MEpJErzBfsd0&e= >> >> >> >> > >> >> > >> >> <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.01-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=w78kALiRtp6DIYAfslpK_TGpubqajF0h32O_z_ITAF4&e=>_/_ >> >> > >> >> >> > >> I followed the coding way of Character.isWhitespace() that invokes >> >> > >> each ChracterData?s isWhitespace() to refactorisDigit(), >> >> > >> isLowerCase(), and isUpperCase(). >> >> > >> >> >> > >> I think this change is also useful on x86, using STTNI. >> >> > >> >> >> > >> >> >> > >> Best regards, >> >> > >> -- >> >> > >> Michihiro, >> >> > >> IBM Research - Tokyo >> >> > >> >> >> > >> >> >> > >> ----- Original message ----- >> >> > >> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_ >> >> >> > >> Sent by: "hotspot-compiler-dev" >> >> > >> >> >> >> <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_ >> >> >> > >> To: "Doerr, Martin" <_martin.doerr at sap.com_ > > >> > >> <_mailto:martin.doerr at sap.com_>> >> >> > >> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > >> > >> <_mailto:volker.simonis at sap.com_>>, >> >> > >> >> >> "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_> " >> >> > >> >> >> <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_ >>, >> >> > >> >> >> "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_> " >> >> > >> >> >> <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_ >> >> >> > >> >> >> > >> Subject: RE: 8213754: PPC64: Add Intrinsics for >> >> > >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> Date: Wed, Nov 21, 2018 1:53 AM >> >> > >> >> >> > >> Hi Martin, >> >> > >> >> >> > >> Thank you for giving your helpful comments. I did not recognize >> >> > >> ?generate_method_call_static? prevents anyoptimizations, but I now >> >> > >> checked it actually degraded the performance, thanks. >> >> > >> >> >> > >> >Please note that we don?t have a machine, yet. So other people will >> >> > >> have to test. >> >> > >> I think Gustavo can help testing this change when its' ready. >> >> > >> >> >> > >> >Would it be possible to introduce more fine-grained intrinsics such >> >> > >> that the ?slow? path is outside of them? >> >> > >> > >> >> > >> >Maybe you can factor out as in the following example? >> >> > >> >if (latin1) return isLatin1Digit(codePoint); >> >> > >> >with isLatin1Digit as HotSpotIntrinsicCandidate. >> >> > >> Thanks for an example, please let me try to separate the Latin block >> >> > >> from other blocks for some time. >> >> > >> >> >> > >> >> >> > >> Best regards, >> >> > >> -- >> >> > >> Michihiro, >> >> > >> IBM Research - Tokyo >> >> > >> >> >> > >> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi >> >> > >> Michihiro, first of all, thanks for working onPower9 opt"Doerr, >> >> > >> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks >> >> > >> for working on Power9optimizations. Please note that we don't ha >> >> > >> >> >> > >> From: "Doerr, Martin" <_martin.doerr at sap.com_ > > >> > >> <_mailto:martin.doerr at sap.com_>> >> >> > >> To: Michihiro Horie <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_ >>, >> >> > >> >> >> "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_> " >> >> > >> >> >> <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_ >>, >> >> > >> >> >> "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_> " >> >> > >> <_ppc-aix-port-dev at openjdk.java.net_ > > >> > >> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> >> >> > >> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > >> > >> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, >> >> > >> Goetz"<_goetz.lindenmaier at sap.com_ > > >> > >> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero >> >> > >> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_ >> >> >> > >> Date: 2018/11/20 01:55 >> >> > >> Subject: RE: 8213754: PPC64: Add Intrinsics for >> >> > >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> >> >> > >> >> >> > >> >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> Hi Michihiro, >> >> > >> >> >> > >> first of all, thanks for working on Power9 optimizations. Please note >> >> > >> that we don?t have a machine, yet. So other peoplewill have to test. >> >> > >> >> >> > >> I think it may be problematic to insert a slow path by >> >> > >> ?generate_method_call_static?. This may be a performancedisadvantage >> >> > >> for some users of other encodings because your intrinsics prevent >> >> > >> inlining and further optimizations. >> >> > >> Would it be possible to introduce more fine-grained intrinsics such >> >> > >> that the ?slow? path is outside of them? >> >> > >> >> >> > >> Maybe you can factor out as in the following example? >> >> > >> if (latin1) return isLatin1Digit(codePoint); >> >> > >> with isLatin1Digit as HotSpotIntrinsicCandidate. >> >> > >> >> >> > >> I can?t judge if this is needed, but I think this should be discussed >> >> > >> first before going into the details. >> >> > >> >> >> > >> Best regards, >> >> > >> Martin >> >> > >> >> >> > >> * >> >> > >> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > > >> <_mailto:HORIE at jp.ibm.com_>>* >> >> > >> **Sent:*Freitag, 16. November 2018 12:53* >> >> > >> **To:*_hotspot-compiler-dev at openjdk.java.net_ >> >> > >> >> >> <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ >> >> > >> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* >> >> > >> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > > >> > >> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker >> >> > >> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_ >>; >> >> > >> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > > >> > >> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero >> >> > >> <_gromero at linux.vnet.ibm.com_ <_mailto:gromero at linux.vnet.ibm.com_ >>* >> >> > >> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for >> >> > >> isDigit/isLowerCase/isUpperCase/isWhitespace >> >> > >> >> >> > >> Dear all, >> >> > >> >> >> > >> Would you please review following change? >> >> > >> >> >> > >> Bug: >> >> > >> __https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=yTUTl4D2EPdboqkkAHXYtHx5KijWhAzXOXPBqwME0iQ&e= >> >> > >> Webrev: >> >> > >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.00-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=88Ms75RO8511eAgWMsvWrTDLmRRcxcKiEs_DkSZmVlc&e= >> >> >> >> > >> >> > >> >> <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=zZl2pxTY0Dn-5RZHkTZSnIRpYzb-w9T_4d8cV7gU3iw&e=> >> >> > >> >> >> > >> This change includes the intrinsics of Character isDigit, >> >> > >> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block >> >> > >> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to >> >> > >> compare a character with 1 or 2 rangedbytes, while the cmpeqb >> >> > >> compares one with 1 to 8 values. Simple micro benchmark attached >> >> > >> showed improvements by 20-40%. >> >> > >> / >> >> > >> //(See attached file: Latin1Test.java)/ >> >> > >> >> >> > >> >> >> > >> Best regards, >> >> > >> -- >> >> > >> Michihiro, >> >> > >> IBM Research - Tokyo >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > > > From joe.darcy at oracle.com Tue Dec 11 23:09:10 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 11 Dec 2018 15:09:10 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <20181211135213.665034978@eggemoggin.niobe.net> References: <20181211135213.665034978@eggemoggin.niobe.net> Message-ID: <24580f82-bc07-109b-c4ad-d8833dca0ba1@oracle.com> On 12/11/2018 1:52 PM, mark.reinhold at oracle.com wrote: > 2018/12/11 7:03:57 -0800, adam.farley at uk.ibm.com: >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > >> I've created a webrev and attached to the bug. >> >> Also, I've mentioned in the bug that there are additional swears in more >> excusable locations. It would be good to get the community's take on >> those. > It also would be good to discuss the instances that you?ve proposed > to change in your patch. > > I can certainly see removing the f-word, and other words of a sexual > nature. Those are clearly inappropriate. > > Removing lesser words, and continuing to police their use henceforth, > strikes me as overkill. > > What do other Committers think? I don't think our sensibilities need be so delicate as to be compelled to purge mild exclamations from test files. As noted elsewhere on this thread, the words altered in the proposed patch which intersect with the words in George Carin's list of "Seven Words You Can Never Say on Television," originate in up-stream sources and would be better addressed there. -Joe From mandy.chung at oracle.com Tue Dec 11 23:57:21 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Dec 2018 15:57:21 -0800 Subject: Review Request JDK-8215238: (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules Message-ID: <48db7228-d2c4-751e-240f-044224383424@oracle.com> Several modules including Java EE and CORBA modules [1] and JavaFX and a few other modules have been removed from JDK. jdeps maintains a list of JDK 8 internal API packages that `jdeps -jdkinternals` can properly flag that a reference to JDK 8 internal API that was renamed or removed while the feature is still supported.? For these removed modules, their internal API packages should be handled as non-JDK API and reports missing dependency if not found.? The patch is simple and the main change is to remove them from the `jdk8_internals.txt` resource file. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8215238/webrev.00/ Thanks Mandy [1] http://openjdk.java.net/jeps/320 From lance.andersen at oracle.com Wed Dec 12 00:32:14 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 11 Dec 2018 19:32:14 -0500 Subject: Review Request JDK-8215238: (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules In-Reply-To: <48db7228-d2c4-751e-240f-044224383424@oracle.com> References: <48db7228-d2c4-751e-240f-044224383424@oracle.com> Message-ID: +1 > On Dec 11, 2018, at 6:57 PM, Mandy Chung wrote: > > Several modules including Java EE and CORBA modules [1] and > JavaFX and a few other modules have been removed from JDK. > > jdeps maintains a list of JDK 8 internal API packages that > `jdeps -jdkinternals` can properly flag that a reference to > JDK 8 internal API that was renamed or removed while the > feature is still supported. For these removed modules, > their internal API packages should be handled as non-JDK > API and reports missing dependency if not found. The patch > is simple and the main change is to remove them from the > `jdk8_internals.txt` resource file. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8215238/webrev.00/ > > Thanks > Mandy > [1] http://openjdk.java.net/jeps/320 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From stuart.marks at oracle.com Wed Dec 12 00:38:32 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 11 Dec 2018 16:38:32 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <20181211135213.665034978@eggemoggin.niobe.net> References: <20181211135213.665034978@eggemoggin.niobe.net> Message-ID: <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> On 12/11/18 1:52 PM, mark.reinhold at oracle.com wrote: > 2018/12/11 7:03:57 -0800, adam.farley at uk.ibm.com: >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > > I can certainly see removing the f-word, and other words of a sexual > nature. Those are clearly inappropriate. > > Removing lesser words, and continuing to police their use henceforth, > strikes me as overkill. > > What do other Committers think? I think it is faintly ridiculous to consider words like "crap" and "damn" as vulgarities to be removed from source code. None of my dictionaries describe "crap" or "damn" as vulgar, while they do describe other words as vulgar. The "Where's that damn torpedo?" quote came from "Star Trek VI", which was rated PG. [1] In the MPAA rating system, PG is the second-least restrictive rating, above only the all-ages G rating. More-restrictive ratings include PG-13, R, and NC-17. [2] The word "damn" or a variant occurs about five times in that movie. [3] The MPAA takes language and swearing very seriously, with fairly strict guidelines on the number of f-bombs and their context to determine a rating of PG-13 or R. [4] Film producers will edit very carefully in order to achieve a particular rating. [5] Given that the producers of "The Martian" had to edit carefully in order to preserve its PG-13 rating, whereas "Star Trek VI" and its five "damns" sailed through with a PG rating, I think it's safe to say that the notoriously Puritan MPAA [6] doesn't concern itself with the word "damn." Neither should we. ** Adam, Starting from your patch, I've removed changes relating to "crap" and "damn" and the changes to upstream jszip.js. This leaves the patches appended below. The SoftChannel.java change is most likely a typo that should be fixed. The BitArray.java change is part of Xalan. We don't actually keep our sources in sync with Xalan, but I note that upstream [7] has made the same change, so we might as well change it too. Would you like me to sponsor this change for you? s'marks [1] https://www.imdb.com/title/tt0102975/ [2] https://filmratings.com/Tips [3] http://www.chakoteya.net/movies/movie6.html [4] https://filmratings.com/Content/Downloads/rating_rules.pdf [5] https://www.polygon.com/2015/10/22/9592366/The-martian-rating-fuck [warning, language] [6] No link, but a web search for "mpaa puritanism" will reveal an unbounded number of articles railing against the arbitrary moralizing imposed by the MPAA via its ratings system. [7] http://svn.apache.org/viewvc/xalan/java/tags/xalan-j_2_7_2/src/org/apache/xalan/xsltc/dom/BitArray.java?view=markup ** # HG changeset patch # User afarley # Date 1544574289 28800 # Tue Dec 11 16:24:49 2018 -0800 # Node ID 0c40c78b6d139eb05b0718d0b524a465419ee9cb # Parent b75a44aad06cd93c823159265a1f200bf0ce390c 8215217: OpenJDK Source Has Too Many Swear Words diff -r b75a44aad06c -r 0c40c78b6d13 src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java --- a/src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java Tue Dec 11 13:10:14 2018 -0800 +++ b/src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java Tue Dec 11 16:24:49 2018 -0800 @@ -1472,7 +1472,7 @@ } for (int controller : co_midi_nrpn_nrpn.keySet()) nrpnChange(controller, 0); - rpnChange(0, 2 << 7); // Bitch Bend sensitivity + rpnChange(0, 2 << 7); // Pitch Bend sensitivity rpnChange(1, 64 << 7); // Channel fine tunning rpnChange(2, 64 << 7); // Channel Coarse Tuning rpnChange(5, 64); // Modulation Depth, +/- 50 cent diff -r b75a44aad06c -r 0c40c78b6d13 src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/BitArray.java --- a/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/BitArray.java Tue Dec 11 13:10:14 2018 -0800 +++ b/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/BitArray.java Tue Dec 11 16:24:49 2018 -0800 @@ -133,7 +133,7 @@ * This method returns the Nth bit that is set in the bit array. The * current position is cached in the following 4 variables and will * help speed up a sequence of next() call in an index iterator. This - * method is a mess, but it is fast and it works, so don't fuck with it. + * method is a mess, but it is fast and it works, so don't change it. */ private int _pos = Integer.MAX_VALUE; private int _node = 0; From joe.darcy at oracle.com Wed Dec 12 01:32:10 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 11 Dec 2018 17:32:10 -0800 Subject: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: References: <5C09DB64.8020608@oracle.com> <3186d105-d977-4b11-4675-38f6f5357739@oracle.com> Message-ID: <5C10651A.5090703@oracle.com> Hi Andrew, Way back when JSR 269 which added the javax.lang.model API was running, we did consider having a "LATEST" enum constant that would be an alias for the most current release. In the end, we decided against this approach and use a pair of "latest" methods on the SourceVersion enum to provide analogous functionality. The use of an enum value in an annotation has to be a compile-time constant, which for enum-typed methods means the enum value has to be referred directly as an enum constant, a final or static final variable is not enough (JLS 9.7.1. Normal Annotations). Therefore, public static final CURRENT_RELEASE = SourceVersion.RELEASE_13; would *not* allow @SupportedSourceVersion(SourceVersion.CURRENT_RELEASE) to be used. Thanks, -Joe On 12/7/2018 6:18 PM, Andrew Luo wrote: > Not a reviewer - looks good anyways - however, I would if some of those constants be refactored to fewer locations? > > For example, I see many copies of: > > @SupportedSourceVersion(SourceVersion.RELEASE_13) > > Perhaps if you declare SourceVersion as: > > RELEASE_12, > RELEASE_13, > CURRENT_RELEASE = RELEASE_13; > > Then you could use: > > @SupportedSourceVersion(SourceVersion.CURRENT_RELEASE) > > Thanks, > > -Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of joe darcy > Sent: Friday, December 7, 2018 9:52 AM > To: Alan Bateman ; Core-Libs-Dev > Subject: Re: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13 > > Hi Alan, > > On 12/7/2018 12:16 AM, Alan Bateman wrote: >> On 07/12/2018 02:31, Joseph D. Darcy wrote: >>> Hello, >>> >>> With the start of JDK 13 around the corner, please review the core >>> libs portions of: >>> >>> JDK-8205626: Start of release updates for JDK 13 >>> http://cr.openjdk.java.net/~darcy/jdk13-fork.2 >>> >>> > [snip] > >> Looks okay (and the same as what we reviewed on build-dev yesterday?). >> > Yes, same changes as on build-dev (other than the update of several more TEST.ROOT files to require jtreg 4.2 b13 rather than b12.) > > I wanted to have a bit more of the testing complete before sending the core libs portion out for the review. > > Thanks, > > -Joe > From gromero at linux.vnet.ibm.com Wed Dec 12 02:07:59 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 12 Dec 2018 00:07:59 -0200 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 Message-ID: Hi Michi, On 12/11/2018 11:12 PM, Michihiro Horie wrote: > Thank you for finding the issue on Power8. You do not need a check with has_darn in the ppc.ad. It is better to add a check in vm_versoin_ppc. I agree. > I uploaded webrev.08 based on your webrev.07. (Thanks for the enhancement of opto assembly and removing trailing spaces!) > http://cr.openjdk.java.net/~mhorie/8213754/webrev.08/ Thanks for the updated webrev. Looks good! I've just pushed webrev.08 to jdk/submit expecting no failures as .07 passed fine. Once I get the jdk/submit results tomorrow I'll push. Best regards, Gustavo > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for "Gustavo Romero" ---2018/12/12 07:57:21---From: "Gustavo Romero" To: "Do"Gustavo Romero" ---2018/12/12 07:57:21---From: "Gustavo Romero" To: "Doerr, Martin" , Michihiro Horie/Japan/IBM at IBMJP > > From: "Gustavo Romero" > To: "Doerr, Martin" , Michihiro Horie/Japan/IBM at IBMJP > Cc: "core-libs-dev at openjdk.java.net" , "hotspot-compiler-dev at openjdk.java.net" , "Roger Riggs" , "Vladimir Kozlov" , "Simonis, Volker" > Date: 2018/12/12 07:57 > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > Hi Michi and Martin, > > On 12/11/2018 01:30 PM, Doerr, Martin wrote: > > thanks for updating. I think it can get shipped when Gustavo is fine with it and jdk/submit tests have passed. > > webrev.06 removed has_darn from match_rule_supported and the JVM now crashes > with SIGILL (cmprb) on CPUs <= POWER8. I think that what we want is both > UseCharacterCompareIntrinsics and has_darn in the predicate, so: > > diff -r 01b519fcb8a8 -r f3bd7a422a6c src/hotspot/cpu/ppc/ppc.ad > --- a/src/hotspot/cpu/ppc/ppc.ad ? ? ? ?Tue Dec 11 11:01:02 2018 -0500 > +++ b/src/hotspot/cpu/ppc/ppc.ad ? ? ? ?Tue Dec 11 12:29:41 2018 -0500 > @@ -2257,6 +2257,11 @@ > ? ? ?return SuperwordUseVSX; > ? ?case Op_PopCountVI: > ? ? ?return (SuperwordUseVSX && UsePopCountInstruction); > + ?case Op_Digit: > + ?case Op_LowerCase: > + ?case Op_UpperCase: > + ?case Op_Whitespace: > + ? ?return (UseCharacterCompareIntrinsics && VM_Version::has_darn()); > ? ?} > > Martin, is what you meant on your last comment about it? > > I tested the change on POWER9 and it looks good (from webrev.06 and also with > webrev.06 + the fix above)! > > I think that the Opto assembly could be improved a little bit around 'done:' > label, like: > > diff -r 89aab62d10cd src/hotspot/cpu/ppc/ppc.ad > --- a/src/hotspot/cpu/ppc/ppc.ad ? ? ? ?Tue Dec 11 12:29:41 2018 -0500 > +++ b/src/hotspot/cpu/ppc/ppc.ad ? ? ? ?Tue Dec 11 15:55:34 2018 -0500 > @@ -12440,7 +12440,8 @@ > ? ? ? ? ? ? ?"LIS ? ? $src2, (signed short)0xAAB5\n\t" > ? ? ? ? ? ? ?"ORI ? ? $src2, $src2, 0xBABA\n\t" > ? ? ? ? ? ? ?"INSRDI ?$src2, $src2, 32, 0\n\t" > - ? ? ? ? ? ?"CMPEQB ?$crx, 1, $src1, $src2\n\t" > + ? ? ? ? ? ?"CMPEQB ?$crx, 1, $src1, $src2\n" > + ? ? ? ? ? ?"done:\n\t" > ? ? ? ? ? ? ?"SETB ? ?$dst, $crx" %} > > ? ?size(48); > @@ -12484,7 +12485,8 @@ > ? ? ? ? ? ? ?"BGT ? ? $crx, done\n\t" > ? ? ? ? ? ? ?"LIS ? ? $src2, (signed short)0xD6C0\n\t" > ? ? ? ? ? ? ?"ORI ? ? $src2, $src2, 0xDED8\n\t" > - ? ? ? ? ? ?"CMPRB ? $crx, 1, $src1, $src2\n\t" > + ? ? ? ? ? ?"CMPRB ? $crx, 1, $src1, $src2\n" > + ? ? ? ? ? ?"done:\n\t" > ? ? ? ? ? ? ?"SETB ? ?$dst, $crx" %} > > so the output would be: > > 024 ? B2: # ? ? B5 B3 <- B1 ?Freq: 1 > 024 ? ? LI ? ? ?R14, 0x5A41 > ? ? ? ? CMPRB ? CCR6, 0, R3, R14 > ? ? ? ? BGT ? ? CCR6, done > ? ? ? ? LIS ? ? R14, (signed short)0xD6C0 > ? ? ? ? ORI ? ? R14, R14, 0xDED8 > ? ? ? ? CMPRB ? CCR6, 1, R3, R14 > done: > ? ? ? ? SETB ? ?R15, CCR6 > 040 ? ? CMPWI ? CCR6, R15, #0 > 044 ? ? Beq ? ? CCR6, B5 ?P=0.000000 C=5377.000000 > > instead of: > > 024 ? B2: # ? ? B5 B3 <- B1 ?Freq: 1 > 024 ? ? LI ? ? ?R14, 0x5A41 > ? ? ? ? CMPRB ? CCR6, 0, R3, R14 > ? ? ? ? BGT ? ? CCR6, done > ? ? ? ? LIS ? ? R14, (signed short)0xD6C0 > ? ? ? ? ORI ? ? R14, R14, 0xDED8 > ? ? ? ? CMPRB ? CCR6, 1, R3, R14 > ? ? ? ? SETB ? ?R15, CCR6 > 040 ? ? CMPWI ? CCR6, R15, #0 > 044 ? ? Beq ? ? CCR6, B5 ?P=0.000000 C=5379.000000 > > If nobody opposes to that tiny enhancement I would like to keep it. > > ... and a nit: several trailing spaces here and there :) > > I generated a webrev with has_darn in match_rule_supported, with the change to > the Opto asm, and with the trailing spaces removed. I uploaded it to: > > http://cr.openjdk.java.net/~gromero/8213754/webrev.07/ > > I pushed that same version to jdk/submit [1] not expecting any failure and once > I get the fine results and if you, Martin are ok with the version in webrev.07 > I'll push it to jdk/jdk. > > I'll update this thread a soon as I get the results back from jdk/submit repo. > I think we have time until Thurday 16:00 UTC, even taking into account the > 3+ different timezones working on that change :) > > Thank you and best regards, > Gustavo > > [1] http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-December/004418.html > > > Note that changes pushed before Thursday 16:00 UTC will go into jdk12. > > > > Best regards, > > > > Martin > > > > *From:*Michihiro Horie > > *Sent:* Dienstag, 11. Dezember 2018 14:08 > > *To:* Doerr, Martin > > *Cc:* core-libs-dev at openjdk.java.net; Gustavo Romero ; hotspot-compiler-dev at openjdk.java.net; Roger Riggs ; Vladimir Kozlov ; Simonis, Volker > > *Subject:* RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > > > Hi Martin, > > > > Thank you so much for your review and pointing out the issue on flag enablement on PPC64. > > > > Latest webrev enables the flag on PPC64 using has_darn in vm_version_ppc and it is used in match_rule_supported in the ad file. > > http://cr.openjdk.java.net/~mhorie/8213754/webrev.06/ ? > > > > > > Best regards, > > -- > > Michihiro, > > IBM Research - Tokyo > > > > Inactive hide details for "Doerr, Martin" ---2018/12/11 20:31:40---Hi Michihiro, the shared code looks good to me, now."Doerr, Martin" ---2018/12/11 20:31:40---Hi Michihiro, the shared code looks good to me, now. > > > > From: "Doerr, Martin" > > > To: Vladimir Kozlov >, Michihiro Horie >, Gustavo Romero > > > Cc: "core-libs-dev at openjdk.java.net " >, "hotspot-compiler-dev at openjdk.java.net " >, Roger Riggs >, "Simonis, Volker" > > > Date: 2018/12/11 20:31 > > Subject: RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > > > > > Hi Michihiro, > > > > the shared code looks good to me, now. > > > > Looks like the PPC64 is not consistent any more. > > Where do you enable UseCharacterCompareIntrinsics on PPC64? > > Why aren't you using it for match_rule_supported in the ad file? > > I think has_darn could be used to enable it in vm_version_ppc. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Vladimir Kozlov > > > Sent: Montag, 10. Dezember 2018 20:33 > > To: Michihiro Horie >; Gustavo Romero > > > Cc: core-libs-dev at openjdk.java.net ; hotspot-compiler-dev at openjdk.java.net ; Doerr, Martin >; Roger Riggs >; Simonis, Volker > > > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > > > On 12/9/18 5:28 PM, Michihiro Horie wrote: > >> Hi Vladimir, > >> > >> Thanks a lot for your review. I also fixed the copyright in intrinsicnode.hpp. > >> > >> ?>Did you look on code generated by C2 with your latest changes? > >> Yes,I usually check generated code with Oprofile and they were as expected like: > >> : > >> 90 0.0905 : 3fff64c27654: rlwinm r12,r9,24,8,31 > >> 12 0.0121 : 3fff64c27658: li r11,14640 > >> 15 0.0151 : 3fff64c2765c: cmprb cr5,0,r31,r11 > >> 5527 5.5587 : 3fff64c27660: setb r11,cr5 > >> 36010 36.2164 : 3fff64c27664: stb r11,16(r15) > > > > Good. > > > >> : > >> > >> I found a CSR FAQ that mentions adding a diagnostic flag do not need CSR process. This time I do not need CSR. > >> https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > > > Thank is correct. > > > >> > >> Hi Gustavo, > >> Could I ask you to sponsor the latest change webrev.05? I would like you to test it on your P9 node too. > > > > Thanks, > > Vladimir > > > >> > >> > >> Best regards, > >> -- > >> Michihiro, > >> IBM Research - Tokyo > >> > >> Inactive hide details for Vladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > > >> To: RogerVladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov > To: Roger Riggs > >> >, Michihiro Horie > > >> > >> From: Vladimir Kozlov > > >> To: Roger Riggs >, Michihiro Horie > > >> Cc: core-libs-dev at openjdk.java.net , hotspot-compiler-dev at openjdk.java.net , martin.doerr at sap.com , volker.simonis at sap.com > >> Date: 2018/12/08 03:48 > >> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > >> > >> ------------------------------------------------------------------------------------------------------------------------ > >> > >> > >> > >> Hi Michihiro, > >> > >> Hotspot changes looks fine. > >> Did you look on code generated by C2 with your latest changes? > >> > >> And Copyright year change in intrinsicnode.hpp is incorrect: > >> > >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > >> + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > >> > >> Should be > >> > >> * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > >> > >> > >> Thanks, > >> Vladimir > >> > >> On 12/7/18 10:08 AM, Roger Riggs wrote: > >> ?> Hi Michihiro, > >> ?> > >> ?> Looks fine with the updates. > >> ?> > >> ?> Its great that the change to isDigit is beneficial on other platforms too. > >> ?> > >> ?> A very small editorial: > >> ?> ? ?There should be a comma ?"," after the 2018 in the copyright of: > >> ?> ? ?test/micro/org/openjdk/bench/java/lang/Characters.java > >> ?> > >> ?> Thanks, Roger > >> ?> > >> ?> > >> ?> On 12/07/2018 03:13 AM, Michihiro Horie wrote: > >> ?>> > >> ?>> Hi Roger, > >> ?>> > >> ?>> I updated my webrev. > >> ?>> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ ? > >> ?>> > >> ?>> > >> ?>> >0x80 might be a good choice or 0xff. > >> ?>> I agree,thanks. > >> ?>> > >> ?>> >I was wondering about the performance without the PPC specific intrinsic but with the > >> ?>> >CharacterDataLatin1.java.template code for isDigit being: > >> ?>> > ? ? ? ?return '0' <= ch && ch <= '9'; > >> ?>> I now understand your point,thanks for your explanation. Both on Power9 and Skylake, the > >> ?>> isDigit(ch)using ?0???9?explicitly in CharacterDataLatin1.java.template without PPC specific > >> ?>> intrinsicwas around 15% faster than the original code that does not include my changes. I fixed my > >> ?>> change using ?0???9?for this isDigit(ch). > >> ?>> > >> ?>> > >> ?>> Best regards, > >> ?>> -- > >> ?>> Michihiro, > >> ?>> IBM Research - Tokyo > >> ?>> > >> ?>> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 > >> ?>> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi Michihiro, On 12/06/2018 02:38 > >> ?>> AM, Michihiro Horie wrote: > >> ?>> > >> ?>> From: Roger Riggs > > >> ?>> To: Michihiro Horie > > >> ?>> Cc: core-libs-dev at openjdk.java.net , hotspot-compiler-dev at openjdk.java.net , martin.doerr at sap.com , > >> ?>> vladimir.kozlov at oracle.com , volker.simonis at sap.com > >> ?>> Date: 2018/12/07 01:23 > >> ?>> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> > >> ?>> ---------------------------------------------------------------------------------------------------- > >> ?>> > >> ?>> > >> ?>> > >> ?>> Hi Michihiro, > >> ?>> > >> ?>> On 12/06/2018 02:38 AM, Michihiro Horie wrote: > >> ?>> > >> ?>> ? ? ? ? Hi Roger, > >> ?>> > >> ?>> ? ? ? ? Thank you for your helpful comments. I updated new webrev, adding a parameter in the jmh > >> ?>> ? ? ? ? test to measure ?other? characters and moving the file to an appropriate location, also > >> ?>> ? ? ? ? fixing the indents and copyright year._ > >> ?>> > >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.03_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=aKLGn7JZawWsl9UR7H-PyYoTpBc23BAKMqGScywbC5U&e= > >> ?>> ? ? ? ? > >> ?>> > >> ?>> The choice of 256 for other is outside the range of Latin1 which is 0..255. > >> ?>> 0x80 might be a good choice or 0xff. > >> ?>> > >> ?>> > >> ?>> ? ? ? ? >Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' > >> ?>> ? ? ? ? >in CharacterDataLatin1.java.template? ?The performance would need to be measured and > >> ?>> ? ? ? ? compared. > >> ?>> ? ? ? ? Yes, there is an opportunity: intrinsic performed 25% better than the original on Power9. > >> ?>> > >> ?>> I was wondering about the performance without the PPC specific intrinsic but with the > >> ?>> CharacterDataLatin1.java.template code for isDigit being: > >> ?>> ? ? ? ? return '0' <= ch && ch <= '9'; > >> ?>> > >> ?>> > >> ?>> ? ? ? ? >Is the profile of in-lining methods changed in any measurable way now that > >> ?>> ? ? ? ? >there is an extra level of method invocation? > >> ?>> ? ? ? ? > ? ?Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == > >> ?>> ? ? ? ? LOWERCASE_LETTER; > >> ?>> ? ? ? ? > > >> ?>> ? ? ? ? >instead of: > >> ?>> ? ? ? ? > ? ?Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > >> ?>> ? ? ? ? I missed this point, thanks. I tried jstack but could not find additional level. > >> ?>> > >> ?>> ? ? ? ? LogCompilation shows CharacterDataLatin1.isLowerCase(ch) is compiled in c1: > >> ?>> ? ? ? ? >> ?>> ? ? ? ? address='0x00003fff5911cb90' relocation_offset='344' insts_offset='368' stub_offset='1136' > >> ?>> ? ? ? ? scopes_data_offset='1248' scopes_pcs_offset='1336' dependencies_offset='1448' > >> ?>> ? ? ? ? nul_chk_table_offset='1456' oops_offset='1184' metadata_offset='1192' > >> ?>> ? ? ? ? method='java.lang.CharacterDataLatin1 isLowerCase (I)Z' bytes='15' count='1024' > >> ?>> ? ? ? ? iicount='1025' stamp='0.058'/> > >> ?>> > >> ?>> Supposing some existing complex code was already taking advantage of the full allowed inline depth. > >> ?>> Then adding an extra level might change the inlining behavior. > >> ?>> > >> ?>> > >> ?>> ? ? ? ? Existing methods in CharacterDataLatin1.java.template etc. directly invoke > >> ?>> ? ? ? ? getProperties(ch), so isLowerCase(ch) would be more aligned with other methods if it looks > >> ?>> ? ? ? ? like as follows? > >> ?>> ? ? ? ? + @HotSpotIntrinsicCandidate > >> ?>> ? ? ? ? + boolean isLowerCase(int ch) { > >> ?>> ? ? ? ? + int props = getProperties(ch); > >> ?>> ? ? ? ? + return (props & $$maskType) == Character.LOWERCASE_LETTER; > >> ?>> ? ? ? ? + } > >> ?>> > >> ?>> Yes, that would alleviate my concern. > >> ?>> > >> ?>> Thanks, Roger > >> ?>> > >> ?>> > >> ?>> > >> ?>> ? ? ? ? Best regards, > >> ?>> ? ? ? ? -- > >> ?>> ? ? ? ? Michihiro, > >> ?>> ? ? ? ? IBM Research - Tokyo > >> ?>> > >> ?>> ? ? ? ? Inactive hide details for Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On 12/05/2018 > >> ?>> ? ? ? ? 07:21 AM, Michihiro Horie wrote:Roger Riggs ---2018/12/06 05:09:36---Hi Michihiro, On > >> ?>> ? ? ? ? 12/05/2018 07:21 AM, Michihiro Horie wrote: > >> ?>> > >> ?>> ? ? ? ? From: Roger Riggs _>_ > >> ?>> ? ? ? ? To: Michihiro Horie _>_ , > >> ?>> ? ? ? ? _vladimir.kozlov at oracle.com_ > >> ?>> ? ? ? ? Cc: _core-libs-dev at openjdk.java.net_ , > >> ?>> ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ , > >> ?>> ? ? ? ? _martin.doerr at sap.com_ , _volker.simonis at sap.com_ > >> ?>> ? ? ? ? > >> ?>> ? ? ? ? Date: 2018/12/06 05:09 > >> ?>> ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ---------------------------------------------------------------------------------------------------- > >> ?>> > >> ?>> > >> ?>> > >> ?>> ? ? ? ? Hi Michihiro, > >> ?>> > >> ?>> ? ? ? ? On 12/05/2018 07:21 AM, Michihiro Horie wrote: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? >There are a few JMH tests for upper and lower in the > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? jmh-jdk-microbenchmarks repo. [1] > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Here is a jmh webrev for the Character methods._ > >> ?>> > >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_jmh-2Dwebrev.00_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=v22au5r5gvv48ufyda1poelXBjJWwuotSFrv-M2AlRY&e= > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Please include at least one > >> character value that is not a member of any of the classes. > >> ?>> ? ? ? ? The performance impact for 'other' characters is important also. > >> ?>> > >> ?>> ? ? ? ? The JMH tests have been moved to the OpenJDK jdk/jdk repo in the directory: > >> ?>> ? ? ? ? ? ?test/micro/org/openjdk/bench/java/lang/ > >> ?>> > >> ?>> ? ? ? ? Now that they are in that repo, they can be included with the rest of the changeset. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Also, I updated C2 changes in the latest webrev. (Thank you for giving > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? valuable comments off-list, Vladimir and Martin!) > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? With the change in is_disabled_by_flags, I added a JVM flag that will need > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? another review request. I would proceed for it if this RFR is accepted._ > >> ?>> > >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.02_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=UXQByb5dFxfAwCCppkizqG_-RWf6DhE_PFkr9TsyzKo&e= > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? The indent in the Java code should > >> be 4 spaces. (Native lib code is 4 spaces, Hotspot is 2 > >> ?>> ? ? ? ? spaces) > >> ?>> > >> ?>> ? ? ? ? Please update the copyrights to include 2018. > >> ?>> > >> ?>> ? ? ? ? Is there an opportunity to improve the performance of isDigit using explicit '0'.. '9' > >> ?>> ? ? ? ? in CharacterDataLatin1.java.template? ?The performance would need to be measured and compared. > >> ?>> > >> ?>> ? ? ? ? Is the profile of in-lining methods changed in any measurable way now that > >> ?>> ? ? ? ? there is an extra level of method invocation? > >> ?>> ? ? ? ? ? ? Character.isLowerCase(ch) -> CharacterData.isLowerCase(ch) -> getType(ch) == > >> ?>> ? ? ? ? LOWERCASE_LETTER; > >> ?>> > >> ?>> ? ? ? ? instead of: > >> ?>> ? ? ? ? ? ? Character.isLowerCase(ch) -> getType(ch) == LOWERCASE_LETTER; > >> ?>> > >> ?>> ? ? ? ? Regards, Roger > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? I need a review on changes in the class library, anyway. Would be grateful > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? if I could have one. > >> ?>> > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo > >> ?>> > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? ----- Original message ----- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? From: Michihiro Horie/Japan/IBM > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? To: Vladimir Kozlov _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , Roger Riggs _&g t;_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Date: Fri, Nov 30, 2018 1:01 PM > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Hi Vladimir, > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Thank you for your further comments. I fixed my code, but I?m afraid > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? discussing such a basic topic involving the two big mailing lists is not > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? good. Please let me have a chance to talk on this off-list. > >> ?>> > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? IBM Research - Tokyo > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Kozlov ---2018/11/30 03:01:42---Hi Michihiro, I still do not > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? understand which Region node you are swapping. Where it is coming from? > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? From: Vladimir Kozlov _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? To: Michihiro Horie _>_ , Roger > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Riggs _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Cc: core-libs-dev _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _volker.simonis at sap.com_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Date: 2018/11/30 03:01 > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> > >> ---------------------------------------------------------------------------------------------------- > >> ?>> > >> ?>> > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Hi Michihiro, > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? I still do not understand which Region node you are swapping. Where it is > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? coming from? > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Vladimir > >> ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? On 11/28/18 10:31 PM, Michihiro Horie wrote: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir,Roger, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Thank you so much for your responses. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Vladimir, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Regarding the hotspot change,I?m new in changing around > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? library_call.cpp,so your comments are very helpful. I will fix > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > my code,especially inline_character_compare()would be like: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > +bool LibraryCallKit::inline_character_compare(vmIntrinsics::ID id){ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* old_rgn = control()->as_Region(); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + RegionNode* new_rgn = new RegionNode(1); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + record_for_igvn(new_rgn); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + // Swap current RegionNode with new one > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* new_ctrl = old_rgn->in(1); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + old_rgn->del_req(1); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + new_rgn->add_req(new_ctrl); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + set_control(_gvn.transform(new_rgn)); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + // argument(0)is receiver > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* codePoint = argument(1); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + Node* n = NULL; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + switch (id){ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isDigit_c : n = new > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? DigitCNode(control(),codePoint);break; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isLowerCase_c : n = new > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? LowerCaseCNode(control(),codePoint);break; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isUpperCase_c : n = new > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? UpperCaseCNode(control(),codePoint);break; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + case vmIntrinsics::_isWhitespace_c : n = new > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? WhitespaceCNode(control(),codePoint);break; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + default: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + fatal_unexpected_iid(id); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + } > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + set_result(_gvn.transform(n)); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > + return true; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > +} > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Microbenchmark showed ~40% improvements. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Roger, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > I would wait foryour review,thanks. I understood the discussion had not > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? been recognized from people in core-libs-dev,and > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > checked it was not actually archived there?. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > IBM Research - Tokyo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Inactive hide details for Roger Riggs ---2018/11/29 11:21:26---Hi, I'll > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? look at it on Thursday.Roger Riggs ---2018/11/29 > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > 11:21:26---Hi, I'll look at it on Thursday. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > From: Roger Riggs _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > To: Vladimir Kozlov _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , Michihiro Horie _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _core-libs-dev at openjdk.java.net_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Cc: _volker.simonis at sap.com_ , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _hotspot-compiler-dev at openjdk.java.net_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , _martin.doerr at sap.com_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Date: 2018/11/29 11:21 > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> > >> ------------------------------------------------------------------------------------------------------------------------ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > Hi, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > I'll look at it on Thursday. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > In spite of it looking like the email was sent to core-lib-dev, I have > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > not seen it before > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > and its not in the core-libs-dev archive. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > $.02, Roger > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > On 11/28/18 7:15 PM, Vladimir Kozlov wrote: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You still need review from core-libs. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> About your hotspot changes. You need to add intrinsics to > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> is_disabled_by_flags() to be able switch them off. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Note, match_rule_supported() calls in > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> are registered. So they will not be available if they are not > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> supported. match_rule_supported() checks in > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() are not needed. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> I don't get what you code in > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> LibraryCallKit::inline_character_compare() is doing. Why you check > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Region node at the beginning and why you add Region and Phi at the end > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> if you have only one path? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> You are creating code for whole method which should return boolean result > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?boolean isDigit(int ch) { > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ? ?return getType(ch) == Character.DECIMAL_DIGIT_NUMBER; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> + ? ?} > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> but your code produce TypeInt::CHAR. why? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> An finally. Did you compare code generated by default and with you > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> changes? what improvement you see? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Thanks, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> Vladimir > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?> On 11/28/18 3:07 PM, Michihiro Horie wrote: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Is there any response from core-libs-dev? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Vladimir, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Could you give your suggestion on how to proceed? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"hotspot-compiler-dev at openjdk.java.net "_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net "_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Thu, Nov 22, 2018 11:28 AM > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Yes, we should wait for the feedback on class library change. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Btw. I think you can further simplify the code in library_call.cpp > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for pointing out it, I think I understand how to simplify > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> code. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Hi Michi, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>On 11/20/2018 02:52 PM, Michihiro Horie wrote: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> >Please note that we don?t have a machine, yet. So other people > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> will have to test. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>> I think Gustavo can help testing this change when its' ready. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Sure :) > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Gustavo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you, Gustavo. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/22 01:33:34---Hi > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, thanks. This proposal makes the javacode much"Doerr, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/22 01:33:34---Hi Michihiro, thanks. This proposal > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> makes the java code much moreintrinsics friendly. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie _>_ , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _"core-libs-dev at openjdk.java.net "_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: _"hotspot-compiler-dev at openjdk.java.net "_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ > >> ?>> ? ? ? , "Simonis, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Volker"_>_ , > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Gustavo Romero > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/22 01:33 > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> > >> ------------------------------------------------------------------------------------------------------------------------ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> thanks. This proposal makes the java code much more intrinsics friendly. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> We should wait for feedback from the core lib folks. Maybe they have > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> some requirements or other proposals. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think these intrinsics should be interesting for Oracle, Intel and > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> others, too. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Btw. I think you can further simplify the code in library_call.cpp > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> (no phi). But we can discuss details when thedirection regarding the > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> java classes is clear. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie _>_ * > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Mittwoch, 21. November 2018 17:14* > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*core-libs-dev at openjdk.java.net; Doerr, Martin > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ * > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*hotspot-compiler-dev at openjdk.java.net; Simonis, Volker > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> _>_ ; Gustavo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? Romero_>_ * > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RE: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I send this RFR to core-libs-dev too, because it changes the class > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> library. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Through trial and error, I separated Latin1 block as in the _ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ___https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.01-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=co8xQFD19i2JBuYtSh2KKr-qUmwPdt6MEpJErzBfsd0&e= > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.01-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=w78kALiRtp6DIYAfslpK_TGpubqajF0h32O_z_ITAF4&e=>_/_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I followed the coding way of Character.isWhitespace() that invokes > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> each ChracterData?s isWhitespace() to refactorisDigit(), > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase(), and isUpperCase(). > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think this change is also useful on x86, using STTNI. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ----- Original message ----- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Michihiro Horie" <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_ >> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Sent by: "hotspot-compiler-dev" > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> > >> <_hotspot-compiler-dev-bounces at openjdk.java.net_<_mailto:hotspot-compiler-dev-bounces at openjdk.java.net_ >> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: "Doerr, Martin" <_martin.doerr at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_> " > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_ >>, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_> " > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_ >> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: Wed, Nov 21, 2018 1:53 AM > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Martin, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thank you for giving your helpful comments. I did not recognize > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static? prevents anyoptimizations, but I now > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> checked it actually degraded the performance, thanks. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Please note that we don?t have a machine, yet. So other people will > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> have to test. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think Gustavo can help testing this change when its' ready. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Would it be possible to introduce more fine-grained intrinsics such > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>Maybe you can factor out as in the following example? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>if (latin1) return isLatin1Digit(codePoint); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?>with isLatin1Digit as HotSpotIntrinsicCandidate. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Thanks for an example, please let me try to separate the Latin block > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> from other blocks for some time. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Inactive hide details for "Doerr, Martin" ---2018/11/20 01:55:27---Hi > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, first of all, thanks for working onPower9 opt"Doerr, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin" ---2018/11/20 01:55:27---Hi Michihiro, first of all, thanks > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for working on Power9optimizations. Please note that we don't ha > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> From: "Doerr, Martin" <_martin.doerr at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> To: Michihiro Horie <_HORIE at jp.ibm.com_ <_mailto:HORIE at jp.ibm.com_ >>, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_> " > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_hotspot-compiler-dev at openjdk.java.net_<_mailto:hotspot-compiler-dev at openjdk.java.net_ >>, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? "_ppc-aix-port-dev at openjdk.java.net_<_mailto:ppc-aix-port-dev at openjdk.java.net_> " > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_ppc-aix-port-dev at openjdk.java.net_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Cc: "Simonis, Volker" <_volker.simonis at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:volker.simonis at sap.com_>>, "Lindenmaier, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Goetz"<_goetz.lindenmaier at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>, Gustavo Romero > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_<_mailto:gromero at linux.vnet.ibm.com_ >> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Date: 2018/11/20 01:55 > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Subject: RE: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> > >> ------------------------------------------------------------------------------------------------------------------------ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Hi Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first of all, thanks for working on Power9 optimizations. Please note > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that we don?t have a machine, yet. So other peoplewill have to test. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I think it may be problematic to insert a slow path by > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> ?generate_method_call_static?. This may be a performancedisadvantage > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> for some users of other encodings because your intrinsics prevent > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> inlining and further optimizations. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would it be possible to introduce more fine-grained intrinsics such > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> that the ?slow? path is outside of them? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Maybe you can factor out as in the following example? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> if (latin1) return isLatin1Digit(codePoint); > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> with isLatin1Digit as HotSpotIntrinsicCandidate. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> I can?t judge if this is needed, but I think this should be discussed > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> first before going into the details. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Martin > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> * > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **From:*Michihiro Horie <_HORIE at jp.ibm.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:HORIE at jp.ibm.com_>>* > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Sent:*Freitag, 16. November 2018 12:53* > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **To:*_hotspot-compiler-dev at openjdk.java.net_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? <_mailto:hotspot-compiler-dev at openjdk.java.net_>;_ppc-aix-port-dev at openjdk.java.net_ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:ppc-aix-port-dev at openjdk.java.net_>* > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Cc:*Doerr, Martin <_martin.doerr at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:martin.doerr at sap.com_>>; Simonis, Volker > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_volker.simonis at sap.com_<_mailto:volker.simonis at sap.com_ >>; > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Lindenmaier, Goetz <_goetz.lindenmaier at sap.com_ > > > ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_mailto:goetz.lindenmaier at sap.com_>>;Gustavo Romero > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> <_gromero at linux.vnet.ibm.com_ <_mailto:gromero at linux.vnet.ibm.com_ >>* > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> **Subject:*RFR: 8213754: PPC64: Add Intrinsics for > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isDigit/isLowerCase/isUpperCase/isWhitespace > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Dear all, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Would you please review following change? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Bug: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> __https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213754-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=yTUTl4D2EPdboqkkAHXYtHx5KijWhAzXOXPBqwME0iQ&e= > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Webrev: > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> __https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8213754_webrev.00-5F-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=88Ms75RO8511eAgWMsvWrTDLmRRcxcKiEs_DkSZmVlc&e= > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> <_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Emhorie_8213754_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=sNklBozv1ZztDu7rnM5SUgqTwPn4CPlp4Gp0uGwfVhs&s=zZl2pxTY0Dn-5RZHkTZSnIRpYzb-w9T_4d8cV7gU3iw&e=> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> This change includes the intrinsics of Character isDigit, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> isLowerCase, isUpperCase, and isWhitespace to support theLatin1 block > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> using POWER9?s instructions cmprb and cmpeqb. The cmprb enables to > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compare a character with 1 or 2 rangedbytes, while the cmpeqb > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> compares one with 1 to 8 values. Simple micro benchmark attached > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> showed improvements by 20-40%. > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> / > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> //(See attached file: Latin1Test.java)/ > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Best regards, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> -- > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> Michihiro, > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> IBM Research - Tokyo > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > ?>> > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> ? ? ? ? ? ? ? ? ? ? ? ? > > >> ?>> > >> ?>> > >> ?>> > >> ?>> > >> ?>> > >> ?>> > >> ?> > >> > >> > >> > >> > > > > > > > > > From stuart.marks at oracle.com Wed Dec 12 02:35:31 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 11 Dec 2018 18:35:31 -0800 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <01C3CC6C-F645-40E3-A9FD-04017843F6F1@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> <01C3CC6C-F645-40E3-A9FD-04017843F6F1@oracle.com> Message-ID: <33d0efad-60d8-4f41-f741-dcbc44b38da0@oracle.com> On 12/11/18 1:21 PM, Vincent Ryan wrote: > My preference is for PrintStream rather than Writer, for the same reason as > Roger: it?s more convenient > for handling System.out. Does that address your concern? PrintStream is fine with me. > I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte > charset so some 0x8X characters > Will trigger the multi-byte sequence and will end up being misinterpreted. Hence > my rather awkward conversion to a String. > Is there a better way? In toPrintableString(), 259 StringBuilder printable = new StringBuilder(toIndex - fromIndex); 260 for (int i = fromIndex; i < toIndex; i++) { 261 if (bytes[i] > 0x1F && bytes[i] < 0x7F) { 262 printable.append((char) bytes[i]); 263 } else if (bytes[i] > (byte)0x9F && bytes[i] <= (byte)0xFF) { 264 printable.append(new String(new byte[]{bytes[i]}, ISO_8859_1)); 265 266 } else { 267 printable.append('.'); 268 } 269 } It works to cast ASCII bytes char, because the 7-bit ASCII range overlaps the low 7 bits of the UTF-16 char range. The bytes values of ISO 8859-1 overlap the low 8 bits of UTF-16, so casts work for them too. For any other charset, you'd need to do codeset conversion. But you're cleverly supporting only ISO 8859-1, so you don't have to do any conversion. :-) > I?m not sure I?ve addressed your concern regarding IOExceptions - can you elaborate? Taking out the OutputStream overloads addressed my concerns. In at least one case the code would wrap the OutputStream into a PrintStream, print stuff to it, and then throw away the PrintStream. If an output error occurred, any error state in the PrintStream would also be thrown away. The creation of the PrintStream wrapper would also use the system's default charset instead of letting the caller control it. The dump() overloads now all take PrintStream, so it's the caller's responsibility to ensure that the PrintStream is using the right charset and to check for errors after. So this is all OK now. Note that the internal getPrintStream(), to wrap an OutputStream in a PrintStream, is now obsolete and can be removed. (Oh, I see Roger has said much the same things. Oh well, the peril of parallel reviews.) ** > BTW updated webrev/javadoc available: > http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ > http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html Now we have a somewhat unsatisfying asymmetry in the APIs. There are four kinds of inputs: 1. byte[] 2. byte[] subrange 3. InputStream 4. ByteBuffer and two kinds of outputs: 1. PrintStream 2. Stream and two variations of formatters: 1. default formatter 2. custom formatter + chunk size This is a total of 16 combinations. But there are only eight methods: three PrintStream methods with choice of input, two stream-output methods using the default formatter, and three stream-output methods using custom chunk+formatter. You don't have to provide ALL combinations, but what's here is an odd subset with some apparently arbitrary choices. For example, if I have a ByteBuffer and I want to dump it to System.out using default formatting, I have to go the Stream.forEachOrdered route AND provide the default chunk size and formatter. HexFormat.dumpAsStream(buf, DEFAULT_CHUNK_SIZE, HEXDUMP_FORMATTER) .forEachOrdered(System.out::println); These aren't huge deals, but they're easily stumbled over. One approach to organizing this is to have a HexFormat instance that contains the setup information and then to have instance methods that either update the setup or perform conversion and output. I'd use static factory methods instead of constructors. For example, you could do this: static factories methods: - from(byte[]) - from(byte[], fromIndex, toIndex) - from(InputStream) - from(ByteBuffer) formatter setup instance methods: - format(chunksize, formatter) output: - void dump(PrintStream) - Stream stream() Using this approach my example from above could be performed as follows: HexFormat.from(buf).dump(System.out); Note, I'm not saying that you HAVE to do it this way. (In particular, the naming could use work.) This is quite possibly overkill. But it's something you might consider, as it gets you all 16 combinations using seven methods, compared to the eight static methods in the current proposal that cover only half of the combinations. Alternatively, pare down the set of static methods to a bare minimum. Provide one that can do everything, and then provide one or two more that are essentially the same as the first but with some hardwired defaults. For example, to help minimize things, you can wrap a ByteBuffer around a byte array subrange, or get an InputStream from a byte array subrange. But you can't get an InputStream from a ByteBuffer or vice-versa, without a lot of work. (I haven't looked at the to* or from* methods.) s'marks From martinrb at google.com Wed Dec 12 02:55:26 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Dec 2018 18:55:26 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: Hi Michal, pleased to meet you. I'll be your sponsor. The test will need a legal header, presumably similar to others authored by redhatters. It is now possible to check in jmh microbenchmarks (but I've never done so myself). The current coding style is non-standard, but deliberate; avoid gratuitous changes like - Node e; + Node e; As author of concurrent/ConcurrentHashMap/WhiteBox.java ... - I thought you'd need a @modules ... did this test actually pass? - you should have some kind of @summary that includes the word "whitebox" - why not "throws ReflectiveOperationException" ? - your reviewer is a bit on the autistic side, so please change /** to /* on the @test comment (it's not javadoc!) On Tue, Dec 11, 2018 at 11:06 AM Michal Vala wrote: > Hi, > > I've been looking into this bug in HashMap where resize() is called > multiple > times when putting whole map into another. > > I come up with following patch: > http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ > > I've tried to do it as little invasive as possible. New resize(int) method > is > called just from putMapEntries for now. Notice that method is called with > size > of the new map. I was experimenting with calling it with 'size()+s', but > this > leads to unwanted space allocation when inserted map rewrites a lot of > existing > keys. > > I've benchmarked this with adding 10millions elements into existing map > and it > gets ~50% improvement: > > unpatched > Benchmark Mode Cnt Score Error Units > MyBenchmark.testMethod thrpt 10 1.248 ? 0.058 ops/s > > patched > Benchmark Mode Cnt Score Error Units > MyBenchmark.testMethod thrpt 10 1.872 ? 0.109 ops/s > > public class MyBenchmark { > static Map mapTocopy = IntStream.range(1, > 10_000_000).boxed().collect(Collectors.toMap(k -> k, > k -> k)); > > @Benchmark > public int testMethod() { > var map = new HashMap(); > map.put(-5, -5); > map.putAll(mapTocopy); > return map.size(); > } > } > > Any ideas for missed corner-cases or some good tests? > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > From orionllmain at gmail.com Wed Dec 12 03:06:59 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Wed, 12 Dec 2018 10:06:59 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: Hi Sergey. `n` and `element` are final fields. Extracting it into local vars will not make any difference. ??, 12 ???. 2018 ?. ? 02:25, ?????? ??????? : > Hi Zheka and Tagir, > > @Override > public void forEach(final Consumer action) { > Objects.requireNonNull(action); > for (int i = 0; i < this.n; i++) { > action.accept(this.element); > } > } > > I think here we should extract this.element and this.n into a local vars, > as Consumer may have interaction with volatile field inside (e.g. > AtomicInteger::addAndGet) which would cause a load of consumed field at > each iteration. See original post by Nitsan Wakart > https://psy-lob-saw.blogspot.com/2014/08/the-volatile-read-suprise.html > > Regards, > Sergey Tsypanov > > > 07.12.2018, 15:22, "Zheka Kozlov" : > > What about forEach()? > > > > @Override > > public void forEach(final Consumer action) { > > Objects.requireNonNull(action); > > for (int i = 0; i < this.n; i++) { > > action.accept(this.element); > > } > > } > > > > I think this version has better chances to be faster than the default > > implementation (did not measure though). > > > > ??, 4 ???. 2018 ?. ? 14:40, Tagir Valeev : > > > >> Hello! > >> > >> > In CopiesList.equals() please use eq() instead of Objects.equal() > (see a > >> comment at the line 5345). > >> > >> Ok > >> > >> > I think you should use iterator() instead of listIterator(). See the > >> explanation here: > >> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html > >> > >> Ok. I wonder why this message received no attention. > >> > >> Here's updated webrev: > >> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r3/ > >> > >> With best regards, > >> Tagir Valeev > >> On Tue, Dec 4, 2018 at 1:10 PM Zheka Kozlov > wrote: > >> > > >> > I think you should use iterator() instead of listIterator(). See the > >> explanation here: > >> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html > >> > > >> > ??, 4 ???. 2018 ?. ? 12:23, Tagir Valeev : > >> >> > >> >> Hello! > >> >> > >> >> Thank you for your comments! > >> >> > >> >> Yes, deserialization will be broken if we assume that size is never > 0. > >> >> Also we'll introduce referential identity Collections.nCopies(0, x) > == > >> >> Collections.nCopies(0, y) which might introduce slight semantics > >> >> change in existing programs. Once I suggested to wire > Arrays.asList() > >> >> (with no args) to Collections.emptyList(), but it was rejected for > the > >> >> same reason: no need to introduce a risk of possible semantics > change. > >> >> > >> >> I updated webrev with equals implementation and test: > >> >> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/ > >> >> Comparing two CopiesList is much faster now indeed. Also we can > spare > >> >> an iterator in the common case and hoist the null-check out of the > >> >> loop. Not sure whether we can rely that JIT will always do this for > >> >> us, but if you think that it's unnecessary, I can merge the loops > >> >> back. Note that now copiesList.equals(arrayList) could be faster > than > >> >> arrayList.equals(copiesList). I don't think it's an issue. On the > >> >> other hand we could keep simpler and delegate to > super-implementation > >> >> if the other object is not a CopiesList (like it's implemented in > >> >> java.util.RegularEnumSet::equals for example). What do you think? > >> >> > >> >> With best regards, > >> >> Tagir Valeev. > >> >> On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks < > stuart.marks at oracle.com> > >> wrote: > >> >> > > >> >> > > >> >> > >> I believe it makes sense to override CopiesList.equals() > >> >> > > Also: contains(), iterator(), listIterator() > >> >> > > >> >> > equals(): sure > >> >> > > >> >> > contains() is already overridden. Not sure there's much benefit to > >> overriding > >> >> > the iterators. > >> >> > > >> >> > s'marks > From roger.riggs at oracle.com Wed Dec 12 03:45:52 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2018 22:45:52 -0500 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: Hi, fyi, jmh tests appropriate for JDK apis are located in the test/micro/... directories. The benchmarks are built with: ? % make build-microbenchmark The results are in the build//images/test/micro/benchmarks.jar $.02, Roger On 12/11/2018 A 9:55 PM, Martin Buchholz wrote: > Hi Michal, pleased to meet you. I'll be your sponsor. > > The test will need a legal header, presumably similar to others authored by > redhatters. > > It is now possible to check in jmh microbenchmarks (but I've never done so > myself). > > The current coding style is non-standard, but deliberate; avoid gratuitous > changes like > - Node e; > + Node e; > > As author of concurrent/ConcurrentHashMap/WhiteBox.java ... > - I thought you'd need a @modules ... did this test actually pass? > - you should have some kind of @summary that includes the word "whitebox" > - why not "throws ReflectiveOperationException" ? > - your reviewer is a bit on the autistic side, so please change /** to /* > on the @test comment (it's not javadoc!) > > > On Tue, Dec 11, 2018 at 11:06 AM Michal Vala wrote: > >> Hi, >> >> I've been looking into this bug in HashMap where resize() is called >> multiple >> times when putting whole map into another. >> >> I come up with following patch: >> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ >> >> I've tried to do it as little invasive as possible. New resize(int) method >> is >> called just from putMapEntries for now. Notice that method is called with >> size >> of the new map. I was experimenting with calling it with 'size()+s', but >> this >> leads to unwanted space allocation when inserted map rewrites a lot of >> existing >> keys. >> >> I've benchmarked this with adding 10millions elements into existing map >> and it >> gets ~50% improvement: >> >> unpatched >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testMethod thrpt 10 1.248 ? 0.058 ops/s >> >> patched >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testMethod thrpt 10 1.872 ? 0.109 ops/s >> >> public class MyBenchmark { >> static Map mapTocopy = IntStream.range(1, >> 10_000_000).boxed().collect(Collectors.toMap(k -> k, >> k -> k)); >> >> @Benchmark >> public int testMethod() { >> var map = new HashMap(); >> map.put(-5, -5); >> map.putAll(mapTocopy); >> return map.size(); >> } >> } >> >> Any ideas for missed corner-cases or some good tests? >> >> -- >> Michal Vala >> OpenJDK QE >> Red Hat Czech >> From martinrb at google.com Wed Dec 12 04:01:55 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Dec 2018 20:01:55 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: > > In performance critical code, we don't trust hotspot to not reload final > fields. Other forEach methods do this, e.g. final Object[] es = queue; for (int i = 0, n = size; i < n; i++) action.accept((E) es[i]); From orionllmain at gmail.com Wed Dec 12 04:13:48 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Wed, 12 Dec 2018 11:13:48 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: Would be better to add @Stable to the fields instead? (`n` and `element` are final, so @Stable is OK here) ??, 12 ???. 2018 ?. ? 11:02, Martin Buchholz : > In performance critical code, we don't trust hotspot to not reload final >> fields. Other forEach methods do this, e.g. > > > final Object[] es = queue; > for (int i = 0, n = size; i < n; i++) > action.accept((E) es[i]); > > From martinrb at google.com Wed Dec 12 04:25:26 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Dec 2018 20:25:26 -0800 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: I used to believe that, but apparently I was wrong. https://openjdk.markmail.org/thread/rfqfultw35i2az45 On Tue, Dec 11, 2018 at 8:14 PM Zheka Kozlov wrote: > Would be better to add @Stable to the fields instead? (`n` and `element` > are final, so @Stable is OK here) > > ??, 12 ???. 2018 ?. ? 11:02, Martin Buchholz : > >> In performance critical code, we don't trust hotspot to not reload final >>> fields. Other forEach methods do this, e.g. >> >> >> final Object[] es = queue; >> for (int i = 0, n = size; i < n; i++) >> action.accept((E) es[i]); >> >> > From martin.doerr at sap.com Wed Dec 12 07:10:24 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 Dec 2018 07:10:24 +0000 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 Message-ID: <5fb47698991649b1914cb8b134a57770@sap.com> Hi Gustavo, thanks for your improvements. You can also remove the trailing \t from the opto assembly. Note that there's no need to re-push newer version to jdk/submit when only PPC files were changed. jdk/submit doesn't look at them. Best regards, Martin -----Original Message----- From: Gustavo Romero Sent: Mittwoch, 12. Dezember 2018 03:08 To: Michihiro Horie Cc: core-libs-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; Doerr, Martin ; Roger Riggs ; Vladimir Kozlov ; Simonis, Volker Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace Hi Michi, On 12/11/2018 11:12 PM, Michihiro Horie wrote: > Thank you for finding the issue on Power8. You do not need a check with has_darn in the ppc.ad. It is better to add a check in vm_versoin_ppc. I agree. > I uploaded webrev.08 based on your webrev.07. (Thanks for the enhancement of opto assembly and removing trailing spaces!) > http://cr.openjdk.java.net/~mhorie/8213754/webrev.08/ Thanks for the updated webrev. Looks good! I've just pushed webrev.08 to jdk/submit expecting no failures as .07 passed fine. Once I get the jdk/submit results tomorrow I'll push. Best regards, Gustavo From volker.simonis at gmail.com Wed Dec 12 07:44:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 12 Dec 2018 08:44:56 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> Message-ID: On Tue, Dec 11, 2018 at 11:47 PM David Holmes wrote: > > On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: > > > > > > On 2018-12-11 00:23, David Holmes wrote: > >> Hi Magnus, > >> > >> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >>> I propose that we introduce a new define, available to all JDK native > >>> files (Hotspot included), called JDK_EXPORT. The behavior of this > >>> symbol will be very similar (as of now, in fact identical) to > >>> JNIEXPORT; however, the semantics will not. > >>> > >>> Currently, we "mis-use" the JNIEXPORT define to mark a function for > >>> exporting from the library. The problem with this is that JNIEXPORT > >>> is part of the JNI interface, and is supposed to be used when C > >>> programs interact with Java. And, when doing this, the function > >>> should be fully decorated like this: "JNIEXPORT foo JNICALL". > >> > >> I've seen a lot of the emails on this issue and I don't fully > >> understand what has been going wrong. But the intent is obviously the > >> JNIEXPORT represents what is needed to export this function for use by > >> JNI, while JNICALL defines the calling convention. I agree there may > >> be some mistmatch when functions are actually not intended for general > >> export outside the JDK but are only for internal JDK use. > >> > >>> We do have many such JNI exports in our native libraries, but we also > >>> have a lot of other, non-JNI exports, where one native library just > >>> provides an interface to other libraries. In these cases, we have > >>> still used JNIEXPORT for the functionality of getting the function > >>> exported, but we have not been consistent in our use of JNICALL. This > >>> has caused us way too much trouble for something that should Just > >>> Work. > >> > >> Are you suggesting that the interface between different libraries in > >> the JDK should not be a JNI interface? Is this because you think the > >> functions in these libraries are only for JDK internal use or ... ?? > >> > >>> I therefore propose that we define "JDK_EXPORT", with the same > >>> behavior as JNIEXPORT (that is, flagging the function for external > >>> visibility in the resulting native library), but which is *not* > >>> supposed to be exported to Java code using JNI, nor supposed to be > >>> decorated with > >> > >> Just a clarification there. JNI functions are not exported to Java > >> code, they are exported to native code. Java code can declare native > >> methods and those native methods must be written as JNI functions, but > >> that's not what we are discussing. Libraries expose a JNI interface (a > >> set of functions in the library) that can be called by application > >> native code, using JNI. > > We're apparently looking at "JNI" and "exporting" from two opposite > > sides here. :-) Just to make everything clear: If I have a Java class > > class MyClass { > > public static void native myNativeFunc(); > > } > > > > then I have one half of the JNI function, the Java half. This must be > > matched by a corresponding implementation in native, like this: > > JNIEXPORT void JNICALL > > Java_MyClass_myNativeFunc(void) { > > // ... do stuff > > } > > > > And this is the native half of the JNI function. Right? Let's leave > > aside which side is "exporting" to the other for now. :-) > > > > This way of setting up native functions that can be called from Java is > > what I refer to as JNI. And when you declare a native JNI function, you > > *must* use both JNIEXPORT and JNICALL. Alright? > > > > We do have a lot of those functions in our native libraries. And they > > are correct just the way they are. > > Yep all well and good. A function declared native in Java must have an > implementation as you describe. But not all native functions exist to > provide the native-half of a Java native function! > > > However, we also have *other* native functions, that are exported, not > > as JNI functions that should be called from Java, but as normal native > > library functions that should be called by other native code. Okay so > > far? And *those* functions have been problematic in how we decorate > > But there are again two cases. Those functions exported from a library > that are expected to be called from external code using the JNI > interface mechanism - such as all the JNI functions and JVM TI functions > we export from the JVM - and those "exported" for access between > libraries within the JDK (such as all the JVM_* functions in libjvm). > > I think it is only the second group that should be addressed by your > JDK_EXPORT proposal - though I'm not completely clear exactly how to > identify them. > > > them. My proposal is that we *refrain* from using JNIEXPORT for those > > functions, and instead use JDK_EXPORT as name for the macro that > > decorates them as exported. That way, we can clearly see that a function > > like this: > > > > JDK_EXPORT void > > JLI_ReadEnv(char* env); > > > > is correctly declared, and will be exported to other native libraries, > > but not to Java. > > The issue is not whether it is "exported to Java"** but whether it is > exported using the JNI mechanism such that other native code calls it > using the JNI mechanism. > > ** There is no way to write a native method declaration in Java such > that it would be linked to the JLI_ReadEnv function. The naming is all > wrong, as is the signature. > But that's exactly what this change is about! Remove the usage of JNIEXPORT from functions which are NOT exported using the JNI mechanism. What don't you like about it ? > > Just to clarify, this has nothing to do with if this is a officially > > supported API or not. In general though, I assume that most (if not > > all?) of our exported functions (apart from the JNI_* stuff) is supposed > > to be consumed by other libraries in the JDK, and is not a public API. > > I think it varies library by library. You may need native application > code that can call directly into native JDK libraries. JLI is the Java > Launcher Interface - I think it was introduced to make it easier for > other launchers to be created. Native agents may need access to > libmanagement or libjdwp functions. Native graphics code may need access > to the JDK graphics library. Some of these accesses may be unsupported > and undocumented, but I don't think you can just cut them all off. > Nobody wants to cut off anything. Magnus only proposes to decorate these required functions with the new JDK_EXPORT macro (instead of JNIEXPORT) in order to make it clear that they are not exported by using the JNI mechanism (but they will still be exported, technically speaking, JDK_EXPORT will even resolve to the exact same function modifiers!). > David > > > > > /Magnus > > > > > > > >> > >>> JNICALL. All current instances of JNIEXPORT which is not pure JNI > >>> native functions should be changed to use JDK_EXPORT instead. > >>> > >>> I further propose that this macro should reside in a new file > >>> "jdk.h", placed in the new directory > >>> src/java.base/share/native/include/internal. This header file path > >>> will automatically be provided to all native libraries, but not > >>> copied to the JDK being built. (The existence of a "include/internal" > >>> directory with this behavior has been discussed before. There are > >>> more files that ought to be moved there, if/when it is created.) I > >>> believe in many cases the #include "jni.h" can be just modified to > >>> #include "#jdk.h", since most native code will not require "jni.h" > >>> unless actually doing JNI calls -- most have included this file to > >>> get the JNIEXPORT macro, which would explain the pervasive use of > >>> #include "jni.h" in our code base. > >> > >> jni.h also defines all of the types used by the JNI. Those types are > >> pervsive to the native code used throughout the JDK. > >> > >>> Thoughts? > >> > >> I think we need to understand the problems on Windows that prompted > >> all this. Then I think we need to look at exactly how jni.h and > >> JNIEXPORT etc are being used and understand whether this is truly an > >> exported interface or not. > >> > >> Cheers, > >> David > >> > >>> /Magnus > >>> > > From Alan.Bateman at oracle.com Wed Dec 12 07:46:08 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 07:46:08 +0000 Subject: Review Request JDK-8215238: (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules In-Reply-To: <48db7228-d2c4-751e-240f-044224383424@oracle.com> References: <48db7228-d2c4-751e-240f-044224383424@oracle.com> Message-ID: <51dabcfd-8719-e412-cfb5-c831ee966305@oracle.com> On 11/12/2018 23:57, Mandy Chung wrote: > Several modules including Java EE and CORBA modules [1] and > JavaFX and a few other modules have been removed from JDK. > > jdeps maintains a list of JDK 8 internal API packages that > `jdeps -jdkinternals` can properly flag that a reference to > JDK 8 internal API that was renamed or removed while the > feature is still supported.? For these removed modules, > their internal API packages should be handled as non-JDK > API and reports missing dependency if not found.? The patch > is simple and the main change is to remove them from the > `jdk8_internals.txt` resource file. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8215238/webrev.00/ Looks good. From david.holmes at oracle.com Wed Dec 12 08:40:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 18:40:02 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> Message-ID: <1d74b9d1-e467-674f-7170-48b48c943a4e@oracle.com> On 12/12/2018 5:44 pm, Volker Simonis wrote: > On Tue, Dec 11, 2018 at 11:47 PM David Holmes wrote: >> >> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 00:23, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>> I propose that we introduce a new define, available to all JDK native >>>>> files (Hotspot included), called JDK_EXPORT. The behavior of this >>>>> symbol will be very similar (as of now, in fact identical) to >>>>> JNIEXPORT; however, the semantics will not. >>>>> >>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>>> exporting from the library. The problem with this is that JNIEXPORT >>>>> is part of the JNI interface, and is supposed to be used when C >>>>> programs interact with Java. And, when doing this, the function >>>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>>> >>>> I've seen a lot of the emails on this issue and I don't fully >>>> understand what has been going wrong. But the intent is obviously the >>>> JNIEXPORT represents what is needed to export this function for use by >>>> JNI, while JNICALL defines the calling convention. I agree there may >>>> be some mistmatch when functions are actually not intended for general >>>> export outside the JDK but are only for internal JDK use. >>>> >>>>> We do have many such JNI exports in our native libraries, but we also >>>>> have a lot of other, non-JNI exports, where one native library just >>>>> provides an interface to other libraries. In these cases, we have >>>>> still used JNIEXPORT for the functionality of getting the function >>>>> exported, but we have not been consistent in our use of JNICALL. This >>>>> has caused us way too much trouble for something that should Just >>>>> Work. >>>> >>>> Are you suggesting that the interface between different libraries in >>>> the JDK should not be a JNI interface? Is this because you think the >>>> functions in these libraries are only for JDK internal use or ... ?? >>>> >>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>> behavior as JNIEXPORT (that is, flagging the function for external >>>>> visibility in the resulting native library), but which is *not* >>>>> supposed to be exported to Java code using JNI, nor supposed to be >>>>> decorated with >>>> >>>> Just a clarification there. JNI functions are not exported to Java >>>> code, they are exported to native code. Java code can declare native >>>> methods and those native methods must be written as JNI functions, but >>>> that's not what we are discussing. Libraries expose a JNI interface (a >>>> set of functions in the library) that can be called by application >>>> native code, using JNI. >>> We're apparently looking at "JNI" and "exporting" from two opposite >>> sides here. :-) Just to make everything clear: If I have a Java class >>> class MyClass { >>> public static void native myNativeFunc(); >>> } >>> >>> then I have one half of the JNI function, the Java half. This must be >>> matched by a corresponding implementation in native, like this: >>> JNIEXPORT void JNICALL >>> Java_MyClass_myNativeFunc(void) { >>> // ... do stuff >>> } >>> >>> And this is the native half of the JNI function. Right? Let's leave >>> aside which side is "exporting" to the other for now. :-) >>> >>> This way of setting up native functions that can be called from Java is >>> what I refer to as JNI. And when you declare a native JNI function, you >>> *must* use both JNIEXPORT and JNICALL. Alright? >>> >>> We do have a lot of those functions in our native libraries. And they >>> are correct just the way they are. >> >> Yep all well and good. A function declared native in Java must have an >> implementation as you describe. But not all native functions exist to >> provide the native-half of a Java native function! >> >>> However, we also have *other* native functions, that are exported, not >>> as JNI functions that should be called from Java, but as normal native >>> library functions that should be called by other native code. Okay so >>> far? And *those* functions have been problematic in how we decorate >> >> But there are again two cases. Those functions exported from a library >> that are expected to be called from external code using the JNI >> interface mechanism - such as all the JNI functions and JVM TI functions >> we export from the JVM - and those "exported" for access between >> libraries within the JDK (such as all the JVM_* functions in libjvm). >> >> I think it is only the second group that should be addressed by your >> JDK_EXPORT proposal - though I'm not completely clear exactly how to >> identify them. >> >>> them. My proposal is that we *refrain* from using JNIEXPORT for those >>> functions, and instead use JDK_EXPORT as name for the macro that >>> decorates them as exported. That way, we can clearly see that a function >>> like this: >>> >>> JDK_EXPORT void >>> JLI_ReadEnv(char* env); >>> >>> is correctly declared, and will be exported to other native libraries, >>> but not to Java. >> >> The issue is not whether it is "exported to Java"** but whether it is >> exported using the JNI mechanism such that other native code calls it >> using the JNI mechanism. >> >> ** There is no way to write a native method declaration in Java such >> that it would be linked to the JLI_ReadEnv function. The naming is all >> wrong, as is the signature. >> > > But that's exactly what this change is about! Remove the usage of > JNIEXPORT from functions which are NOT exported using the JNI > mechanism. What don't you like about it ? I'm just saying we need to be clear about what functions we plan on changing. Taking concrete examples as I don't see JLI_Read anywhere, we have: JNIEXPORT void JNICALL JLI_ReportErrorMessage(const char* fmt, ...) { JNIEXPORT void JNICALL JLI_ReportErrorMessageSys(const char* fmt, ...) { JNIEXPORT void JNICALL JLI_ReportExceptionDescription(JNIEnv * env) { JNIEXPORT StdArg JNICALL *JLI_GetStdArgs() { JNIEXPORT int JNICALL JLI_GetStdArgc() { return 0; } which seems to define the exported interface for (part of) libJLI and establishes both the export status and the expected calling convention. Would these be changed? >>> Just to clarify, this has nothing to do with if this is a officially >>> supported API or not. In general though, I assume that most (if not >>> all?) of our exported functions (apart from the JNI_* stuff) is supposed >>> to be consumed by other libraries in the JDK, and is not a public API. >> >> I think it varies library by library. You may need native application >> code that can call directly into native JDK libraries. JLI is the Java >> Launcher Interface - I think it was introduced to make it easier for >> other launchers to be created. Native agents may need access to >> libmanagement or libjdwp functions. Native graphics code may need access >> to the JDK graphics library. Some of these accesses may be unsupported >> and undocumented, but I don't think you can just cut them all off. >> > > Nobody wants to cut off anything. Magnus only proposes to decorate > these required functions with the new JDK_EXPORT macro (instead of > JNIEXPORT) in order to make it clear that they are not exported by > using the JNI mechanism (but they will still be exported, technically > speaking, JDK_EXPORT will even resolve to the exact same function > modifiers!). Maybe I've misunderstood the proposal. I thought some functions presently JNIEXPORT and JNICALL would be changed to just JDK_EXPORT as they are deemed not to be "JNI exported functions" as they are not the native-half of any Java native method. If the proposal is only to use JDK_EXPORT where JNICALL is missing (and JDK_EXPORT is identical to JNIEXPORT) that seems fine as it just serves as "documentation". But if JDKEXPORT differs from JNI_EXPORT then you may change the ability of external code to link to libraries it presently does link to. And the change to jdk.h versus jni.h is still unclear to me given jni.h defines the types that allow interaction with Java and which may still be needed in a JDK_EXPORT function implementation. I think there is overloaded use of the term "JNI" function in all this David ----- >> David >> >>> >>> /Magnus >>> >>> >>> >>>> >>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>> native functions should be changed to use JDK_EXPORT instead. >>>>> >>>>> I further propose that this macro should reside in a new file >>>>> "jdk.h", placed in the new directory >>>>> src/java.base/share/native/include/internal. This header file path >>>>> will automatically be provided to all native libraries, but not >>>>> copied to the JDK being built. (The existence of a "include/internal" >>>>> directory with this behavior has been discussed before. There are >>>>> more files that ought to be moved there, if/when it is created.) I >>>>> believe in many cases the #include "jni.h" can be just modified to >>>>> #include "#jdk.h", since most native code will not require "jni.h" >>>>> unless actually doing JNI calls -- most have included this file to >>>>> get the JNIEXPORT macro, which would explain the pervasive use of >>>>> #include "jni.h" in our code base. >>>> >>>> jni.h also defines all of the types used by the JNI. Those types are >>>> pervsive to the native code used throughout the JDK. >>>> >>>>> Thoughts? >>>> >>>> I think we need to understand the problems on Windows that prompted >>>> all this. Then I think we need to look at exactly how jni.h and >>>> JNIEXPORT etc are being used and understand whether this is truly an >>>> exported interface or not. >>>> >>>> Cheers, >>>> David >>>> >>>>> /Magnus >>>>> >>> From aph at redhat.com Wed Dec 12 09:50:52 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 12 Dec 2018 09:50:52 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: <75fafa4b-263b-56cd-5a9a-a8afc0287f0f@redhat.com> On 12/11/18 3:03 PM, Adam Farley8 wrote: > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > I've created a webrev and attached to the bug. > > Also, I've mentioned in the bug that there are additional swears in more > excusable locations. It would be good to get the community's take on > those. Zounds! Heavens to Betsy! Please defer this patch until April 1 2019. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Alan.Bateman at oracle.com Wed Dec 12 10:09:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 10:09:31 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <73833f4b-6586-01a7-4654-ffdfaccf441b@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> <73833f4b-6586-01a7-4654-ffdfaccf441b@oracle.com> Message-ID: On 11/12/2018 20:00, Sean Mullan wrote: > > These exceptions are generated from a very low level part of the > native JDK Windows or Unix FileSystem implementations. That is a > concern. The previous usages of this property were more focused and > confined to smaller parts of the code resulting in fewer code paths to > analyze. > > I think we need to take a step back. I think we need to reconsider > whether the jdk.includeInExceptions security property is appropriate > for this type of enhancement. > > Therefore, I oppose this change as-is. I'm happy to participate in a > more involved discussion where we start with use cases and motivation > before jumping to solutions. I also dislike this patch and you are probably right that jdk.includeInExceptions needs to be re-examined or pulled out completely. In addition to the surprise leakage issue, this patch is inconsistent as it hanges the exception for only a subset of the file system operations. -Alan From forax at univ-mlv.fr Wed Dec 12 10:26:06 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Dec 2018 11:26:06 +0100 (CET) Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <75fafa4b-263b-56cd-5a9a-a8afc0287f0f@redhat.com> References: <75fafa4b-263b-56cd-5a9a-a8afc0287f0f@redhat.com> Message-ID: <2007643539.573656.1544610366330.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Andrew Haley" > ?: "Adam Farley8" , "core-libs-dev" > Envoy?: Mercredi 12 D?cembre 2018 10:50:52 > Objet: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words > On 12/11/18 3:03 PM, Adam Farley8 wrote: > >> I've spotted 12 instances of swear words in OpenJDK source comments, and >> it seems appropriate to remove them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 >> >> I've created a webrev and attached to the bug. >> >> Also, I've mentioned in the bug that there are additional swears in more >> excusable locations. It would be good to get the community's take on >> those. > > Zounds! Heavens to Betsy! Please defer this patch until April 1 2019. Global Warming perhaps ? that's said we should fix the typo in SoftChannel. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 R?mi From adinn at redhat.com Wed Dec 12 10:55:33 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 12 Dec 2018 10:55:33 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <20181211135213.665034978@eggemoggin.niobe.net> References: <20181211135213.665034978@eggemoggin.niobe.net> Message-ID: <2de68711-240d-b4fb-fd5c-38246bf3d7c8@redhat.com> On 11/12/2018 21:52, mark.reinhold at oracle.com wrote: > I can certainly see removing the f-word, and other words of a sexual > nature. Those are clearly inappropriate. > > Removing lesser words, and continuing to police their use henceforth, > strikes me as overkill. > > What do other Committers think? I agree that strikes a better balance. I believe Stuart Marks (adjacent) post makes a good, clear case as to why and appropriately corrects the originally proposed solution. 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 From magnus.ihse.bursie at oracle.com Wed Dec 12 10:54:56 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 11:54:56 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <1d74b9d1-e467-674f-7170-48b48c943a4e@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <1d74b9d1-e467-674f-7170-48b48c943a4e@oracle.com> Message-ID: <0f80432d-fd9d-d510-e9b0-d2b7100e8a08@oracle.com> On 2018-12-12 09:40, David Holmes wrote: > On 12/12/2018 5:44 pm, Volker Simonis wrote: >> On Tue, Dec 11, 2018 at 11:47 PM David Holmes >> wrote: >>> >>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 00:23, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>> I propose that we introduce a new define, available to all JDK >>>>>> native >>>>>> files (Hotspot included), called JDK_EXPORT. The behavior of this >>>>>> symbol will be very similar (as of now, in fact identical) to >>>>>> JNIEXPORT; however, the semantics will not. >>>>>> >>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>>>> exporting from the library. The problem with this is that JNIEXPORT >>>>>> is part of the JNI interface, and is supposed to be used when C >>>>>> programs interact with Java. And, when doing this, the function >>>>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>>>> >>>>> I've seen a lot of the emails on this issue and I don't fully >>>>> understand what has been going wrong. But the intent is obviously the >>>>> JNIEXPORT represents what is needed to export this function for >>>>> use by >>>>> JNI, while JNICALL defines the calling convention. I agree there may >>>>> be some mistmatch when functions are actually not intended for >>>>> general >>>>> export outside the JDK but are only for internal JDK use. >>>>> >>>>>> We do have many such JNI exports in our native libraries, but we >>>>>> also >>>>>> have a lot of other, non-JNI exports, where one native library just >>>>>> provides an interface to other libraries. In these cases, we have >>>>>> still used JNIEXPORT for the functionality of getting the function >>>>>> exported, but we have not been consistent in our use of JNICALL. >>>>>> This >>>>>> has caused us way too much trouble for something that should Just >>>>>> Work. >>>>> >>>>> Are you suggesting that the interface between different libraries in >>>>> the JDK should not be a JNI interface? Is this because you think the >>>>> functions in these libraries are only for JDK internal use or ... ?? >>>>> >>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>> behavior as JNIEXPORT (that is, flagging the function for external >>>>>> visibility in the resulting native library), but which is *not* >>>>>> supposed to be exported to Java code using JNI, nor supposed to be >>>>>> decorated with >>>>> >>>>> Just a clarification there. JNI functions are not exported to Java >>>>> code, they are exported to native code. Java code can declare native >>>>> methods and those native methods must be written as JNI functions, >>>>> but >>>>> that's not what we are discussing. Libraries expose a JNI >>>>> interface (a >>>>> set of functions in the library) that can be called by application >>>>> native code, using JNI. >>>> We're apparently looking at "JNI" and "exporting" from two opposite >>>> sides here. :-) Just to make everything clear: If I have a Java class >>>> class MyClass { >>>> public static void native myNativeFunc(); >>>> } >>>> >>>> then I have one half of the JNI function, the Java half. This must be >>>> matched by a corresponding implementation in native, like this: >>>> JNIEXPORT void JNICALL >>>> Java_MyClass_myNativeFunc(void) { >>>> // ... do stuff >>>> } >>>> >>>> And this is the native half of the JNI function. Right? Let's leave >>>> aside which side is "exporting" to the other for now. :-) >>>> >>>> This way of setting up native functions that can be called from >>>> Java is >>>> what I refer to as JNI. And when you declare a native JNI function, >>>> you >>>> *must* use both JNIEXPORT and JNICALL. Alright? >>>> >>>> We do have a lot of those functions in our native libraries. And they >>>> are correct just the way they are. >>> >>> Yep all well and good. A function declared native in Java must have an >>> implementation as you describe. But not all native functions exist to >>> provide the native-half of a Java native function! >>> >>>> However, we also have *other* native functions, that are exported, not >>>> as JNI functions that should be called from Java, but as normal native >>>> library functions that should be called by other native code. Okay so >>>> far? And *those* functions have been problematic in how we decorate >>> >>> But there are again two cases. Those functions exported from a library >>> that are expected to be called from external code using the JNI >>> interface mechanism - such as all the JNI functions and JVM TI >>> functions >>> we export from the JVM - and those "exported" for access between >>> libraries within the JDK (such as all the JVM_* functions in libjvm). >>> >>> I think it is only the second group that should be addressed by your >>> JDK_EXPORT proposal - though I'm not completely clear exactly how to >>> identify them. >>> >>>> them. My proposal is that we *refrain* from using JNIEXPORT for those >>>> functions, and instead use JDK_EXPORT as name for the macro that >>>> decorates them as exported. That way, we can clearly see that a >>>> function >>>> like this: >>>> >>>> JDK_EXPORT void >>>> JLI_ReadEnv(char* env); >>>> >>>> is correctly declared, and will be exported to other native libraries, >>>> but not to Java. >>> >>> The issue is not whether it is "exported to Java"** but whether it is >>> exported using the JNI mechanism such that other native code calls it >>> using the JNI mechanism. >>> >>> ** There is no way to write a native method declaration in Java such >>> that it would be linked to the JLI_ReadEnv function. The naming is all >>> wrong, as is the signature. >>> >> >> But that's exactly what this change is about! Remove the usage of >> JNIEXPORT from functions which are NOT exported using the JNI >> mechanism. What don't you like about it ? > > I'm just saying we need to be clear about what functions we plan on > changing. Taking concrete examples as I don't see JLI_Read anywhere, > we have: > > JNIEXPORT void JNICALL > JLI_ReportErrorMessage(const char* fmt, ...) { > > JNIEXPORT void JNICALL > JLI_ReportErrorMessageSys(const char* fmt, ...) { > > JNIEXPORT void JNICALL > JLI_ReportExceptionDescription(JNIEnv * env) { > > JNIEXPORT StdArg JNICALL > *JLI_GetStdArgs() > { > > JNIEXPORT int JNICALL > JLI_GetStdArgc() { > return 0; > } > > which seems to define the exported interface for (part of) libJLI and > establishes both the export status and the expected calling > convention. Would these be changed? Yes! Those are exactly the kind of functions that should change. At this point, I intended to go out and make a full list of all functions that I wanted to change, but a grep for JNIEXPORT resulted in over 3800 hits, so I'm not doing it now. (However, if my proposal is eventually accepted, I will need to go through these 3800 calls and check them up. Fortunately, with some scripting, the search can be drastically limited.) These functions you list *cannot* be called from Java. There is no corresponding Java native methods. All suchs methods need to follow the JNI calling convention, which does not *only* put requirements on the decoration, but also on the name ("Java_fully_qualified_class_name_and_method") and on the argument list (first argument must be a JNIEnv*). For the purpose of this discussion, I'm calling functions that fulfil these requirements *JNI functions*. The functions you listed above is *not* JNI function. OK? Other examples of non-JNI functions are e.g: JNIEXPORT void JNICALL SplashSetScaleFactor(float); (from splashscreen) or JNIEXPORT jboolean JNICALL doDrawPath(DrawHandler* hnd, ...) Contrast this with: JNIEXPORT void JNICALL Java_sun_java2d_loops_DrawPath_DrawPath(JNIEnv *env, jobject self, ...) The latter function is called, not from some other native code, but directly from java, since there is a sun.java2d.loops.DrawPath.DrawPath() method (it's apparently a native constructor, a bit odd, but hey... 2d...). The former function is called from *other native libraries in the JDK*, from native code, using #import "java2d/loops/ProcessPath.h" and then calling doDrawPath(). I think there's an obvious difference between these two, and I'm getting increasingly frustrated that I'm unable to communicate this difference to you. :-( Are you with me now, with this classification? My proposal is that we should *only* use JNIEXPORT and JNICALL in the latter case, the JNI case. The former case, the non-JNI, "native lib to native lib" function, should use JDK_EXPORT instead of JNIEXPORT, so we let JNIEXPORT correctly signify that the function marked is a JNI-call. *Also*, we should remove JNICALL as well. Since these functions are just ways for our native libraries to communicate with another, we can determine to change the calling convention at will, just as if we've added a new argument to a function signature. Also, for practical purposes, JNICALL is empty for all platforms except Windows 32. And, just to be extremely clear, I do *not* propose we change official APIs. Documented, public function calls will not be affected. This includes e.g. JNIEXPORT jint JNICALL JNI_CreateJavaVM(JavaVM **pvm, void **penv, void *args); which will continue to look like that, even though it can not be called from Java. It also applies to all other functions in jni.h, and other documented header files. > >>>> Just to clarify, this has nothing to do with if this is a officially >>>> supported API or not. In general though, I assume that most (if not >>>> all?) of our exported functions (apart from the JNI_* stuff) is >>>> supposed >>>> to be consumed by other libraries in the JDK, and is not a public API. >>> >>> I think it varies library by library. You may need native application >>> code that can call directly into native JDK libraries. JLI is the Java >>> Launcher Interface - I think it was introduced to make it easier for >>> other launchers to be created. Native agents may need access to >>> libmanagement or libjdwp functions. Native graphics code may need >>> access >>> to the JDK graphics library. Some of these accesses may be unsupported >>> and undocumented, but I don't think you can just cut them all off. >>> >> >> Nobody wants to cut off anything. Magnus only proposes to decorate >> these required functions with the new JDK_EXPORT macro (instead of >> JNIEXPORT) in order to make it clear that they are not exported by >> using the JNI mechanism (but they will still be exported, technically >> speaking, JDK_EXPORT will even resolve to the exact same function >> modifiers!). > > Maybe I've misunderstood the proposal. I thought some functions > presently JNIEXPORT and JNICALL would be changed to just JDK_EXPORT as > they are deemed not to be "JNI exported functions" as they are not the > native-half of any Java native method. If I understand you correctly, this is what I'm proposing. > If the proposal is only to use JDK_EXPORT where JNICALL is missing > (and JDK_EXPORT is identical to JNIEXPORT) that seems fine as it just > serves as "documentation". But if JDKEXPORT differs from JNI_EXPORT > then you may change the ability of external code to link to libraries > it presently does link to. JDK_EXPORT and JNIEXPORT will be identical. The difference is, we can in the future change JDK_EXPORT at will, without having to do a CCC or risk breaking tons of user code. For instance, in AIX, we build native libraries with all symbols for xlc version 12 or below, but for version 13 doing proper symbol visibility becomes doable. In that case, the AIX team might find that it would be a good idea to declare JNIEXPORT as a way to set exported visibility on functions, to help user's developing native code, but we might still keep JDK_EXPORT as a no-op (and continue exporting all symbols) for our internal need. (Not saying any of this is a good idea, but it's an example of the freedom it gives us.) I think you are trying to use "JNICALL is missing" as a way to measure either: 1) the function is a JNI-function, an implementation of a Java native method, or 2) the function is officially documented Unfortunately, neither of these are true. And the presence, or absence, of JNICALL is at this time mostly arbitrary, for non-JNI ("lib to lib") functions. Which is one thing that has caused us a lot of trouble! > > And the change to jdk.h versus jni.h is still unclear to me given > jni.h defines the types that allow interaction with Java and which may > still be needed in a JDK_EXPORT function implementation. > > I think there is overloaded use of the term "JNI" function in all this Yes, that is one part of the confusion I want to address. There is no need to bring in "JNI" in functions that has nothing to do with JNI. /Magnus > > David > ----- > >>> David >>> >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>>> native functions should be changed to use JDK_EXPORT instead. >>>>>> >>>>>> I further propose that this macro should reside in a new file >>>>>> "jdk.h", placed in the new directory >>>>>> src/java.base/share/native/include/internal. This header file path >>>>>> will automatically be provided to all native libraries, but not >>>>>> copied to the JDK being built. (The existence of a >>>>>> "include/internal" >>>>>> directory with this behavior has been discussed before. There are >>>>>> more files that ought to be moved there, if/when it is created.) I >>>>>> believe in many cases the #include "jni.h" can be just modified to >>>>>> #include "#jdk.h", since most native code will not require "jni.h" >>>>>> unless actually doing JNI calls -- most have included this file to >>>>>> get the JNIEXPORT macro, which would explain the pervasive use of >>>>>> #include "jni.h" in our code base. >>>>> >>>>> jni.h also defines all of the types used by the JNI. Those types are >>>>> pervsive to the native code used throughout the JDK. >>>>> >>>>>> Thoughts? >>>>> >>>>> I think we need to understand the problems on Windows that prompted >>>>> all this. Then I think we need to look at exactly how jni.h and >>>>> JNIEXPORT etc are being used and understand whether this is truly an >>>>> exported interface or not. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> /Magnus >>>>>> >>>> From magnus.ihse.bursie at oracle.com Wed Dec 12 11:03:20 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:03:20 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> Message-ID: <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> On 2018-12-11 23:47, David Holmes wrote: > On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-11 00:23, David Holmes wrote: >>> Hi Magnus, >>> >>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>> I propose that we introduce a new define, available to all JDK >>>> native files (Hotspot included), called JDK_EXPORT. The behavior of >>>> this symbol will be very similar (as of now, in fact identical) to >>>> JNIEXPORT; however, the semantics will not. >>>> >>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>> exporting from the library. The problem with this is that JNIEXPORT >>>> is part of the JNI interface, and is supposed to be used when C >>>> programs interact with Java. And, when doing this, the function >>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>> >>> I've seen a lot of the emails on this issue and I don't fully >>> understand what has been going wrong. But the intent is obviously >>> the JNIEXPORT represents what is needed to export this function for >>> use by JNI, while JNICALL defines the calling convention. I agree >>> there may be some mistmatch when functions are actually not intended >>> for general export outside the JDK but are only for internal JDK use. >>> >>>> We do have many such JNI exports in our native libraries, but we >>>> also have a lot of other, non-JNI exports, where one native library >>>> just provides an interface to other libraries. In these cases, we >>>> have still used JNIEXPORT for the functionality of getting the >>>> function exported, but we have not been consistent in our use of >>>> JNICALL. This has caused us way too much trouble for something that >>>> should Just Work. >>> >>> Are you suggesting that the interface between different libraries in >>> the JDK should not be a JNI interface? Is this because you think the >>> functions in these libraries are only for JDK internal use or ... ?? >>> >>>> I therefore propose that we define "JDK_EXPORT", with the same >>>> behavior as JNIEXPORT (that is, flagging the function for external >>>> visibility in the resulting native library), but which is *not* >>>> supposed to be exported to Java code using JNI, nor supposed to be >>>> decorated with >>> >>> Just a clarification there. JNI functions are not exported to Java >>> code, they are exported to native code. Java code can declare native >>> methods and those native methods must be written as JNI functions, >>> but that's not what we are discussing. Libraries expose a JNI >>> interface (a set of functions in the library) that can be called by >>> application native code, using JNI. >> We're apparently looking at "JNI" and "exporting" from two opposite >> sides here. :-) Just to make everything clear: If I have a Java class >> class MyClass { >> public static void native myNativeFunc(); >> } >> >> then I have one half of the JNI function, the Java half. This must be >> matched by a corresponding implementation in native, like this: >> JNIEXPORT void JNICALL >> Java_MyClass_myNativeFunc(void) { >> // ... do stuff >> } >> >> And this is the native half of the JNI function. Right? Let's leave >> aside which side is "exporting" to the other for now. :-) >> >> This way of setting up native functions that can be called from Java >> is what I refer to as JNI. And when you declare a native JNI >> function, you *must* use both JNIEXPORT and JNICALL. Alright? >> >> We do have a lot of those functions in our native libraries. And they >> are correct just the way they are. > > Yep all well and good. A function declared native in Java must have an > implementation as you describe. But not all native functions exist to > provide the native-half of a Java native function! > >> However, we also have *other* native functions, that are exported, >> not as JNI functions that should be called from Java, but as normal >> native library functions that should be called by other native code. >> Okay so far? And *those* functions have been problematic in how we >> decorate > > But there are again two cases. Those functions exported from a library > that are expected to be called from external code using the JNI > interface mechanism - such as all the JNI functions and JVM TI > functions we export from the JVM - and those "exported" for access > between libraries within the JDK (such as all the JVM_* functions in > libjvm). > > I think it is only the second group that should be addressed by your > JDK_EXPORT proposal - though I'm not completely clear exactly how to > identify them. Alright, now I think we're on the same page again. :) Yes, this is what I'm saying. I'm not proposing to modify public APIs. You identify external APIs by the fact that they are documented. And if you are unsure, you ask Jon. ;-) > >> them. My proposal is that we *refrain* from using JNIEXPORT for those >> functions, and instead use JDK_EXPORT as name for the macro that >> decorates them as exported. That way, we can clearly see that a >> function like this: >> >> JDK_EXPORT void >> JLI_ReadEnv(char* env); >> >> is correctly declared, and will be exported to other native >> libraries, but not to Java. > > The issue is not whether it is "exported to Java"** but whether it is > exported using the JNI mechanism such that other native code calls it > using the JNI mechanism. > > ** There is no way to write a native method declaration in Java such > that it would be linked to the JLI_ReadEnv function. The naming is all > wrong, as is the signature. > >> Just to clarify, this has nothing to do with if this is a officially >> supported API or not. In general though, I assume that most (if not >> all?) of our exported functions (apart from the JNI_* stuff) is >> supposed to be consumed by other libraries in the JDK, and is not a >> public API. > > I think it varies library by library. You may need native application > code that can call directly into native JDK libraries. JLI is the Java > Launcher Interface - I think it was introduced to make it easier for > other launchers to be created. Native agents may need access to > libmanagement or libjdwp functions. Native graphics code may need > access to the JDK graphics library. Some of these accesses may be > unsupported and undocumented, but I don't think you can just cut them > all off. If they are unsupported and undocumented, I sure as h*ll can cut them all off! :-) Besides, and let me re-iterate this, the only change that will happen by removing JNICALL, is on Windows 32. No other platform will be affected. There is no official support for Windows 32 anymore. There's some low-effort community work done on keeping Windows 32 alive, but it's not backed by any major player. Right now, they are taking a lot of hits *due to the fact* that we have not sorted this out, and waste a lot of their precious effort trying to fix this piecemeal. If we do fix things according to this proposal, then it's at least clear how things *should* work. If it turns out that there's some code out there in the wild, running on Windows 32, that uses an undocumented and unsupported function call, and it breaks -- well, sucks to be them. They'll just have to do what everyone does who uses an undocumented interface that suddenly changes: update their code. /Magnus > > David > >> >> /Magnus >> >> >> >>> >>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>> native functions should be changed to use JDK_EXPORT instead. >>>> >>>> I further propose that this macro should reside in a new file >>>> "jdk.h", placed in the new directory >>>> src/java.base/share/native/include/internal. This header file path >>>> will automatically be provided to all native libraries, but not >>>> copied to the JDK being built. (The existence of a >>>> "include/internal" directory with this behavior has been discussed >>>> before. There are more files that ought to be moved there, if/when >>>> it is created.) I believe in many cases the #include "jni.h" can be >>>> just modified to #include "#jdk.h", since most native code will not >>>> require "jni.h" unless actually doing JNI calls -- most have >>>> included this file to get the JNIEXPORT macro, which would explain >>>> the pervasive use of #include "jni.h" in our code base. >>> >>> jni.h also defines all of the types used by the JNI. Those types are >>> pervsive to the native code used throughout the JDK. >>> >>>> Thoughts? >>> >>> I think we need to understand the problems on Windows that prompted >>> all this. Then I think we need to look at exactly how jni.h and >>> JNIEXPORT etc are being used and understand whether this is truly an >>> exported interface or not. >>> >>> Cheers, >>> David >>> >>>> /Magnus >>>> >> From magnus.ihse.bursie at oracle.com Wed Dec 12 11:14:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:14:22 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> Message-ID: <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> On 2018-12-11 18:22, Bob Vandette wrote: > Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad > functions. Perhaps you should just follow the same procedure for the debug > library. > > #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad at 8", "JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"_JVM_OnLoad at 12", "JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"_Agent_OnLoad at 12", "Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"_Agent_OnUnload at 4", "Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach at 12", ?Agent_OnAttach?} Yes, that sounds mostly reasonable. The latest iteration of the patch is doing just this. I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. But if there are other *_OnEvent() functions in the JDK code, they should be fixed too to handle decorated names. To the best of my knowledge, jdwpTransport_OnLoad was the only such *_OnEvent function that did not handle decorated names. I searched the code base for the pattern '[a-zA-Z]+_On[A-Z][a-zA-Z]*' and skimmed the result, but could not find anything else apart from those listed by you above, and the jdwpTransport_OnLoad. Any knowledge of additional such functions but with different names must come from the component teams. /Magnus > > Bob. > > >> On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote: >> >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention. So, the patch only works for 16 bytes of >> parameters. To be generic, the routine needs to have the stack size >> passed in by the caller. If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. >> >> #if defined(_WIN32) && !defined(_WIN64) onLoad = >> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) >> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. From aph at redhat.com Wed Dec 12 11:17:57 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 12 Dec 2018 11:17:57 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <20181211135213.665034978@eggemoggin.niobe.net> References: <20181211135213.665034978@eggemoggin.niobe.net> Message-ID: <57fb4675-6fd9-6f0c-f7c2-0475f848fd99@redhat.com> On 12/11/18 9:52 PM, mark.reinhold at oracle.com wrote: > I can certainly see removing the f-word, and other words of a sexual > nature. Those are clearly inappropriate. Fair enough, but we shouldn't touch imported sources, as Joe Darcy pointed out. Let the rudeness be fixed at source. > Removing lesser words, and continuing to police their use henceforth, > strikes me as overkill. > > What do other Committers think? I agree with your judgment. Sometimes emphasis is important, and to reduce a very strong emphasis to mild disapproval is an information-losing change. We would be doing a disservice to the reader. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Wed Dec 12 11:19:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:19:15 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: On 2018-12-11 18:16, Alexey Ivanov wrote: > Hi Simon, > > Thank you for your comments. > > The updated webrev: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > > Indeed, it looks much cleaner. Yes! This seems like the correct fix. Ship it! :) /Magnus > > Regards, > Alexey > > On 11/12/2018 16:43, Simon Tooke wrote: >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as >>> well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention. So, the patch only works for 16 bytes of >> parameters. To be generic, the routine needs to have the stack size >> passed in by the caller. If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. >> >> #if defined(_WIN32) && !defined(_WIN64) onLoad = >> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> "_jdwpTransport_OnLoad at 16"); #else onLoad = >> (jdwpTransport_OnLoad_t) >> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. > From Alan.Bateman at oracle.com Wed Dec 12 11:35:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 11:35:28 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> Message-ID: <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: > : > > I searched the code for "jdwpTransport_On" to see of there was any > corresponding OnUnload function (or other), but could not find any. That's right, an unload wasn't needed when that SPI was originally added but could be added in the event that some future debugger agent need it. The SPI is a supported/documented JDK-specific mechanism, its "spec" is hosted here: https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html I see this thread is touching on the functions exported by libjli. This library is part of the launcher and shouldn't be used directly by anything outside of the JDK. However we have to be careful because JavaFX `javapackager` tool has been using it. There's a JEP to bring a similar tool, jpackage in the current proposal, that will supersede it but in the mean time we need to be careful not to break it. A second issue is that the libjli is listed in the property list (Info.plist) on macOS. This came from Apple in 7u4 and periodically things show up that are using it,? e.g. that recent breakage with Eclipse that was never fully diagnosed but we think it was using Info.plist. -Alan From david.holmes at oracle.com Wed Dec 12 12:17:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 22:17:15 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> Message-ID: Okay I went away and did some homework ... Let me back up a bit and see if I have the evolution of this correctly. The native implementation of Java methods should be declared and defined with JNIEXPORT and JNICALL. JNIEXPORT controls the export visibility so they can be linked. JNICALL controls the calling convention and is needed so that the JVM's calling convention matches the native code. [This part was unclear to me.] Other native methods exported from the same (or different) native libraries may also be decorated with JNIEXPORT and JNICALL. But in places there is a mismatch between the declaration in the header and the definition leading to errors. There are two main types of such native functions: a) those publicly defined in the various native APIs: JNI itself (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... b) those intended only for use by other native code within the JDK libraries (JLI_* - though I note Alan's comment re javafxpackager, others??) and a possible third type are callback functions like the JPLISAgent event handlers (e.g. eventHandlerVMInit). There is a view that no native method that isn't the native-half of a Java method should use JNICALL. [Okay I can see how that makes sense - regardless of the actual calling convention used marking such methods as "must use the same calling convention as the VM native method call" is somewhat meaningless. Yet obviously the public native APIs do specify JNICALL so this is not a hard and fast rule. Further the callbacks must also follow a convention known to the VM doing the calling!] Where we have (introduced?) a discrepancy between the definition and declaration the approach has been (because of the previous view) to remove JNICALL. [This should only relate to methods of kind (b) above.] That leaves those methods with JNIEXPORT only. That seems wrong to you because they are not "JNI methods", so you want to replace with JDK_EXPORT to make it clear. [Ok - this seems reasonable.] If JNICALL is removed from those native methods and they are currently linked by external applications, those applications may stop working. But this only affects win32 (as its the only platform where JNICALL is different to the default C/C++ calling convention?) so your position is this is acceptable breakage - and would only affect unsupported/undocumented APIs. Does that sum it up? We still need to be sure that we're only changing functions of type (b) above. And I note that this has been driven by the choice to remove JNICALL where there was a discrepancy - that leads to the visibility of the two kinds of methods. If it had been chosen to add JNICALL where missing instead, then we may not have been having this conversation. This will also need a CSR request due to the change in linking behaviour. Cheers, David ----- On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: > > > On 2018-12-11 23:47, David Holmes wrote: >> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 00:23, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>> I propose that we introduce a new define, available to all JDK >>>>> native files (Hotspot included), called JDK_EXPORT. The behavior of >>>>> this symbol will be very similar (as of now, in fact identical) to >>>>> JNIEXPORT; however, the semantics will not. >>>>> >>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>>> exporting from the library. The problem with this is that JNIEXPORT >>>>> is part of the JNI interface, and is supposed to be used when C >>>>> programs interact with Java. And, when doing this, the function >>>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>>> >>>> I've seen a lot of the emails on this issue and I don't fully >>>> understand what has been going wrong. But the intent is obviously >>>> the JNIEXPORT represents what is needed to export this function for >>>> use by JNI, while JNICALL defines the calling convention. I agree >>>> there may be some mistmatch when functions are actually not intended >>>> for general export outside the JDK but are only for internal JDK use. >>>> >>>>> We do have many such JNI exports in our native libraries, but we >>>>> also have a lot of other, non-JNI exports, where one native library >>>>> just provides an interface to other libraries. In these cases, we >>>>> have still used JNIEXPORT for the functionality of getting the >>>>> function exported, but we have not been consistent in our use of >>>>> JNICALL. This has caused us way too much trouble for something that >>>>> should Just Work. >>>> >>>> Are you suggesting that the interface between different libraries in >>>> the JDK should not be a JNI interface? Is this because you think the >>>> functions in these libraries are only for JDK internal use or ... ?? >>>> >>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>> behavior as JNIEXPORT (that is, flagging the function for external >>>>> visibility in the resulting native library), but which is *not* >>>>> supposed to be exported to Java code using JNI, nor supposed to be >>>>> decorated with >>>> >>>> Just a clarification there. JNI functions are not exported to Java >>>> code, they are exported to native code. Java code can declare native >>>> methods and those native methods must be written as JNI functions, >>>> but that's not what we are discussing. Libraries expose a JNI >>>> interface (a set of functions in the library) that can be called by >>>> application native code, using JNI. >>> We're apparently looking at "JNI" and "exporting" from two opposite >>> sides here. :-) Just to make everything clear: If I have a Java class >>> class MyClass { >>> ?? public static void native myNativeFunc(); >>> } >>> >>> then I have one half of the JNI function, the Java half. This must be >>> matched by a corresponding implementation in native, like this: >>> JNIEXPORT void JNICALL >>> Java_MyClass_myNativeFunc(void) { >>> // ... do stuff >>> } >>> >>> And this is the native half of the JNI function. Right? Let's leave >>> aside which side is "exporting" to the other for now. :-) >>> >>> This way of setting up native functions that can be called from Java >>> is what I refer to as JNI. And when you declare a native JNI >>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>> >>> We do have a lot of those functions in our native libraries. And they >>> are correct just the way they are. >> >> Yep all well and good. A function declared native in Java must have an >> implementation as you describe. But not all native functions exist to >> provide the native-half of a Java native function! >> >>> However, we also have *other* native functions, that are exported, >>> not as JNI functions that should be called from Java, but as normal >>> native library functions that should be called by other native code. >>> Okay so far? And *those* functions have been problematic in how we >>> decorate >> >> But there are again two cases. Those functions exported from a library >> that are expected to be called from external code using the JNI >> interface mechanism - such as all the JNI functions and JVM TI >> functions we export from the JVM - and those "exported" for access >> between libraries within the JDK (such as all the JVM_* functions in >> libjvm). >> >> I think it is only the second group that should be addressed by your >> JDK_EXPORT proposal - though I'm not completely clear exactly how to >> identify them. > Alright, now I think we're on the same page again. :) > > Yes, this is what I'm saying. I'm not proposing to modify public APIs. > > You identify external APIs by the fact that they are documented. And if > you are unsure, you ask Jon. ;-) > >> >>> them. My proposal is that we *refrain* from using JNIEXPORT for those >>> functions, and instead use JDK_EXPORT as name for the macro that >>> decorates them as exported. That way, we can clearly see that a >>> function like this: >>> >>> JDK_EXPORT void >>> JLI_ReadEnv(char* env); >>> >>> is correctly declared, and will be exported to other native >>> libraries, but not to Java. >> >> The issue is not whether it is "exported to Java"** but whether it is >> exported using the JNI mechanism such that other native code calls it >> using the JNI mechanism. >> >> ** There is no way to write a native method declaration in Java such >> that it would be linked to the JLI_ReadEnv function. The naming is all >> wrong, as is the signature. >> >>> Just to clarify, this has nothing to do with if this is a officially >>> supported API or not. In general though, I assume that most (if not >>> all?) of our exported functions (apart from the JNI_* stuff) is >>> supposed to be consumed by other libraries in the JDK, and is not a >>> public API. >> >> I think it varies library by library. You may need native application >> code that can call directly into native JDK libraries. JLI is the Java >> Launcher Interface - I think it was introduced to make it easier for >> other launchers to be created. Native agents may need access to >> libmanagement or libjdwp functions. Native graphics code may need >> access to the JDK graphics library. Some of these accesses may be >> unsupported and undocumented, but I don't think you can just cut them >> all off. > If they are unsupported and undocumented, I sure as h*ll can cut them > all off! :-) > > Besides, and let me re-iterate this, the only change that will happen by > removing JNICALL, is on Windows 32. No other platform will be affected. > There is no official support for Windows 32 anymore. There's some > low-effort community work done on keeping Windows 32 alive, but it's not > backed by any major player. Right now, they are taking a lot of hits > *due to the fact* that we have not sorted this out, and waste a lot of > their precious effort trying to fix this piecemeal. If we do fix things > according to this proposal, then it's at least clear how things *should* > work. If it turns out that there's some code out there in the wild, > running on Windows 32, that uses an undocumented and unsupported > function call, and it breaks -- well, sucks to be them. They'll just > have to do what everyone does who uses an undocumented interface that > suddenly changes: update their code. > > /Magnus > >> >> David >> >>> >>> /Magnus >>> >>> >>> >>>> >>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>> native functions should be changed to use JDK_EXPORT instead. >>>>> >>>>> I further propose that this macro should reside in a new file >>>>> "jdk.h", placed in the new directory >>>>> src/java.base/share/native/include/internal. This header file path >>>>> will automatically be provided to all native libraries, but not >>>>> copied to the JDK being built. (The existence of a >>>>> "include/internal" directory with this behavior has been discussed >>>>> before. There are more files that ought to be moved there, if/when >>>>> it is created.) I believe in many cases the #include "jni.h" can be >>>>> just modified to #include "#jdk.h", since most native code will not >>>>> require "jni.h" unless actually doing JNI calls -- most have >>>>> included this file to get the JNIEXPORT macro, which would explain >>>>> the pervasive use of #include "jni.h" in our code base. >>>> >>>> jni.h also defines all of the types used by the JNI. Those types are >>>> pervsive to the native code used throughout the JDK. >>>> >>>>> Thoughts? >>>> >>>> I think we need to understand the problems on Windows that prompted >>>> all this. Then I think we need to look at exactly how jni.h and >>>> JNIEXPORT etc are being used and understand whether this is truly an >>>> exported interface or not. >>>> >>>> Cheers, >>>> David >>>> >>>>> /Magnus >>>>> >>> > From vincent.x.ryan at oracle.com Wed Dec 12 12:32:33 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 12 Dec 2018 12:32:33 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <33d0efad-60d8-4f41-f741-dcbc44b38da0@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> <01C3CC6C-F645-40E3-A9FD-04017843F6F1@oracle.com> <33d0efad-60d8-4f41-f741-dcbc44b38da0@oracle.com> Message-ID: Thanks for your proposal. Comments below. > On 12 Dec 2018, at 02:35, Stuart Marks wrote: > > > > On 12/11/18 1:21 PM, Vincent Ryan wrote: >> My preference is for PrintStream rather than Writer, for the same reason as Roger: it?s more convenient >> for handling System.out. Does that address your concern? > > PrintStream is fine with me. > >> I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte charset so some 0x8X characters >> Will trigger the multi-byte sequence and will end up being misinterpreted. Hence my rather awkward conversion to a String. >> Is there a better way? > > In toPrintableString(), > > 259 StringBuilder printable = new StringBuilder(toIndex - fromIndex); > 260 for (int i = fromIndex; i < toIndex; i++) { > 261 if (bytes[i] > 0x1F && bytes[i] < 0x7F) { > 262 printable.append((char) bytes[i]); > 263 } else if (bytes[i] > (byte)0x9F && bytes[i] <= (byte)0xFF) { > 264 printable.append(new String(new byte[]{bytes[i]}, ISO_8859_1)); > 265 > 266 } else { > 267 printable.append('.'); > 268 } > 269 } > > It works to cast ASCII bytes char, because the 7-bit ASCII range overlaps the low 7 bits of the UTF-16 char range. The bytes values of ISO 8859-1 overlap the low 8 bits of UTF-16, so casts work for them too. > > For any other charset, you'd need to do codeset conversion. But you're cleverly supporting only ISO 8859-1, so you don't have to do any conversion. :-) > >> I?m not sure I?ve addressed your concern regarding IOExceptions - can you elaborate? > > Taking out the OutputStream overloads addressed my concerns. In at least one case the code would wrap the OutputStream into a PrintStream, print stuff to it, and then throw away the PrintStream. If an output error occurred, any error state in the PrintStream would also be thrown away. The creation of the PrintStream wrapper would also use the system's default charset instead of letting the caller control it. > > The dump() overloads now all take PrintStream, so it's the caller's responsibility to ensure that the PrintStream is using the right charset and to check for errors after. So this is all OK now. > > Note that the internal getPrintStream(), to wrap an OutputStream in a PrintStream, is now obsolete and can be removed. > > (Oh, I see Roger has said much the same things. Oh well, the peril of parallel reviews.) > > ** > >> BTW updated webrev/javadoc available: >> http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ >> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html > > Now we have a somewhat unsatisfying asymmetry in the APIs. > > There are four kinds of inputs: > > 1. byte[] > 2. byte[] subrange > 3. InputStream > 4. ByteBuffer > > and two kinds of outputs: > > 1. PrintStream > 2. Stream > > and two variations of formatters: > > 1. default formatter > 2. custom formatter + chunk size > > This is a total of 16 combinations. But there are only eight methods: three PrintStream methods with choice of input, two stream-output methods using the default formatter, and three stream-output methods using custom chunk+formatter. > > You don't have to provide ALL combinations, but what's here is an odd subset with some apparently arbitrary choices. For example, if I have a ByteBuffer and I want to dump it to System.out using default formatting, I have to go the Stream.forEachOrdered route AND provide the default chunk size and formatter. > > HexFormat.dumpAsStream(buf, DEFAULT_CHUNK_SIZE, HEXDUMP_FORMATTER) > .forEachOrdered(System.out::println); > > These aren't huge deals, but they're easily stumbled over. > > One approach to organizing this is to have a HexFormat instance that contains the setup information and then to have instance methods that either update the setup or perform conversion and output. I'd use static factory methods instead of constructors. For example, you could do this: > > static factories methods: > - from(byte[]) > - from(byte[], fromIndex, toIndex) > - from(InputStream) > - from(ByteBuffer) > > formatter setup instance methods: > - format(chunksize, formatter) > > output: > - void dump(PrintStream) > - Stream stream() > > Using this approach my example from above could be performed as follows: > > HexFormat.from(buf).dump(System.out); > > Note, I'm not saying that you HAVE to do it this way. (In particular, the naming could use work.) This is quite possibly overkill. But it's something you might consider, as it gets you all 16 combinations using seven methods, compared to the eight static methods in the current proposal that cover only half of the combinations. > > Alternatively, pare down the set of static methods to a bare minimum. Provide one that can do everything, and then provide one or two more that are essentially the same as the first but with some hardwired defaults. For example, to help minimize things, you can wrap a ByteBuffer around a byte array subrange, or get an InputStream from a byte array subrange. But you can't get an InputStream from a ByteBuffer or vice-versa, without a lot of work. > > (I haven't looked at the to* or from* methods.) > > s?marks Your chaining approach has merit and the method chaining is attractive but it would be a significant change to the API at this advanced stage. I agree that there are gaps in the combinations and perhaps that could be addressed by introducing a few convenience methods. I think ByteBuffer is under-represented and propose adding the following two methods to handle the simplified, default cases: public static Stream dumpAsStream(ByteBuffer buffer) public static void dump(ByteBuffer buffer, PrintStream out) That would be 10 combos for 10 methods versus 16 combos for 7 methods which is still not full coverage but perhaps more methods could be added in the future if there is demand for them. From magnus.ihse.bursie at oracle.com Wed Dec 12 12:58:27 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 13:58:27 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> Message-ID: On 2018-12-12 12:35, Alan Bateman wrote: > On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >> : >> >> I searched the code for "jdwpTransport_On" to see of there was any >> corresponding OnUnload function (or other), but could not find any. > That's right, an unload wasn't needed when that SPI was originally > added but could be added in the event that some future debugger agent > need it. The SPI is a supported/documented JDK-specific mechanism, its > "spec" is hosted here: > > https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html > ... yet in all that time, we have not fully supported the spec on Windows 32. :-( (We never discovered this because of lack of testing, I presume, and that our internal usage empoyed a questonable workaround.) > > I see this thread is touching on the functions exported by libjli. > This library is part of the launcher and shouldn't be used directly by > anything outside of the JDK. However we have to be careful because > JavaFX `javapackager` tool has been using it. There's a JEP to bring a > similar tool, jpackage in the current proposal, that will supersede it > but in the mean time we need to be careful not to break it. A second > issue is that the libjli is listed in the property list (Info.plist) > on macOS. This came from Apple in 7u4 and periodically things show up > that are using it, e.g. that recent breakage with Eclipse that was > never fully diagnosed but we think it was using Info.plist. The latest patch, as suggested, will not modify JLI, but instead fix the broken behaviour of JDWP on Windows 32. /Magnus From gromero at linux.vnet.ibm.com Wed Dec 12 13:17:26 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 12 Dec 2018 11:17:26 -0200 Subject: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace In-Reply-To: <5fb47698991649b1914cb8b134a57770@sap.com> References: <49a83fc27d2e4e1dbb16827e8cbe4815@sap.com> <0f660efc-21eb-d516-f5c5-22d505b116c0@oracle.com> <2763a0e8-291e-ddbf-5f72-f171cfa0971 <5fb47698991649b1914cb8b134a57770@sap.com> Message-ID: Hi Martin, On 12/12/2018 05:10 AM, Doerr, Martin wrote: > thanks for your improvements. You can also remove the trailing \t from the opto assembly. > Note that there's no need to re-push newer version to jdk/submit when only PPC files were changed. jdk/submit doesn't look at them. Got it. Pushed to jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/7384e00d5860 Thank you. Best regards, Gustavo > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero > Sent: Mittwoch, 12. Dezember 2018 03:08 > To: Michihiro Horie > Cc: core-libs-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; Doerr, Martin ; Roger Riggs ; Vladimir Kozlov ; Simonis, Volker > Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > > Hi Michi, > > On 12/11/2018 11:12 PM, Michihiro Horie wrote: >> Thank you for finding the issue on Power8. You do not need a check with has_darn in the ppc.ad. It is better to add a check in vm_versoin_ppc. > > I agree. > >> I uploaded webrev.08 based on your webrev.07. (Thanks for the enhancement of opto assembly and removing trailing spaces!) >> http://cr.openjdk.java.net/~mhorie/8213754/webrev.08/ > > Thanks for the updated webrev. Looks good! > I've just pushed webrev.08 to jdk/submit expecting no failures as .07 passed fine. > > Once I get the jdk/submit results tomorrow I'll push. > > Best regards, > Gustavo > From mvala at redhat.com Wed Dec 12 13:34:59 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 12 Dec 2018 14:34:59 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: Hi Martin, thanks for review and sponsorship. All fixed, details inlined. new webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.01/ On 12/12/18 3:55 AM, Martin Buchholz wrote: > Hi Michal, pleased to meet you. I'll be your sponsor. > > The test will need a legal header, presumably similar to others authored by > redhatters. fixed > > It is now possible to check in jmh microbenchmarks (but I've never done so > myself). done > > The current coding style is non-standard, but deliberate; avoid gratuitous > changes like > - Node e; > + Node e; Fixed. I insist on adding {} to if/else as it is extremely prone to errors. I can add it in different changeset if you like. > > As author of concurrent/ConcurrentHashMap/WhiteBox.java ... > - I thought you'd need a @modules ... did this test actually pass?It pass but with WARNING: An illegal reflective access operation has occurred. Fixed. > - you should have some kind of @summary that includes the word "whitebox" fixed > - why not "throws ReflectiveOperationException" ? fixed > - your reviewer is a bit on the autistic side, so please change /** to /* > on the @test comment (it's not javadoc!) fixed (other tests in HashMap have also /**. I guess it does not worth the separate fix. or?) > > > On Tue, Dec 11, 2018 at 11:06 AM Michal Vala wrote: > >> Hi, >> >> I've been looking into this bug in HashMap where resize() is called >> multiple >> times when putting whole map into another. >> >> I come up with following patch: >> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ >> >> I've tried to do it as little invasive as possible. New resize(int) method >> is >> called just from putMapEntries for now. Notice that method is called with >> size >> of the new map. I was experimenting with calling it with 'size()+s', but >> this >> leads to unwanted space allocation when inserted map rewrites a lot of >> existing >> keys. >> >> I've benchmarked this with adding 10millions elements into existing map >> and it >> gets ~50% improvement: >> >> unpatched >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testMethod thrpt 10 1.248 ? 0.058 ops/s >> >> patched >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testMethod thrpt 10 1.872 ? 0.109 ops/s >> >> public class MyBenchmark { >> static Map mapTocopy = IntStream.range(1, >> 10_000_000).boxed().collect(Collectors.toMap(k -> k, >> k -> k)); >> >> @Benchmark >> public int testMethod() { >> var map = new HashMap(); >> map.put(-5, -5); >> map.putAll(mapTocopy); >> return map.size(); >> } >> } >> >> Any ideas for missed corner-cases or some good tests? >> >> -- >> Michal Vala >> OpenJDK QE >> Red Hat Czech >> > -- Michal Vala OpenJDK QE Red Hat Czech From mvala at redhat.com Wed Dec 12 13:36:33 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 12 Dec 2018 14:36:33 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: <5ddbe5e9-bd9a-c3b6-15bf-cf43dea0c0e0@redhat.com> thank you Roger, I've added jmh benchmark. see new webrev in reply to Martin's review. On 12/12/18 4:45 AM, Roger Riggs wrote: > Hi, > > fyi, jmh tests appropriate for JDK apis are located in the test/micro/... > directories. > > The benchmarks are built with: > ? % make build-microbenchmark > > The results are in the build//images/test/micro/benchmarks.jar > > $.02, Roger > > On 12/11/2018 A 9:55 PM, Martin Buchholz wrote: >> Hi Michal, pleased to meet you.? I'll be your sponsor. >> >> The test will need a legal header, presumably similar to others authored by >> redhatters. >> >> It is now possible to check in jmh microbenchmarks (but I've never done so >> myself). >> >> The current coding style is non-standard, but deliberate; avoid gratuitous >> changes like >> -??????????????? Node e; >> +??????????????? Node e; >> >> As author of concurrent/ConcurrentHashMap/WhiteBox.java ... >> - I thought you'd need a @modules ... did this test actually pass? >> - you should have some kind of @summary that includes the word "whitebox" >> - why not "throws ReflectiveOperationException" ? >> - your reviewer is a bit on the autistic side, so please change /** to /* >> on the @test comment (it's not javadoc!) >> >> >> On Tue, Dec 11, 2018 at 11:06 AM Michal Vala wrote: >> >>> Hi, >>> >>> I've been looking into this bug in HashMap where resize() is called >>> multiple >>> times when putting whole map into another. >>> >>> I come up with following patch: >>> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ >>> >>> I've tried to do it as little invasive as possible. New resize(int) method >>> is >>> called just from putMapEntries for now. Notice that method is called with >>> size >>> of the new map. I was experimenting with calling it with 'size()+s', but >>> this >>> leads to unwanted space allocation when inserted map rewrites a lot of >>> existing >>> keys. >>> >>> I've benchmarked this with adding 10millions elements into existing map >>> and it >>> gets ~50% improvement: >>> >>> unpatched >>> Benchmark??????????????? Mode? Cnt? Score?? Error? Units >>> MyBenchmark.testMethod? thrpt?? 10? 1.248 ? 0.058? ops/s >>> >>> patched >>> Benchmark??????????????? Mode? Cnt? Score?? Error? Units >>> MyBenchmark.testMethod? thrpt?? 10? 1.872 ? 0.109? ops/s >>> >>> public class MyBenchmark { >>> ????? static Map mapTocopy = IntStream.range(1, >>> 10_000_000).boxed().collect(Collectors.toMap(k -> k, >>> ????????????? k -> k)); >>> >>> ????? @Benchmark >>> ????? public int testMethod() { >>> ????????? var map = new HashMap(); >>> ????????? map.put(-5, -5); >>> ????????? map.putAll(mapTocopy); >>> ????????? return map.size(); >>> ????? } >>> } >>> >>> Any ideas for missed corner-cases or some good tests? >>> >>> -- >>> Michal Vala >>> OpenJDK QE >>> Red Hat Czech >>> > -- Michal Vala OpenJDK QE Red Hat Czech From alexey.ivanov at oracle.com Wed Dec 12 15:34:18 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 15:34:18 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> Message-ID: On 12/12/2018 12:58, Magnus Ihse Bursie wrote: > > > On 2018-12-12 12:35, Alan Bateman wrote: >> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >>> : >>> >>> I searched the code for "jdwpTransport_On" to see of there was any >>> corresponding OnUnload function (or other), but could not find any. >> That's right, an unload wasn't needed when that SPI was originally >> added but could be added in the event that some future debugger agent >> need it. The SPI is a supported/documented JDK-specific mechanism, >> its "spec" is hosted here: >> >> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html >> > ... yet in all that time, we have not fully supported the spec on > Windows 32. :-( (We never discovered this because of lack of testing, > I presume, and that our internal usage empoyed a questonable workaround.) The spec does not specify whether the mangled name should be exported or not (for Windows 32 bit). I looked through JNI specification and have found no mention of JNIEXPORT or JNICALL. https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html This example uses extern "C" modifier but neither JNIEXPORT or JNICALL: https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments > >> >> I see this thread is touching on the functions exported by libjli. >> This library is part of the launcher and shouldn't be used directly >> by anything outside of the JDK. However we have to be careful because >> JavaFX `javapackager` tool has been using it. There's a JEP to bring >> a similar tool, jpackage in the current proposal, that will supersede >> it but in the mean time we need to be careful not to break it. A >> second issue is that the libjli is listed in the property list >> (Info.plist) on macOS. This came from Apple in 7u4 and periodically >> things show up that are using it, e.g. that recent breakage with >> Eclipse that was never fully diagnosed but we think it was using >> Info.plist. > The latest patch, as suggested, will not modify JLI, but instead fix > the broken behaviour of JDWP on Windows 32. Yes, that's right. However, I believe the previous versions did not modify libjli. Regards, Alexey > > /Magnus From alexey.ivanov at oracle.com Wed Dec 12 15:43:38 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 15:43:38 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> Message-ID: Hi Bob, Thank you for the pointers on how the same situation is handled in Hotspot for *_OnLoad* functions. At this time, we're dealing with one symbol only. If other symbols are added in the future, we should definitely use this approach. Regards, Alexey On 11/12/2018 17:22, Bob Vandette wrote: > Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad > functions. Perhaps you should just follow the same procedure for the debug > library. > > #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad at 8", "JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"_JVM_OnLoad at 12", "JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"_Agent_OnLoad at 12", "Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"_Agent_OnUnload at 4", "Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach at 12", ?Agent_OnAttach?} > > Bob. > > >> On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote: >> >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention. So, the patch only works for 16 bytes of >> parameters. To be generic, the routine needs to have the stack size >> passed in by the caller. If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. >> >> #if defined(_WIN32) && !defined(_WIN64) onLoad = >> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) >> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. From Roger.Riggs at oracle.com Wed Dec 12 15:52:24 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Dec 2018 10:52:24 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <1543912487.2437.16.camel@paratix.ch> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> Message-ID: <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> Hi Phillip, Sorry, got busy... Can you rebase the patch to the current repo, it did not apply cleanly. I know you are focused on removing the deprecation, but a few localized improvements would be good. In Attributes.java : 346-337, it uses StringBuffer, please change it to StringBuilder. ? Unless thread safety is an issue, StringBuilder is recommended, it is ? slightly more efficient since it does no synchronization. - And the StringBuilder should be sized when it is created, to avoid needing to resize it later. ? Using a single StringBuilder all the entries, using setLength(0), would save allocating ? for each entry. ?- check the indentation @line 308-20 and 311. In Manifest.java: ?- write72 method? !String.isEmpty() is preferred over the .length() > 0. ?- if the line is empty, should it write the LINE_BREAK_BYTES? ?? A blank line in the manifest may be seen as significant. ?- in the write method: Change StringBuffer to StringBuilder ?- The javadoc links to MANIFEST_VERSION and SIGNATURE_VERSION should use "#". ???? * {@link Attributes.Name#MANIFEST_VERSION} or ???? * {@link Attributes.Name#SIGNATURE_VERSION} must be set in Thanks, Roger On 12/04/2018 03:34 AM, Philipp Kunz wrote: > Hi Roger, > > I'm afraid the previous patch missed the tests, should be included > this time. > > The intention of the patch is to solve only bug 8066619 about > deprecation. I sincerely hope the changes are neutral. > > The new ValueUtf8Coding test heavily coincides/overlaps with 6202130 > which is why I mentioned it. I'm however not satisfied that that test > alone also completely solves 6202130 because 6202130 has or might have > implications with breaking characters encoded in UTF-8 with more than > one bytes across a line break onto a continuation line which is not > part of the current patch proposed for 8066619. At some point I > proposed ValueUtf8Coding with only removing the comments from the > implementation in > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056166.html > but I have changed my mind since then and think now 6202130 should > also change the implementation not to break lines inside of multi-byte > characters which is not part of the current patch and is probably > easier after the current patch if necessary at all. Both 6202130 and > the current patch for 8066619 here touch the UTF-8 coding of manifests > and which ever is solved first should add a corresponding test because > no such test exists yet I believe. Worth to mention are > test/jdk/tools/launcher/DiacriticTest.java and > test/jdk/tools/launcher/UnicodeTest.java both of which test the JVM > launch and have a somewhat different purpose. I haven't found any > other test for the specifically changed lines of code apart from > probably many tests that use manifests indirectly in some form. > > Regards, > Philipp > > > On Mon, 2018-12-03 at 16:43 -0500, Roger Riggs wrote: >> Hi Phillip, >> >> The amount detail obscures the general purpose. >> And there appears to be more than 1. >> The Jira issue IDs mentioned are 8066619 and 6202130. >> >> Is this functionally neutral and only fixes the deprecations? >> >> There is a mention that a test is needed for multi-byte chars, but a test >> is not included.? Is there an existing test for that? >> >> Its probably best to identify the main functional improvement (multi-byte) >> and fix the deprecation as a side effect. >> >> Thanks for digging through the issues and the explanations; >> it will take a bit of study to unravel and understand everything in this >> changeset. >> >> Regards, Roger >> >> >> On 12/01/2018 06:49 AM, Philipp Kunz wrote: >>> Find the proposed patch attached. Some comments and explanations, >>> here: There is a quite interesting implementation in Manifest and >>> Attributes worth quite some explanation. The way it used to work >>> before was: 1. put manifest header name, colon and space into a >>> StringBuffer -> the buffer now contains a string of characters each >>> high-byte of which is zero as explained later why this is important. >>> the high-bytes are zero because the set of allowed characters is >>> very limited to ":", " ", "a" - "z", "A" - "Z", "0" - "9", "_", and >>> "-" according to Attributes.Name#hash(String) so far with only the >>> name and the separator and yet without the values. 2. if the value >>> is not null, encode it in UTF-8 into a byte array and instantiate a >>> String with it using deprecated String#String(byte[],int,int,int) >>> resulting in a String with the same length as the byte array before >>> holding one byte in each character's low-byte. This makes a >>> difference for characters encoded with more than one byte in UTF-8. >>> The new String is potentially longer than the original value. 3.?if >>> the value is not null, append value to buffer. The one UTF-8 encoded >>> byte per character from the appended string is preserved also in the >>> buffer along with the previous buffer contents. 3alt. if the value >>> is null, add "null" to the buffer. See >>> java.lang.AbstractStringBuilder#append(String). Neither of the >>> characters of "null" has a non-zero high-byte encoded as UTF-16 >>> chars. 4. make72Safe inserts line breaks with continuation spaces. >>> Note that the buffer here contains only one byte per character >>> because all high- bytes are still zero so that line.length() and >>> line.insert(index, ...) effectively operate with byte offsets and >>> not characters. 5. buffer.toString() 6. >>> DataOutputStream#writeBytes(String). First of all read the JavaDoc >>> comment for it, which explains it all: Writes out the string to the >>> underlying output stream as a ????sequence of bytes. Each character >>> in the string is written out, in ????sequence, by discarding its >>> high eight bits. If no exception is ????thrown, the counter >>> written is incremented by the ????length of >>> s This restores the earlier UTF-8 encoding correctly. >>> The topic has been discussed and mentioned already in >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052946.ht >>> ml https://bugs.openjdk.java.net/browse/JDK-6202130 >>> String(byte[],int,int,int) works "well" or "well enough" only >>> together with DataOutputStream#writeBytes(String). When removing >>> String(byte[],int,int,int) from Manifest and Attributes because >>> deprecated, it makes no sense to keep using >>> DataOutputStream#writeBytes(String) either. For the same reason >>> as?String#String(byte[],int,int,int) has been deprecated, I suggest >>> to also deprecate java.io.DataOutput#writeBytes(String) as a >>> separate issue. This might relate to >>> https://bugs.openjdk.java.net/browse/JDK-6400767 but that one came >>> to a different conclusion some ten years ago. I preferred to stick >>> with the DataOutputStream even though not strictly necessary any >>> more. It is and has been in the API of Attributes (unfortunately not >>> private) and should better not be removed by changing the parameter >>> type. Same for Manifest#make72Safe(StringBuffer) which I deprecated >>> rather than having removed. Someone could have extended a class from >>> Manifest and use such a method and when changing the signature it >>> could no longer even compile in a far-fetched case. LINE_BREAK, >>> CONTINUATION_SPACE, LINE_BREAK_BYTES, and >>> LINE_BREAK_WITH_CONTINUATION_SPACE_BYTES should prevent having to >>> invoke getBytes(UTF_8) over and over again on "\r\n" and "\r\n " >>> with the idea to slightly improve performance this way. I figured it >>> does not need JavaDoc comments but would be happy to add them if >>> desired. I removed "XXX Need to handle UTF8 values." from >>> Manifest#read after adding a test for it in ValueUtf8Coding. This >>> change and test also relate to bug 6202130 but does not solve that >>> one completely. ValueUtf8Coding demonstrates that Manifest can read >>> UTF-8 encoded values which is a necessary test case to cover for >>> this patch here. ValueUtf8Coding is the same test as already >>> submitted and suggested earlier. See >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/threa >>> d.html#55848 Indentation in Attributes#write(DataOutputStream) was >>> five spaces on most lines. I?fixed indentation only on the lines >>> changed anyway. I replaced String#String(byte[],int,int,String) with >>> String#String(byte[],int,int,java.nio.charset.StandardCharsets.UTF_8) >>> which as a difference does not declare to throw a >>> java.io.UnsupportedEncodingException. That also replaced "UTF8" as a >>> charset name which I would consider not optimal regarding >>> sun.nio.cs.UTF_8#UTF_8() and sun.nio.cs.UTF_8#historicalName(). In >>> my opinion there is still some duplicated or at least very similar >>> code in Manifest#write, Attributes#writeMain, and Attributes#write >>> but I preferred to change less rather than more and not to further >>> refactor and re-combine it. In EmptyKeysAndValues and >>> NullKeysAndValues tests I tried to demonstrate that the changed >>> implementation does not change behaviour also in edge cases. I would >>> have expected not having to test all these cases but then I realized >>> it was possible to test and is therefore possible in a real use case >>> as well however far-fetched. At least the if (value != null) { lines >>> (three times) most obviously demand to test the null value cases. >>> I'm looking curiously forward to any kind of feedback or opinion. >>> Philipp >> >> From daniel.fuchs at oracle.com Wed Dec 12 16:04:42 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Dec 2018 16:04:42 +0000 Subject: RFR (trivial): 8211093: Default logging.properties sets log level for com.xyz.foo Message-ID: Hi, Please find below a fix for: 8211093: Default logging.properties sets log level for com.xyz.foo https://bugs.openjdk.java.net/browse/JDK-8211093 Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8211093/webrev.00 best regards, -- daniel From alexey.ivanov at oracle.com Wed Dec 12 16:02:33 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:02:33 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: Hi Simon, I'd like to clarify some points? Please see my comments inline: On 11/12/2018 17:16, Alexey Ivanov wrote: > Hi Simon, > > Thank you for your comments. > > The updated webrev: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > > Indeed, it looks much cleaner. > > Regards, > Alexey > > On 11/12/2018 16:43, Simon Tooke wrote: >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as >>> well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention.? So, the patch only works for 16 bytes of >> parameters.? To be generic, the routine needs to have the stack size >> passed in by the caller.? If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. At this time, it's only one function. So the current approach works well enough, although it will not scale. If other similar functions are added in the future, _OnUnload for example, we should implement approach used in Hotspot as suggested by Bob: http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024373.html >> >> >> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >> (jdwpTransport_OnLoad_t) >> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif I believe falling back to undecorated name is the right thing in the case where the decorated name isn't found. Only the undecorated name has been looked up before. If a (third-party) JDWP transport DLL exports the undecorated name only, it will fail to load. With fallback in place, it will load successfully. Does it sound reasonable? Regards, Alexey >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. > From alexey.ivanov at oracle.com Wed Dec 12 16:10:57 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:10:57 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> Message-ID: <6345d99a-de96-2659-b1e2-b9a137847b68@oracle.com> Ali has scanned the code base, he says, ?couldn?t find (hopefully tbh) other occurrences of such mismatches.? On 10/12/2018 10:45, Magnus Ihse Bursie wrote: > It might be worthwhile to scan the entire code base for JNICALL and > verify that we have no more mismatches. In general, JNICALL should be > preserved on all officially supported, exported interfaces. It need > not be present on interfaces used only internally, and my current > thinking is that it would be better if it were removed on all internal > interfaces. But at the very least, it should be consistently > specificed where exported and imported. (Any misses here is probably > due to duplicate declarations, instead of properly including header > files, so that's the correct way to resolve any problems found...) -- Regards, Alexey From alexey.ivanov at oracle.com Wed Dec 12 16:13:30 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:13:30 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <998A7FEB-9846-40F5-8880-1812302F002F@gmail.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> <998A7FEB-9846-40F5-8880-1812302F002F@gmail.com> Message-ID: <49872f2d-229e-6da9-6d35-2db161f3f589@oracle.com> Thank you, Ali, for doing this! On 10/12/2018 21:13, Ali ?nce wrote: > Hi Alexey, > > I?ve searched for |GetProcAddress| usages across source code and > couldn?t find (hopefully tbh) other occurrences of such mismatches. > > Regards, > > Ali > >> From alexey.ivanov at oracle.com Wed Dec 12 16:14:48 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:14:48 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <6345d99a-de96-2659-b1e2-b9a137847b68@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> <6345d99a-de96-2659-b1e2-b9a137847b68@oracle.com> Message-ID: <7189cb83-7a6e-4cf7-dc77-a91a18919e4e@oracle.com> Forgot to add the link: On 12/12/2018 16:10, Alexey Ivanov wrote: > Ali has scanned the code base, he says, ?couldn?t find (hopefully tbh) > other occurrences of such mismatches.? http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024358.html > > On 10/12/2018 10:45, Magnus Ihse Bursie wrote: >> It might be worthwhile to scan the entire code base for JNICALL and >> verify that we have no more mismatches. In general, JNICALL should be >> preserved on all officially supported, exported interfaces. It need >> not be present on interfaces used only internally, and my current >> thinking is that it would be better if it were removed on all >> internal interfaces. But at the very least, it should be consistently >> specificed where exported and imported. (Any misses here is probably >> due to duplicate declarations, instead of properly including header >> files, so that's the correct way to resolve any problems found...) > -- Regards, Alexey From Roger.Riggs at oracle.com Wed Dec 12 16:14:52 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Dec 2018 11:14:52 -0500 Subject: RFR (trivial): 8211093: Default logging.properties sets log level for com.xyz.foo In-Reply-To: References: Message-ID: <390607d1-7d98-d370-cc7c-b8826bc9f914@oracle.com> Hi Daniel, The change looks fine. The test addition is good, though it goes well beyond testing that bug is no longer present. Thnaks, Roger On 12/12/2018 11:04 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8211093: Default logging.properties sets log level for com.xyz.foo > https://bugs.openjdk.java.net/browse/JDK-8211093 > > Webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8211093/webrev.00 > > best regards, > > -- daniel From brian.burkhalter at oracle.com Wed Dec 12 16:22:15 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 12 Dec 2018 08:22:15 -0800 Subject: RFR (trivial): 8211093: Default logging.properties sets log level for com.xyz.foo In-Reply-To: <390607d1-7d98-d370-cc7c-b8826bc9f914@oracle.com> References: <390607d1-7d98-d370-cc7c-b8826bc9f914@oracle.com> Message-ID: Hi Daniel, Roger, +1 on the patch and Roger?s comment. Brian > On Dec 12, 2018, at 8:14 AM, Roger Riggs wrote: > > The change looks fine. > > The test addition is good, though it goes well beyond testing > that bug is no longer present. From mark.reinhold at oracle.com Wed Dec 12 16:33:09 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 12 Dec 2018 08:33:09 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> Message-ID: <20181212083309.70758469@eggemoggin.niobe.net> 2018/12/11 16:38:32 -0800, stuart.marks at oracle.com: > Adam, > > Starting from your patch, I've removed changes relating to "crap" and "damn" and > the changes to upstream jszip.js. This leaves the patches appended below. The > SoftChannel.java change is most likely a typo that should be fixed. The > BitArray.java change is part of Xalan. We don't actually keep our sources in > sync with Xalan, but I note that upstream [7] has made the same change, so we > might as well change it too. > > ... Thanks for the enlightening historical analysis, and for wrangling this patch. > ... > > # HG changeset patch > # User afarley > # Date 1544574289 28800 > # Tue Dec 11 16:24:49 2018 -0800 > # Node ID 0c40c78b6d139eb05b0718d0b524a465419ee9cb > # Parent b75a44aad06cd93c823159265a1f200bf0ce390c > 8215217: OpenJDK Source Has Too Many Swear Words Nit: Please use sentence case in issue summaries (?OpenJDK source has too many swear words?) rather than title case. This is just a patch, not a novel. - Mark From alexey.ivanov at oracle.com Wed Dec 12 16:38:27 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:38:27 +0000 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry (was: [PATCH] Windows 32-bit DLL name decoration) In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: Hi all, I have updated the summary of JDK-8214122 and the subject accordingly. Could you please review the following fix? https://bugs.openjdk.java.net/browse/JDK-8214122 webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ *Root cause* jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 bit Windows according to the name decorations [1] for __stdcall [2] calling conventions. *Fix* On 32 bit Windows, look up the decorated name, _jdwpTransport_OnLoad at 16, first; if not found, look up the undecorated name, jdwpTransport_OnLoad. Regards, Alexey [1] https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 On 12/12/2018 11:19, Magnus Ihse Bursie wrote: > > > On 2018-12-11 18:16, Alexey Ivanov wrote: >> Hi Simon, >> >> Thank you for your comments. >> >> The updated webrev: >> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >> >> Indeed, it looks much cleaner. > Yes! This seems like the correct fix. > > Ship it! :) > > /Magnus > >> >> Regards, >> Alexey >> >> On 11/12/2018 16:43, Simon Tooke wrote: >>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>> Hi everyone, >>>> >>>> I came up with the following patch: >>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>> >>>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>> __stdcall-mangled name. I used conditional compilation so that for >>>> other platforms the code remains as it is now. >>>> >>>> jshell starts successfully with this fix; an IDE debugger works as >>>> well. >>>> >>> I am not a reviewer, but this patch only works for the specific case >>> under discussion; the '@16' refers to the reserved stack size in the >>> Pascal calling convention.? So, the patch only works for 16 bytes of >>> parameters.? To be generic, the routine needs to have the stack size >>> passed in by the caller.? If a generic fix isn't desired (and I hope it >>> is), I'd prefer to see the caller simply pass the decorated or >>> undecorated name depending on the Win32/64 defines. >>> >>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>> (jdwpTransport_OnLoad_t) >>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>> >>> >>> Thanks, >>> -Simon >>> >>>> Regards, >>>> Alexey >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>> >>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>> Since removing JNICALL is not an option, there are only two options: >>>>>> >>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>> source file; >>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>> with fallback to undecorated one. >>>>> Yes. >>>>> >>>>> I think the correct solution here is 2. >> > From magnus.ihse.bursie at oracle.com Wed Dec 12 16:43:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 17:43:18 +0100 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> On 2018-12-12 17:38, Alexey Ivanov wrote: > Hi all, > > I have updated the summary of JDK-8214122 and the subject accordingly. > > Could you please review the following fix? > > https://bugs.openjdk.java.net/browse/JDK-8214122 > webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Looks good to me. /Magnus > > *Root cause* > jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 bit > Windows according to the name decorations [1] for __stdcall [2] > calling conventions. > > *Fix* > On 32 bit Windows, look up the decorated name, > _jdwpTransport_OnLoad at 16, first; if not found, look up the undecorated > name, jdwpTransport_OnLoad. > > > Regards, > Alexey > > [1] > https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC > [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 > > On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-11 18:16, Alexey Ivanov wrote: >>> Hi Simon, >>> >>> Thank you for your comments. >>> >>> The updated webrev: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>> >>> Indeed, it looks much cleaner. >> Yes! This seems like the correct fix. >> >> Ship it! :) >> >> /Magnus >> >>> >>> Regards, >>> Alexey >>> >>> On 11/12/2018 16:43, Simon Tooke wrote: >>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>> Hi everyone, >>>>> >>>>> I came up with the following patch: >>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>> >>>>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>> other platforms the code remains as it is now. >>>>> >>>>> jshell starts successfully with this fix; an IDE debugger works as >>>>> well. >>>>> >>>> I am not a reviewer, but this patch only works for the specific case >>>> under discussion; the '@16' refers to the reserved stack size in the >>>> Pascal calling convention. So, the patch only works for 16 bytes of >>>> parameters. To be generic, the routine needs to have the stack size >>>> passed in by the caller. If a generic fix isn't desired (and I >>>> hope it >>>> is), I'd prefer to see the caller simply pass the decorated or >>>> undecorated name depending on the Win32/64 defines. >>>> >>>> #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>> "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>> (jdwpTransport_OnLoad_t) >>>> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>> >>>> >>>> Thanks, >>>> -Simon >>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>> >>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>> options: >>>>>>> >>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>> source file; >>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>>> with fallback to undecorated one. >>>>>> Yes. >>>>>> >>>>>> I think the correct solution here is 2. >>> >> > From claes.redestad at oracle.com Wed Dec 12 16:53:11 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 17:53:11 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base Message-ID: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Hi, please review this patch to use String.isEmpty when applicable: Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Why? - It reads better :-) - Better startup/warmup due fewer method invocations - Better peak performance: String.isEmpty is ~1.2x faster than String.length Most changes are simple search and replace, but I took the liberty to clean out some dead/pointless uses and improve formatting in places due the shorter expression length. Instances of "".equals(string) were only changed when it was immediately obvious that string is not null, e.g., due a preceding null check. Thanks! /Claes From daniel.fuchs at oracle.com Wed Dec 12 16:54:29 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Dec 2018 16:54:29 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> Hi Claes, It might read even better if things like: + resultString = !specarg.isEmpty() ? specarg.intern(): opt; were changed into: + resultString = specarg.isEmpty() ? opt : specarg.intern(); best regards, -- daniel On 12/12/2018 16:53, Claes Redestad wrote: > Hi, > > please review this patch to use String.isEmpty when applicable: > > Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > > Why? > - It reads better :-) > - Better startup/warmup due fewer method invocations > - Better peak performance: String.isEmpty is ~1.2x faster than > ? String.length > > Most changes are simple search and replace, but I took the liberty to > clean out some dead/pointless uses and improve formatting in places due > the shorter expression length. > > Instances of "".equals(string) were only changed when it was immediately > obvious that string is not null, e.g., due a preceding null check. > > Thanks! > > /Claes From magnus.ihse.bursie at oracle.com Wed Dec 12 16:52:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 17:52:15 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> Message-ID: <4b5b40b0-7206-1852-179e-3bb582b4f8c2@oracle.com> On 2018-12-12 16:34, Alexey Ivanov wrote: > > > On 12/12/2018 12:58, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-12 12:35, Alan Bateman wrote: >>> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >>>> : >>>> >>>> I searched the code for "jdwpTransport_On" to see of there was any >>>> corresponding OnUnload function (or other), but could not find any. >>> That's right, an unload wasn't needed when that SPI was originally >>> added but could be added in the event that some future debugger >>> agent need it. The SPI is a supported/documented JDK-specific >>> mechanism, its "spec" is hosted here: >>> >>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html >>> >> ... yet in all that time, we have not fully supported the spec on >> Windows 32. :-( (We never discovered this because of lack of testing, >> I presume, and that our internal usage empoyed a questonable >> workaround.) > > The spec does not specify whether the mangled name should be exported > or not (for Windows 32 bit). > > I looked through JNI specification and have found no mention of > JNIEXPORT or JNICALL. > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html > > This example uses extern "C" modifier but neither JNIEXPORT or JNICALL: > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments > I'm not sure if it's worth continuing this discussion, but at the very least the specs have been not very clear on this. The links you cite point to the JNI specification, not JDWP. I don't bother go looking for the exact place in the JNI spec, but I assume they state that you must implement the header file as generated by javac (formerly javah). These do look like this: * DO NOT EDIT THIS FILE - it is machine generated */ #include /* Header for class sun_nio_ch_FileKey */ #ifndef _Included_sun_nio_ch_FileKey #define _Included_sun_nio_ch_FileKey #ifdef __cplusplus extern "C" { #endif /* * Class: sun_nio_ch_FileKey * Method: init * Signature: (Ljava/io/FileDescriptor;)V */ JNIEXPORT void JNICALL Java_sun_nio_ch_FileKey_init (JNIEnv *, jobject, jobject); So at least implicitly, they say that you need to use JNIEXPORT and JNICALL. And there is no /export thingy here. And no instructions in the specs to do a specific export; if it were, we would have needed it for all the hundereds of JNI functions in the JDK. So obviously the JNI code reads decorated names on Windows 32. Then again, it is not clear that the spec for JNI should apply to JDWP. But, if they state that you must use the JNICALL, and this will, unless other actions are taken, such as using /export, by default create a decorated name, I think it's very clear that *if* this indeed was intended to be the formal interface, it *should* have been explicitly written in the spec. /Magnus > >> >>> >>> I see this thread is touching on the functions exported by libjli. >>> This library is part of the launcher and shouldn't be used directly >>> by anything outside of the JDK. However we have to be careful >>> because JavaFX `javapackager` tool has been using it. There's a JEP >>> to bring a similar tool, jpackage in the current proposal, that will >>> supersede it but in the mean time we need to be careful not to break >>> it. A second issue is that the libjli is listed in the property list >>> (Info.plist) on macOS. This came from Apple in 7u4 and periodically >>> things show up that are using it, e.g. that recent breakage with >>> Eclipse that was never fully diagnosed but we think it was using >>> Info.plist. >> The latest patch, as suggested, will not modify JLI, but instead fix >> the broken behaviour of JDWP on Windows 32. > > Yes, that's right. > However, I believe the previous versions did not modify libjli. > > Regards, > Alexey > >> >> /Magnus > From Alan.Bateman at oracle.com Wed Dec 12 16:56:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 16:56:17 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: On 12/12/2018 16:53, Claes Redestad wrote: > Hi, > > please review this patch to use String.isEmpty when applicable: > > Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > > Why? > - It reads better :-) > - Better startup/warmup due fewer method invocations > - Better peak performance: String.isEmpty is ~1.2x faster than > ? String.length > > Most changes are simple search and replace, but I took the liberty to > clean out some dead/pointless uses and improve formatting in places due > the shorter expression length. > > Instances of "".equals(string) were only changed when it was immediately > obvious that string is not null, e.g., due a preceding null check. In Checks.java, the parameter change from CharSequence to String means that "cs" needs to be renamed. -Alan. From Alan.Bateman at oracle.com Wed Dec 12 16:58:48 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 16:58:48 +0000 Subject: 8214696: Module class should be filtered by core reflection Message-ID: I'd like add java.lang.Module to list of classes that has its fields filtered from core reflection. As with previous addition in this area, this is another class where hacking its fields leads to integrity and security issues. The change is trivial: ?? http://cr.openjdk.java.net/~alanb/8214696/webrev/index.html -Alan From claes.redestad at oracle.com Wed Dec 12 17:04:33 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 18:04:33 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: <10eafdbe-f524-2534-3bea-3744c06fbc81@oracle.com> On 2018-12-12 17:56, Alan Bateman wrote: > In Checks.java, the parameter change from CharSequence to String means > that "cs" needs to be renamed. Changed to 'str' /Claes From alexey.ivanov at oracle.com Wed Dec 12 17:01:23 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 17:01:23 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <4b5b40b0-7206-1852-179e-3bb582b4f8c2@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> <4b5b40b0-7206-1852-179e-3bb582b4f8c2@oracle.com> Message-ID: On 12/12/2018 16:52, Magnus Ihse Bursie wrote: > On 2018-12-12 16:34, Alexey Ivanov wrote: >> >> >> On 12/12/2018 12:58, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-12 12:35, Alan Bateman wrote: >>>> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >>>>> : >>>>> >>>>> I searched the code for "jdwpTransport_On" to see of there was any >>>>> corresponding OnUnload function (or other), but could not find any. >>>> That's right, an unload wasn't needed when that SPI was originally >>>> added but could be added in the event that some future debugger >>>> agent need it. The SPI is a supported/documented JDK-specific >>>> mechanism, its "spec" is hosted here: >>>> >>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html >>>> >>> ... yet in all that time, we have not fully supported the spec on >>> Windows 32. :-( (We never discovered this because of lack of >>> testing, I presume, and that our internal usage empoyed a >>> questonable workaround.) >> >> The spec does not specify whether the mangled name should be exported >> or not (for Windows 32 bit). >> >> I looked through JNI specification and have found no mention of >> JNIEXPORT or JNICALL. >> https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html >> >> This example uses extern "C" modifier but neither JNIEXPORT or JNICALL: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments >> > I'm not sure if it's worth continuing this discussion, but at the very > least the specs have been not very clear on this. I absolutely agree it's not worth it. It does not solve the problem at hand; it does not solve any problem at all. So let's leave it here. -- Alexey > The links you cite point to the JNI specification, not JDWP. I don't > bother go looking for the exact place in the JNI spec, but I assume > they state that you must implement the header file as generated by > javac (formerly javah). These do look like this: > > * DO NOT EDIT THIS FILE - it is machine generated */ > #include > /* Header for class sun_nio_ch_FileKey */ > > #ifndef _Included_sun_nio_ch_FileKey > #define _Included_sun_nio_ch_FileKey > #ifdef __cplusplus > extern "C" { > #endif > /* > ?* Class:???? sun_nio_ch_FileKey > ?* Method:??? init > ?* Signature: (Ljava/io/FileDescriptor;)V > ?*/ > JNIEXPORT void JNICALL Java_sun_nio_ch_FileKey_init > ? (JNIEnv *, jobject, jobject); > > So at least implicitly, they say that you need to use JNIEXPORT and > JNICALL. And there is no /export thingy here. And no instructions in > the specs to do a specific export; if it were, we would have needed it > for all the hundereds of JNI functions in the JDK. So obviously the > JNI code reads decorated names on Windows 32. > > Then again, it is not clear that the spec for JNI should apply to > JDWP. But, if they state that you must use the JNICALL, and this will, > unless other actions are taken, such as using /export, by default > create a decorated name, I think it's very clear that *if* this indeed > was intended to be the formal interface, it *should* have been > explicitly written in the spec. > > /Magnus > > >> >>> >>>> >>>> I see this thread is touching on the functions exported by libjli. >>>> This library is part of the launcher and shouldn't be used directly >>>> by anything outside of the JDK. However we have to be careful >>>> because JavaFX `javapackager` tool has been using it. There's a JEP >>>> to bring a similar tool, jpackage in the current proposal, that >>>> will supersede it but in the mean time we need to be careful not to >>>> break it. A second issue is that the libjli is listed in the >>>> property list (Info.plist) on macOS. This came from Apple in 7u4 >>>> and periodically things show up that are using it, e.g. that recent >>>> breakage with Eclipse that was never fully diagnosed but we think >>>> it was using Info.plist. >>> The latest patch, as suggested, will not modify JLI, but instead fix >>> the broken behaviour of JDWP on Windows 32. >> >> Yes, that's right. >> However, I believe the previous versions did not modify libjli. >> >> Regards, >> Alexey >> >>> >>> /Magnus >> > From claes.redestad at oracle.com Wed Dec 12 17:06:24 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 18:06:24 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> Message-ID: <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> On 2018-12-12 17:54, Daniel Fuchs wrote: > Hi Claes, > > It might read even better if things like: > > +??????? resultString = !specarg.isEmpty() ? specarg.intern(): opt; > > were changed into: > > +??????? resultString = specarg.isEmpty() ? opt : specarg.intern(); > > best regards, I only found this pattern in this file, so incremental diff will look like the below. I will update in place due hugeness of webrev. Thanks! /Claes diff -r 732b03e40349 src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java Wed Dec 12 17:41:46 2018 +0100 +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java Wed Dec 12 18:03:57 2018 +0100 @@ -641,10 +641,10 @@ String specarg = spec.substring(sidx); switch (specop) { case '.': // terminate the option sequence - resultString = !specarg.isEmpty() ? specarg.intern(): opt; + resultString = specarg.isEmpty() ? opt : specarg.intern(); break doArgs; case '?': // abort the option sequence - resultString = !specarg.isEmpty() ? specarg.intern(): arg; + resultString = specarg.isEmpty() ? arg : specarg.intern(); isError = true; break eachSpec; case '@': // change the effective opt name @@ -655,7 +655,7 @@ val = ""; break; case '!': // negation option - String negopt = !specarg.isEmpty() ? specarg.intern(): opt; + String negopt = specarg.isEmpty() ? opt : specarg.intern(); properties.remove(negopt); properties.put(negopt, null); // leave placeholder didAction = true; From vicente.romero at oracle.com Wed Dec 12 17:02:45 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Dec 2018 12:02:45 -0500 Subject: RFR JDK-8215300: additional changes to constants API Message-ID: Hi, Please review some final changes to the constants API. The changes should make the API clearer and more precise and were recommended in the CSR [3] Thanks, Vicente [1] (jira issue) https://bugs.openjdk.java.net/browse/JDK-8215300 [2] (webrev) http://cr.openjdk.java.net/~vromero/8215300/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8202031 From lance.andersen at oracle.com Wed Dec 12 17:07:59 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 12 Dec 2018 12:07:59 -0500 Subject: 8214696: Module class should be filtered by core reflection In-Reply-To: References: Message-ID: Looks good Alan > On Dec 12, 2018, at 11:58 AM, Alan Bateman wrote: > > I'd like add java.lang.Module to list of classes that has its fields filtered from core reflection. As with previous addition in this area, this is another class where hacking its fields leads to integrity and security issues. The change is trivial: > http://cr.openjdk.java.net/~alanb/8214696/webrev/index.html > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mark.reinhold at oracle.com Wed Dec 12 17:27:57 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 12 Dec 2018 09:27:57 -0800 Subject: 12 RFR (XS) 8215301: Module-summary page is unreadably wide Message-ID: <20181212092757.307968556@eggemoggin.niobe.net> Bug: https://bugs.openjdk.java.net/browse/JDK-8215301 Webrev: https://cr.openjdk.java.net/~mr/rev/8215301/ The `make generate-summary` target produces a handy tabular summary of all of the modules in a JDK build into `$BUILD/images/gengraphs/module-summary.html`. Several JDK modules (e.g., `java.desktop` and `jdk.internal.vm.compiler`) include many providers for a particular service, and the providers are all listed in a single line, resulting in a very wide HTML page that?s difficult to read even on a large screen. Output before: https://cr.openjdk.java.net/~mr/rev/8215301/module-summary-old.html After: https://cr.openjdk.java.net/~mr/rev/8215301/module-summary-new.html Thanks, - Mark From henry.jen at oracle.com Wed Dec 12 17:36:06 2018 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 12 Dec 2018 09:36:06 -0800 Subject: RFR: 8215000: tools/launcher/JliLaunchTest.java fails on Windows Message-ID: Hi, Can I get a review of following patch? Looks like the assumption test jdk will be in PATH is simply not true, jtreg doesn?t do that. Also, this patch make sure the JDK to be tested is first in the search path. Cheers, Henry diff -r 241b8151b6b6 test/jdk/tools/launcher/JliLaunchTest.java --- a/test/jdk/tools/launcher/JliLaunchTest.java Fri Nov 30 13:42:49 2018 -0800 +++ b/test/jdk/tools/launcher/JliLaunchTest.java Wed Dec 12 09:31:53 2018 -0800 @@ -49,10 +49,12 @@ Map env = pb.environment(); if (Platform.isWindows()) { // The DLL should be in JDK/bin + String libdir = Paths.get(Utils.TEST_JDK).resolve("bin").toAbsolutePath().toString(); + env.compute("PATH", (k, v) -> (k == null) ? libdir : libdir + ";" + v); } else { String libdir = Paths.get(Utils.TEST_JDK).resolve("lib").toAbsolutePath().toString(); String LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; - env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? libdir : v + ":" + libdir); + env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? libdir : libdir + ":" + v); } OutputAnalyzer outputf = new OutputAnalyzer(pb.start()); From mandy.chung at oracle.com Wed Dec 12 17:38:01 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Dec 2018 09:38:01 -0800 Subject: 8214696: Module class should be filtered by core reflection In-Reply-To: References: Message-ID: On 12/12/18 8:58 AM, Alan Bateman wrote: > I'd like add java.lang.Module to list of classes that has its fields > filtered from core reflection. As with previous addition in this area, > this is another class where hacking its fields leads to integrity and > security issues. The change is trivial: > ?? http://cr.openjdk.java.net/~alanb/8214696/webrev/index.html Looks good to me. Mandy From vincent.x.ryan at oracle.com Wed Dec 12 18:21:20 2018 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 12 Dec 2018 18:21:20 +0000 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> <01C3CC6C-F645-40E3-A9FD-04017843F6F1@oracle.com> <33d0efad-60d8-4f41-f741-dcbc44b38da0@oracle.com> Message-ID: <5D024752-B1D2-43F7-AD90-17C86EB1CE38@oracle.com> FYI I?ve updated the webrev/javadoc with latest edits including the 2 new ByteBuffer methods: http://cr.openjdk.java.net/~vinnie/8170769/webrev.09/ http://cr.openjdk.java.net/~vinnie/8170769/javadoc.09/api/java.base/java/util/HexFormat.html (NOTE: internal link to HexFormat.Formatter class is currently broken) If that is an acceptable compromise then I believe all outstanding issues have now been addressed. Thanks to all those who provided review comments. > On 12 Dec 2018, at 12:32, Vincent Ryan wrote: > > Thanks for your proposal. > Comments below. > >> On 12 Dec 2018, at 02:35, Stuart Marks wrote: >> >> >> >> On 12/11/18 1:21 PM, Vincent Ryan wrote: >>> My preference is for PrintStream rather than Writer, for the same reason as Roger: it?s more convenient >>> for handling System.out. Does that address your concern? >> >> PrintStream is fine with me. >> >>> I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte charset so some 0x8X characters >>> Will trigger the multi-byte sequence and will end up being misinterpreted. Hence my rather awkward conversion to a String. >>> Is there a better way? >> >> In toPrintableString(), >> >> 259 StringBuilder printable = new StringBuilder(toIndex - fromIndex); >> 260 for (int i = fromIndex; i < toIndex; i++) { >> 261 if (bytes[i] > 0x1F && bytes[i] < 0x7F) { >> 262 printable.append((char) bytes[i]); >> 263 } else if (bytes[i] > (byte)0x9F && bytes[i] <= (byte)0xFF) { >> 264 printable.append(new String(new byte[]{bytes[i]}, ISO_8859_1)); >> 265 >> 266 } else { >> 267 printable.append('.'); >> 268 } >> 269 } >> >> It works to cast ASCII bytes char, because the 7-bit ASCII range overlaps the low 7 bits of the UTF-16 char range. The bytes values of ISO 8859-1 overlap the low 8 bits of UTF-16, so casts work for them too. >> >> For any other charset, you'd need to do codeset conversion. But you're cleverly supporting only ISO 8859-1, so you don't have to do any conversion. :-) >> >>> I?m not sure I?ve addressed your concern regarding IOExceptions - can you elaborate? >> >> Taking out the OutputStream overloads addressed my concerns. In at least one case the code would wrap the OutputStream into a PrintStream, print stuff to it, and then throw away the PrintStream. If an output error occurred, any error state in the PrintStream would also be thrown away. The creation of the PrintStream wrapper would also use the system's default charset instead of letting the caller control it. >> >> The dump() overloads now all take PrintStream, so it's the caller's responsibility to ensure that the PrintStream is using the right charset and to check for errors after. So this is all OK now. >> >> Note that the internal getPrintStream(), to wrap an OutputStream in a PrintStream, is now obsolete and can be removed. >> >> (Oh, I see Roger has said much the same things. Oh well, the peril of parallel reviews.) >> >> ** >> >>> BTW updated webrev/javadoc available: >>> http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ >>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html >> >> Now we have a somewhat unsatisfying asymmetry in the APIs. >> >> There are four kinds of inputs: >> >> 1. byte[] >> 2. byte[] subrange >> 3. InputStream >> 4. ByteBuffer >> >> and two kinds of outputs: >> >> 1. PrintStream >> 2. Stream >> >> and two variations of formatters: >> >> 1. default formatter >> 2. custom formatter + chunk size >> >> This is a total of 16 combinations. But there are only eight methods: three PrintStream methods with choice of input, two stream-output methods using the default formatter, and three stream-output methods using custom chunk+formatter. >> >> You don't have to provide ALL combinations, but what's here is an odd subset with some apparently arbitrary choices. For example, if I have a ByteBuffer and I want to dump it to System.out using default formatting, I have to go the Stream.forEachOrdered route AND provide the default chunk size and formatter. >> >> HexFormat.dumpAsStream(buf, DEFAULT_CHUNK_SIZE, HEXDUMP_FORMATTER) >> .forEachOrdered(System.out::println); >> >> These aren't huge deals, but they're easily stumbled over. >> >> One approach to organizing this is to have a HexFormat instance that contains the setup information and then to have instance methods that either update the setup or perform conversion and output. I'd use static factory methods instead of constructors. For example, you could do this: >> >> static factories methods: >> - from(byte[]) >> - from(byte[], fromIndex, toIndex) >> - from(InputStream) >> - from(ByteBuffer) >> >> formatter setup instance methods: >> - format(chunksize, formatter) >> >> output: >> - void dump(PrintStream) >> - Stream stream() >> >> Using this approach my example from above could be performed as follows: >> >> HexFormat.from(buf).dump(System.out); >> >> Note, I'm not saying that you HAVE to do it this way. (In particular, the naming could use work.) This is quite possibly overkill. But it's something you might consider, as it gets you all 16 combinations using seven methods, compared to the eight static methods in the current proposal that cover only half of the combinations. >> >> Alternatively, pare down the set of static methods to a bare minimum. Provide one that can do everything, and then provide one or two more that are essentially the same as the first but with some hardwired defaults. For example, to help minimize things, you can wrap a ByteBuffer around a byte array subrange, or get an InputStream from a byte array subrange. But you can't get an InputStream from a ByteBuffer or vice-versa, without a lot of work. >> >> (I haven't looked at the to* or from* methods.) >> >> s?marks > > Your chaining approach has merit and the method chaining is attractive but it would be a significant change to the API at this advanced stage. > > I agree that there are gaps in the combinations and perhaps that could be addressed by introducing a few convenience methods. > I think ByteBuffer is under-represented and propose adding the following two methods to handle the simplified, default cases: > > public static Stream dumpAsStream(ByteBuffer buffer) > > public static void dump(ByteBuffer buffer, PrintStream out) > > > That would be 10 combos for 10 methods versus 16 combos for 7 methods which is still not full coverage but perhaps more methods could > be added in the future if there is demand for them. > > > > From brent.christian at oracle.com Wed Dec 12 18:30:04 2018 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 12 Dec 2018 10:30:04 -0800 Subject: RFR: 8215000: tools/launcher/JliLaunchTest.java fails on Windows In-Reply-To: References: Message-ID: <22c8f70d-0ed7-e84c-840f-0cb031c68963@oracle.com> Hi, Shouldn't the lambdas be checking for v == null, rather than k == null? -Brent On 12/12/18 9:36 AM, Henry Jen wrote: > Hi, > > Can I get a review of following patch? > > Looks like the assumption test jdk will be in PATH is simply not true, jtreg doesn?t do that. > Also, this patch make sure the JDK to be tested is first in the search path. > > Cheers, > Henry > > > diff -r 241b8151b6b6 test/jdk/tools/launcher/JliLaunchTest.java > --- a/test/jdk/tools/launcher/JliLaunchTest.java Fri Nov 30 13:42:49 2018 -0800 > +++ b/test/jdk/tools/launcher/JliLaunchTest.java Wed Dec 12 09:31:53 2018 -0800 > @@ -49,10 +49,12 @@ > Map env = pb.environment(); > if (Platform.isWindows()) { > // The DLL should be in JDK/bin > + String libdir = Paths.get(Utils.TEST_JDK).resolve("bin").toAbsolutePath().toString(); > + env.compute("PATH", (k, v) -> (k == null) ? libdir : libdir + ";" + v); > } else { > String libdir = Paths.get(Utils.TEST_JDK).resolve("lib").toAbsolutePath().toString(); > String LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; > - env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? libdir : v + ":" + libdir); > + env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? libdir : libdir + ":" + v); > } > > OutputAnalyzer outputf = new OutputAnalyzer(pb.start()); > From mandy.chung at oracle.com Wed Dec 12 18:40:25 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Dec 2018 10:40:25 -0800 Subject: 12 RFR (XS) 8215301: Module-summary page is unreadably wide In-Reply-To: <20181212092757.307968556@eggemoggin.niobe.net> References: <20181212092757.307968556@eggemoggin.niobe.net> Message-ID: <04dd0b1d-a273-4d35-5a50-4f7282e61030@oracle.com> Looks good. This makes the list of providers very clear.?? Thanks for making this change. Mandy On 12/12/18 9:27 AM, mark.reinhold at oracle.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8215301 > Webrev: https://cr.openjdk.java.net/~mr/rev/8215301/ > > The `make generate-summary` target produces a handy tabular summary > of all of the modules in a JDK build into > `$BUILD/images/gengraphs/module-summary.html`. Several JDK modules > (e.g., `java.desktop` and `jdk.internal.vm.compiler`) include many > providers for a particular service, and the providers are all listed > in a single line, resulting in a very wide HTML page that?s difficult > to read even on a large screen. > > Output before: https://cr.openjdk.java.net/~mr/rev/8215301/module-summary-old.html > After: https://cr.openjdk.java.net/~mr/rev/8215301/module-summary-new.html > > Thanks, > - Mark From mandy.chung at oracle.com Wed Dec 12 18:50:09 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Dec 2018 10:50:09 -0800 Subject: RFR: 8215000: tools/launcher/JliLaunchTest.java fails on Windows In-Reply-To: <22c8f70d-0ed7-e84c-840f-0cb031c68963@oracle.com> References: <22c8f70d-0ed7-e84c-840f-0cb031c68963@oracle.com> Message-ID: <764f6de7-a03c-302f-e532-0a1dd42f23e9@oracle.com> Brent is right since k is the given key and non-null.? Although it does not cause any issue as it only adds an empty element in the path, we should fix it in this patch. Mandy On 12/12/18 10:30 AM, Brent Christian wrote: > Hi, > > Shouldn't the lambdas be checking for v == null, rather than k == null? > > -Brent > > On 12/12/18 9:36 AM, Henry Jen wrote: >> Hi, >> >> Can I get a review of following patch? >> >> Looks like the assumption test jdk will be in PATH is simply not >> true, jtreg doesn?t do that. >> Also, this patch make sure the JDK to be tested is first in the >> search path. >> >> Cheers, >> Henry >> >> >> diff -r 241b8151b6b6 test/jdk/tools/launcher/JliLaunchTest.java >> --- a/test/jdk/tools/launcher/JliLaunchTest.java??????? Fri Nov 30 >> 13:42:49 2018 -0800 >> +++ b/test/jdk/tools/launcher/JliLaunchTest.java??????? Wed Dec 12 >> 09:31:53 2018 -0800 >> @@ -49,10 +49,12 @@ >> ????????? Map env = pb.environment(); >> ????????? if (Platform.isWindows()) { >> ????????????? // The DLL should be in JDK/bin >> +??????????? String libdir = >> Paths.get(Utils.TEST_JDK).resolve("bin").toAbsolutePath().toString(); >> +??????????? env.compute("PATH", (k, v) -> (k == null) ? libdir : >> libdir + ";" + v); >> ????????? } else { >> ????????????? String libdir = >> Paths.get(Utils.TEST_JDK).resolve("lib").toAbsolutePath().toString(); >> ????????????? String LD_LIBRARY_PATH = Platform.isOSX() ? >> "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; >> -??????????? env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? >> libdir : v + ":" + libdir); >> +??????????? env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? >> libdir : libdir + ":" + v); >> ????????? } >> >> ????????? OutputAnalyzer outputf = new OutputAnalyzer(pb.start()); >> From Roger.Riggs at oracle.com Wed Dec 12 19:03:45 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Dec 2018 14:03:45 -0500 Subject: RFR 8215309 : Convert package.html files to package-info.java files Message-ID: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> Please review a conversion of some package.html files to package-info.java files. This bunch targets packages: package com.sun.rowset.providers; package java.rmi; package java.rmi.activation; package java.rmi.dgc; package java.rmi.registry; package java.rmi.server; package java.sql; package java.util.logging; package java.util.prefs; package javax.rmi.ssl; package javax.smartcardio; package javax.sql; package javax.sql.rowset.serial; Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/ Thanks, Roger From joe.darcy at oracle.com Wed Dec 12 19:21:42 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 12 Dec 2018 11:21:42 -0800 Subject: RFR 8215309 : Convert package.html files to package-info.java files In-Reply-To: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> References: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> Message-ID: Hi Roger, From a quick skim, the changes looked fine. Thanks, -Joe On 12/12/2018 11:03 AM, Roger Riggs wrote: > Please review a conversion of some package.html files to > package-info.java files. > This bunch targets packages: > > ?? package com.sun.rowset.providers; > ?? package java.rmi; > ?? package java.rmi.activation; > ?? package java.rmi.dgc; > ?? package java.rmi.registry; > ?? package java.rmi.server; > ?? package java.sql; > ?? package java.util.logging; > ?? package java.util.prefs; > ?? package javax.rmi.ssl; > ?? package javax.smartcardio; > ?? package javax.sql; > ?? package javax.sql.rowset.serial; > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/ > > Thanks, Roger > > From henry.jen at oracle.com Wed Dec 12 19:39:37 2018 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 12 Dec 2018 11:39:37 -0800 Subject: RFR: 8215000: tools/launcher/JliLaunchTest.java fails on Windows In-Reply-To: <764f6de7-a03c-302f-e532-0a1dd42f23e9@oracle.com> References: <22c8f70d-0ed7-e84c-840f-0cb031c68963@oracle.com> <764f6de7-a03c-302f-e532-0a1dd42f23e9@oracle.com> Message-ID: <543AA5AD-CB05-4700-99D4-4D4651CC8FF9@oracle.com> Duh, should be v==null. Thanks for catching it. Cheers, Henry > On Dec 12, 2018, at 10:50 AM, Mandy Chung wrote: > > Brent is right since k is the given key and non-null. Although it does not cause any issue as it only adds an empty element in the path, we should fix it in this patch. > > Mandy > > On 12/12/18 10:30 AM, Brent Christian wrote: >> Hi, >> >> Shouldn't the lambdas be checking for v == null, rather than k == null? >> >> -Brent >> >> On 12/12/18 9:36 AM, Henry Jen wrote: >>> Hi, >>> >>> Can I get a review of following patch? >>> >>> Looks like the assumption test jdk will be in PATH is simply not true, jtreg doesn?t do that. >>> Also, this patch make sure the JDK to be tested is first in the search path. >>> >>> Cheers, >>> Henry >>> >>> >>> diff -r 241b8151b6b6 test/jdk/tools/launcher/JliLaunchTest.java >>> --- a/test/jdk/tools/launcher/JliLaunchTest.java Fri Nov 30 13:42:49 2018 -0800 >>> +++ b/test/jdk/tools/launcher/JliLaunchTest.java Wed Dec 12 09:31:53 2018 -0800 >>> @@ -49,10 +49,12 @@ >>> Map env = pb.environment(); >>> if (Platform.isWindows()) { >>> // The DLL should be in JDK/bin >>> + String libdir = Paths.get(Utils.TEST_JDK).resolve("bin").toAbsolutePath().toString(); >>> + env.compute("PATH", (k, v) -> (k == null) ? libdir : libdir + ";" + v); >>> } else { >>> String libdir = Paths.get(Utils.TEST_JDK).resolve("lib").toAbsolutePath().toString(); >>> String LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; >>> - env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? libdir : v + ":" + libdir); >>> + env.compute(LD_LIBRARY_PATH, (k, v) -> (k == null) ? libdir : libdir + ":" + v); >>> } >>> >>> OutputAnalyzer outputf = new OutputAnalyzer(pb.start()); >>> > From lance.andersen at oracle.com Wed Dec 12 19:44:53 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 12 Dec 2018 14:44:53 -0500 Subject: RFR 8215309 : Convert package.html files to package-info.java files In-Reply-To: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> References: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> Message-ID: Hi Roger, I went through the changes and look OK as nothing jumped out. > On Dec 12, 2018, at 2:03 PM, Roger Riggs wrote: > > Please review a conversion of some package.html files to package-info.java files. > This bunch targets packages: > > package com.sun.rowset.providers; > package java.rmi; > package java.rmi.activation; > package java.rmi.dgc; > package java.rmi.registry; > package java.rmi.server; > package java.sql; > package java.util.logging; > package java.util.prefs; > package javax.rmi.ssl; > package javax.smartcardio; > package javax.sql; > package javax.sql.rowset.serial; > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/ > > Thanks, Roger > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Wed Dec 12 20:16:43 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Dec 2018 12:16:43 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: Software is hard. I found myself removing the remaining style changes to be able to review the changes. (We're going to have to disagree about the value of curlies). Here's my reduction: --- src/main/java/util/HashMap.java 11 Nov 2018 16:27:28 -0000 1.9 +++ src/main/java/util/HashMap.java 12 Dec 2018 20:10:03 -0000 @@ -503,7 +503,7 @@ threshold = tableSizeFor(t); } else if (s > threshold) - resize(); + resize(s); for (Map.Entry e : m.entrySet()) { K key = e.getKey(); V value = e.getValue(); @@ -661,6 +661,30 @@ } /** + * Resizes the table to the nearest power of two to {@code size}. + * Moves all items to the new table. + * + * @param size expected number of elements in the new table + * @return the table + */ + final Node[] resize(int size) { + if (size < 0) { + throw new IllegalArgumentException("Negative number of elements does not make sense."); + } + Node[] oldTable = table; + int oldCapacity = (oldTable == null) ? 0 : oldTable.length; + int newCapacity = tableSizeFor(size); + + // need to resize? + if (newCapacity > oldCapacity) { + threshold = (int) ((float) newCapacity * loadFactor); + return createTableAndMoveElements(newCapacity, oldCapacity, oldTable); + } else { + return oldTable; + } + } + + /** * Initializes or doubles table size. If null, allocates in * accord with initial capacity target held in field threshold. * Otherwise, because we are using power-of-two expansion, the @@ -695,6 +719,11 @@ (int)ft : Integer.MAX_VALUE); } threshold = newThr; + + return createTableAndMoveElements(newCap, oldCap, oldTab); + } + + private Node[] createTableAndMoveElements(int newCap, int oldCap, Node[] oldTab) { @SuppressWarnings({"rawtypes","unchecked"}) Node[] newTab = (Node[])new Node[newCap]; table = newTab; Here's a test that fails with the proposed patch: https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html /** * "Missing" test found while investigating JDK-8210280. * See discussion on mailing list. * TODO: randomize */ public void testBug8210280() { Map m = impl.emptyMap(); for (int i = 0; i < 4; i++) m.put(7 + i * 16, 0); Map more = impl.emptyMap(); for (int i = 0; i < 128; i++) more.put(-i, 42); m.putAll(more); for (int i = 0; i < 4; i++) assertEquals(0, m.get(7 + i * 16)); } From Roger.Riggs at oracle.com Wed Dec 12 20:15:47 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Dec 2018 15:15:47 -0500 Subject: RFR 8215309 : Convert package.html files to package-info.java files In-Reply-To: References: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> Message-ID: <66d05253-e3ac-771f-786e-f251df6a1db2@oracle.com> Thanks Joe, Lance. On 12/12/2018 02:44 PM, Lance Andersen wrote: > Hi Roger, > > I went through the changes and look OK as nothing jumped out. > > >> On Dec 12, 2018, at 2:03 PM, Roger Riggs > > wrote: >> >> Please review a conversion of some package.html files to >> package-info.java files. >> This bunch targets packages: >> >> ??package com.sun.rowset.providers; >> ??package java.rmi; >> ??package java.rmi.activation; >> ??package java.rmi.dgc; >> ??package java.rmi.registry; >> ??package java.rmi.server; >> ??package java.sql; >> ??package java.util.logging; >> ??package java.util.prefs; >> ??package javax.rmi.ssl; >> ??package javax.smartcardio; >> ??package javax.sql; >> ??package javax.sql.rowset.serial; >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/ >> >> >> Thanks, Roger >> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From martinrb at google.com Wed Dec 12 20:29:12 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Dec 2018 12:29:12 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: When hacking on HashMap, one always needs to keep LinkedHashMap in the back of one's mind. If you use removeEldestEntry then the occupancy can never get beyond some limit. It may be weird to have elements that are part of a putAll being removed during the call to putAll. There's already a call to resize causing the backing array to grow in this (very corner) case, so it's arguably not introducing new weird behavior. If removeEldestEntry is overridden then ideally you would only grow by doubling, but it's such a corner case this may not be worth doing. From david.holmes at oracle.com Wed Dec 12 21:25:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Dec 2018 07:25:19 +1000 Subject: 12 RFR (XS) 8215301: Module-summary page is unreadably wide In-Reply-To: <20181212092757.307968556@eggemoggin.niobe.net> References: <20181212092757.307968556@eggemoggin.niobe.net> Message-ID: <914b71e6-d336-fc35-47c6-4d0b4ce7795a@oracle.com> On 13/12/2018 3:27 am, mark.reinhold at oracle.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8215301 > Webrev: https://cr.openjdk.java.net/~mr/rev/8215301/ > > The `make generate-summary` target produces a handy tabular summary > of all of the modules in a JDK build into > `$BUILD/images/gengraphs/module-summary.html`. Several JDK modules > (e.g., `java.desktop` and `jdk.internal.vm.compiler`) include many > providers for a particular service, and the providers are all listed > in a single line, resulting in a very wide HTML page that?s difficult > to read even on a large screen. > > Output before: https://cr.openjdk.java.net/~mr/rev/8215301/module-summary-old.html > After: https://cr.openjdk.java.net/~mr/rev/8215301/module-summary-new.html That's much better - thanks! But I have to wonder about the number of services and providers in jdk.internal.vm.compiler! Thanks, David > Thanks, > - Mark > From cushon at google.com Wed Dec 12 21:39:13 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 12 Dec 2018 13:39:13 -0800 Subject: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: On Fri, Dec 7, 2018 at 5:02 PM Liam Miller-Cushon wrote: > I rebased the webrev, and made some additional improvements and > simplifications: > http://cr.openjdk.java.net/~cushon/8198526/webrev.01/ > The spec issue has been resolved (JDK-8215035), so this change is ready for review. From sundararajan.athijegannathan at oracle.com Thu Dec 13 03:25:17 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 13 Dec 2018 08:55:17 +0530 Subject: 8214696: Module class should be filtered by core reflection In-Reply-To: References: Message-ID: <5C11D11D.8040604@oracle.com> Looks good -Sundar On 12/12/18, 10:28 PM, Alan Bateman wrote: > I'd like add java.lang.Module to list of classes that has its fields > filtered from core reflection. As with previous addition in this area, > this is another class where hacking its fields leads to integrity and > security issues. The change is trivial: > http://cr.openjdk.java.net/~alanb/8214696/webrev/index.html > > -Alan From patrick at os.amperecomputing.com Thu Dec 13 03:23:56 2018 From: patrick at os.amperecomputing.com (Patrick Zhang) Date: Thu, 13 Dec 2018 03:23:56 +0000 Subject: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path In-Reply-To: References: <87pnupcjep.fsf@oldenburg.str.redhat.com> <87539e1a-998a-68b2-4644-39378c1b77b2@oracle.com> <87r2f45byx.fsf@oldenburg.str.redhat.com> Message-ID: Ping... Apply for a sponsor for this simple patch. I doubt if I could have permission to file the issue/bug report anywhere, could anyone kindly give a guidance? Thanks. Regards Patrick -----Original Message----- From: core-libs-dev On Behalf Of Patrick Zhang Sent: Thursday, December 6, 2018 4:28 PM To: core-libs-dev at openjdk.java.net; David Holmes Cc: Florian Weimer Subject: RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path To All, Who could help sponsor this simple patch (may require a wide range of building tests)? Thanks in advance. Regards Patrick -----Original Message----- From: David Holmes Sent: Monday, December 3, 2018 8:11 AM To: Patrick Zhang ; Florian Weimer Cc: core-libs-dev at openjdk.java.net Subject: Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path Hi Patrick, On 30/11/2018 11:41 pm, Patrick Zhang wrote: > Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see gcc.gnu.org says that "it gets the same special treatment that is applied to the standard system directories". As such the issue gets hidden (error suppressed). > > Hi David, > Thanks for your suggestion. My intention was to limit the influence range as far as I could since I don't have other systems except CentOS/Fedora to verify (even just smoke test) all paths. You'd need some assistance testing a wider range of platforms but that can be arranged. > In addition, if we make below update, does it mean the macro " _REENTRANT " can be removed too? This is probably the only place where _REENTRANT gets used AFAIK. _REENTRANT is also examined by system headers. It's probably legacy but would require more investigation. Cheers, David > #ifdef _MSC_VER // Windows > #define gmtime_r(t, s) gmtime(t) > #endif > > Regards > Patrick > > -----Original Message----- > From: Florian Weimer > Sent: Thursday, November 29, 2018 8:02 PM > To: David Holmes > Cc: Patrick Zhang ; > jdk-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: OpenJDK fails to build with GCC when the #include > inside zip.cpp comes from a non-sysroot path > > * David Holmes: > >> This should really be being discussed on core-libs-dev. > > Okay, moving the conversation. > >>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp >>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cpp Tue Oct 09 08:33:33 2018 +0100 >>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cpp Wed Nov 28 22:13:12 2018 -0500 >>> @@ -415,9 +415,7 @@ >>> ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); >>> } >>> -#ifdef _REENTRANT // solaris >>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >>> +#if !defined(_REENTRANT) // linux >>> #define gmtime_r(t, s) gmtime(t) >>> #endif >>> /* >> >> Under the theme "two wrongs don't make a right" the use of _REENTRANT >> here is totally inappropriate AFAICS. It seems to be a misguided >> attempt at determining whether we need the thread-safe gmtime_r or >> not >> - and the answer to that should always be yes IMHO. >> >> We define _REENTRANT for: >> - linux >> - gcc >> - xlc >> >> So the original code will define: >> >> extern "C" struct tm *gmtime_r(const time_t *, struct tm *); >> >> for linux (and AIX with xlc?) but not Solaris, OS X or Windows. >> >> But Solaris has gmtime_r anyway. So the existing code seems a really >> convoluted hack. AFAICS we have gmtime_r everywhere but Windows >> (where gmtime is already thread-safe). So it seems to me that all we >> should need here is: >> >> -#ifdef _REENTRANT // solaris >> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else >> +#ifdef _MSC_VER // Windows >> #define gmtime_r(t, s) gmtime(t) >> #endif > > That looks much cleaner. > > Thanks, > Florian > From orionllmain at gmail.com Thu Dec 13 04:48:35 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Thu, 13 Dec 2018 11:48:35 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: OK, this is a fixed version: @Override public void forEach(Consumer action) { Objects.requireNonNull(action); final int n = this.n; final E e = this.element; for (int i = 0; i < n; i++) { action.accept(e); } } Tagir, can you add this to your patch? I signed the OCA. ??, 12 ???. 2018 ?. ? 11:25, Martin Buchholz : > I used to believe that, but apparently I was wrong. > https://openjdk.markmail.org/thread/rfqfultw35i2az45 > > On Tue, Dec 11, 2018 at 8:14 PM Zheka Kozlov > wrote: > >> Would be better to add @Stable to the fields instead? (`n` and `element` >> are final, so @Stable is OK here) >> >> ??, 12 ???. 2018 ?. ? 11:02, Martin Buchholz : >> >>> In performance critical code, we don't trust hotspot to not reload final >>>> fields. Other forEach methods do this, e.g. >>> >>> >>> final Object[] es = queue; >>> for (int i = 0, n = size; i < n; i++) >>> action.accept((E) es[i]); >>> >>> >> From amaembo at gmail.com Thu Dec 13 05:33:44 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 13 Dec 2018 12:33:44 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: Hello, Zheka! I'm not sure whether it's possible to commit a patch which is partially contributed by another person. Probably you should submit it separately? Also for complete patch a testcase would be necessary. With best regards, Tagir Valeev. On Thu, Dec 13, 2018 at 11:48 AM Zheka Kozlov wrote: > > OK, this is a fixed version: > > @Override > public void forEach(Consumer action) { > Objects.requireNonNull(action); > final int n = this.n; > final E e = this.element; > for (int i = 0; i < n; i++) { > action.accept(e); > } > } > > Tagir, can you add this to your patch? I signed the OCA. > > > ??, 12 ???. 2018 ?. ? 11:25, Martin Buchholz : >> >> I used to believe that, but apparently I was wrong. >> https://openjdk.markmail.org/thread/rfqfultw35i2az45 >> >> On Tue, Dec 11, 2018 at 8:14 PM Zheka Kozlov wrote: >>> >>> Would be better to add @Stable to the fields instead? (`n` and `element` are final, so @Stable is OK here) >>> >>> ??, 12 ???. 2018 ?. ? 11:02, Martin Buchholz : >>>>> >>>>> In performance critical code, we don't trust hotspot to not reload final fields. Other forEach methods do this, e.g. >>>> >>>> >>>> final Object[] es = queue; >>>> for (int i = 0, n = size; i < n; i++) >>>> action.accept((E) es[i]); >>>> From daniel.fuchs at oracle.com Thu Dec 13 10:09:03 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Dec 2018 10:09:03 +0000 Subject: RFR 8215309 : Convert package.html files to package-info.java files In-Reply-To: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> References: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> Message-ID: <0b56495a-f8ee-e269-7a76-538bf2a20339@oracle.com> Hi Roger, Thanks for doing this. The java.util.logging package-info looks good to me. best regards, -- daniel On 12/12/2018 19:03, Roger Riggs wrote: > Please review a conversion of some package.html files to > package-info.java files. > This bunch targets packages: > > ?? package com.sun.rowset.providers; > ?? package java.rmi; > ?? package java.rmi.activation; > ?? package java.rmi.dgc; > ?? package java.rmi.registry; > ?? package java.rmi.server; > ?? package java.sql; > ?? package java.util.logging; > ?? package java.util.prefs; > ?? package javax.rmi.ssl; > ?? package javax.smartcardio; > ?? package javax.sql; > ?? package javax.sql.rowset.serial; > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/ > > Thanks, Roger > > From magnus.ihse.bursie at oracle.com Thu Dec 13 10:37:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 11:37:52 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> Message-ID: On 2018-12-12 13:17, David Holmes wrote: > Okay I went away and did some homework ... > > Let me back up a bit and see if I have the evolution of this correctly. > > The native implementation of Java methods should be declared and > defined with JNIEXPORT and JNICALL. > > JNIEXPORT controls the export visibility so they can be linked. > > JNICALL controls the calling convention and is needed so that the > JVM's calling convention matches the native code. [This part was > unclear to me.] Yes. And JNICALL is empty on all platforms except Windows 32, that's why we're only seeing issues about mismatch there. > > Other native methods exported from the same (or different) native > libraries may also be decorated with JNIEXPORT and JNICALL. But in > places there is a mismatch between the declaration in the header and > the definition leading to errors. Yes; this mismatch has typically happened when the linking has not been done by simply including the relevant header file, but either duplicating the definition, or looking up the symbol dynamically. Otherwise things should basically work out. > > There are two main types of such native functions: > > a) those publicly defined in the various native APIs: JNI itself > (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... > > b) those intended only for use by other native code within the JDK > libraries (JLI_* - though I note Alan's comment re javafxpackager, > others??) > > and a possible third type are callback functions like the JPLISAgent > event handlers (e.g. eventHandlerVMInit). I'm not sure I understand what the third type is, but if it is a publically defined API (which, at a first look, the JPLISAgent API seems to be), then it's part of catagory a, otherwise it's part of category b. I must also state that my initial proposal didn't separate these two cases. I had in mind only the b cases -- I have no intention of changing public specifications, but I did not express this in my proposal. That might have been one source of confusion. I apologize for this omission. > > There is a view that no native method that isn't the native-half of a > Java method should use JNICALL. [Okay I can see how that makes sense - > regardless of the actual calling convention used marking such methods > as "must use the same calling convention as the VM native method call" > is somewhat meaningless. Yet obviously the public native APIs do > specify JNICALL so this is not a hard and fast rule. Further the > callbacks must also follow a convention known to the VM doing the > calling!] Yes, or rather the rule is "only native half Java methods should use JNICALL, and also all public APIs where so is specified". > > Where we have (introduced?) a discrepancy between the definition and > declaration the approach has been (because of the previous view) to > remove JNICALL. [This should only relate to methods of kind (b) above.] Actually, it's not so much as we have *removed* JNICALL, as that we have *introduced* JNIEXPORT. When I removed the map files, I also removed the .def files and /export command lines for Windows. As a result, I needed to add JNIEXPORT to a lot of places. Initially, I followed the rule of adding JNICALL to those calls -- but I can surely have missed a couple of places, since things will work fine anyway, as long as caller and callee agree on the calling convention; and a mismatch can only happen on Windows 32, which we do not build and test. So there is a risk that even with the initial patch, not all newly added JNIEXPORTs had JNICALL. Then, it turned out, that a lot of this code did not compile with Windows 32. With no deeper analysis of the flaw, the blame was put on the absence or presence of JNICALL, and a series of patches were made where JNICALL was more or less arbitrarily added or removed, until things "worked". This should have been a warning sign, and I was increasingly uneasy about all these changes, but I hadn't spent enough time to realize what the core issue was or how to resolve it properly. > > That leaves those methods with JNIEXPORT only. > > That seems wrong to you because they are not "JNI methods", so you > want to replace with JDK_EXPORT to make it clear. [Ok - this seems > reasonable.] Yes. And given the fact that we have a bunch of "non-JNI methods" that use the JNIEXPORT...JNICALL pattern, another way to interpret the JDK_EXPORT semantics is that this function is exported for usage *in the JDK*, but not for public consumption. > > If JNICALL is removed from those native methods and they are currently > linked by external applications, those applications may stop working. > But this only affects win32 (as its the only platform where JNICALL is > different to the default C/C++ calling convention?) so your position > is this is acceptable breakage - and would only affect > unsupported/undocumented APIs. Yes. In fact, it's possible that at least some of the breakage that occurred was due to new *addition* of JNICALL, which was not present before. We might have had something like (I'm making this specific example up) a function "void ZIP_OpenFile(char* name)" with no decoration at all, and a "/export:ZIP_OpenFile" on the command line, and a ZIP_OpenFile entry in the unix map file. And I converted this to "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto -- although I didn't fully realize this at the time, changed the calling convention and name decoration on Windows 32. When something broke, perhaps because the user of ZIP_OpenFile did not include the proper header file with the JNICALL modifier, the solution was to remove the JNICALL part. And of all the bug reports I've seen on this, the issues has been internal linking only, i.e. problems building the JDK, not complaints that external tools tried to use internal interfaces and failed. So yes, my position is if this should break things, tough shit. That, of courses, requires that we do not change public APIs, so we need to be careful not to mess with those. > > Does that sum it up? Yep, I think so. > > We still need to be sure that we're only changing functions of type > (b) above. Yes, definitely. > > And I note that this has been driven by the choice to remove JNICALL > where there was a discrepancy - that leads to the visibility of the > two kinds of methods. If it had been chosen to add JNICALL where > missing instead, then we may not have been having this conversation. Actually, as I said, this has more been the result of a lot of added JNICALL where previously there was none. An alternative course of action is the make sure that *all* calls use the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix all parts of code to actually accept the decorated names on Windows 32. This will lead to a lot more code changes, like the fix for JDK-8214122 (JDWP is broken on 32 bit Windows: transport library missing onLoad entry). And all this special case handling will be needed only on Windows 32, which is a platform we do not want to spend to much time or effort on. And finally, I think doing so would make us miss out on an opportunity to make the semantics clearer. > > This will also need a CSR request due to the change in linking behaviour. I'm not sure what you mean by this..? My entire intention here is that we should make no changes to documented interfaces; this is strictly an internal change, so no CSR should be needed. Also, I don't understand what you mean by "linking behavior"? /Magnus > > Cheers, > David > ----- > > On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-11 23:47, David Holmes wrote: >>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 00:23, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>> I propose that we introduce a new define, available to all JDK >>>>>> native files (Hotspot included), called JDK_EXPORT. The behavior >>>>>> of this symbol will be very similar (as of now, in fact >>>>>> identical) to JNIEXPORT; however, the semantics will not. >>>>>> >>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>> for exporting from the library. The problem with this is that >>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>> used when C programs interact with Java. And, when doing this, >>>>>> the function should be fully decorated like this: "JNIEXPORT foo >>>>>> JNICALL". >>>>> >>>>> I've seen a lot of the emails on this issue and I don't fully >>>>> understand what has been going wrong. But the intent is obviously >>>>> the JNIEXPORT represents what is needed to export this function >>>>> for use by JNI, while JNICALL defines the calling convention. I >>>>> agree there may be some mistmatch when functions are actually not >>>>> intended for general export outside the JDK but are only for >>>>> internal JDK use. >>>>> >>>>>> We do have many such JNI exports in our native libraries, but we >>>>>> also have a lot of other, non-JNI exports, where one native >>>>>> library just provides an interface to other libraries. In these >>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>> getting the function exported, but we have not been consistent in >>>>>> our use of JNICALL. This has caused us way too much trouble for >>>>>> something that should Just Work. >>>>> >>>>> Are you suggesting that the interface between different libraries >>>>> in the JDK should not be a JNI interface? Is this because you >>>>> think the functions in these libraries are only for JDK internal >>>>> use or ... ?? >>>>> >>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>> external visibility in the resulting native library), but which >>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>> supposed to be decorated with >>>>> >>>>> Just a clarification there. JNI functions are not exported to Java >>>>> code, they are exported to native code. Java code can declare >>>>> native methods and those native methods must be written as JNI >>>>> functions, but that's not what we are discussing. Libraries expose >>>>> a JNI interface (a set of functions in the library) that can be >>>>> called by application native code, using JNI. >>>> We're apparently looking at "JNI" and "exporting" from two opposite >>>> sides here. :-) Just to make everything clear: If I have a Java class >>>> class MyClass { >>>> public static void native myNativeFunc(); >>>> } >>>> >>>> then I have one half of the JNI function, the Java half. This must >>>> be matched by a corresponding implementation in native, like this: >>>> JNIEXPORT void JNICALL >>>> Java_MyClass_myNativeFunc(void) { >>>> // ... do stuff >>>> } >>>> >>>> And this is the native half of the JNI function. Right? Let's leave >>>> aside which side is "exporting" to the other for now. :-) >>>> >>>> This way of setting up native functions that can be called from >>>> Java is what I refer to as JNI. And when you declare a native JNI >>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>> >>>> We do have a lot of those functions in our native libraries. And >>>> they are correct just the way they are. >>> >>> Yep all well and good. A function declared native in Java must have >>> an implementation as you describe. But not all native functions >>> exist to provide the native-half of a Java native function! >>> >>>> However, we also have *other* native functions, that are exported, >>>> not as JNI functions that should be called from Java, but as normal >>>> native library functions that should be called by other native >>>> code. Okay so far? And *those* functions have been problematic in >>>> how we decorate >>> >>> But there are again two cases. Those functions exported from a >>> library that are expected to be called from external code using the >>> JNI interface mechanism - such as all the JNI functions and JVM TI >>> functions we export from the JVM - and those "exported" for access >>> between libraries within the JDK (such as all the JVM_* functions in >>> libjvm). >>> >>> I think it is only the second group that should be addressed by your >>> JDK_EXPORT proposal - though I'm not completely clear exactly how to >>> identify them. >> Alright, now I think we're on the same page again. :) >> >> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >> >> You identify external APIs by the fact that they are documented. And >> if you are unsure, you ask Jon. ;-) >> >>> >>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>> those functions, and instead use JDK_EXPORT as name for the macro >>>> that decorates them as exported. That way, we can clearly see that >>>> a function like this: >>>> >>>> JDK_EXPORT void >>>> JLI_ReadEnv(char* env); >>>> >>>> is correctly declared, and will be exported to other native >>>> libraries, but not to Java. >>> >>> The issue is not whether it is "exported to Java"** but whether it >>> is exported using the JNI mechanism such that other native code >>> calls it using the JNI mechanism. >>> >>> ** There is no way to write a native method declaration in Java such >>> that it would be linked to the JLI_ReadEnv function. The naming is >>> all wrong, as is the signature. >>> >>>> Just to clarify, this has nothing to do with if this is a >>>> officially supported API or not. In general though, I assume that >>>> most (if not all?) of our exported functions (apart from the JNI_* >>>> stuff) is supposed to be consumed by other libraries in the JDK, >>>> and is not a public API. >>> >>> I think it varies library by library. You may need native >>> application code that can call directly into native JDK libraries. >>> JLI is the Java Launcher Interface - I think it was introduced to >>> make it easier for other launchers to be created. Native agents may >>> need access to libmanagement or libjdwp functions. Native graphics >>> code may need access to the JDK graphics library. Some of these >>> accesses may be unsupported and undocumented, but I don't think you >>> can just cut them all off. >> If they are unsupported and undocumented, I sure as h*ll can cut them >> all off! :-) >> >> Besides, and let me re-iterate this, the only change that will happen >> by removing JNICALL, is on Windows 32. No other platform will be >> affected. There is no official support for Windows 32 anymore. >> There's some low-effort community work done on keeping Windows 32 >> alive, but it's not backed by any major player. Right now, they are >> taking a lot of hits *due to the fact* that we have not sorted this >> out, and waste a lot of their precious effort trying to fix this >> piecemeal. If we do fix things according to this proposal, then it's >> at least clear how things *should* work. If it turns out that there's >> some code out there in the wild, running on Windows 32, that uses an >> undocumented and unsupported function call, and it breaks -- well, >> sucks to be them. They'll just have to do what everyone does who uses >> an undocumented interface that suddenly changes: update their code. >> >> /Magnus >> >>> >>> David >>> >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>>> native functions should be changed to use JDK_EXPORT instead. >>>>>> >>>>>> I further propose that this macro should reside in a new file >>>>>> "jdk.h", placed in the new directory >>>>>> src/java.base/share/native/include/internal. This header file >>>>>> path will automatically be provided to all native libraries, but >>>>>> not copied to the JDK being built. (The existence of a >>>>>> "include/internal" directory with this behavior has been >>>>>> discussed before. There are more files that ought to be moved >>>>>> there, if/when it is created.) I believe in many cases the >>>>>> #include "jni.h" can be just modified to #include "#jdk.h", since >>>>>> most native code will not require "jni.h" unless actually doing >>>>>> JNI calls -- most have included this file to get the JNIEXPORT >>>>>> macro, which would explain the pervasive use of #include "jni.h" >>>>>> in our code base. >>>>> >>>>> jni.h also defines all of the types used by the JNI. Those types >>>>> are pervsive to the native code used throughout the JDK. >>>>> >>>>>> Thoughts? >>>>> >>>>> I think we need to understand the problems on Windows that >>>>> prompted all this. Then I think we need to look at exactly how >>>>> jni.h and JNIEXPORT etc are being used and understand whether this >>>>> is truly an exported interface or not. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> /Magnus >>>>>> >>>> >> From daniel.fuchs at oracle.com Thu Dec 13 11:44:25 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Dec 2018 11:44:25 +0000 Subject: RFR 8215309 : Convert package.html files to package-info.java files In-Reply-To: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> References: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> Message-ID: <01cbf448-40c7-da79-dfa7-fd8c5c6e653b@oracle.com> Hi Roger, As a side note: http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/src/java.smartcardio/share/classes/javax/smartcardio/package-info.java could probably use {@link } instead of and {@code } instead of < > at some places. Similarly the converted java.sql.rowset, java.sql, and javax.sql package-info files are using instead of {@code }. But maybe you'll want to handle that as (a) separate issue(s). best regards, -- daniel On 12/12/2018 19:03, Roger Riggs wrote: > Please review a conversion of some package.html files to > package-info.java files. > This bunch targets packages: > > ?? package com.sun.rowset.providers; > ?? package java.rmi; > ?? package java.rmi.activation; > ?? package java.rmi.dgc; > ?? package java.rmi.registry; > ?? package java.rmi.server; > ?? package java.sql; > ?? package java.util.logging; > ?? package java.util.prefs; > ?? package javax.rmi.ssl; > ?? package javax.smartcardio; > ?? package javax.sql; > ?? package javax.sql.rowset.serial; > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/ > > Thanks, Roger > > From adam.farley at uk.ibm.com Thu Dec 13 11:49:10 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 13 Dec 2018 11:49:10 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> Message-ID: Hi Stuart, A good compromise. Well referenced. Yes, could you sponsor this change? Thanks, - Adam Stuart Marks wrote on 12/12/2018 00:38:32: ... > > > # HG changeset patch > # User afarley > # Date 1544574289 28800 > # Tue Dec 11 16:24:49 2018 -0800 > # Node ID 0c40c78b6d139eb05b0718d0b524a465419ee9cb > # Parent b75a44aad06cd93c823159265a1f200bf0ce390c > 8215217: OpenJDK Source Has Too Many Swear Words > > diff -r b75a44aad06c -r 0c40c78b6d13 > src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java > --- a/src/java.desktop/share/classes/com/sun/media/sound/ > SoftChannel.java Tue > Dec 11 13:10:14 2018 -0800 > +++ b/src/java.desktop/share/classes/com/sun/media/sound/ > SoftChannel.java Tue > Dec 11 16:24:49 2018 -0800 > @@ -1472,7 +1472,7 @@ > } > for (int controller : co_midi_nrpn_nrpn.keySet()) > nrpnChange(controller, 0); > - rpnChange(0, 2 << 7); // Bitch Bend sensitivity > + rpnChange(0, 2 << 7); // Pitch Bend sensitivity > rpnChange(1, 64 << 7); // Channel fine tunning > rpnChange(2, 64 << 7); // Channel Coarse Tuning > rpnChange(5, 64); // Modulation Depth, +/- 50 cent > diff -r b75a44aad06c -r 0c40c78b6d13 > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/ > dom/BitArray.java > --- > a/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/ > xsltc/dom/BitArray.java > Tue Dec 11 13:10:14 2018 -0800 > +++ > b/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/ > xsltc/dom/BitArray.java > Tue Dec 11 16:24:49 2018 -0800 > @@ -133,7 +133,7 @@ > * This method returns the Nth bit that is set in the bit array. The > * current position is cached in the following 4 variables and will > * help speed up a sequence of next() call in an index iterator. This > - * method is a mess, but it is fast and it works, so don't fuck with it. > + * method is a mess, but it is fast and it works, so don't change it. > */ > private int _pos = Integer.MAX_VALUE; > private int _node = 0; > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neugens.limasoftware at gmail.com Thu Dec 13 11:58:32 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 13 Dec 2018 12:58:32 +0100 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: Message-ID: For a moment I had to check if this was 1st of April, but yikes! :) Thanks for cleaning it up. Cheers, Mario Il giorno mar 11 dic 2018 alle ore 16:33 Alan Bateman ha scritto: > > On 11/12/2018 15:03, Adam Farley8 wrote: > > Hey All, > > > > I've spotted 12 instances of swear words in OpenJDK source comments, and > > it seems appropriate to remove them. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 > > > > I've created a webrev and attached to the bug. > > > > Also, I've mentioned in the bug that there are additional swears in more > > excusable locations. It would be good to get the community's take on > > those. > > > > Reviews and opinions welcome. :) > "Where's that damn torpedo?" might be from Star Trek. > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From adam.farley at uk.ibm.com Thu Dec 13 12:23:36 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 13 Dec 2018 12:23:36 +0000 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> Message-ID: Update: The revised webrev can be found here: http://cr.openjdk.java.net/~afarley/8215217/webrev/ It can also be found in the zip attached to the bug. Best Regards Adam Farley IBM Runtimes Adam Farley8/UK/IBM wrote on 13/12/2018 11:49:12: > From: Adam Farley8/UK/IBM > To: Stuart Marks > Cc: core-libs-dev at openjdk.java.net, mark.reinhold at oracle.com > Date: 13/12/2018 11:49 > Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words > > Hi Stuart, > > A good compromise. Well referenced. > > Yes, could you sponsor this change? > > Thanks, > > - Adam > > Stuart Marks wrote on 12/12/2018 00:38:32: > ... > > > > > > # HG changeset patch > > # User afarley > > # Date 1544574289 28800 > > # Tue Dec 11 16:24:49 2018 -0800 > > # Node ID 0c40c78b6d139eb05b0718d0b524a465419ee9cb > > # Parent b75a44aad06cd93c823159265a1f200bf0ce390c > > 8215217: OpenJDK Source Has Too Many Swear Words > > > > diff -r b75a44aad06c -r 0c40c78b6d13 > > src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java > > --- a/src/java.desktop/share/classes/com/sun/media/sound/ > > SoftChannel.java Tue > > Dec 11 13:10:14 2018 -0800 > > +++ b/src/java.desktop/share/classes/com/sun/media/sound/ > > SoftChannel.java Tue > > Dec 11 16:24:49 2018 -0800 > > @@ -1472,7 +1472,7 @@ > > } > > for (int controller : co_midi_nrpn_nrpn.keySet()) > > nrpnChange(controller, 0); > > - rpnChange(0, 2 << 7); // Bitch Bend sensitivity > > + rpnChange(0, 2 << 7); // Pitch Bend sensitivity > > rpnChange(1, 64 << 7); // Channel fine tunning > > rpnChange(2, 64 << 7); // Channel Coarse Tuning > > rpnChange(5, 64); // Modulation Depth, +/- 50 cent > > diff -r b75a44aad06c -r 0c40c78b6d13 > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/ > > dom/BitArray.java > > --- > > a/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/ > > xsltc/dom/BitArray.java > > Tue Dec 11 13:10:14 2018 -0800 > > +++ > > b/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/ > > xsltc/dom/BitArray.java > > Tue Dec 11 16:24:49 2018 -0800 > > @@ -133,7 +133,7 @@ > > * This method returns the Nth bit that is set in the bit array. The > > * current position is cached in the following 4 variables and will > > * help speed up a sequence of next() call in an index iterator. This > > - * method is a mess, but it is fast and it works, so don't > fuck with it. > > + * method is a mess, but it is fast and it works, so don't change it. > > */ > > private int _pos = Integer.MAX_VALUE; > > private int _node = 0; > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From shade at redhat.com Thu Dec 13 12:27:56 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Dec 2018 13:27:56 +0100 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> Message-ID: <77739342-3a8d-eeaa-5589-a1a52f7d9d51@redhat.com> On 12/13/18 1:23 PM, Adam Farley8 wrote: > Update: The revised webrev can be found here: > http://cr.openjdk.java.net/~afarley/8215217/webrev/ > > It can also be found in the zip attached to the bug. Looks good to me. Thanks, -Aleksey From patrick at reini.net Thu Dec 13 12:36:47 2018 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 13 Dec 2018 13:36:47 +0100 Subject: Querstion about ForkJoinPool / SecurityManager interoperability Message-ID: Hi everybody, I'm not sure if this mailing list the correct one, if not please give me a note where to place that question. When trying to use the Weld SE with together with a SecurityManager and I got a exception thrown out of the ForkJoinWorkerThread: java.lang.SecurityException: setContextClassLoader at java.base/java.util.concurrent.ForkJoinWorkerThread$InnocuousForkJoinWorkerThread.setContextClassLoader(ForkJoinWorkerThread.java:239) I did some digging in the ForkJoinPool and there it states the possible reason: "If no thread factory is supplied via a system property, then the common pool uses a factory that uses the system class loader as the thread context class loader. In addition, if a SecurityManager is present, then the common pool uses a factory supplying threads that have no Permissions enabled. Upon any error in establishing these settings, default parameters are used. It is possible to disable or limit the use of threads in the common pool by setting the parallelism property to zero, and/or using a factory that may return null. However doing so may cause unjoined tasks to never be executed." Now the special case of using those special threads with no permission are only created when the ForkJoinPool is initialized with a security manager installed at this point of time. If the security manager will be installed later, it has not impact what so ever (this is my actual work-around the problem for now) Even if the security manager is enabled before the initialize of the ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread instances (sometimes it picks the main thread instead, that has not the restrictions, what I think should not be the case and is a potential security leak too) Why is this done this way and the change of the context class loader or uncaught exception handler not checked by the actual security manager instead? Can anybody enlighten me on this so I can file the correct bug at the correct place :-) -Patrick From daniel.fuchs at oracle.com Thu Dec 13 13:06:07 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Dec 2018 13:06:07 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> Message-ID: <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> Looks good Claes! I eyeballed the rest of the patch and found nothing wrong - but with a patch this size it would be easy to miss something. Were you able to measure any improvement after patching? best regards, -- daniel On 12/12/2018 17:06, Claes Redestad wrote: > > > On 2018-12-12 17:54, Daniel Fuchs wrote: >> Hi Claes, >> >> It might read even better if things like: >> >> +??????? resultString = !specarg.isEmpty() ? specarg.intern(): opt; >> >> were changed into: >> >> +??????? resultString = specarg.isEmpty() ? opt : specarg.intern(); >> >> best regards, > > I only found this pattern in this file, so incremental > diff will look like the below. I will update in place due hugeness of > webrev. > > Thanks! > > /Claes > > diff -r 732b03e40349 > src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > Wed Dec 12 17:41:46 2018 +0100 > +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > Wed Dec 12 18:03:57 2018 +0100 > @@ -641,10 +641,10 @@ > ???????????????????? String specarg = spec.substring(sidx); > ???????????????????? switch (specop) { > ???????????????????? case '.':? // terminate the option sequence > -??????????????????????? resultString = !specarg.isEmpty() ? > specarg.intern(): opt; > +??????????????????????? resultString = specarg.isEmpty() ? opt : > specarg.intern(); > ???????????????????????? break doArgs; > ???????????????????? case '?':? // abort the option sequence > -??????????????????????? resultString = !specarg.isEmpty() ? > specarg.intern(): arg; > +??????????????????????? resultString = specarg.isEmpty() ? arg : > specarg.intern(); > ???????????????????????? isError = true; > ???????????????????????? break eachSpec; > ???????????????????? case '@':? // change the effective opt name > @@ -655,7 +655,7 @@ > ???????????????????????? val = ""; > ???????????????????????? break; > ???????????????????? case '!':? // negation option > -??????????????????????? String negopt = !specarg.isEmpty() ? > specarg.intern(): opt; > +??????????????????????? String negopt = specarg.isEmpty() ? opt : > specarg.intern(); > ???????????????????????? properties.remove(negopt); > ???????????????????????? properties.put(negopt, null);? // leave > placeholder > ???????????????????????? didAction = true; From claes.redestad at oracle.com Thu Dec 13 13:17:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 13 Dec 2018 14:17:05 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> Message-ID: <3917b2c2-127a-8ed2-dfec-fb4e1f4631f2@oracle.com> On 2018-12-13 14:06, Daniel Fuchs wrote: > Looks good Claes! Thanks! > I eyeballed the rest of the patch and found > nothing wrong - but with a patch this size > it would be easy to miss something. Yes, I've gone through it a couple of times now to be sure. > > Were you able to measure any improvement after > patching? There's a tiny reduction in bytecode executed in initPhase1, but on any real measures any improvement is in the noise. /Claes > > best regards, > > -- daniel From dl at cs.oswego.edu Thu Dec 13 13:23:37 2018 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 13 Dec 2018 08:23:37 -0500 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: References: Message-ID: On 12/13/18 7:36 AM, Patrick Reinhart wrote: > Now the special case of using those special threads with no permission > are only created when the ForkJoinPool is initialized with a security > manager installed at this point of time. If the security manager will be > installed later, it has not impact what so ever (this is my actual > work-around the problem for now) Dynamically installing a security manager encounters races that at best need a lot of care to manage. This is an issue in several contexts (not just thread pools). Sorry that I don't know of a general solution. > > Even if the security manager is enabled before the initialize of the > ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread > instances (sometimes it picks the main thread instead, that has not the > restrictions, what I think should not be the case and is a potential > security leak too) The rationale is that parallel workers should not have more permissions than callers, but possibly fewer. > > Why is this done this way and the change of the context class loader or > uncaught exception handler not checked by the actual security manager > instead? Could you explain what you would like to have happen? -Doug From lance.andersen at oracle.com Thu Dec 13 13:42:12 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 13 Dec 2018 08:42:12 -0500 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <77739342-3a8d-eeaa-5589-a1a52f7d9d51@redhat.com> References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> <77739342-3a8d-eeaa-5589-a1a52f7d9d51@redhat.com> Message-ID: <24E8CE38-3E76-4B97-8574-87509DA929EF@oracle.com> Looks fine. I can sponsor once approved if needed > On Dec 13, 2018, at 7:27 AM, Aleksey Shipilev wrote: > > On 12/13/18 1:23 PM, Adam Farley8 wrote: >> Update: The revised webrev can be found here: >> http://cr.openjdk.java.net/~afarley/8215217/webrev/ >> >> It can also be found in the zip attached to the bug. > > Looks good to me. > > Thanks, > -Aleksey > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From patrick at reini.net Thu Dec 13 13:44:45 2018 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 13 Dec 2018 14:44:45 +0100 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: References: Message-ID: <25205448a5eb04d12e36ec3a378afc16@reini.net> Hi Dough, Thanks first of all for that quick answer... On 2018-12-13 14:23, Doug Lea wrote: > On 12/13/18 7:36 AM, Patrick Reinhart wrote: > >> Now the special case of using those special threads with no permission >> are only created when the ForkJoinPool is initialized with a security >> manager installed at this point of time. If the security manager will >> be >> installed later, it has not impact what so ever (this is my actual >> work-around the problem for now) > > Dynamically installing a security manager encounters races that at best > need a lot of care to manage. This is an issue in several contexts (not > just thread pools). Sorry that I don't know of a general solution. I do also not have a better solution for that case (at least this saved my live for now) >> Even if the security manager is enabled before the initialize of the >> ForkJoinPool not all work is delegated to >> InnocuousForkJoinWorkerThread >> instances (sometimes it picks the main thread instead, that has not >> the >> restrictions, what I think should not be the case and is a potential >> security leak too) > > The rationale is that parallel workers should not have more permissions > than callers, but possibly fewer. ok, so then in that regard the main thread is the caller here. >> Why is this done this way and the change of the context class loader >> or >> uncaught exception handler not checked by the actual security manager >> instead? > > Could you explain what you would like to have happen? In my case it would made sense that the actual active SecurityManager would have been called for permission to set the context class loader (in my case with the Weld initialization the actual context loader would be "null" and after be reset to the one previously returned by the Thread. This special case could have been handled also by the InnocuousForkJoinWorkerThread could in my opinion be relaxed to accept null or the system classloader to be set using setContextClassLoader() something like this: public void setContextClassLoader(ClassLoader cl) { if (cl == null || ClassLoader.getSystemClassLoader().equals(cl)) { return; } throw new SecurityException("setContextClassLoader"); } -Patrick From dl at cs.oswego.edu Thu Dec 13 14:15:12 2018 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 13 Dec 2018 09:15:12 -0500 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: <25205448a5eb04d12e36ec3a378afc16@reini.net> References: <25205448a5eb04d12e36ec3a378afc16@reini.net> Message-ID: On 12/13/18 8:44 AM, Patrick Reinhart wrote: > > This special case could have been handled also by the > InnocuousForkJoinWorkerThread > could in my opinion be relaxed to accept null or the system classloader > to be set > using setContextClassLoader() Thanks. We should/will do this. The unconditional throw was clearly too strong; innocuous calls can be allowed. This doesn't address the general issues of dynamic security manager installation, but at least removes an obstacle for people trying to cope. I created CR: https://bugs.openjdk.java.net/browse/JDK-8215359 -Doug From Roger.Riggs at oracle.com Thu Dec 13 14:16:36 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2018 09:16:36 -0500 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> Message-ID: <204133bf-093b-a507-b39a-802de4fda61b@oracle.com> Hi Adam, The patch looks fine. Once the patch is committed, the zip file attached to the issue has no purpose and is just wasted space. Attaching the patch would waste less space but still be redundant. Best practice is to put the webrev's on cr.openjdk.java.net. A link from the issue to the email thread on openjdk.java.net is also helpful. $.02, Roger On 12/13/2018 07:23 AM, Adam Farley8 wrote: > Update: The revised webrev can be found here: > http://cr.openjdk.java.net/~afarley/8215217/webrev/ > > It can also be found in the zip attached to the bug. > > Best Regards > > Adam Farley > IBM Runtimes > > > Adam Farley8/UK/IBM wrote on 13/12/2018 11:49:12: > >> From: Adam Farley8/UK/IBM >> To: Stuart Marks >> Cc: core-libs-dev at openjdk.java.net, mark.reinhold at oracle.com >> Date: 13/12/2018 11:49 >> Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words >> >> Hi Stuart, >> >> A good compromise. Well referenced. >> >> Yes, could you sponsor this change? >> >> Thanks, >> >> - Adam >> >> Stuart Marks wrote on 12/12/2018 00:38:32: >> ... >>> >>> # HG changeset patch >>> # User afarley >>> # Date 1544574289 28800 >>> # Tue Dec 11 16:24:49 2018 -0800 >>> # Node ID 0c40c78b6d139eb05b0718d0b524a465419ee9cb >>> # Parent b75a44aad06cd93c823159265a1f200bf0ce390c >>> 8215217: OpenJDK Source Has Too Many Swear Words >>> >>> diff -r b75a44aad06c -r 0c40c78b6d13 >>> src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java >>> --- a/src/java.desktop/share/classes/com/sun/media/sound/ >>> SoftChannel.java Tue >>> Dec 11 13:10:14 2018 -0800 >>> +++ b/src/java.desktop/share/classes/com/sun/media/sound/ >>> SoftChannel.java Tue >>> Dec 11 16:24:49 2018 -0800 >>> @@ -1472,7 +1472,7 @@ >>> } >>> for (int controller : co_midi_nrpn_nrpn.keySet()) >>> nrpnChange(controller, 0); >>> - rpnChange(0, 2 << 7); // Bitch Bend sensitivity >>> + rpnChange(0, 2 << 7); // Pitch Bend sensitivity >>> rpnChange(1, 64 << 7); // Channel fine tunning >>> rpnChange(2, 64 << 7); // Channel Coarse Tuning >>> rpnChange(5, 64); // Modulation Depth, +/- 50 > cent >>> diff -r b75a44aad06c -r 0c40c78b6d13 >>> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/ >>> dom/BitArray.java >>> --- >>> a/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/ >>> xsltc/dom/BitArray.java >>> Tue Dec 11 13:10:14 2018 -0800 >>> +++ >>> b/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/ >>> xsltc/dom/BitArray.java >>> Tue Dec 11 16:24:49 2018 -0800 >>> @@ -133,7 +133,7 @@ >>> * This method returns the Nth bit that is set in the bit array. > The >>> * current position is cached in the following 4 variables and > will >>> * help speed up a sequence of next() call in an index iterator. > This >>> - * method is a mess, but it is fast and it works, so don't >> fuck with it. >>> + * method is a mess, but it is fast and it works, so don't change > it. >>> */ >>> private int _pos = Integer.MAX_VALUE; >>> private int _node = 0; >>> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Thu Dec 13 14:22:48 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2018 09:22:48 -0500 Subject: RFR 8215309 : Convert package.html files to package-info.java files In-Reply-To: <01cbf448-40c7-da79-dfa7-fd8c5c6e653b@oracle.com> References: <7b809fc1-c468-0e83-d03e-4a1e88f4c319@oracle.com> <01cbf448-40c7-da79-dfa7-fd8c5c6e653b@oracle.com> Message-ID: Thanks Daniel, I created a new issue JDK-8215361. On 12/13/2018 06:44 AM, Daniel Fuchs wrote: > > http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/src/java.smartcardio/share/classes/javax/smartcardio/package-info.java > > > could probably use {@link } instead of and {@code } > instead of < > at some places. > > Similarly the converted java.sql.rowset, java.sql, and > javax.sql package-info files are using instead > of {@code }. From vicente.romero at oracle.com Thu Dec 13 15:14:12 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 13 Dec 2018 10:14:12 -0500 Subject: RFR JDK-8215300: additional changes to constants API In-Reply-To: References: Message-ID: Hi all, I have provided another iteration to the webrev at [1]. This one includes additional changes to make sure that no array descriptor with more than 255 dimensions is created. Thanks, Vicente http://cr.openjdk.java.net/~vromero/8215300/webrev.01/ On 12/12/18 12:02 PM, Vicente Romero wrote: > Hi, > > Please review some final changes to the constants API. The changes > should make the API clearer and more precise and were recommended in > the CSR [3] > > Thanks, > Vicente > > [1] (jira issue) https://bugs.openjdk.java.net/browse/JDK-8215300 > [2] (webrev) http://cr.openjdk.java.net/~vromero/8215300/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8202031 From brian.goetz at oracle.com Thu Dec 13 15:17:30 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Dec 2018 10:17:30 -0500 Subject: RFR JDK-8215300: additional changes to constants API In-Reply-To: References: Message-ID: +1 from me. Appears that it covers all the issues that were raised in the CSR and by JCK since integration. > On Dec 13, 2018, at 10:14 AM, Vicente Romero wrote: > > Hi all, > > I have provided another iteration to the webrev at [1]. This one includes additional changes to make sure that no array descriptor with more than 255 dimensions is created. > > Thanks, > Vicente > > http://cr.openjdk.java.net/~vromero/8215300/webrev.01/ > > > On 12/12/18 12:02 PM, Vicente Romero wrote: >> Hi, >> >> Please review some final changes to the constants API. The changes should make the API clearer and more precise and were recommended in the CSR [3] >> >> Thanks, >> Vicente >> >> [1] (jira issue) https://bugs.openjdk.java.net/browse/JDK-8215300 >> [2] (webrev) http://cr.openjdk.java.net/~vromero/8215300/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8202031 > From kishor.gollapalliwar at gmail.com Thu Dec 13 15:19:06 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Thu, 13 Dec 2018 20:49:06 +0530 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: <636451fa-45b8-1861-999a-c3fd3a26673c@oracle.com> References: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> <636451fa-45b8-1861-999a-c3fd3a26673c@oracle.com> Message-ID: Hello Stuart, Forgive me for delayed response. I was not well for a week, due to which lot of work got queued up in office. It took a while to sort it out. Your guidance was really helpful. And by end of this week I'll share first patch, containing document enhancements for SortedSet class. Hope I'm not too late. Thanks, Kishor Gollapalliwar On Fri 30 Nov, 2018, 10:22 Stuart Marks On 11/1/18 8:12 PM, Kishor Gollapalliwar wrote: > > Thank you for providing this opportunity. I'm up for this challenge and > I'd > > love to take this task. The only huddle would be, how to proceed, ie > planning > > things step by step, as this is my first time. If you can help me with > the > > planning, I'll do the rest and fix these issues. > > Hi, sorry for the delay. I had a couple conferences and then some vacation. > > This issue comes up periodically. Consider this Stack Overflow question > and this > answer in particular: > > https://stackoverflow.com/a/53375284/1441122 > > It quotes the relevant part of the TreeSet spec (which is also in the > SortedSet > interface): > > > Note that the ordering maintained by a sorted set (whether or not an > explicit > > comparator is provided) must be consistent with equals if the sorted set > is > > to correctly implement the Set interface. (See the Comparable interface > or > > Comparator interface for a precise definition of consistent with equals.) > > This is so because the Set interface is defined in terms of the equals > > operation, but a sorted set performs all element comparisons using its > > compareTo (or compare) method, so two elements that are deemed equal by > this > > method are, from the standpoint of the sorted set, equal. The behavior > of a > > sorted set is well-defined even if its ordering is inconsistent with > equals; > > it just fails to obey the general contract of the Set interface. > > What's missing here are 1) a clear statement that membership in a > SortedSet is > determined by the comparison method, and 2) a crisp definition of > "comparison > method". > > Various places in the spec mention something like "the Comparator's > compare() > method, if there is a comparator method, otherwise the compareTo() method > if the > set is using the elements' natural order...." The term "comparison method" > should be defined early on so that it can be used in later parts of the > spec, > avoiding the comparator/natural-order awkwardness. > > Then, it should be specified that the comparison method 1) determines > membership > in the set as well as 2) ordering of set iteration, subsetting, etc. This > overlaps some with the first two paragraphs of the SortedSet class spec. > > Regarding membership, the Set interface says: > > > sets contain no pair of elements e1 and e2 such that e1.equals(e2) > > SortedSet should have something similar, e.g., > > > SortedSets contain no pair of elements e1 and e2 such that e1 CMP e2 == 0 > > where "CMP" is the "comparison method". (You don't have to use this > notation, > but the idea is that there is no pair of elements in the set for which the > comparison method returns zero.) > > Only at this point should the "consistent with equals" discussion be > introduced. > The problem with the existing text is that it introduces the "consistent > with > equals" topic, and then only incidentally mentions that set membership is > determined by "equality" according to the comparison method instead of > equals(). > > That's the first step, which basically amounts to rewriting the first > three > paragraphs of the SortedSet class specification. The subsequent steps are: > > 2) Reconcile class doc of SortedSet subtypes, e.g. NavigableSet, TreeSet, > possibly ConcurrentSkipListSet. > > 3) Audit all method specs of all classes and reconcile them with the class > specs. A starting point for methods to look at is in this bug: > > https://bugs.openjdk.java.net/browse/JDK-8190545 > > 4) 5) 6) Similar steps as above for the SortedMap family. > > ** > > I'd suggest just starting off with the first step instead of trying to do > it all > at once. Don't worry about posting webrevs or specdiffs yet; just send a > patch > or even plain text of the draft to the list and I'll start reviewing it. > > Thanks, > > s'marks > From joe.darcy at oracle.com Thu Dec 13 16:50:39 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 13 Dec 2018 08:50:39 -0800 Subject: RFR JDK-8215300: additional changes to constants API In-Reply-To: References: Message-ID: After the fact; looks good. Thanks, -Joe On 12/13/2018 7:17 AM, Brian Goetz wrote: > +1 from me. > > Appears that it covers all the issues that were raised in the CSR and by JCK since integration. > >> On Dec 13, 2018, at 10:14 AM, Vicente Romero wrote: >> >> Hi all, >> >> I have provided another iteration to the webrev at [1]. This one includes additional changes to make sure that no array descriptor with more than 255 dimensions is created. >> >> Thanks, >> Vicente >> >> http://cr.openjdk.java.net/~vromero/8215300/webrev.01/ >> >> >> On 12/12/18 12:02 PM, Vicente Romero wrote: >>> Hi, >>> >>> Please review some final changes to the constants API. The changes should make the API clearer and more precise and were recommended in the CSR [3] >>> >>> Thanks, >>> Vicente >>> >>> [1] (jira issue) https://bugs.openjdk.java.net/browse/JDK-8215300 >>> [2] (webrev) http://cr.openjdk.java.net/~vromero/8215300/webrev.00/ >>> [3] https://bugs.openjdk.java.net/browse/JDK-8202031 From stuart.marks at oracle.com Thu Dec 13 18:10:21 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 13 Dec 2018 10:10:21 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: <24E8CE38-3E76-4B97-8574-87509DA929EF@oracle.com> References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> <77739342-3a8d-eeaa-5589-a1a52f7d9d51@redhat.com> <24E8CE38-3E76-4B97-8574-87509DA929EF@oracle.com> Message-ID: <11df1440-4b18-953e-d5e5-c3f75b7e84ec@oracle.com> Thanks Lance, I had already volunteered to sponsor this. On 12/13/18 5:42 AM, Lance Andersen wrote: > Looks fine. > > I can sponsor once approved if needed > > >> On Dec 13, 2018, at 7:27 AM, Aleksey Shipilev > > wrote: >> >> On 12/13/18 1:23 PM, Adam Farley8 wrote: >>> Update: The revised webrev can be found here: >>> http://cr.openjdk.java.net/~afarley/8215217/webrev/ >>> >>> It can also be found in the zip attached to the bug. >> >> Looks good to me. >> >> Thanks, >> -Aleksey >> >> > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From patrick at reini.net Thu Dec 13 19:34:19 2018 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 13 Dec 2018 20:34:19 +0100 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: References: <25205448a5eb04d12e36ec3a378afc16@reini.net> Message-ID: <7488b9df-72dc-525e-916e-7103348dbf90@reini.net> Should I prepare a webrev for this change? -Patrick Am 13.12.18 um 15:15 schrieb Doug Lea: > On 12/13/18 8:44 AM, Patrick Reinhart wrote: >> This special case could have been handled also by the >> InnocuousForkJoinWorkerThread >> could in my opinion be relaxed to accept null or the system classloader >> to be set >> using setContextClassLoader() > Thanks. We should/will do this. The unconditional throw was clearly too > strong; innocuous calls can be allowed. This doesn't address the general > issues of dynamic security manager installation, but at least removes an > obstacle for people trying to cope. > > I created CR: https://bugs.openjdk.java.net/browse/JDK-8215359 > > -Doug From lance.andersen at oracle.com Thu Dec 13 20:30:09 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 13 Dec 2018 15:30:09 -0500 Subject: RFR 8215372: test/jdk/java/nio/file/DirectoryStream/Basic.java not correct for validating the use of a glob Message-ID: <6B9768EE-CEA3-4C8A-BD00-50F0557CB05F@oracle.com> Hi all, Attached is the patch for https://bugs.openjdk.java.net/browse/JDK-8215372 that addresses the test DirectoyStream/Basic.java which was not correctly validating newDirectoryStream using a glob: ????????? $ hg diff test/jdk/java/nio/file/DirectoryStream/Basic.java diff -r 413c28945e0f test/jdk/java/nio/file/DirectoryStream/Basic.java --- a/test/jdk/java/nio/file/DirectoryStream/Basic.java Wed Dec 05 19:17:22 2018 +0100 +++ b/test/jdk/java/nio/file/DirectoryStream/Basic.java Thu Dec 13 15:16:57 2018 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2018, 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 @@ -73,14 +73,18 @@ private PathMatcher matcher = dir.getFileSystem().getPathMatcher("glob:f*"); public boolean accept(Path file) { - return matcher.matches(file); + return matcher.matches(file.getFileName()); } }; + + found = false; try (DirectoryStream ds = newDirectoryStream(dir, filter)) { for (Path entry: ds) { - if (!entry.getFileName().equals(foo)) - throw new RuntimeException("entry not expected"); + if (entry.getFileName().equals(foo)) + found = true; } + if (!found) + throw new RuntimeException(String.format("Error: entry: %s was not found", foo)); } // check filtering: z* should not match any files @@ -88,7 +92,7 @@ private PathMatcher matcher = dir.getFileSystem().getPathMatcher("glob:z*"); public boolean accept(Path file) { - return matcher.matches(file); + return matcher.matches(file.getFileName()); } }; try (DirectoryStream ds = newDirectoryStream(dir, filter)) { $ -------------------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mathiske at amazon.com Thu Dec 13 17:26:36 2018 From: mathiske at amazon.com (Mathiske, Bernd) Date: Thu, 13 Dec 2018 17:26:36 +0000 Subject: The meaning of the java.vendor property? Message-ID: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> I was wondering if it?s OK to modify the ?java.vendor? system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() What is a ?vendor? in this context? Is it always supposed to be ?Oracle Corporation? to stay compatible? Or is it supposed to be whoever builds and packages the binaries so we can track the origin of the binary artifacts better? Bernd From stuart.marks at oracle.com Thu Dec 13 22:40:53 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 13 Dec 2018 14:40:53 -0800 Subject: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words In-Reply-To: References: <20181211135213.665034978@eggemoggin.niobe.net> <5df5f5c1-86be-b2ac-75db-8b03eb8c3e09@oracle.com> Message-ID: <298d7398-ed06-19ad-fc26-486487d93d35@oracle.com> On 12/13/18 4:23 AM, Adam Farley8 wrote: > Update: The revised webrev can be found here: > http://cr.openjdk.java.net/~afarley/8215217/webrev/ I've now pushed this changeset. As a closing observation, I'll note that the original patch did find several vulgarities in OpenJDK. However, all of them originated from upstream sources. That means the 8 million or so lines of code in OpenJDK that aren't from any upstream source base don't have any vulgarities. I'd say that's pretty f--, er, darned impressive. :-) s'marks From ivan.gerasimov at oracle.com Thu Dec 13 23:11:12 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Dec 2018 15:11:12 -0800 Subject: RFR 8214761 : Bug in parallel Kahan summation implementation In-Reply-To: <6fb0565c-81cd-07fa-1c4f-fdf406b75f25@oracle.com> References: <6fb0565c-81cd-07fa-1c4f-fdf406b75f25@oracle.com> Message-ID: Gentle ping. On 12/9/18 7:37 PM, Ivan Gerasimov wrote: > Hello! > > DoubleSummaryStatistics takes advantage of Kahan summation algorithm > to reduce the error of the total sum. > > Internally it maintains a field double sumCompensation, which keeps > lower bits (which were rounded off) of the last addition. > > Note, that the compensation has to be subtracted from the result to > add those bits back: > > 166 private void sumWithCompensation(double value) { > 167 double tmp = value - sumCompensation; > 168 double velvel = sum + tmp; // Little wolf of rounding error > 169 sumCompensation = (velvel - sum) - tmp; > 170 sum = velvel; > 171 } > > At the line 169, tmp normally has more lower bits than (velvel - sum). > > However, when two DoubleSummaryStatistics objects are combined, this > compensation part is *added* to the total, which may result in a less > accurate result. > > The same bug is replicated in DoubleStreams. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214761 > WEBREV: http://cr.openjdk.java.net/~igerasim/8214761/00/webrev/ > -- With kind regards, Ivan Gerasimov From claes.redestad at oracle.com Thu Dec 13 23:20:03 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Dec 2018 00:20:03 +0100 Subject: RFR: 8215380: Backout accidental change to String::length Message-ID: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> Hi, I need to revert an accidental change to String.length Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 Patch inlined below Running the accidentally pushed version in naive microbenchmarks showed that avoiding the shift operation can improve throughput of str.length() by a small measure (~1.06x) for latin1-only inputs, neutral for mixed or utf16-only inputs, but also adds a branch (visible in profiling) which could blow up in more real cases. Regardless, it should be reviewed and discussed on it's own merits. Sorry! /Claes diff -r 8bf9268df0e2 src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java Thu Dec 13 15:31:05 2018 +0100 +++ b/src/java.base/share/classes/java/lang/String.java Thu Dec 13 23:59:43 2018 +0100 @@ -664,7 +664,7 @@ * object. */ public int length() { - return isLatin1() ? value.length : value.length >> UTF16; + return value.length >> coder(); } /** From joe.darcy at oracle.com Thu Dec 13 23:41:22 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 13 Dec 2018 15:41:22 -0800 Subject: RFR: 8215380: Backout accidental change to String::length In-Reply-To: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> References: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> Message-ID: <5C12EE22.4090501@oracle.com> +1 to revert to the prior version, Cheers, -Joe On 12/13/2018 3:20 PM, Claes Redestad wrote: > Hi, > > I need to revert an accidental change to String.length > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 > Patch inlined below > > Running the accidentally pushed version in naive microbenchmarks showed > that avoiding the shift operation can improve throughput of str.length() > by a small measure (~1.06x) for latin1-only inputs, neutral for mixed > or utf16-only inputs, but also adds a branch (visible in profiling) > which could blow up in more real cases. Regardless, it should be > reviewed and discussed on it's own merits. Sorry! > > /Claes > > diff -r 8bf9268df0e2 src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java Thu Dec 13 > 15:31:05 2018 +0100 > +++ b/src/java.base/share/classes/java/lang/String.java Thu Dec 13 > 23:59:43 2018 +0100 > @@ -664,7 +664,7 @@ > * object. > */ > public int length() { > - return isLatin1() ? value.length : value.length >> UTF16; > + return value.length >> coder(); > } > > /** From stuart.marks at oracle.com Thu Dec 13 23:43:30 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 13 Dec 2018 15:43:30 -0800 Subject: RFR: 8215380: Backout accidental change to String::length In-Reply-To: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> References: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> Message-ID: Hi Claes, Thank for catching this. Looks good. Note that the original changeset (JDK-8215281) went into JDK 12 before the RDP1 fork, so this fix should also go into JDK 12. That's a different repo now. It will then be auto-propagated to the JDK mainline ("JDK 13"). Since JDK-8215380 is a P3 bug, it's eligible to go into JDK 12 after RDP1 without any further approval. s'marks On 12/13/18 3:20 PM, Claes Redestad wrote: > Hi, > > I need to revert an accidental change to String.length > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 > Patch inlined below > > Running the accidentally pushed version in naive microbenchmarks showed > that avoiding the shift operation can improve throughput of str.length() > by a small measure (~1.06x) for latin1-only inputs, neutral for mixed > or utf16-only inputs, but also adds a branch (visible in profiling) > which could blow up in more real cases. Regardless, it should be > reviewed and discussed on it's own merits. Sorry! > > /Claes > > diff -r 8bf9268df0e2 src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java??? Thu Dec 13 15:31:05 > 2018 +0100 > +++ b/src/java.base/share/classes/java/lang/String.java??? Thu Dec 13 23:59:43 > 2018 +0100 > @@ -664,7 +664,7 @@ > ????? *????????? object. > ????? */ > ???? public int length() { > -??????? return isLatin1() ? value.length : value.length >> UTF16; > +??????? return value.length >> coder(); > ???? } > > ???? /** From martinrb at google.com Fri Dec 14 04:51:42 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Dec 2018 20:51:42 -0800 Subject: The meaning of the java.vendor property? In-Reply-To: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> References: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> Message-ID: There's a configure flag for java.vendor (but not java.specification.vendor) which is a strong hint. --with-vendor-name Set vendor name. Among others, used to set the 'java.vendor' and 'java.vm.vendor' system properties. [not specified] On Thu, Dec 13, 2018 at 2:14 PM Mathiske, Bernd wrote: > I was wondering if it?s OK to modify the ?java.vendor? system property as > reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK > distribution builders seem to be doing so, but others not. Is there a rule > for this? The documentation does not seem exactly conclusive: > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() > > What is a ?vendor? in this context? Is it always supposed to be ?Oracle > Corporation? to stay compatible? Or is it supposed to be whoever builds and > packages the binaries so we can track the origin of the binary artifacts > better? > > Bernd > > From mvala at redhat.com Fri Dec 14 06:37:34 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 14 Dec 2018 07:37:34 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> Thanks Martin for finding this serious issue and the testcase. I understand the issue, but so far I've been unable to find effective enough solution that beats high/low head/tail bucket splitting. I'll keep looking into it and I'll propose a new patch or write some summary and results of my experiments. Probably next week. On 12/12/18 9:16 PM, Martin Buchholz wrote: > Software is hard. > > I found myself removing the remaining style changes to be able to review > the changes. > (We're going to have to disagree about the value of curlies). > Here's my reduction: > > --- src/main/java/util/HashMap.java 11 Nov 2018 16:27:28 -0000 1.9 > +++ src/main/java/util/HashMap.java 12 Dec 2018 20:10:03 -0000 > @@ -503,7 +503,7 @@ > threshold = tableSizeFor(t); > } > else if (s > threshold) > - resize(); > + resize(s); > for (Map.Entry e : m.entrySet()) { > K key = e.getKey(); > V value = e.getValue(); > @@ -661,6 +661,30 @@ > } > > /** > + * Resizes the table to the nearest power of two to {@code size}. > + * Moves all items to the new table. > + * > + * @param size expected number of elements in the new table > + * @return the table > + */ > + final Node[] resize(int size) { > + if (size < 0) { > + throw new IllegalArgumentException("Negative number of > elements does not make sense."); > + } > + Node[] oldTable = table; > + int oldCapacity = (oldTable == null) ? 0 : oldTable.length; > + int newCapacity = tableSizeFor(size); > + > + // need to resize? > + if (newCapacity > oldCapacity) { > + threshold = (int) ((float) newCapacity * loadFactor); > + return createTableAndMoveElements(newCapacity, oldCapacity, > oldTable); > + } else { > + return oldTable; > + } > + } > + > + /** > * Initializes or doubles table size. If null, allocates in > * accord with initial capacity target held in field threshold. > * Otherwise, because we are using power-of-two expansion, the > @@ -695,6 +719,11 @@ > (int)ft : Integer.MAX_VALUE); > } > threshold = newThr; > + > + return createTableAndMoveElements(newCap, oldCap, oldTab); > + } > + > + private Node[] createTableAndMoveElements(int newCap, int oldCap, > Node[] oldTab) { > @SuppressWarnings({"rawtypes","unchecked"}) > Node[] newTab = (Node[])new Node[newCap]; > table = newTab; > > > Here's a test that fails with the proposed patch: > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > > /** > * "Missing" test found while investigating JDK-8210280. > * See discussion on mailing list. > * TODO: randomize > */ > public void testBug8210280() { > Map m = impl.emptyMap(); > for (int i = 0; i < 4; i++) m.put(7 + i * 16, 0); > Map more = impl.emptyMap(); > for (int i = 0; i < 128; i++) more.put(-i, 42); > m.putAll(more); > for (int i = 0; i < 4; i++) assertEquals(0, m.get(7 + i * 16)); > } > -- Michal Vala OpenJDK QE Red Hat Czech From mvala at redhat.com Fri Dec 14 06:41:03 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 14 Dec 2018 07:41:03 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> Message-ID: <1119878c-809b-e5c0-5455-513016ddadc3@redhat.com> Thanks, looking into that. On 12/12/18 9:29 PM, Martin Buchholz wrote: > When hacking on HashMap, one always needs to keep LinkedHashMap in the back > of one's mind. > > If you use removeEldestEntry then the occupancy can never get beyond some > limit. It may be weird to have elements that are part of a putAll being > removed during the call to putAll. There's already a call to resize > causing the backing array to grow in this (very corner) case, so it's > arguably not introducing new weird behavior. If removeEldestEntry is > overridden then ideally you would only grow by doubling, but it's such a > corner case this may not be worth doing. > -- Michal Vala OpenJDK QE Red Hat Czech From volker.simonis at gmail.com Fri Dec 14 08:12:14 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 14 Dec 2018 09:12:14 +0100 Subject: The meaning of the java.vendor property? In-Reply-To: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> References: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> Message-ID: Hi Bernd, from my understanding you can choose to freely set the following properties (and we do that for SapMachine, as you can see): java.vendor = SAP SE java.vendor.url = https://sapmachine.io java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new java.vm.vendor = SAP SE The following "specification.vendor" properties have to show the Java SE spec lead (which currently is Oracle) so you shouldn't change them: java.specification.vendor = Oracle Corporation java.vm.specification.vendor = Oracle Corporation Regards, Volker On Thu, Dec 13, 2018 at 11:14 PM Mathiske, Bernd wrote: > > I was wondering if it?s OK to modify the ?java.vendor? system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive: > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() > > What is a ?vendor? in this context? Is it always supposed to be ?Oracle Corporation? to stay compatible? Or is it supposed to be whoever builds and packages the binaries so we can track the origin of the binary artifacts better? > > Bernd > From takiguc at linux.vnet.ibm.com Fri Dec 14 09:58:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 14 Dec 2018 18:58:25 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> Message-ID: <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> Hello Alan. I opened JDK-8215333 for Charset filtering issue [1]. I cannot wait until JDK-8215333 is closed. Is it possible to put IBM-29626C charset with standard way ? [1] https://bugs.openjdk.java.net/browse/JDK-8215333 Thanks, Ichiroh Takiguchi On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > Hello Roger, Magnus and Alan. > I may need to put alias information into charsets file. > stdcs-xxx cannot handle this information... > > Still AIX needs IBM-29626C charset for default encoding... > > I appreciate if you give me further suggestions. > > Thanks, > Ichiroh Takiguchi > > On 2018-12-10 20:50, Alan Bateman wrote: >> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>> On 2018-12-07 21:20, Roger Riggs wrote: >>>> Hi, >>>> >>>> It is a nice feature that charsets are selected at build time using >>>> the stdcs-xxx files. >>>> This change breaks that pattern and embeds os specific information >>>> in more than one place. >>>> That does not seem like an improvement.? Is there any alternative? >>> I agree. Why is it not enough just to add it to stdcs-aix? >> My reading of the patch is that the "os" key is to avoid generating it >> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> non-AIX platforms. The general direction is welcome but I think >> further work and discussion will be needed to get the right set of >> changes to support filtering in the build. It can probably be >> separated from the changes to add IBM-29626C to AIX's java.base. >> >> -Alan From Alan.Bateman at oracle.com Fri Dec 14 11:38:06 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Dec 2018 11:38:06 +0000 Subject: RFR 8215372: test/jdk/java/nio/file/DirectoryStream/Basic.java not correct for validating the use of a glob In-Reply-To: <6B9768EE-CEA3-4C8A-BD00-50F0557CB05F@oracle.com> References: <6B9768EE-CEA3-4C8A-BD00-50F0557CB05F@oracle.com> Message-ID: <1d0a51fc-aab0-1630-9e1d-f258ac6979f5@oracle.com> On 13/12/2018 20:30, Lance Andersen wrote: > Hi all, > > Attached is the patch for https://bugs.openjdk.java.net/browse/JDK-8215372 that addresses the test DirectoyStream/Basic.java which was not correctly validating newDirectoryStream using a glob: > The test update looks good to me. -Alan From dl at cs.oswego.edu Fri Dec 14 12:43:38 2018 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 14 Dec 2018 07:43:38 -0500 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: <7488b9df-72dc-525e-916e-7103348dbf90@reini.net> References: <25205448a5eb04d12e36ec3a378afc16@reini.net> <7488b9df-72dc-525e-916e-7103348dbf90@reini.net> Message-ID: <0daea2f6-881f-9816-d5ce-f6cc1ed05cba@cs.oswego.edu> On 12/13/18 2:34 PM, Patrick Reinhart wrote: > Should I prepare a webrev for this change? No, I think we are all set (thanks Martin!) https://bugs.openjdk.java.net/browse/JDK-8215359 > > -Patrick > > Am 13.12.18 um 15:15 schrieb Doug Lea: >> On 12/13/18 8:44 AM, Patrick Reinhart wrote: >>> This special case could have been handled also by the >>> InnocuousForkJoinWorkerThread >>> could in my opinion be relaxed to accept null or the system classloader >>> to be set >>> using setContextClassLoader() >> Thanks. We should/will do this. The unconditional throw was clearly too >> strong; innocuous calls can be allowed. This doesn't address the general >> issues of dynamic security manager installation, but at least removes an >> obstacle for people trying to cope. >> >> I created CR: https://bugs.openjdk.java.net/browse/JDK-8215359 >> >> -Doug > > > From andy.herrick at oracle.com Fri Dec 14 12:46:30 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 14 Dec 2018 07:46:30 -0500 Subject: jpackage EA Build 0 Message-ID: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, This build is intended for developers interested in jpackage, and is provided as a convenience so that they don't need to build from the source code (branch="JDK-8200758-branch"). Warning: This build is based on an incomplete version of JDK 12 . Please send feedback via e-mail to core-libs-dev at openjdk.java.net /Andy From patrick at reini.net Fri Dec 14 13:09:21 2018 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Dec 2018 14:09:21 +0100 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: <0daea2f6-881f-9816-d5ce-f6cc1ed05cba@cs.oswego.edu> References: <25205448a5eb04d12e36ec3a378afc16@reini.net> <7488b9df-72dc-525e-916e-7103348dbf90@reini.net> <0daea2f6-881f-9816-d5ce-f6cc1ed05cba@cs.oswego.edu> Message-ID: <6f60bc28c7e4252c743cf9bdfde0ae26@reini.net> Wow - nice :-) On 2018-12-14 13:43, Doug Lea wrote: > On 12/13/18 2:34 PM, Patrick Reinhart wrote: >> Should I prepare a webrev for this change? > > No, I think we are all set (thanks Martin!) > https://bugs.openjdk.java.net/browse/JDK-8215359 > > > From Roger.Riggs at oracle.com Fri Dec 14 14:06:34 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 14 Dec 2018 09:06:34 -0500 Subject: RFR: 8215380: Backout accidental change to String::length In-Reply-To: References: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> Message-ID: <99692d1b-eb1a-28fe-d9ad-b779de840a9e@oracle.com> +1 On 12/13/2018 06:43 PM, Stuart Marks wrote: > Hi Claes, > > Thank for catching this. Looks good. > > Note that the original changeset (JDK-8215281) went into JDK 12 before > the RDP1 fork, so this fix should also go into JDK 12. That's a > different repo now. It will then be auto-propagated to the JDK > mainline ("JDK 13"). > > Since JDK-8215380 is a P3 bug, it's eligible to go into JDK 12 after > RDP1 without any further approval. > > s'marks > > > On 12/13/18 3:20 PM, Claes Redestad wrote: >> Hi, >> >> I need to revert an accidental change to String.length >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 >> Patch inlined below >> >> Running the accidentally pushed version in naive microbenchmarks showed >> that avoiding the shift operation can improve throughput of str.length() >> by a small measure (~1.06x) for latin1-only inputs, neutral for mixed >> or utf16-only inputs, but also adds a branch (visible in profiling) >> which could blow up in more real cases. Regardless, it should be >> reviewed and discussed on it's own merits. Sorry! >> >> /Claes >> >> diff -r 8bf9268df0e2 src/java.base/share/classes/java/lang/String.java >> --- a/src/java.base/share/classes/java/lang/String.java??? Thu Dec 13 >> 15:31:05 2018 +0100 >> +++ b/src/java.base/share/classes/java/lang/String.java??? Thu Dec 13 >> 23:59:43 2018 +0100 >> @@ -664,7 +664,7 @@ >> ?????? *????????? object. >> ?????? */ >> ????? public int length() { >> -??????? return isLatin1() ? value.length : value.length >> UTF16; >> +??????? return value.length >> coder(); >> ????? } >> >> ????? /** From Roger.Riggs at oracle.com Fri Dec 14 14:15:38 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 14 Dec 2018 09:15:38 -0500 Subject: The meaning of the java.vendor property? In-Reply-To: References: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> Message-ID: <6b69fce5-7e80-75c1-170b-7024b320da64@oracle.com> That's my understanding also. Vendor is the entity that builds and releases the bundle. Regards, Roger On 12/14/2018 03:12 AM, Volker Simonis wrote: > Hi Bernd, > > from my understanding you can choose to freely set the following > properties (and we do that for SapMachine, as you can see): > > java.vendor = SAP SE > java.vendor.url = https://sapmachine.io > java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new > java.vm.vendor = SAP SE > > The following "specification.vendor" properties have to show the Java > SE spec lead (which currently is Oracle) so you shouldn't change them: > > java.specification.vendor = Oracle Corporation > java.vm.specification.vendor = Oracle Corporation > > Regards, > Volker > > On Thu, Dec 13, 2018 at 11:14 PM Mathiske, Bernd wrote: >> I was wondering if it?s OK to modify the ?java.vendor? system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive: >> >> https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html >> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() >> >> What is a ?vendor? in this context? Is it always supposed to be ?Oracle Corporation? to stay compatible? Or is it supposed to be whoever builds and packages the binaries so we can track the origin of the binary artifacts better? >> >> Bernd >> From claes.redestad at oracle.com Fri Dec 14 15:17:58 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Dec 2018 16:17:58 +0100 Subject: RFR: 8215380: Backout accidental change to String::length In-Reply-To: <99692d1b-eb1a-28fe-d9ad-b779de840a9e@oracle.com> References: <49871451-0ae9-853f-d2e9-0bb87f596976@oracle.com> <99692d1b-eb1a-28fe-d9ad-b779de840a9e@oracle.com> Message-ID: Thanks everyone for reviewing! I have pushed this to jdk/jdk12 /Claes On 2018-12-14 15:06, Roger Riggs wrote: > +1 > > On 12/13/2018 06:43 PM, Stuart Marks wrote: >> Hi Claes, >> >> Thank for catching this. Looks good. >> >> Note that the original changeset (JDK-8215281) went into JDK 12 before >> the RDP1 fork, so this fix should also go into JDK 12. That's a >> different repo now. It will then be auto-propagated to the JDK >> mainline ("JDK 13"). >> >> Since JDK-8215380 is a P3 bug, it's eligible to go into JDK 12 after >> RDP1 without any further approval. >> >> s'marks From martinrb at google.com Fri Dec 14 15:11:52 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 14 Dec 2018 07:11:52 -0800 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: References: Message-ID: On Thu, Dec 13, 2018 at 4:37 AM Patrick Reinhart wrote: > Even if the security manager is enabled before the initialize of the > ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread > instances (sometimes it picks the main thread instead, that has not the > restrictions, what I think should not be the case and is a potential > security leak too) > Looking again at testCommonPoolThreadContextClassLoader, we had once noticed that a common pool task might escape into a caller thread, but as usual, we then forgot about it. 97 // Ensure runInCommonPool is truly running in the common pool, 98 // by giving this thread no opportunity to "help" on get(). And this might indeed be a security problem that should be fixed. From andrew_m_leonard at uk.ibm.com Fri Dec 14 16:24:14 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 14 Dec 2018 16:24:14 +0000 Subject: JDK-8165199: UUID.fromString(str) compliance checking? Message-ID: hi, So i'm just taking a look at what appears quite a simple bug : https://bugs.openjdk.java.net/browse/JDK-8165199 , at least the fix is simple to make UUID.fromString(str) strictly uuid bnf compliant. However, I wanted to get community opinion on potential "compliance" issues with doing such a fix? As it currently stands the method will allow any string up to 36 characters containing 4 "-"'s, eg: this would be valid abc-123-123-123-abc123 whereas a properly formatted UUID string should be hex values of lengths 8-4-4-4-12. There are obvious implications in increasing the validation that it could break some existing applications that were either knowing or un-knowingly specifying the strings in a non-spec way... am I just being paranoid..!? Thoughts? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From claes.redestad at oracle.com Fri Dec 14 16:42:06 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Dec 2018 17:42:06 +0100 Subject: JDK-8165199: UUID.fromString(str) compliance checking? In-Reply-To: References: Message-ID: Hi, a stricter implementation could also be (much) more performant. I've been meaning to propose a patch that makes strict mode default and adds a configuration option to fall back to the current, relaxed implementation. Adding such compatibility options always feel a bit like a dirty hack, though. /Claes On 2018-12-14 17:24, Andrew Leonard wrote: > hi, > So i'm just taking a look at what appears quite a simple bug : > https://bugs.openjdk.java.net/browse/JDK-8165199 , at least the fix is > simple to make UUID.fromString(str) strictly uuid bnf compliant. However, > I wanted to get community opinion on potential "compliance" issues with > doing such a fix? > As it currently stands the method will allow any string up to 36 > characters containing 4 "-"'s, eg: this would be valid > abc-123-123-123-abc123 > whereas a properly formatted UUID string should be hex values of lengths > 8-4-4-4-12. > > There are obvious implications in increasing the validation that it could > break some existing applications that were either knowing or un-knowingly > specifying the strings in a non-spec way... > > am I just being paranoid..!? Thoughts? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From joe.darcy at oracle.com Fri Dec 14 16:58:03 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 14 Dec 2018 08:58:03 -0800 Subject: JDK-8165199: UUID.fromString(str) compliance checking? In-Reply-To: References: Message-ID: Hello, Note that a fix to this issue would require a CSR (https://wiki.openjdk.java.net/display/csr/Main) to either assess the behavioral compatibility impact of changing the existing behavior or to review a new API added for stricter parsing. Cheers, -Joe On 12/14/2018 8:42 AM, Claes Redestad wrote: > Hi, > > a stricter implementation could also be (much) more performant. I've > been meaning to propose a patch that makes strict mode default and adds > a configuration option to fall back to the current, relaxed > implementation. Adding such compatibility options always feel a bit like > a dirty hack, though. > > /Claes > > On 2018-12-14 17:24, Andrew Leonard wrote: >> hi, >> So i'm just taking a look at what appears quite a simple bug : >> https://bugs.openjdk.java.net/browse/JDK-8165199 , at least the fix is >> simple to make UUID.fromString(str) strictly uuid bnf compliant. >> However, >> I wanted to get community opinion on potential "compliance" issues with >> doing such a fix? >> As it currently stands the method will allow any string up to 36 >> characters containing 4 "-"'s, eg: this would be valid >> ???? abc-123-123-123-abc123 >> whereas a properly formatted UUID string should be hex values of lengths >> 8-4-4-4-12. >> >> There are obvious implications in increasing the validation that it >> could >> break some existing applications that were either knowing or >> un-knowingly >> specifying the strings in a non-spec way... >> >> am I just being paranoid..!? Thoughts? >> >> Thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU >> From mvala at redhat.com Fri Dec 14 17:00:09 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 14 Dec 2018 18:00:09 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> Message-ID: Hi, here's the new webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.02/ I solved the issue by incrementally doubling the new table, before adding new elements. This solution has no such performance boost as first buggy one, it's still measurable for case when adding big map to another, small non-empty map. This is faster because doubling happens with a lot less elements than it would happen while adding new elements. one of benchmark runs clean upstream: HashMapBench.putAllWithBigMapToNonEmptyMap avgt 10 189.055 ? 12.911 ms/op with patch: HashMapBench.putAllWithBigMapToNonEmptyMap avgt 10 211.921 ? 23.793 ms/op I've also tried generic approach without holding head and tail pointers to the bucket. However, need of preserve the order kills this solution. Tail pointer boost is too good. Another generic approach would be to hold tail pointers just where needed, but I couldn't find effective solution for now (without e.g. having second table of the same size, which is killer). I'm still looking into removeEldestEntry with LinkedHashMap. On 12/14/18 7:37 AM, Michal Vala wrote: > Thanks Martin for finding this serious issue and the testcase. > > I understand the issue, but so far I've been unable to find effective enough > solution that beats high/low head/tail bucket splitting. I'll keep looking into > it and I'll propose a new patch or write some summary and results of my > experiments. Probably next week. > > On 12/12/18 9:16 PM, Martin Buchholz wrote: >> Software is hard. >> >> I found myself removing the remaining style changes to be able to review >> the changes. >> (We're going to have to disagree about the value of curlies). >> Here's my reduction: >> >> --- src/main/java/util/HashMap.java 11 Nov 2018 16:27:28 -0000 1.9 >> +++ src/main/java/util/HashMap.java 12 Dec 2018 20:10:03 -0000 >> @@ -503,7 +503,7 @@ >> ????????????????????? threshold = tableSizeFor(t); >> ????????????? } >> ????????????? else if (s > threshold) >> -??????????????? resize(); >> +??????????????? resize(s); >> ????????????? for (Map.Entry e : m.entrySet()) { >> ????????????????? K key = e.getKey(); >> ????????????????? V value = e.getValue(); >> @@ -661,6 +661,30 @@ >> ????? } >> >> ????? /** >> +???? * Resizes the table to the nearest power of two to {@code size}. >> +???? * Moves all items to the new table. >> +???? * >> +???? * @param size expected number of elements in the new table >> +???? * @return the table >> +???? */ >> +??? final Node[] resize(int size) { >> +??????? if (size < 0) { >> +??????????? throw new IllegalArgumentException("Negative number of >> elements does not make sense."); >> +??????? } >> +??????? Node[] oldTable = table; >> +??????? int oldCapacity = (oldTable == null) ? 0 : oldTable.length; >> +??????? int newCapacity = tableSizeFor(size); >> + >> +??????? // need to resize? >> +??????? if (newCapacity > oldCapacity) { >> +??????????? threshold = (int) ((float) newCapacity * loadFactor); >> +??????????? return createTableAndMoveElements(newCapacity, oldCapacity, >> oldTable); >> +??????? } else { >> +??????????? return oldTable; >> +??????? } >> +??? } >> + >> +??? /** >> ?????? * Initializes or doubles table size.? If null, allocates in >> ?????? * accord with initial capacity target held in field threshold. >> ?????? * Otherwise, because we are using power-of-two expansion, the >> @@ -695,6 +719,11 @@ >> ??????????????????????? (int)ft : Integer.MAX_VALUE); >> ????????? } >> ????????? threshold = newThr; >> + >> +??????? return createTableAndMoveElements(newCap, oldCap, oldTab); >> +??? } >> + >> +??? private Node[] createTableAndMoveElements(int newCap, int oldCap, >> Node[] oldTab) { >> ????????? @SuppressWarnings({"rawtypes","unchecked"}) >> ????????? Node[] newTab = (Node[])new Node[newCap]; >> ????????? table = newTab; >> >> >> Here's a test that fails with the proposed patch: >> >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html >> >> >> ???? /** >> ????? * "Missing" test found while investigating JDK-8210280. >> ????? * See discussion on mailing list. >> ????? * TODO: randomize >> ????? */ >> ???? public void testBug8210280() { >> ???????? Map m = impl.emptyMap(); >> ???????? for (int i = 0; i < 4; i++) m.put(7 + i * 16, 0); >> ???????? Map more = impl.emptyMap(); >> ???????? for (int i = 0; i < 128; i++) more.put(-i, 42); >> ???????? m.putAll(more); >> ???????? for (int i = 0; i < 4; i++) assertEquals(0, m.get(7 + i * 16)); >> ???? } >> > -- Michal Vala OpenJDK QE Red Hat Czech From claes.redestad at oracle.com Fri Dec 14 17:12:58 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Dec 2018 18:12:58 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods Message-ID: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> Hi, the various PrintStream.println methods are inefficient: nested synchronization, multiple flushes and a scan of the input string for newlines that in the end is pointless in this context since newLine will always flush anyway (if autoflush is enabled). While performance of printing to console/file is likely to be dominated by the I/O overheads, there are plenty of simple text processing applications using stdout to pipe output to another process for which performance of println could definitely matter. Webrev: http://cr.openjdk.java.net/~redestad/8215412/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215412 Using a simple test program like this: public class Test { public static void main (String ... args) { for (int i = 0; i < Integer.parseInt(args[0]); i++) System.out.println(args[1]); } } ... and stating the cost of running: $ java Test 100000 tttttttttttttttttttttttttttttttttttttttttttttt | wc -l ... I get a 15-30% reduction in cycles and wall clock time (larger reduction the more output is produced). Thanks! /Claes From mik3hall at gmail.com Fri Dec 14 17:26:59 2018 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 14 Dec 2018 11:26:59 -0600 Subject: jpackage EA Build 0 In-Reply-To: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> > > Warning: This build is based on an incomplete version of JDK 12 . > So when I download (OS X) it appears it is included with a entire jdk 12 build? From kevin.rushforth at oracle.com Fri Dec 14 17:30:03 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Dec 2018 09:30:03 -0800 Subject: jpackage EA Build 0 In-Reply-To: <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> Message-ID: <56023554-4994-46d2-42ce-3cd812dc9eb5@oracle.com> Correct. jpackage will be delivered as a tool that is part of the JDK. Future EA builds will likely include an EA of JDK 13. -- Kevin On 12/14/2018 9:26 AM, Michael Hall wrote: >> Warning: This build is based on an incomplete version of JDK 12 . >> > So when I download (OS X) it appears it is included with a entire jdk 12 build? From mik3hall at gmail.com Fri Dec 14 17:42:33 2018 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 14 Dec 2018 11:42:33 -0600 Subject: jpackage EA Build 0 In-Reply-To: <56023554-4994-46d2-42ce-3cd812dc9eb5@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <56023554-4994-46d2-42ce-3cd812dc9eb5@oracle.com> Message-ID: <25E5349C-C30D-4873-9471-537CCFAC7946@gmail.com> > On Dec 14, 2018, at 11:30 AM, Kevin Rushforth wrote: > > Correct. jpackage will be delivered as a tool that is part of the JDK. Future EA builds will likely include an EA of JDK 13. > > -- Kevin > > On 12/14/2018 9:26 AM, Michael Hall wrote: >>> Warning: This build is based on an incomplete version of JDK 12 . >>> >> So when I download (OS X) it appears it is included with a entire jdk 12 build? OK thanks, this might take a little figuring out. I haven?t done anything like this for a while. If I replace the Plugins/Java.runtime/Contents for my application with the jpackage downloaded idk-12.jdk/Contents directory I get a JRELoadError dialog on launch. Are there actual JDK 12 dependencies with the command or is that what it?s being worked on and tested with and there may not actually be 12 dependencies? So I could say drop the jpackage command into my app?s current earlier JRE bin directory and it might work? From kevin.rushforth at oracle.com Fri Dec 14 17:53:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Dec 2018 09:53:51 -0800 Subject: jpackage EA Build 0 In-Reply-To: <25E5349C-C30D-4873-9471-537CCFAC7946@gmail.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <56023554-4994-46d2-42ce-3cd812dc9eb5@oracle.com> <25E5349C-C30D-4873-9471-537CCFAC7946@gmail.com> Message-ID: <5277f703-475d-5afe-cc4d-2289be28f710@oracle.com> > So I could say drop the jpackage command into my app?s current earlier JRE bin directory and it might work? No. You need to run jpackage from the JDK 12 ea build that you downloaded. jpackage isn't something you drop into your application, it's a tool you run to package up your application with a Java Runtime. By default it uses the Java Runtime from which you run jpackage, but you can specify a different Java Runtime to use to bundle with your application via: ??? jpacakge create-image --runtime-image /somewhere_else/jdk-11 ... -- Kevin On 12/14/2018 9:42 AM, Michael Hall wrote: >> On Dec 14, 2018, at 11:30 AM, Kevin Rushforth wrote: >> >> Correct. jpackage will be delivered as a tool that is part of the JDK. Future EA builds will likely include an EA of JDK 13. >> >> -- Kevin >> >> On 12/14/2018 9:26 AM, Michael Hall wrote: >>>> Warning: This build is based on an incomplete version of JDK 12 . >>>> >>> So when I download (OS X) it appears it is included with a entire jdk 12 build? > OK thanks, this might take a little figuring out. I haven?t done anything like this for a while. > If I replace the Plugins/Java.runtime/Contents for my application with the jpackage downloaded idk-12.jdk/Contents directory I get a JRELoadError dialog on launch. > Are there actual JDK 12 dependencies with the command or is that what it?s being worked on and tested with and there may not actually be 12 dependencies? > So I could say drop the jpackage command into my app?s current earlier JRE bin directory and it might work? > From mik3hall at gmail.com Fri Dec 14 17:57:23 2018 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 14 Dec 2018 11:57:23 -0600 Subject: jpackage EA Build 0 In-Reply-To: <5277f703-475d-5afe-cc4d-2289be28f710@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <56023554-4994-46d2-42ce-3cd812dc9eb5@oracle.com> <25E5349C-C30D-4873-9471-537CCFAC7946@gmail.com> <5277f703-475d-5afe-cc4d-2289be28f710@oracle.com> Message-ID: > On Dec 14, 2018, at 11:53 AM, Kevin Rushforth wrote: > > > So I could say drop the jpackage command into my app?s current earlier JRE bin directory and it might work? > > No. You need to run jpackage from the JDK 12 ea build that you downloaded. jpackage isn't something you drop into your application, it's a tool you run to package up your application with a Java Runtime. By default it uses the Java Runtime from which you run jpackage, but you can specify a different Java Runtime to use to bundle with your application via: > > jpacakge create-image --runtime-image /somewhere_else/jdk-11 ? The apps a CLI java shell I do most of my testing with. OK, I?ll either have to figure out normal command line usage for 12 or the JRELoadError. Thanks again From philip.race at oracle.com Fri Dec 14 17:58:39 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 14 Dec 2018 09:58:39 -0800 Subject: jpackage EA Build 0 In-Reply-To: <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> Message-ID: <6350161d-fd1a-b525-6a6c-9266285582d1@oracle.com> "Incomplete" meant "JDK 12 is not yet completed". Perhaps that could have been worded differently like "a non-final version of JDK12". I think the intent was to make it clear what JDK version this was. Eg it is not built on top of 11 GA. It is built on top of the current JDK development branch .. which happens to be intended to become 12. And actually the NEXT build will be built on top of JDK 13 .. since 12 just forked off to be stablised for release. jpackage can't be separated from the JDK any more than all the other tools that ship with JDK. It is not going to be a "standalone" tool that "happens" to be bundled with the JDK. -phil. On 12/14/18 9:26 AM, Michael Hall wrote: >> Warning: This build is based on an incomplete version of JDK 12 . >> > So when I download (OS X) it appears it is included with a entire jdk 12 build? From mik3hall at gmail.com Fri Dec 14 18:03:11 2018 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 14 Dec 2018 12:03:11 -0600 Subject: jpackage EA Build 0 In-Reply-To: <6350161d-fd1a-b525-6a6c-9266285582d1@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <6350161d-fd1a-b525-6a6c-9266285582d1@oracle.com> Message-ID: <55591AF4-4974-4419-B64E-3CF1AE0DD8DF@gmail.com> > On Dec 14, 2018, at 11:58 AM, Phil Race wrote: > > "Incomplete" meant "JDK 12 is not yet completed". > Perhaps that could have been worded differently like "a non-final version of JDK12". > I think the intent was to make it clear what JDK version this was. Eg it is not built on top > of 11 GA. It is built on top of the current JDK development branch .. which happens to be > intended to become 12. And actually the NEXT build will be built on top of JDK 13 .. > since 12 just forked off to be stablised for release. > > jpackage can't be separated from the JDK any more than all the other tools > that ship with JDK. It is not going to be a "standalone" tool that "happens" > to be bundled with the JDK. OK fair enough, got that. This just made me wonder though, would JDK 12 be the only JRE that can be targeted for packaging? It can only make JDK 12 executables? From kevin.rushforth at oracle.com Fri Dec 14 18:06:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Dec 2018 10:06:15 -0800 Subject: jpackage EA Build 0 In-Reply-To: <55591AF4-4974-4419-B64E-3CF1AE0DD8DF@gmail.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <6350161d-fd1a-b525-6a6c-9266285582d1@oracle.com> <55591AF4-4974-4419-B64E-3CF1AE0DD8DF@gmail.com> Message-ID: On 12/14/2018 10:03 AM, Michael Hall wrote: >> On Dec 14, 2018, at 11:58 AM, Phil Race wrote: >> >> "Incomplete" meant "JDK 12 is not yet completed". >> Perhaps that could have been worded differently like "a non-final version of JDK12". >> I think the intent was to make it clear what JDK version this was. Eg it is not built on top >> of 11 GA. It is built on top of the current JDK development branch .. which happens to be >> intended to become 12. And actually the NEXT build will be built on top of JDK 13 .. >> since 12 just forked off to be stablised for release. >> >> jpackage can't be separated from the JDK any more than all the other tools >> that ship with JDK. It is not going to be a "standalone" tool that "happens" >> to be bundled with the JDK. > OK fair enough, got that. This just made me wonder though, would JDK 12 be the only JRE that can be targeted for packaging? > It can only make JDK 12 executables? > No, the purpose of the --runtime-image option is to allow bundling other JREs with your app. Specifically, we will test the ability to bundle a JRE 11. -- Kevin From Roger.Riggs at oracle.com Fri Dec 14 18:06:15 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 14 Dec 2018 13:06:15 -0500 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> Message-ID: Hi Claes, 611: Can't the loop break after finding the first \n? 916: I'd probably call writeln(String.valueOf(x)) and skip the extra method call. Is there any benefit of doing the String conversions before the synchronized block? As is in the old code for println(Object x). There isn't much contention I expect so it's probably a benefit, (compared to easy to read code). Thanks, Roger On 12/14/2018 12:12 PM, Claes Redestad wrote: > Hi, > > ?the various PrintStream.println methods are inefficient: nested > synchronization, multiple flushes and a scan of the input string for > newlines that in the end is pointless in this context since newLine will > always flush anyway (if autoflush is enabled). > > ?While performance of printing to console/file is likely to be > dominated by the I/O overheads, there are plenty of simple text > processing applications using stdout to pipe output to another process > for which performance of println could definitely matter. > > Webrev: http://cr.openjdk.java.net/~redestad/8215412/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215412 > > Using a simple test program like this: > > public class Test { > ? public static void main (String ... args) { > ??? for (int i = 0; i < Integer.parseInt(args[0]); i++) > ????? System.out.println(args[1]); > ? } > } > > ... and stating the cost of running: > > $ java Test 100000 tttttttttttttttttttttttttttttttttttttttttttttt | wc -l > > ... I get a 15-30% reduction in cycles and wall clock time (larger > reduction the more output is produced). > > Thanks! > > /Claes From philip.race at oracle.com Fri Dec 14 18:05:09 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 14 Dec 2018 10:05:09 -0800 Subject: jpackage EA Build 0 In-Reply-To: <55591AF4-4974-4419-B64E-3CF1AE0DD8DF@gmail.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <6350161d-fd1a-b525-6a6c-9266285582d1@oracle.com> <55591AF4-4974-4419-B64E-3CF1AE0DD8DF@gmail.com> Message-ID: See Kevin's last reply. -phil. On 12/14/18 10:03 AM, Michael Hall wrote: > OK fair enough, got that. This just made me wonder though, would JDK 12 be the only JRE that can be targeted for packaging? > It can only make JDK 12 executables? > From mik3hall at gmail.com Fri Dec 14 18:09:47 2018 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 14 Dec 2018 12:09:47 -0600 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <0402F979-F648-4E35-A316-76E0FDAB3E4A@gmail.com> <6350161d-fd1a-b525-6a6c-9266285582d1@oracle.com> <55591AF4-4974-4419-B64E-3CF1AE0DD8DF@gmail.com> Message-ID: > On Dec 14, 2018, at 12:05 PM, Phil Race wrote: > > See Kevin's last reply. > > -phil. > > On 12/14/18 10:03 AM, Michael Hall wrote: >> OK fair enough, got that. This just made me wonder though, would JDK 12 be the only JRE that can be targeted for packaging? >> It can only make JDK 12 executables? >> > Ah, oops, stopped reading for now past the part that answered my original question. Good enough again. > No, the purpose of the --runtime-image option is to allow bundling other JREs with your app. Specifically, we will test the ability to bundle a JRE 11. Ah again. So back supported for 11, prior to that may or may not work. From sam.carlberg at gmail.com Fri Dec 14 19:22:00 2018 From: sam.carlberg at gmail.com (Sam Carlberg) Date: Fri, 14 Dec 2018 14:22:00 -0500 Subject: Using jpacakge with a mixed-modularity app Message-ID: Say I have an app with both modular and non-modular dependencies. With jlink, I can generate a runnable image for the app by linking the modular dependencies and placing the non-modular dependencies on the classpath using a custom launch script. Can jpackage take this mixed-modularity image and create an installer for it? Or would it have to take a fully-modular image and add the non-modular dependencies and app jar as a separate step? I can find no information in the JEP on how non-modular JARs (aside from the main JAR) should be included in a package Sam Carlberg From mathiske at amazon.com Fri Dec 14 19:46:28 2018 From: mathiske at amazon.com (Mathiske, Bernd) Date: Fri, 14 Dec 2018 19:46:28 +0000 Subject: The meaning of the java.vendor property? In-Reply-To: References: <18392896-29AC-4067-888B-5642132A64A0@amazon.com> Message-ID: <3FADE560-D6EA-4F64-8C91-424D81AD6A6D@amazon.com> Martin, Volker, Many things for quickly providing these clarifying words! Going forward, I will be assuming that "vendor" means whoever built the distribution and that there is some intended differentiation in the values of "java.vendor" and "java.vm.vendor". Bernd From: Martin Buchholz Date: Friday, December 14, 2018 at 5:52 AM To: "Mathiske, Bernd" Cc: "core-libs-dev at openjdk.java.net" Subject: Re: The meaning of the java.vendor property? There's a configure flag for java.vendor (but not java.specification.vendor) which is a strong hint. --with-vendor-name Set vendor name. Among others, used to set the 'java.vendor' and 'java.vm.vendor' system properties. [not specified] ?On 12/14/18, 9:13 AM, "Volker Simonis" wrote: Hi Bernd, from my understanding you can choose to freely set the following properties (and we do that for SapMachine, as you can see): java.vendor = SAP SE java.vendor.url = https://sapmachine.io java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new java.vm.vendor = SAP SE The following "specification.vendor" properties have to show the Java SE spec lead (which currently is Oracle) so you shouldn't change them: java.specification.vendor = Oracle Corporation java.vm.specification.vendor = Oracle Corporation Regards, Volker On Thu, Dec 13, 2018 at 11:14 PM Mathiske, Bernd wrote: > > I was wondering if it?s OK to modify the ?java.vendor? system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive: > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() > > What is a ?vendor? in this context? Is it always supposed to be ?Oracle Corporation? to stay compatible? Or is it supposed to be whoever builds and packages the binaries so we can track the origin of the binary artifacts better? > > Bernd > From claes.redestad at oracle.com Fri Dec 14 20:22:44 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Dec 2018 21:22:44 +0100 Subject: RFR: 8215412: Optimize PrintStream.println methods In-Reply-To: References: <5da400e5-2085-1d11-b733-34e0cd2b7219@oracle.com> Message-ID: Hi, On 2018-12-14 19:06, Roger Riggs wrote: > Hi Claes, > > 611: Can't the loop break after finding the first \n? shouldn't have been a loop there at all (and yes, in the pre-existing version breaking after finding the first \n should be ok) > > 916: I'd probably call writeln(String.valueOf(x)) and skip the extra > method call. We need to call String.valueOf twice in the Object case to deal with toString() returning null. That said, concerns was raised that this implementation might change behavior in code that overrides PrintStream unexpectedly due println no longer calling the corresponding print method. I've prepared the work for a CSR to investigate and assess if that behavior change is too risky, and in the meantime implemented a version of this optimization that only optimizes println if PrintStream is defined in java.base: http://cr.openjdk.java.net/~redestad/8215412/jdk.01/ Same performance characteristics in the simple tests I've used to verify this, and no measurable regression (but no speed-up) for classes overriding PrintStream. Thanks! /Claes > > Is there any benefit of doing the String conversions before the > synchronized block? > As is in the old code for println(Object x). > There isn't much contention I expect so it's probably a benefit, > (compared to easy to read code). > > Thanks, Roger > > > On 12/14/2018 12:12 PM, Claes Redestad wrote: >> Hi, >> >> ?the various PrintStream.println methods are inefficient: nested >> synchronization, multiple flushes and a scan of the input string for >> newlines that in the end is pointless in this context since newLine will >> always flush anyway (if autoflush is enabled). >> >> ?While performance of printing to console/file is likely to be >> dominated by the I/O overheads, there are plenty of simple text >> processing applications using stdout to pipe output to another process >> for which performance of println could definitely matter. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215412/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215412 >> >> Using a simple test program like this: >> >> public class Test { >> ? public static void main (String ... args) { >> ??? for (int i = 0; i < Integer.parseInt(args[0]); i++) >> ????? System.out.println(args[1]); >> ? } >> } >> >> ... and stating the cost of running: >> >> $ java Test 100000 tttttttttttttttttttttttttttttttttttttttttttttt | wc -l >> >> ... I get a 15-30% reduction in cycles and wall clock time (larger >> reduction the more output is produced). >> >> Thanks! >> >> /Claes > From andrew_m_leonard at uk.ibm.com Fri Dec 14 22:00:45 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 14 Dec 2018 22:00:45 +0000 Subject: JDK-8165199: UUID.fromString(str) compliance checking? In-Reply-To: References: Message-ID: Yes, this was my concern, source compatibility... With the current implementation it is not too harmful to "sloppy" app code. If it's not causing any other underlying "bug" then I would be tempted to leave this "sleeping dog..." Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: joe darcy To: Claes Redestad , Andrew Leonard , core-libs-dev at openjdk.java.net Date: 14/12/2018 16:58 Subject: Re: JDK-8165199: UUID.fromString(str) compliance checking? Hello, Note that a fix to this issue would require a CSR ( https://wiki.openjdk.java.net/display/csr/Main ) to either assess the behavioral compatibility impact of changing the existing behavior or to review a new API added for stricter parsing. Cheers, -Joe On 12/14/2018 8:42 AM, Claes Redestad wrote: > Hi, > > a stricter implementation could also be (much) more performant. I've > been meaning to propose a patch that makes strict mode default and adds > a configuration option to fall back to the current, relaxed > implementation. Adding such compatibility options always feel a bit like > a dirty hack, though. > > /Claes > > On 2018-12-14 17:24, Andrew Leonard wrote: >> hi, >> So i'm just taking a look at what appears quite a simple bug : >> https://bugs.openjdk.java.net/browse/JDK-8165199 , at least the fix is >> simple to make UUID.fromString(str) strictly uuid bnf compliant. >> However, >> I wanted to get community opinion on potential "compliance" issues with >> doing such a fix? >> As it currently stands the method will allow any string up to 36 >> characters containing 4 "-"'s, eg: this would be valid >> abc-123-123-123-abc123 >> whereas a properly formatted UUID string should be hex values of lengths >> 8-4-4-4-12. >> >> There are obvious implications in increasing the validation that it >> could >> break some existing applications that were either knowing or >> un-knowingly >> specifying the strings in a non-spec way... >> >> am I just being paranoid..!? Thoughts? >> >> Thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU >> Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From patrick at reini.net Fri Dec 14 22:50:29 2018 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Dec 2018 23:50:29 +0100 Subject: Querstion about ForkJoinPool / SecurityManager interoperability In-Reply-To: References: Message-ID: <1320a011-3c08-39b8-4f92-9dc6925b8cc3@reini.net> Hi Martin, In my simplified test, I managed to reproduce the execution in the main thread, when I did not wait for a start and directly called get()... as in your test here: 99 await(taskStarted); -Patrick Am 14.12.18 um 16:11 schrieb Martin Buchholz: > > > On Thu, Dec 13, 2018 at 4:37 AM Patrick Reinhart > wrote: > > Even if the security manager is enabled before the initialize of the > ForkJoinPool not all work is delegated to > InnocuousForkJoinWorkerThread > instances (sometimes it picks the main thread instead, that has > not the > restrictions, what I think should not be the case and is a potential > security leak too) > > > Looking again at?testCommonPoolThreadContextClassLoader, we had once > noticed that a common pool task might escape into a caller thread, but > as usual, we then forgot about it. > > ? 97? ? ? ? ?// Ensure runInCommonPool is truly running in the common > pool, > ? 98? ? ? ? ?// by giving this thread no opportunity to "help" on get(). > > ?And this might indeed be a security problem that should be fixed. From Alan.Bateman at oracle.com Sat Dec 15 09:40:45 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 15 Dec 2018 09:40:45 +0000 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny Message-ID: This is test only change to fix a few tests that don't have complete @modules or --add-exports options and so fail when running jtreg with vmoption:--illegal-access=deny. The only change that might not be obvious is to langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test creates a custom class loader to load the CreateSymbols tool from the make tree. jtreg doesn't know how to export packages to the unnamed module of custom class loaders so the test is changed to open the packages to the test and then pass on the rights to the unnamed module of the custom class loader. http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html -Alan From eolivelli at gmail.com Sat Dec 15 09:53:58 2018 From: eolivelli at gmail.com (Enrico Olivelli) Date: Sat, 15 Dec 2018 10:53:58 +0100 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: Message-ID: Hi Alan, A little off-topic: Is there any plan to move to 'deny' by default in Java 12 ? Enrico Il sab 15 dic 2018, 10:41 Alan Bateman ha scritto: > This is test only change to fix a few tests that don't have complete > @modules or --add-exports options and so fail when running jtreg with > vmoption:--illegal-access=deny. > > The only change that might not be obvious is to > langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test > creates a custom class loader to load the CreateSymbols tool from the > make tree. jtreg doesn't know how to export packages to the unnamed > module of custom class loaders so the test is changed to open the > packages to the test and then pass on the rights to the unnamed module > of the custom class loader. > > http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html > > -Alan > -- -- Enrico Olivelli From claes.redestad at oracle.com Sat Dec 15 14:58:43 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 15 Dec 2018 15:58:43 +0100 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: Message-ID: Hi Alan, On 2018-12-15 10:40, Alan Bateman wrote: > This is test only change to fix a few tests that don't have complete > @modules or --add-exports options and so fail when running jtreg with > vmoption:--illegal-access=deny. > > The only change that might not be obvious is to > langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test > creates a custom class loader to load the CreateSymbols tool from the > make tree. jtreg doesn't know how to export packages to the unnamed > module of custom class loaders so the test is changed to open the > packages to the test and then pass on the rights to the unnamed module > of the custom class loader. > > http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html looks ok to me. /Claes From Alan.Bateman at oracle.com Sat Dec 15 16:12:24 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 15 Dec 2018 16:12:24 +0000 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: Message-ID: <72cb9e84-8a5b-9148-e645-87a931a16de5@oracle.com> On 15/12/2018 09:53, Enrico Olivelli wrote: > Hi Alan, > A little off-topic: Is there any plan to move to 'deny' by default in > Java 12 ? > Not for JDK 12 as that release is in Rampdown Phase One. -Alan From sverre.moe at gmail.com Sat Dec 15 16:26:57 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Sat, 15 Dec 2018 17:26:57 +0100 Subject: jpackage EA Build 0 In-Reply-To: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: Some feedback from using this new JDK12 jpackage. The argument --version is no longer used for setting the bundler version. Thus one needs to specify bundle resources (spec for RPM and control for DEB), if the version is anything other than "1.0". I have yet to find out how to specify the bundle resources. It tells to put them on the class path, but that cannot be right, as jpackage is module. Using default package resource [menu icon] (add package/movies.png to the class path to customize) Why is --icon the only bundle argument that can be set on jpackage? Using custom package resource [menu icon] (loaded from file /home/sverre/workspace/movies/src/main/deploy/package/linux/movies.png) If these arguments where available there would be no need to add the bundle resources to any class path. --version, --release, --icon, --desktop, --linux-rpm-spec-file, --linux-deb-control-file, --windows-exe-iss-file The project I am trying this on is a fully modularized JavaFX application. task createInstaller(type: Exec) { dependsOn createRuntime dependsOn installDist commandLine '/usr/java/jdk-12/bin/jpackage', 'create-installer', '--verbose', '--name', project.name, '--description', project.description, '--vendor', "Smeaworks Inc", '--install-dir', "/opt/smeaworks", '--category', "Some/Category/Application", '--module-path', new File(installDist.outputs.files.singleFile, "lib"), '--module', "${mainClassName}", '--runtime-image', ""${buildDir}/runtime '--output', "$buildDir/jfx/native" } /Sverre Den fre. 14. des. 2018 kl. 13:47 skrev Andy Herrick : > I am pleased to announce that the first EA build of jpackage is now > available at : https://jdk.java.net/jpackage/ > > This is an early access build of JEP 343: Packaging Tool > , aimed at testing a prototype > implementation of jpackage, > > This build is intended for developers interested in jpackage, and is > provided as a convenience so that they don't need to build from the > source code > (branch="JDK-8200758-branch"). > > Warning: This build is based on an incomplete version of JDK 12 > . > > Please send feedback via e-mail to core-libs-dev at openjdk.java.net > > /Andy > > From eolivelli at gmail.com Sat Dec 15 16:51:10 2018 From: eolivelli at gmail.com (Enrico Olivelli) Date: Sat, 15 Dec 2018 17:51:10 +0100 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: <72cb9e84-8a5b-9148-e645-87a931a16de5@oracle.com> References: <72cb9e84-8a5b-9148-e645-87a931a16de5@oracle.com> Message-ID: Il sab 15 dic 2018, 17:12 Alan Bateman ha scritto: > On 15/12/2018 09:53, Enrico Olivelli wrote: > > Hi Alan, > > A little off-topic: Is there any plan to move to 'deny' by default in > > Java 12 ? > > > Not for JDK 12 as that release is in Rampdown Phase One. > Thanks Enrico > > -Alan > -- -- Enrico Olivelli From sverre.moe at gmail.com Sat Dec 15 17:21:00 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Sat, 15 Dec 2018 18:21:00 +0100 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: Noticed now that there was an --app-version argument as replacement for the previous --version. Though I would like to see any examples during help how to specify the bundle resources to class path. /Sverre Den l?r. 15. des. 2018 kl. 17:26 skrev Sverre Moe : > Some feedback from using this new JDK12 jpackage. > > The argument --version is no longer used for setting the bundler version. > Thus one needs to specify bundle resources (spec for RPM and control for > DEB), if the version is anything other than "1.0". > > I have yet to find out how to specify the bundle resources. It tells to > put them on the class path, but that cannot be right, as jpackage is module. > Using default package resource [menu icon] (add package/movies.png to the > class path to customize) > > Why is --icon the only bundle argument that can be set on jpackage? > Using custom package resource [menu icon] (loaded from file > /home/sverre/workspace/movies/src/main/deploy/package/linux/movies.png) > > If these arguments where available there would be no need to add the > bundle resources to any class path. > --version, --release, --icon, --desktop, --linux-rpm-spec-file, > --linux-deb-control-file, --windows-exe-iss-file > > The project I am trying this on is a fully modularized JavaFX application. > task createInstaller(type: Exec) { > dependsOn createRuntime > dependsOn installDist > > commandLine '/usr/java/jdk-12/bin/jpackage', 'create-installer', > '--verbose', > '--name', project.name, > '--description', project.description, > '--vendor', "Smeaworks Inc", > '--install-dir', "/opt/smeaworks", > '--category', "Some/Category/Application", > '--module-path', new > File(installDist.outputs.files.singleFile, "lib"), > '--module', "${mainClassName}", > '--runtime-image', ""${buildDir}/runtime > '--output', "$buildDir/jfx/native" > } > > /Sverre > > > Den fre. 14. des. 2018 kl. 13:47 skrev Andy Herrick < > andy.herrick at oracle.com>: > >> I am pleased to announce that the first EA build of jpackage is now >> available at : https://jdk.java.net/jpackage/ >> >> This is an early access build of JEP 343: Packaging Tool >> , aimed at testing a prototype >> implementation of jpackage, >> >> This build is intended for developers interested in jpackage, and is >> provided as a convenience so that they don't need to build from the >> source code >> (branch="JDK-8200758-branch"). >> >> Warning: This build is based on an incomplete version of JDK 12 >> . >> >> Please send feedback via e-mail to core-libs-dev at openjdk.java.net >> >> /Andy >> >> From andy.herrick at oracle.com Sat Dec 15 17:44:14 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 15 Dec 2018 12:44:14 -0500 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> On 12/15/2018 11:26 AM, Sverre Moe wrote: > Some feedback from using this new JDK12 jpackage. > > The argument --version is no longer used for setting the bundler version. > Thus one needs to specify bundle resources (spec for RPM and control > for DEB), if the version is anything other than "1.0". Sorry - the name of the option was changed to "--appVersion" recently (to not conflict with --version used to display the version of jpackage). > > I have yet to find out how to specify the bundle resources. It tells > to put them on the class path, but that cannot be right, as jpackage > is module. > Using default package resource [menu icon] ?(add package/movies.png to > the class path to customize) I meant to get back to you on this.? This is an incorrect warning message that needs to be fixed - I will file a bug. The icon should be specified by the --icon option, has nothing to do with a class-path.? This is a resource for the packager not the app. All resources for the app should be specified by combination of --input, --files, and --module-path > > Why is --icon the only bundle argument that can be set on jpackage? > Using custom package resource [menu icon] ?(loaded from file > /home/sverre/workspace/movies/src/main/deploy/package/linux/movies.png) not sure I understand this. > > If these arguments where available there would be no need to add the > bundle resources to any class path. > --version, --release, --icon, --desktop, --linux-rpm-spec-file, > --linux-deb-control-file, --windows-exe-iss-file or this either, > > The project I am trying this on is a fully modularized JavaFX application. > ? ? task createInstaller(type: Exec) { > ? ? ? ? dependsOn createRuntime > ? ? ? ? dependsOn installDist > ? ? ? ? commandLine '/usr/java/jdk-12/bin/jpackage', 'create-installer', > ? ? ? ? ? ? '--verbose', > ? ? ? ? ? ? '--name', project.name , > ? ? ? ? ? ? '--description', project.description, > ? ? ? ? ? ? '--vendor', "Smeaworks Inc", > ? ? ? ? ? ? '--install-dir', "/opt/smeaworks", > ? ? ? ? ? ? '--category', "Some/Category/Application", > ? ? ? ? ? ? '--module-path', new > File(installDist.outputs.files.singleFile, "lib"), > ? ? ? ? ? ? '--module', "${mainClassName}", > ? ? ? ? ? ? '--runtime-image', ""${buildDir}/runtime > ? ? ? ? ? ? '--output', "$buildDir/jfx/native" > ? ? } the latest build contains bug JDK-8213392, which prevents using --module-path and --runtime-image together (see https://bugs.openjdk.java.net/browse/JDK-8213962) This will soon be fixed - but it would still be advisable to run jlink first from the original runtime image with the desired module path. to get a minimal runtime image for your app. /Andy > > /Sverre > > > Den fre. 14. des. 2018 kl. 13:47 skrev Andy Herrick > >: > > I am pleased to announce that the first EA build of jpackage is now > available at : https://jdk.java.net/jpackage/ > > This is an early access build of JEP 343: Packaging Tool > , aimed at testing a prototype > implementation of jpackage, > > This build is intended for developers interested in jpackage, and is > provided as a convenience so that they don't need to build from the > source code > (branch="JDK-8200758-branch"). > > Warning: This build is based on an incomplete version of JDK 12 > . > > Please send feedback via e-mail to core-libs-dev at openjdk.java.net > > > /Andy > From joe.darcy at oracle.com Sat Dec 15 18:22:42 2018 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 15 Dec 2018 10:22:42 -0800 Subject: JDK-8165199: UUID.fromString(str) compliance checking? In-Reply-To: References: Message-ID: <6941f27d-b84b-8a16-f67b-550d3a7c6f42@oracle.com> Hello, On 12/14/2018 2:00 PM, Andrew Leonard wrote: > Yes, this was my concern, source compatibility... > With the current implementation it is not too harmful to "sloppy" app > code. If it's not causing any other underlying "bug" then I would be > tempted to leave this "sleeping dog..." To use language precisely, the kind of compatibly at issue here is *behavioral* compatibility.? From the definitions used by in the CSR process: "For Java programs, there are three main categories of compatibility: ??? Source: Source compatibility concerns translating Java source code into class files. ??? Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link without error. ??? Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime." https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility Since the proposed change would only impact the implementation and not the method signatures, etc. it is a behavioral compatibility concern. Given the length of time the existing behavior has been present, I would be hesitant to change it now. HTH, -Joe From sverre.moe at gmail.com Sat Dec 15 19:48:40 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Sat, 15 Dec 2018 20:48:40 +0100 Subject: jpackage EA Build 0 In-Reply-To: <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> Message-ID: Den l?r. 15. des. 2018 kl. 18:44 skrev Andy Herrick : > > > On 12/15/2018 11:26 AM, Sverre Moe wrote: > > Some feedback from using this new JDK12 jpackage. > > I have yet to find out how to specify the bundle resources. It tells to put them on the class path, but that cannot be right, as jpackage is module. > Using default package resource [menu icon] (add package/movies.png to the class path to customize) > > I meant to get back to you on this. This is an incorrect warning message that needs to be fixed - I will file a bug. > > All resources for the app should be specified by combination of --input, --files, and --module-path Would be helpful to see some examples how to combine these to specify the package resources, as a part of the help output. Tried '--input', "${buildDir}/deploy/package", '--files', 'movies.png', '--module-path', "${buildDir}/deploy/package", > Why is --icon the only bundle argument that can be set on jpackage? > Using custom package resource [menu icon] (loaded from file /home/sverre/workspace/movies/src/main/deploy/package/linux/movies.png) > > not sure I understand this. The menu icon for package resource can be set by either --icon or the resource package/app.png. What I meant is there is no CLI argument for the other package resources like "Menu shortcut descriptor", "RPM spec file". Then why only have argument for icon. > The project I am trying this on is a fully modularized JavaFX application. > task createInstaller(type: Exec) { > dependsOn createRuntime > dependsOn installDist > > commandLine '/usr/java/jdk-12/bin/jpackage', 'create-installer', > '--verbose', > '--name', project.name, > '--description', project.description, > '--vendor', "Smeaworks Inc", > '--install-dir', "/opt/smeaworks", > '--category', "Some/Category/Application", > '--module-path', new File(installDist.outputs.files.singleFile, "lib"), > '--module', "${mainClassName}", > '--runtime-image', ""${buildDir}/runtime > '--output', "$buildDir/jfx/native" > } > > the latest build contains bug JDK-8213392, which prevents using --module-path and --runtime-image together (see https://bugs.openjdk.java.net/browse/JDK-8213962) I did not get any problems with using both --module-path and --runtime-image with jpackage. > but it would still be advisable to run jlink first from the original runtime image with the desired module path. to get a minimal runtime image for your app. I didn't quite understand what you meant with this. I did run jlink first to create a Java 11 runtime image which I used with jpackager. task createRuntime(type: Exec) { dependsOn installDist doFirst { delete "${buildDir}/runtime" } def libDir = new File(installDist.outputs.files.singleFile, "lib").path commandLine 'jlink', '--module-path', "/usr/java/jdk-11/jmods:${libDir}", '--add-modules', 'no.smeaworks.movies', '--output', "${buildDir}/runtime" } From ecki at zusammenkunft.net Sun Dec 16 02:30:02 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 16 Dec 2018 03:30:02 +0100 Subject: Throwable.addSuppressed again Message-ID: <5c15b8aa.1c69fb81.9dc1f.54d2@mx.google.com> Hello, a while back I reported a Problem with ?self Suppression? in the context of FilterOutputStream where a ?cached? exception thrown by flush() and close() resulted in a IllegalArgumentException: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026743.html This was fixed for the Filter streams: https://bugs.openjdk.java.net/browse/JDK-8042377 However the discussion if this is generally a bad behavior of Thread.addSuppressed had no conclusion. I just stumbled across another case where the IllegalArgumentException of Throwable.addSuppressed was a Problem: i had seen a case where an OutOfMemoryException in a try-with-resource created the same Problem. I cant reproduce the Situation clearly (it is related to Closing URLClassLoaders) but it looks like in some cases there is an native OOM exception instances are re-used. So if a OOM leads to cleanup of resources which trigger the exception again, it will happen. In this case it is rather unfortunate (if somebody expects to see and handle the OutOfMemoryException it wont be visible anymore since only the IllegalArgumentException is propagated) I do think (again) that Throwable.addSuppressed should throw the IAE ever, it is more robust to just silently skip the Operation. Alan, did you know if there have been any follow-up discussion? BTW: there is also a constructor switch to not record suppressed exceptions, this switch is however evaluated after the identity check is done. This might be worth re-arranging, then Errors and VM Exceptions could at least turn the recording off for themselves. (not sure who and why uses this constructor) https://hg.openjdk.java.net/jdk/jdk/file/dcbb71b9e7c0/src/java.base/share/classes/java/lang/Throwable.java#l1033 Gruss Bernd -- http://bernd.eckenfels.net From ecki at zusammenkunft.net Sun Dec 16 03:31:28 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 16 Dec 2018 04:31:28 +0100 Subject: Throwable.addSuppressed again In-Reply-To: <5c15b8aa.1c69fb81.9dc1f.54d2@mx.google.com> References: <5c15b8aa.1c69fb81.9dc1f.54d2@mx.google.com> Message-ID: <5c15c711.1c69fb81.2b5ca.f808@mx.google.com> Just an Addition: looks like the OOME uses already enableSuppression=true (in most? Cases) so a change to check enableSuppression before checking self-supression seems like an very effective change (if it is decided to Keep this Assertion at all). Gruss Bernd -- http://bernd.eckenfels.net From andy.herrick at oracle.com Sun Dec 16 13:27:31 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 16 Dec 2018 08:27:31 -0500 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> Message-ID: <6ca44e63-e922-3dbd-b7eb-1fd69c8b62ad@oracle.com> On 12/15/2018 2:48 PM, Sverre Moe wrote: > Den l?r. 15. des. 2018 kl. 18:44 skrev Andy Herrick : >> >> On 12/15/2018 11:26 AM, Sverre Moe wrote: >> >> Some feedback from using this new JDK12 jpackage. >> >> I have yet to find out how to specify the bundle resources. It tells to put them on the class path, but that cannot be right, as jpackage is module. >> Using default package resource [menu icon] (add package/movies.png to the class path to customize) >> >> I meant to get back to you on this. This is an incorrect warning message that needs to be fixed - I will file a bug. >> >> All resources for the app should be specified by combination of --input, --files, and --module-path > Would be helpful to see some examples how to combine these to specify > the package resources, as a part of the help output. > Tried > '--input', "${buildDir}/deploy/package", > '--files', 'movies.png', > '--module-path', "${buildDir}/deploy/package", > > >> Why is --icon the only bundle argument that can be set on jpackage? >> Using custom package resource [menu icon] (loaded from file /home/sverre/workspace/movies/src/main/deploy/package/linux/movies.png) >> >> not sure I understand this. > The menu icon for package resource can be set by either --icon or the > resource package/app.png. What I meant is there is no CLI argument for > the other package resources like "Menu shortcut descriptor", "RPM spec > file". Then why only have argument for icon. > >> The project I am trying this on is a fully modularized JavaFX application. >> task createInstaller(type: Exec) { >> dependsOn createRuntime >> dependsOn installDist >> >> commandLine '/usr/java/jdk-12/bin/jpackage', 'create-installer', >> '--verbose', >> '--name', project.name, >> '--description', project.description, >> '--vendor', "Smeaworks Inc", >> '--install-dir', "/opt/smeaworks", >> '--category', "Some/Category/Application", >> '--module-path', new File(installDist.outputs.files.singleFile, "lib"), >> '--module', "${mainClassName}", >> '--runtime-image', ""${buildDir}/runtime >> '--output', "$buildDir/jfx/native" >> } >> >> the latest build contains bug JDK-8213392, which prevents using --module-path and --runtime-image together (see https://bugs.openjdk.java.net/browse/JDK-8213962) > I did not get any problems with using both --module-path and > --runtime-image with jpackage. The result of JDK-8213392 was not that there was any problem creating the package, but that the packaged app would not run, because the modules from the --module-path arg are never included in the packaged app, or referenced in the vm args used when launching java. It is not clear to me what? - new File(installDist.outputs.files.singleFile, "lib") - actually is. Is this already in the runtime you created (if so you do you need this line ?) (if not , 8213392 will prevent it from being included in your app.) > >> but it would still be advisable to run jlink first from the original runtime image with the desired module path. to get a minimal runtime image for your app. > I didn't quite understand what you meant with this. > I did run jlink first to create a Java 11 runtime image which I used > with jpackager. > task createRuntime(type: Exec) { > dependsOn installDist > > doFirst { > delete "${buildDir}/runtime" > } > > def libDir = new File(installDist.outputs.files.singleFile, "lib").path > > commandLine 'jlink', > '--module-path', "/usr/java/jdk-11/jmods:${libDir}", > '--add-modules', 'no.smeaworks.movies', > '--output', "${buildDir}/runtime" > } which jlink are you running here? /usr/java/jdk-11/bin/jlink or /usr/java/jdk-12/bin/jlink ? in the first case you really are creating a Java 11 runtime with FX, in the second case you are creating a Java 12 runtime with FX from JDK-11 (assuming FX is what is in "/usr/java/jdk-11/jmods:${libDir}") /Andy From dl at cs.oswego.edu Sun Dec 16 14:23:55 2018 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 16 Dec 2018 09:23:55 -0500 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> Message-ID: <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> On 12/14/18 1:37 AM, Michal Vala wrote: > Thanks Martin for finding this serious issue and the testcase. > Sorry that I wasn't paying attention to this and so forced Martin to discover the hard way that because of LinkeHashMap, you can't skip doubling steps (at least not without a lot of rework). Also, the documentation should have mentioned this. A simpler way to reduce overhead in the case at hand is just to loop in putMapEntries: --- HashMap.java.~1.9.~ 2018-11-11 15:43:24.982878495 -0500 +++ HashMap.java 2018-12-16 09:05:48.924727867 -0500 @@ -502,8 +502,13 @@ if (t > threshold) threshold = tableSizeFor(t); } - else if (s > threshold) - resize(); + else { + // Because of LinkedHashMap constraints, we cannot + // expand all at once, but can reduce total resize + // effort by repeated doubling now vs later + while (table.length < MAXIMUM_CAPACITY && s > threshold) + resize(); + } for (Map.Entry e : m.entrySet()) { K key = e.getKey(); V value = e.getValue(); From sverre.moe at gmail.com Sun Dec 16 14:26:37 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Sun, 16 Dec 2018 15:26:37 +0100 Subject: jpackage EA Build 0 In-Reply-To: <6ca44e63-e922-3dbd-b7eb-1fd69c8b62ad@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> <6ca44e63-e922-3dbd-b7eb-1fd69c8b62ad@oracle.com> Message-ID: Den s?n. 16. des. 2018 kl. 14:27 skrev Andy Herrick : > > The result of JDK-8213392 was not that there was any problem creating > the package, but that the packaged app would not run, because the > modules from the --module-path arg are never included in the packaged > app, or referenced in the vm args used when launching java. I gathered that eventually. So I moved my --module-path from jpackage to jlink, thus packaging my application with the runtime image then used with jpackage. > It is not clear to me what - new > File(installDist.outputs.files.singleFile, "lib") - actually is. Is this > already in the runtime you created (if so you do you need this line ?) > (if not , 8213392 will prevent it from being included in your app.) The gradle task installDist assembles my application with all its dependencies under bulld/install/app/, and that File is just to avoid hard coding the path to its lib directory with all my JARs. I removed that --module-path when running jpackage and included it instead with jlink. > >> but it would still be advisable to run jlink first from the original runtime image with the desired module path. to get a minimal runtime image for your app. > > I didn't quite understand what you meant with this. > > I did run jlink first to create a Java 11 runtime image which I used > > with jpackager. > > task createRuntime(type: Exec) { > > dependsOn installDist > > > > doFirst { > > delete "${buildDir}/runtime" > > } > > > > def libDir = new File(installDist.outputs.files.singleFile, "lib").path > > > > commandLine 'jlink', > > '--module-path', "/usr/java/jdk-11/jmods:${libDir}", > > '--add-modules', 'no.smeaworks.movies', > > '--output', "${buildDir}/runtime" > > } > > which jlink are you running here /usr/java/jdk-11/bin/jlink or > /usr/java/jdk-12/bin/jlink ? > > in the first case you really are creating a Java 11 runtime with FX, in > the second case you are creating a Java 12 runtime with FX from JDK-11 > > (assuming FX is what is in "/usr/java/jdk-11/jmods:${libDir}") It is running jlink from JDK 11. The module path has the Java 11 jmods at /usr/java/jdk-11/jmods. My application and all its dependencies which includes the FX at ${libDir}. /Sverre From andy.herrick at oracle.com Sun Dec 16 18:31:34 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 16 Dec 2018 13:31:34 -0500 Subject: jpackage EA Build 0 In-Reply-To: <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> Message-ID: <9775097f-9642-990e-793d-48b8ed373b20@oracle.com> On 12/15/2018 12:44 PM, Andy Herrick wrote: >> >> I have yet to find out how to specify the bundle resources. It tells >> to put them on the class path, but that cannot be right, as jpackage >> is module. >> Using default package resource [menu icon] ?(add package/movies.png >> to the class path to customize) > > I meant to get back to you on this.? This is an incorrect warning > message that needs to be fixed - I will file a bug. > > The icon should be specified by the --icon option, has nothing to do > with a class-path.? This is a resource for the packager not the app. > > All resources for the app should be specified by combination of > --input, --files, and --module-path > While investigating this, I found undocumented functionality left over from JavaFXPackager that may be the root of these class-path messages. This is both dangerous and powerful, and will require some discussion before we either remove it or enhance and document it. The functionality is as follows: Some of the internal resources of jpackage (other than the Localized I18N properties files) may be over-ridden by files places in ./package// for windows this currently includes:? icon_inno_setup.bmp, javalogo_white_48.ico, template.iss, template.jre.iss, template.jre.wxs, template.wxs,? and WinLauncher.template . There is some name translation required, for example if I run the following command: jpackage create-installer exe \ --verbose --input input --output output/menu --name menu --icon config/awt.ico \ --win-menu --main-jar HiDPI.jar --class test.robot.RobotScreenTest --files HiDPI.jar? \ if file ./package/windows/menu.iss exists, ./package/windows/menu.iss will be used instead of src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/template.iss. also if ./package/windows/menu.ico exists, it will be used instead of config/awt.ico (or instead of javalogo_white_48.ico when no --icon is given). The bmp used in inno setup can be replaced either by adding package/windows/menu-setup-icon.bmp, or by modifying the appropriate line in ./package/windows/menu.iss a post install script can be run for the exe installer by adding: ./package/windows/menu-post-image.wsf (even though there is no such default resource). -------------- As I said we will need to discuss this internally, and we may choose to just remove it, but as pointed out above, there are other installer parameters (mostly included in the various templates) that a user may wish to customize, for which there are no CLI options. Although the current behavior of reading resources from "./package// is not really acceptable, adding a CLI option such as --resources-override might be possible. /Andy From sverre.moe at gmail.com Sun Dec 16 19:28:28 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Sun, 16 Dec 2018 20:28:28 +0100 Subject: jpackage EA Build 0 In-Reply-To: <9775097f-9642-990e-793d-48b8ed373b20@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> <9775097f-9642-990e-793d-48b8ed373b20@oracle.com> Message-ID: Den s?n. 16. des. 2018 kl. 19:32 skrev Andy Herrick : > > > On 12/15/2018 12:44 PM, Andy Herrick wrote: > While investigating this, I found undocumented functionality left over > from JavaFXPackager that may be the root of these class-path messages. > > This is both dangerous and powerful, and will require some discussion > before we either remove it or enhance and document it. > > The functionality is as follows: > > if file ./package/windows/menu.iss exists, ./package/windows/menu.iss > will be used instead of > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/template.iss. > > also if ./package/windows/menu.ico exists, it will be used instead of > config/awt.ico (or instead of javalogo_white_48.ico when no --icon is > given). > > The bmp used in inno setup can be replaced either by adding > package/windows/menu-setup-icon.bmp, or by modifying the appropriate > line in ./package/windows/menu.iss Yes, this is same as it was for javapackager, but having the package/ placed on project root is not ideal. It seem jpackage has changed the directory structure a little, now using just package instead of package/. > As I said we will need to discuss this internally, and we may choose to > just remove it, but as pointed out above, there are other installer > parameters (mostly included in the various templates) that a user may > wish to customize, for which there are no CLI options. I would not think removing these resource override to be a good idea. The default templates may not always suffice. An --app-release would be very useful, specially in addition to the --app-version. Release information in the version will work for DEB, but will fail for RPM since '-' is not allowed. > Although the current behavior of reading resources from > "./package// is not > really acceptable, adding a CLI option such as --resources-override > might be possible. I second an CLI option that would specify where these resources are. Currently we are preprocessing these resources to replace strings such as project name, version, etc. src/main/deploy/package/linux > build/deploy/package/linux /Sverre From david.holmes at oracle.com Mon Dec 17 00:57:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 10:57:34 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> Message-ID: Hi Magnus, Thanks for explaining how addition of JNIEXPORT may have started this problem. One follow up: >> This will also need a CSR request due to the change in linking behaviour. > I'm not sure what you mean by this..? My entire intention here is that we should make no changes to documented interfaces; this is strictly an internal change, so no CSR should be needed. Also, I don't understand what you mean by "linking behavior"? A CSR request is also required for behavioural changes - which this is. Someone linking an "internal only" function today may get an error if JNICALL is removed tomorrow. This may be acceptable but that is what the CSR request establishes. Thanks, David On 13/12/2018 8:37 pm, Magnus Ihse Bursie wrote: > On 2018-12-12 13:17, David Holmes wrote: >> Okay I went away and did some homework ... >> >> Let me back up a bit and see if I have the evolution of this correctly. >> >> The native implementation of Java methods should be declared and >> defined with JNIEXPORT and JNICALL. >> >> JNIEXPORT controls the export visibility so they can be linked. >> >> JNICALL controls the calling convention and is needed so that the >> JVM's calling convention matches the native code. [This part was >> unclear to me.] > Yes. And JNICALL is empty on all platforms except Windows 32, that's why > we're only seeing issues about mismatch there. >> >> Other native methods exported from the same (or different) native >> libraries may also be decorated with JNIEXPORT and JNICALL. But in >> places there is a mismatch between the declaration in the header and >> the definition leading to errors. > Yes; this mismatch has typically happened when the linking has not been > done by simply including the relevant header file, but either > duplicating the definition, or looking up the symbol dynamically. > Otherwise things should basically work out. >> >> There are two main types of such native functions: >> >> a) those publicly defined in the various native APIs: JNI itself >> (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... >> >> b) those intended only for use by other native code within the JDK >> libraries (JLI_* - though I note Alan's comment re javafxpackager, >> others??) >> >> and a possible third type are callback functions like the JPLISAgent >> event handlers (e.g. eventHandlerVMInit). > > I'm not sure I understand what the third type is, but if it is a > publically defined API (which, at a first look, the JPLISAgent API seems > to be), then it's part of catagory a, otherwise it's part of category b. > > I must also state that my initial proposal didn't separate these two > cases. I had in mind only the b cases -- I have no intention of changing > public specifications, but I did not express this in my proposal. That > might have been one source of confusion. I apologize for this omission. >> >> There is a view that no native method that isn't the native-half of a >> Java method should use JNICALL. [Okay I can see how that makes sense - >> regardless of the actual calling convention used marking such methods >> as "must use the same calling convention as the VM native method call" >> is somewhat meaningless. Yet obviously the public native APIs do >> specify JNICALL so this is not a hard and fast rule. Further the >> callbacks must also follow a convention known to the VM doing the >> calling!] > Yes, or rather the rule is "only native half Java methods should use > JNICALL, and also all public APIs where so is specified". > >> >> Where we have (introduced?) a discrepancy between the definition and >> declaration the approach has been (because of the previous view) to >> remove JNICALL. [This should only relate to methods of kind (b) above.] > Actually, it's not so much as we have *removed* JNICALL, as that we have > *introduced* JNIEXPORT. When I removed the map files, I also removed the > .def files and /export command lines for Windows. As a result, I needed > to add JNIEXPORT to a lot of places. Initially, I followed the rule of > adding JNICALL to those calls -- but I can surely have missed a couple > of places, since things will work fine anyway, as long as caller and > callee agree on the calling convention; and a mismatch can only happen > on Windows 32, which we do not build and test. So there is a risk that > even with the initial patch, not all newly added JNIEXPORTs had JNICALL. > > Then, it turned out, that a lot of this code did not compile with > Windows 32. With no deeper analysis of the flaw, the blame was put on > the absence or presence of JNICALL, and a series of patches were made > where JNICALL was more or less arbitrarily added or removed, until > things "worked". This should have been a warning sign, and I was > increasingly uneasy about all these changes, but I hadn't spent enough > time to realize what the core issue was or how to resolve it properly. > >> >> That leaves those methods with JNIEXPORT only. >> >> That seems wrong to you because they are not "JNI methods", so you >> want to replace with JDK_EXPORT to make it clear. [Ok - this seems >> reasonable.] > Yes. And given the fact that we have a bunch of "non-JNI methods" that > use the JNIEXPORT...JNICALL pattern, another way to interpret the > JDK_EXPORT semantics is that this function is exported for usage *in the > JDK*, but not for public consumption. >> >> If JNICALL is removed from those native methods and they are currently >> linked by external applications, those applications may stop working. >> But this only affects win32 (as its the only platform where JNICALL is >> different to the default C/C++ calling convention?) so your position >> is this is acceptable breakage - and would only affect >> unsupported/undocumented APIs. > Yes. In fact, it's possible that at least some of the breakage that > occurred was due to new *addition* of JNICALL, which was not present > before. We might have had something like (I'm making this specific > example up) a function "void ZIP_OpenFile(char* name)" with no > decoration at all, and a "/export:ZIP_OpenFile" on the command line, and > a ZIP_OpenFile entry in the unix map file. And I converted this to > "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto -- > although I didn't fully realize this at the time, changed the calling > convention and name decoration on Windows 32. When something broke, > perhaps because the user of ZIP_OpenFile did not include the proper > header file with the JNICALL modifier, the solution was to remove the > JNICALL part. > > And of all the bug reports I've seen on this, the issues has been > internal linking only, i.e. problems building the JDK, not complaints > that external tools tried to use internal interfaces and failed. So yes, > my position is if this should break things, tough shit. That, of > courses, requires that we do not change public APIs, so we need to be > careful not to mess with those. >> >> Does that sum it up? > Yep, I think so. >> >> We still need to be sure that we're only changing functions of type >> (b) above. > Yes, definitely. >> >> And I note that this has been driven by the choice to remove JNICALL >> where there was a discrepancy - that leads to the visibility of the >> two kinds of methods. If it had been chosen to add JNICALL where >> missing instead, then we may not have been having this conversation. > Actually, as I said, this has more been the result of a lot of added > JNICALL where previously there was none. > > An alternative course of action is the make sure that *all* calls use > the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix all > parts of code to actually accept the decorated names on Windows 32. This > will lead to a lot more code changes, like the fix for JDK-8214122 (JDWP > is broken on 32 bit Windows: transport library missing onLoad entry). > And all this special case handling will be needed only on Windows 32, > which is a platform we do not want to spend to much time or effort on. > And finally, I think doing so would make us miss out on an opportunity > to make the semantics clearer. >> >> This will also need a CSR request due to the change in linking behaviour. > I'm not sure what you mean by this..? My entire intention here is that > we should make no changes to documented interfaces; this is strictly an > internal change, so no CSR should be needed. Also, I don't understand > what you mean by "linking behavior"? > > /Magnus >> >> Cheers, >> David >> ----- >> >> On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 23:47, David Holmes wrote: >>>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-11 00:23, David Holmes wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>>> I propose that we introduce a new define, available to all JDK >>>>>>> native files (Hotspot included), called JDK_EXPORT. The behavior >>>>>>> of this symbol will be very similar (as of now, in fact >>>>>>> identical) to JNIEXPORT; however, the semantics will not. >>>>>>> >>>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>>> for exporting from the library. The problem with this is that >>>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>>> used when C programs interact with Java. And, when doing this, >>>>>>> the function should be fully decorated like this: "JNIEXPORT foo >>>>>>> JNICALL". >>>>>> >>>>>> I've seen a lot of the emails on this issue and I don't fully >>>>>> understand what has been going wrong. But the intent is obviously >>>>>> the JNIEXPORT represents what is needed to export this function >>>>>> for use by JNI, while JNICALL defines the calling convention. I >>>>>> agree there may be some mistmatch when functions are actually not >>>>>> intended for general export outside the JDK but are only for >>>>>> internal JDK use. >>>>>> >>>>>>> We do have many such JNI exports in our native libraries, but we >>>>>>> also have a lot of other, non-JNI exports, where one native >>>>>>> library just provides an interface to other libraries. In these >>>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>>> getting the function exported, but we have not been consistent in >>>>>>> our use of JNICALL. This has caused us way too much trouble for >>>>>>> something that should Just Work. >>>>>> >>>>>> Are you suggesting that the interface between different libraries >>>>>> in the JDK should not be a JNI interface? Is this because you >>>>>> think the functions in these libraries are only for JDK internal >>>>>> use or ... ?? >>>>>> >>>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>>> external visibility in the resulting native library), but which >>>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>>> supposed to be decorated with >>>>>> >>>>>> Just a clarification there. JNI functions are not exported to Java >>>>>> code, they are exported to native code. Java code can declare >>>>>> native methods and those native methods must be written as JNI >>>>>> functions, but that's not what we are discussing. Libraries expose >>>>>> a JNI interface (a set of functions in the library) that can be >>>>>> called by application native code, using JNI. >>>>> We're apparently looking at "JNI" and "exporting" from two opposite >>>>> sides here. :-) Just to make everything clear: If I have a Java class >>>>> class MyClass { >>>>> ?? public static void native myNativeFunc(); >>>>> } >>>>> >>>>> then I have one half of the JNI function, the Java half. This must >>>>> be matched by a corresponding implementation in native, like this: >>>>> JNIEXPORT void JNICALL >>>>> Java_MyClass_myNativeFunc(void) { >>>>> // ... do stuff >>>>> } >>>>> >>>>> And this is the native half of the JNI function. Right? Let's leave >>>>> aside which side is "exporting" to the other for now. :-) >>>>> >>>>> This way of setting up native functions that can be called from >>>>> Java is what I refer to as JNI. And when you declare a native JNI >>>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>>> >>>>> We do have a lot of those functions in our native libraries. And >>>>> they are correct just the way they are. >>>> >>>> Yep all well and good. A function declared native in Java must have >>>> an implementation as you describe. But not all native functions >>>> exist to provide the native-half of a Java native function! >>>> >>>>> However, we also have *other* native functions, that are exported, >>>>> not as JNI functions that should be called from Java, but as normal >>>>> native library functions that should be called by other native >>>>> code. Okay so far? And *those* functions have been problematic in >>>>> how we decorate >>>> >>>> But there are again two cases. Those functions exported from a >>>> library that are expected to be called from external code using the >>>> JNI interface mechanism - such as all the JNI functions and JVM TI >>>> functions we export from the JVM - and those "exported" for access >>>> between libraries within the JDK (such as all the JVM_* functions in >>>> libjvm). >>>> >>>> I think it is only the second group that should be addressed by your >>>> JDK_EXPORT proposal - though I'm not completely clear exactly how to >>>> identify them. >>> Alright, now I think we're on the same page again. :) >>> >>> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >>> >>> You identify external APIs by the fact that they are documented. And >>> if you are unsure, you ask Jon. ;-) >>> >>>> >>>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>>> those functions, and instead use JDK_EXPORT as name for the macro >>>>> that decorates them as exported. That way, we can clearly see that >>>>> a function like this: >>>>> >>>>> JDK_EXPORT void >>>>> JLI_ReadEnv(char* env); >>>>> >>>>> is correctly declared, and will be exported to other native >>>>> libraries, but not to Java. >>>> >>>> The issue is not whether it is "exported to Java"** but whether it >>>> is exported using the JNI mechanism such that other native code >>>> calls it using the JNI mechanism. >>>> >>>> ** There is no way to write a native method declaration in Java such >>>> that it would be linked to the JLI_ReadEnv function. The naming is >>>> all wrong, as is the signature. >>>> >>>>> Just to clarify, this has nothing to do with if this is a >>>>> officially supported API or not. In general though, I assume that >>>>> most (if not all?) of our exported functions (apart from the JNI_* >>>>> stuff) is supposed to be consumed by other libraries in the JDK, >>>>> and is not a public API. >>>> >>>> I think it varies library by library. You may need native >>>> application code that can call directly into native JDK libraries. >>>> JLI is the Java Launcher Interface - I think it was introduced to >>>> make it easier for other launchers to be created. Native agents may >>>> need access to libmanagement or libjdwp functions. Native graphics >>>> code may need access to the JDK graphics library. Some of these >>>> accesses may be unsupported and undocumented, but I don't think you >>>> can just cut them all off. >>> If they are unsupported and undocumented, I sure as h*ll can cut them >>> all off! :-) >>> >>> Besides, and let me re-iterate this, the only change that will happen >>> by removing JNICALL, is on Windows 32. No other platform will be >>> affected. There is no official support for Windows 32 anymore. >>> There's some low-effort community work done on keeping Windows 32 >>> alive, but it's not backed by any major player. Right now, they are >>> taking a lot of hits *due to the fact* that we have not sorted this >>> out, and waste a lot of their precious effort trying to fix this >>> piecemeal. If we do fix things according to this proposal, then it's >>> at least clear how things *should* work. If it turns out that there's >>> some code out there in the wild, running on Windows 32, that uses an >>> undocumented and unsupported function call, and it breaks -- well, >>> sucks to be them. They'll just have to do what everyone does who uses >>> an undocumented interface that suddenly changes: update their code. >>> >>> /Magnus >>> >>>> >>>> David >>>> >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>> >>>>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>>>> native functions should be changed to use JDK_EXPORT instead. >>>>>>> >>>>>>> I further propose that this macro should reside in a new file >>>>>>> "jdk.h", placed in the new directory >>>>>>> src/java.base/share/native/include/internal. This header file >>>>>>> path will automatically be provided to all native libraries, but >>>>>>> not copied to the JDK being built. (The existence of a >>>>>>> "include/internal" directory with this behavior has been >>>>>>> discussed before. There are more files that ought to be moved >>>>>>> there, if/when it is created.) I believe in many cases the >>>>>>> #include "jni.h" can be just modified to #include "#jdk.h", since >>>>>>> most native code will not require "jni.h" unless actually doing >>>>>>> JNI calls -- most have included this file to get the JNIEXPORT >>>>>>> macro, which would explain the pervasive use of #include "jni.h" >>>>>>> in our code base. >>>>>> >>>>>> jni.h also defines all of the types used by the JNI. Those types >>>>>> are pervsive to the native code used throughout the JDK. >>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> I think we need to understand the problems on Windows that >>>>>> prompted all this. Then I think we need to look at exactly how >>>>>> jni.h and JNIEXPORT etc are being used and understand whether this >>>>>> is truly an exported interface or not. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> /Magnus >>>>>>> >>>>> >>> > From dean.long at oracle.com Mon Dec 17 02:51:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 18:51:48 -0800 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> Message-ID: If we are adding JDK_EXPORT, does it make sense to add JDK_CALL as well? dl On 12/16/18 4:57 PM, David Holmes wrote: > Hi Magnus, > > Thanks for explaining how addition of JNIEXPORT may have started this > problem. > > One follow up: > >>> This will also need a CSR request due to the change in linking >>> behaviour. >> I'm not sure what you mean by this..? My entire intention here is >> that we should make no changes to documented interfaces; this is >> strictly an internal change, so no CSR should be needed. Also, I >> don't understand what you mean by "linking behavior"? > > A CSR request is also required for behavioural changes - which this > is. Someone linking an "internal only" function today may get an error > if JNICALL is removed tomorrow. This may be acceptable but that is > what the CSR request establishes. > > Thanks, > David > > > On 13/12/2018 8:37 pm, Magnus Ihse Bursie wrote: >> On 2018-12-12 13:17, David Holmes wrote: >>> Okay I went away and did some homework ... >>> >>> Let me back up a bit and see if I have the evolution of this correctly. >>> >>> The native implementation of Java methods should be declared and >>> defined with JNIEXPORT and JNICALL. >>> >>> JNIEXPORT controls the export visibility so they can be linked. >>> >>> JNICALL controls the calling convention and is needed so that the >>> JVM's calling convention matches the native code. [This part was >>> unclear to me.] >> Yes. And JNICALL is empty on all platforms except Windows 32, that's >> why we're only seeing issues about mismatch there. >>> >>> Other native methods exported from the same (or different) native >>> libraries may also be decorated with JNIEXPORT and JNICALL. But in >>> places there is a mismatch between the declaration in the header and >>> the definition leading to errors. >> Yes; this mismatch has typically happened when the linking has not >> been done by simply including the relevant header file, but either >> duplicating the definition, or looking up the symbol dynamically. >> Otherwise things should basically work out. >>> >>> There are two main types of such native functions: >>> >>> a) those publicly defined in the various native APIs: JNI itself >>> (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... >>> >>> b) those intended only for use by other native code within the JDK >>> libraries (JLI_* - though I note Alan's comment re javafxpackager, >>> others??) >>> >>> and a possible third type are callback functions like the JPLISAgent >>> event handlers (e.g. eventHandlerVMInit). >> >> I'm not sure I understand what the third type is, but if it is a >> publically defined API (which, at a first look, the JPLISAgent API >> seems to be), then it's part of catagory a, otherwise it's part of >> category b. >> >> I must also state that my initial proposal didn't separate these two >> cases. I had in mind only the b cases -- I have no intention of >> changing public specifications, but I did not express this in my >> proposal. That might have been one source of confusion. I apologize >> for this omission. >>> >>> There is a view that no native method that isn't the native-half of >>> a Java method should use JNICALL. [Okay I can see how that makes >>> sense - regardless of the actual calling convention used marking >>> such methods as "must use the same calling convention as the VM >>> native method call" is somewhat meaningless. Yet obviously the >>> public native APIs do specify JNICALL so this is not a hard and fast >>> rule. Further the callbacks must also follow a convention known to >>> the VM doing the calling!] >> Yes, or rather the rule is "only native half Java methods should use >> JNICALL, and also all public APIs where so is specified". >> >>> >>> Where we have (introduced?) a discrepancy between the definition and >>> declaration the approach has been (because of the previous view) to >>> remove JNICALL. [This should only relate to methods of kind (b) above.] >> Actually, it's not so much as we have *removed* JNICALL, as that we >> have *introduced* JNIEXPORT. When I removed the map files, I also >> removed the .def files and /export command lines for Windows. As a >> result, I needed to add JNIEXPORT to a lot of places. Initially, I >> followed the rule of adding JNICALL to those calls -- but I can >> surely have missed a couple of places, since things will work fine >> anyway, as long as caller and callee agree on the calling convention; >> and a mismatch can only happen on Windows 32, which we do not build >> and test. So there is a risk that even with the initial patch, not >> all newly added JNIEXPORTs had JNICALL. >> >> Then, it turned out, that a lot of this code did not compile with >> Windows 32. With no deeper analysis of the flaw, the blame was put on >> the absence or presence of JNICALL, and a series of patches were made >> where JNICALL was more or less arbitrarily added or removed, until >> things "worked". This should have been a warning sign, and I was >> increasingly uneasy about all these changes, but I hadn't spent >> enough time to realize what the core issue was or how to resolve it >> properly. >> >>> >>> That leaves those methods with JNIEXPORT only. >>> >>> That seems wrong to you because they are not "JNI methods", so you >>> want to replace with JDK_EXPORT to make it clear. [Ok - this seems >>> reasonable.] >> Yes. And given the fact that we have a bunch of "non-JNI methods" >> that use the JNIEXPORT...JNICALL pattern, another way to interpret >> the JDK_EXPORT semantics is that this function is exported for usage >> *in the JDK*, but not for public consumption. >>> >>> If JNICALL is removed from those native methods and they are >>> currently linked by external applications, those applications may >>> stop working. But this only affects win32 (as its the only platform >>> where JNICALL is different to the default C/C++ calling convention?) >>> so your position is this is acceptable breakage - and would only >>> affect unsupported/undocumented APIs. >> Yes. In fact, it's possible that at least some of the breakage that >> occurred was due to new *addition* of JNICALL, which was not present >> before. We might have had something like (I'm making this specific >> example up) a function "void ZIP_OpenFile(char* name)" with no >> decoration at all, and a "/export:ZIP_OpenFile" on the command line, >> and a ZIP_OpenFile entry in the unix map file. And I converted this >> to "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto >> -- although I didn't fully realize this at the time, changed the >> calling convention and name decoration on Windows 32. When something >> broke, perhaps because the user of ZIP_OpenFile did not include the >> proper header file with the JNICALL modifier, the solution was to >> remove the JNICALL part. >> >> And of all the bug reports I've seen on this, the issues has been >> internal linking only, i.e. problems building the JDK, not complaints >> that external tools tried to use internal interfaces and failed. So >> yes, my position is if this should break things, tough shit. That, of >> courses, requires that we do not change public APIs, so we need to be >> careful not to mess with those. >>> >>> Does that sum it up? >> Yep, I think so. >>> >>> We still need to be sure that we're only changing functions of type >>> (b) above. >> Yes, definitely. >>> >>> And I note that this has been driven by the choice to remove JNICALL >>> where there was a discrepancy - that leads to the visibility of the >>> two kinds of methods. If it had been chosen to add JNICALL where >>> missing instead, then we may not have been having this conversation. >> Actually, as I said, this has more been the result of a lot of added >> JNICALL where previously there was none. >> >> An alternative course of action is the make sure that *all* calls use >> the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix >> all parts of code to actually accept the decorated names on Windows >> 32. This will lead to a lot more code changes, like the fix for >> JDK-8214122 (JDWP is broken on 32 bit Windows: transport library >> missing onLoad entry). And all this special case handling will be >> needed only on Windows 32, which is a platform we do not want to >> spend to much time or effort on. And finally, I think doing so would >> make us miss out on an opportunity to make the semantics clearer. >>> >>> This will also need a CSR request due to the change in linking >>> behaviour. >> I'm not sure what you mean by this..? My entire intention here is >> that we should make no changes to documented interfaces; this is >> strictly an internal change, so no CSR should be needed. Also, I >> don't understand what you mean by "linking behavior"? >> >> /Magnus >>> >>> Cheers, >>> David >>> ----- >>> >>> On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 23:47, David Holmes wrote: >>>>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>> On 2018-12-11 00:23, David Holmes wrote: >>>>>>> Hi Magnus, >>>>>>> >>>>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>>>> I propose that we introduce a new define, available to all JDK >>>>>>>> native files (Hotspot included), called JDK_EXPORT. The >>>>>>>> behavior of this symbol will be very similar (as of now, in >>>>>>>> fact identical) to JNIEXPORT; however, the semantics will not. >>>>>>>> >>>>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>>>> for exporting from the library. The problem with this is that >>>>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>>>> used when C programs interact with Java. And, when doing this, >>>>>>>> the function should be fully decorated like this: "JNIEXPORT >>>>>>>> foo JNICALL". >>>>>>> >>>>>>> I've seen a lot of the emails on this issue and I don't fully >>>>>>> understand what has been going wrong. But the intent is >>>>>>> obviously the JNIEXPORT represents what is needed to export this >>>>>>> function for use by JNI, while JNICALL defines the calling >>>>>>> convention. I agree there may be some mistmatch when functions >>>>>>> are actually not intended for general export outside the JDK but >>>>>>> are only for internal JDK use. >>>>>>> >>>>>>>> We do have many such JNI exports in our native libraries, but >>>>>>>> we also have a lot of other, non-JNI exports, where one native >>>>>>>> library just provides an interface to other libraries. In these >>>>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>>>> getting the function exported, but we have not been consistent >>>>>>>> in our use of JNICALL. This has caused us way too much trouble >>>>>>>> for something that should Just Work. >>>>>>> >>>>>>> Are you suggesting that the interface between different >>>>>>> libraries in the JDK should not be a JNI interface? Is this >>>>>>> because you think the functions in these libraries are only for >>>>>>> JDK internal use or ... ?? >>>>>>> >>>>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>>>> external visibility in the resulting native library), but which >>>>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>>>> supposed to be decorated with >>>>>>> >>>>>>> Just a clarification there. JNI functions are not exported to >>>>>>> Java code, they are exported to native code. Java code can >>>>>>> declare native methods and those native methods must be written >>>>>>> as JNI functions, but that's not what we are discussing. >>>>>>> Libraries expose a JNI interface (a set of functions in the >>>>>>> library) that can be called by application native code, using JNI. >>>>>> We're apparently looking at "JNI" and "exporting" from two >>>>>> opposite sides here. :-) Just to make everything clear: If I have >>>>>> a Java class >>>>>> class MyClass { >>>>>> ?? public static void native myNativeFunc(); >>>>>> } >>>>>> >>>>>> then I have one half of the JNI function, the Java half. This >>>>>> must be matched by a corresponding implementation in native, like >>>>>> this: >>>>>> JNIEXPORT void JNICALL >>>>>> Java_MyClass_myNativeFunc(void) { >>>>>> // ... do stuff >>>>>> } >>>>>> >>>>>> And this is the native half of the JNI function. Right? Let's >>>>>> leave aside which side is "exporting" to the other for now. :-) >>>>>> >>>>>> This way of setting up native functions that can be called from >>>>>> Java is what I refer to as JNI. And when you declare a native JNI >>>>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>>>> >>>>>> We do have a lot of those functions in our native libraries. And >>>>>> they are correct just the way they are. >>>>> >>>>> Yep all well and good. A function declared native in Java must >>>>> have an implementation as you describe. But not all native >>>>> functions exist to provide the native-half of a Java native function! >>>>> >>>>>> However, we also have *other* native functions, that are >>>>>> exported, not as JNI functions that should be called from Java, >>>>>> but as normal native library functions that should be called by >>>>>> other native code. Okay so far? And *those* functions have been >>>>>> problematic in how we decorate >>>>> >>>>> But there are again two cases. Those functions exported from a >>>>> library that are expected to be called from external code using >>>>> the JNI interface mechanism - such as all the JNI functions and >>>>> JVM TI functions we export from the JVM - and those "exported" for >>>>> access between libraries within the JDK (such as all the JVM_* >>>>> functions in libjvm). >>>>> >>>>> I think it is only the second group that should be addressed by >>>>> your JDK_EXPORT proposal - though I'm not completely clear exactly >>>>> how to identify them. >>>> Alright, now I think we're on the same page again. :) >>>> >>>> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >>>> >>>> You identify external APIs by the fact that they are documented. >>>> And if you are unsure, you ask Jon. ;-) >>>> >>>>> >>>>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>>>> those functions, and instead use JDK_EXPORT as name for the macro >>>>>> that decorates them as exported. That way, we can clearly see >>>>>> that a function like this: >>>>>> >>>>>> JDK_EXPORT void >>>>>> JLI_ReadEnv(char* env); >>>>>> >>>>>> is correctly declared, and will be exported to other native >>>>>> libraries, but not to Java. >>>>> >>>>> The issue is not whether it is "exported to Java"** but whether it >>>>> is exported using the JNI mechanism such that other native code >>>>> calls it using the JNI mechanism. >>>>> >>>>> ** There is no way to write a native method declaration in Java >>>>> such that it would be linked to the JLI_ReadEnv function. The >>>>> naming is all wrong, as is the signature. >>>>> >>>>>> Just to clarify, this has nothing to do with if this is a >>>>>> officially supported API or not. In general though, I assume that >>>>>> most (if not all?) of our exported functions (apart from the >>>>>> JNI_* stuff) is supposed to be consumed by other libraries in the >>>>>> JDK, and is not a public API. >>>>> >>>>> I think it varies library by library. You may need native >>>>> application code that can call directly into native JDK libraries. >>>>> JLI is the Java Launcher Interface - I think it was introduced to >>>>> make it easier for other launchers to be created. Native agents >>>>> may need access to libmanagement or libjdwp functions. Native >>>>> graphics code may need access to the JDK graphics library. Some of >>>>> these accesses may be unsupported and undocumented, but I don't >>>>> think you can just cut them all off. >>>> If they are unsupported and undocumented, I sure as h*ll can cut >>>> them all off! :-) >>>> >>>> Besides, and let me re-iterate this, the only change that will >>>> happen by removing JNICALL, is on Windows 32. No other platform >>>> will be affected. There is no official support for Windows 32 >>>> anymore. There's some low-effort community work done on keeping >>>> Windows 32 alive, but it's not backed by any major player. Right >>>> now, they are taking a lot of hits *due to the fact* that we have >>>> not sorted this out, and waste a lot of their precious effort >>>> trying to fix this piecemeal. If we do fix things according to this >>>> proposal, then it's at least clear how things *should* work. If it >>>> turns out that there's some code out there in the wild, running on >>>> Windows 32, that uses an undocumented and unsupported function >>>> call, and it breaks -- well, sucks to be them. They'll just have to >>>> do what everyone does who uses an undocumented interface that >>>> suddenly changes: update their code. >>>> >>>> /Magnus >>>> >>>>> >>>>> David >>>>> >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> JNICALL. All current instances of JNIEXPORT which is not pure >>>>>>>> JNI native functions should be changed to use JDK_EXPORT instead. >>>>>>>> >>>>>>>> I further propose that this macro should reside in a new file >>>>>>>> "jdk.h", placed in the new directory >>>>>>>> src/java.base/share/native/include/internal. This header file >>>>>>>> path will automatically be provided to all native libraries, >>>>>>>> but not copied to the JDK being built. (The existence of a >>>>>>>> "include/internal" directory with this behavior has been >>>>>>>> discussed before. There are more files that ought to be moved >>>>>>>> there, if/when it is created.) I believe in many cases the >>>>>>>> #include "jni.h" can be just modified to #include "#jdk.h", >>>>>>>> since most native code will not require "jni.h" unless actually >>>>>>>> doing JNI calls -- most have included this file to get the >>>>>>>> JNIEXPORT macro, which would explain the pervasive use of >>>>>>>> #include "jni.h" in our code base. >>>>>>> >>>>>>> jni.h also defines all of the types used by the JNI. Those types >>>>>>> are pervsive to the native code used throughout the JDK. >>>>>>> >>>>>>>> Thoughts? >>>>>>> >>>>>>> I think we need to understand the problems on Windows that >>>>>>> prompted all this. Then I think we need to look at exactly how >>>>>>> jni.h and JNIEXPORT etc are being used and understand whether >>>>>>> this is truly an exported interface or not. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Mon Dec 17 03:07:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 13:07:48 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> Message-ID: <3d7cd0eb-9694-840f-1e1e-4abc71877461@oracle.com> On 17/12/2018 12:51 pm, dean.long at oracle.com wrote: > If we are adding JDK_EXPORT, does it make sense to add JDK_CALL as well? It should never be necessary. JNICALL is only needed to ensure caller and callee use the same calling convention. For JDK_EXPORT the caller and callee are part of the same thing - the JDK - and will always use the same (platform default) calling convention. David > dl > > On 12/16/18 4:57 PM, David Holmes wrote: >> Hi Magnus, >> >> Thanks for explaining how addition of JNIEXPORT may have started this >> problem. >> >> One follow up: >> >>>> This will also need a CSR request due to the change in linking >>>> behaviour. >>> I'm not sure what you mean by this..? My entire intention here is >>> that we should make no changes to documented interfaces; this is >>> strictly an internal change, so no CSR should be needed. Also, I >>> don't understand what you mean by "linking behavior"? >> >> A CSR request is also required for behavioural changes - which this >> is. Someone linking an "internal only" function today may get an error >> if JNICALL is removed tomorrow. This may be acceptable but that is >> what the CSR request establishes. >> >> Thanks, >> David >> >> >> On 13/12/2018 8:37 pm, Magnus Ihse Bursie wrote: >>> On 2018-12-12 13:17, David Holmes wrote: >>>> Okay I went away and did some homework ... >>>> >>>> Let me back up a bit and see if I have the evolution of this correctly. >>>> >>>> The native implementation of Java methods should be declared and >>>> defined with JNIEXPORT and JNICALL. >>>> >>>> JNIEXPORT controls the export visibility so they can be linked. >>>> >>>> JNICALL controls the calling convention and is needed so that the >>>> JVM's calling convention matches the native code. [This part was >>>> unclear to me.] >>> Yes. And JNICALL is empty on all platforms except Windows 32, that's >>> why we're only seeing issues about mismatch there. >>>> >>>> Other native methods exported from the same (or different) native >>>> libraries may also be decorated with JNIEXPORT and JNICALL. But in >>>> places there is a mismatch between the declaration in the header and >>>> the definition leading to errors. >>> Yes; this mismatch has typically happened when the linking has not >>> been done by simply including the relevant header file, but either >>> duplicating the definition, or looking up the symbol dynamically. >>> Otherwise things should basically work out. >>>> >>>> There are two main types of such native functions: >>>> >>>> a) those publicly defined in the various native APIs: JNI itself >>>> (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... >>>> >>>> b) those intended only for use by other native code within the JDK >>>> libraries (JLI_* - though I note Alan's comment re javafxpackager, >>>> others??) >>>> >>>> and a possible third type are callback functions like the JPLISAgent >>>> event handlers (e.g. eventHandlerVMInit). >>> >>> I'm not sure I understand what the third type is, but if it is a >>> publically defined API (which, at a first look, the JPLISAgent API >>> seems to be), then it's part of catagory a, otherwise it's part of >>> category b. >>> >>> I must also state that my initial proposal didn't separate these two >>> cases. I had in mind only the b cases -- I have no intention of >>> changing public specifications, but I did not express this in my >>> proposal. That might have been one source of confusion. I apologize >>> for this omission. >>>> >>>> There is a view that no native method that isn't the native-half of >>>> a Java method should use JNICALL. [Okay I can see how that makes >>>> sense - regardless of the actual calling convention used marking >>>> such methods as "must use the same calling convention as the VM >>>> native method call" is somewhat meaningless. Yet obviously the >>>> public native APIs do specify JNICALL so this is not a hard and fast >>>> rule. Further the callbacks must also follow a convention known to >>>> the VM doing the calling!] >>> Yes, or rather the rule is "only native half Java methods should use >>> JNICALL, and also all public APIs where so is specified". >>> >>>> >>>> Where we have (introduced?) a discrepancy between the definition and >>>> declaration the approach has been (because of the previous view) to >>>> remove JNICALL. [This should only relate to methods of kind (b) above.] >>> Actually, it's not so much as we have *removed* JNICALL, as that we >>> have *introduced* JNIEXPORT. When I removed the map files, I also >>> removed the .def files and /export command lines for Windows. As a >>> result, I needed to add JNIEXPORT to a lot of places. Initially, I >>> followed the rule of adding JNICALL to those calls -- but I can >>> surely have missed a couple of places, since things will work fine >>> anyway, as long as caller and callee agree on the calling convention; >>> and a mismatch can only happen on Windows 32, which we do not build >>> and test. So there is a risk that even with the initial patch, not >>> all newly added JNIEXPORTs had JNICALL. >>> >>> Then, it turned out, that a lot of this code did not compile with >>> Windows 32. With no deeper analysis of the flaw, the blame was put on >>> the absence or presence of JNICALL, and a series of patches were made >>> where JNICALL was more or less arbitrarily added or removed, until >>> things "worked". This should have been a warning sign, and I was >>> increasingly uneasy about all these changes, but I hadn't spent >>> enough time to realize what the core issue was or how to resolve it >>> properly. >>> >>>> >>>> That leaves those methods with JNIEXPORT only. >>>> >>>> That seems wrong to you because they are not "JNI methods", so you >>>> want to replace with JDK_EXPORT to make it clear. [Ok - this seems >>>> reasonable.] >>> Yes. And given the fact that we have a bunch of "non-JNI methods" >>> that use the JNIEXPORT...JNICALL pattern, another way to interpret >>> the JDK_EXPORT semantics is that this function is exported for usage >>> *in the JDK*, but not for public consumption. >>>> >>>> If JNICALL is removed from those native methods and they are >>>> currently linked by external applications, those applications may >>>> stop working. But this only affects win32 (as its the only platform >>>> where JNICALL is different to the default C/C++ calling convention?) >>>> so your position is this is acceptable breakage - and would only >>>> affect unsupported/undocumented APIs. >>> Yes. In fact, it's possible that at least some of the breakage that >>> occurred was due to new *addition* of JNICALL, which was not present >>> before. We might have had something like (I'm making this specific >>> example up) a function "void ZIP_OpenFile(char* name)" with no >>> decoration at all, and a "/export:ZIP_OpenFile" on the command line, >>> and a ZIP_OpenFile entry in the unix map file. And I converted this >>> to "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto >>> -- although I didn't fully realize this at the time, changed the >>> calling convention and name decoration on Windows 32. When something >>> broke, perhaps because the user of ZIP_OpenFile did not include the >>> proper header file with the JNICALL modifier, the solution was to >>> remove the JNICALL part. >>> >>> And of all the bug reports I've seen on this, the issues has been >>> internal linking only, i.e. problems building the JDK, not complaints >>> that external tools tried to use internal interfaces and failed. So >>> yes, my position is if this should break things, tough shit. That, of >>> courses, requires that we do not change public APIs, so we need to be >>> careful not to mess with those. >>>> >>>> Does that sum it up? >>> Yep, I think so. >>>> >>>> We still need to be sure that we're only changing functions of type >>>> (b) above. >>> Yes, definitely. >>>> >>>> And I note that this has been driven by the choice to remove JNICALL >>>> where there was a discrepancy - that leads to the visibility of the >>>> two kinds of methods. If it had been chosen to add JNICALL where >>>> missing instead, then we may not have been having this conversation. >>> Actually, as I said, this has more been the result of a lot of added >>> JNICALL where previously there was none. >>> >>> An alternative course of action is the make sure that *all* calls use >>> the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix >>> all parts of code to actually accept the decorated names on Windows >>> 32. This will lead to a lot more code changes, like the fix for >>> JDK-8214122 (JDWP is broken on 32 bit Windows: transport library >>> missing onLoad entry). And all this special case handling will be >>> needed only on Windows 32, which is a platform we do not want to >>> spend to much time or effort on. And finally, I think doing so would >>> make us miss out on an opportunity to make the semantics clearer. >>>> >>>> This will also need a CSR request due to the change in linking >>>> behaviour. >>> I'm not sure what you mean by this..? My entire intention here is >>> that we should make no changes to documented interfaces; this is >>> strictly an internal change, so no CSR should be needed. Also, I >>> don't understand what you mean by "linking behavior"? >>> >>> /Magnus >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>> On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-11 23:47, David Holmes wrote: >>>>>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>> On 2018-12-11 00:23, David Holmes wrote: >>>>>>>> Hi Magnus, >>>>>>>> >>>>>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>>>>> I propose that we introduce a new define, available to all JDK >>>>>>>>> native files (Hotspot included), called JDK_EXPORT. The >>>>>>>>> behavior of this symbol will be very similar (as of now, in >>>>>>>>> fact identical) to JNIEXPORT; however, the semantics will not. >>>>>>>>> >>>>>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>>>>> for exporting from the library. The problem with this is that >>>>>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>>>>> used when C programs interact with Java. And, when doing this, >>>>>>>>> the function should be fully decorated like this: "JNIEXPORT >>>>>>>>> foo JNICALL". >>>>>>>> >>>>>>>> I've seen a lot of the emails on this issue and I don't fully >>>>>>>> understand what has been going wrong. But the intent is >>>>>>>> obviously the JNIEXPORT represents what is needed to export this >>>>>>>> function for use by JNI, while JNICALL defines the calling >>>>>>>> convention. I agree there may be some mistmatch when functions >>>>>>>> are actually not intended for general export outside the JDK but >>>>>>>> are only for internal JDK use. >>>>>>>> >>>>>>>>> We do have many such JNI exports in our native libraries, but >>>>>>>>> we also have a lot of other, non-JNI exports, where one native >>>>>>>>> library just provides an interface to other libraries. In these >>>>>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>>>>> getting the function exported, but we have not been consistent >>>>>>>>> in our use of JNICALL. This has caused us way too much trouble >>>>>>>>> for something that should Just Work. >>>>>>>> >>>>>>>> Are you suggesting that the interface between different >>>>>>>> libraries in the JDK should not be a JNI interface? Is this >>>>>>>> because you think the functions in these libraries are only for >>>>>>>> JDK internal use or ... ?? >>>>>>>> >>>>>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>>>>> external visibility in the resulting native library), but which >>>>>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>>>>> supposed to be decorated with >>>>>>>> >>>>>>>> Just a clarification there. JNI functions are not exported to >>>>>>>> Java code, they are exported to native code. Java code can >>>>>>>> declare native methods and those native methods must be written >>>>>>>> as JNI functions, but that's not what we are discussing. >>>>>>>> Libraries expose a JNI interface (a set of functions in the >>>>>>>> library) that can be called by application native code, using JNI. >>>>>>> We're apparently looking at "JNI" and "exporting" from two >>>>>>> opposite sides here. :-) Just to make everything clear: If I have >>>>>>> a Java class >>>>>>> class MyClass { >>>>>>> ?? public static void native myNativeFunc(); >>>>>>> } >>>>>>> >>>>>>> then I have one half of the JNI function, the Java half. This >>>>>>> must be matched by a corresponding implementation in native, like >>>>>>> this: >>>>>>> JNIEXPORT void JNICALL >>>>>>> Java_MyClass_myNativeFunc(void) { >>>>>>> // ... do stuff >>>>>>> } >>>>>>> >>>>>>> And this is the native half of the JNI function. Right? Let's >>>>>>> leave aside which side is "exporting" to the other for now. :-) >>>>>>> >>>>>>> This way of setting up native functions that can be called from >>>>>>> Java is what I refer to as JNI. And when you declare a native JNI >>>>>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>>>>> >>>>>>> We do have a lot of those functions in our native libraries. And >>>>>>> they are correct just the way they are. >>>>>> >>>>>> Yep all well and good. A function declared native in Java must >>>>>> have an implementation as you describe. But not all native >>>>>> functions exist to provide the native-half of a Java native function! >>>>>> >>>>>>> However, we also have *other* native functions, that are >>>>>>> exported, not as JNI functions that should be called from Java, >>>>>>> but as normal native library functions that should be called by >>>>>>> other native code. Okay so far? And *those* functions have been >>>>>>> problematic in how we decorate >>>>>> >>>>>> But there are again two cases. Those functions exported from a >>>>>> library that are expected to be called from external code using >>>>>> the JNI interface mechanism - such as all the JNI functions and >>>>>> JVM TI functions we export from the JVM - and those "exported" for >>>>>> access between libraries within the JDK (such as all the JVM_* >>>>>> functions in libjvm). >>>>>> >>>>>> I think it is only the second group that should be addressed by >>>>>> your JDK_EXPORT proposal - though I'm not completely clear exactly >>>>>> how to identify them. >>>>> Alright, now I think we're on the same page again. :) >>>>> >>>>> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >>>>> >>>>> You identify external APIs by the fact that they are documented. >>>>> And if you are unsure, you ask Jon. ;-) >>>>> >>>>>> >>>>>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>>>>> those functions, and instead use JDK_EXPORT as name for the macro >>>>>>> that decorates them as exported. That way, we can clearly see >>>>>>> that a function like this: >>>>>>> >>>>>>> JDK_EXPORT void >>>>>>> JLI_ReadEnv(char* env); >>>>>>> >>>>>>> is correctly declared, and will be exported to other native >>>>>>> libraries, but not to Java. >>>>>> >>>>>> The issue is not whether it is "exported to Java"** but whether it >>>>>> is exported using the JNI mechanism such that other native code >>>>>> calls it using the JNI mechanism. >>>>>> >>>>>> ** There is no way to write a native method declaration in Java >>>>>> such that it would be linked to the JLI_ReadEnv function. The >>>>>> naming is all wrong, as is the signature. >>>>>> >>>>>>> Just to clarify, this has nothing to do with if this is a >>>>>>> officially supported API or not. In general though, I assume that >>>>>>> most (if not all?) of our exported functions (apart from the >>>>>>> JNI_* stuff) is supposed to be consumed by other libraries in the >>>>>>> JDK, and is not a public API. >>>>>> >>>>>> I think it varies library by library. You may need native >>>>>> application code that can call directly into native JDK libraries. >>>>>> JLI is the Java Launcher Interface - I think it was introduced to >>>>>> make it easier for other launchers to be created. Native agents >>>>>> may need access to libmanagement or libjdwp functions. Native >>>>>> graphics code may need access to the JDK graphics library. Some of >>>>>> these accesses may be unsupported and undocumented, but I don't >>>>>> think you can just cut them all off. >>>>> If they are unsupported and undocumented, I sure as h*ll can cut >>>>> them all off! :-) >>>>> >>>>> Besides, and let me re-iterate this, the only change that will >>>>> happen by removing JNICALL, is on Windows 32. No other platform >>>>> will be affected. There is no official support for Windows 32 >>>>> anymore. There's some low-effort community work done on keeping >>>>> Windows 32 alive, but it's not backed by any major player. Right >>>>> now, they are taking a lot of hits *due to the fact* that we have >>>>> not sorted this out, and waste a lot of their precious effort >>>>> trying to fix this piecemeal. If we do fix things according to this >>>>> proposal, then it's at least clear how things *should* work. If it >>>>> turns out that there's some code out there in the wild, running on >>>>> Windows 32, that uses an undocumented and unsupported function >>>>> call, and it breaks -- well, sucks to be them. They'll just have to >>>>> do what everyone does who uses an undocumented interface that >>>>> suddenly changes: update their code. >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> JNICALL. All current instances of JNIEXPORT which is not pure >>>>>>>>> JNI native functions should be changed to use JDK_EXPORT instead. >>>>>>>>> >>>>>>>>> I further propose that this macro should reside in a new file >>>>>>>>> "jdk.h", placed in the new directory >>>>>>>>> src/java.base/share/native/include/internal. This header file >>>>>>>>> path will automatically be provided to all native libraries, >>>>>>>>> but not copied to the JDK being built. (The existence of a >>>>>>>>> "include/internal" directory with this behavior has been >>>>>>>>> discussed before. There are more files that ought to be moved >>>>>>>>> there, if/when it is created.) I believe in many cases the >>>>>>>>> #include "jni.h" can be just modified to #include "#jdk.h", >>>>>>>>> since most native code will not require "jni.h" unless actually >>>>>>>>> doing JNI calls -- most have included this file to get the >>>>>>>>> JNIEXPORT macro, which would explain the pervasive use of >>>>>>>>> #include "jni.h" in our code base. >>>>>>>> >>>>>>>> jni.h also defines all of the types used by the JNI. Those types >>>>>>>> are pervsive to the native code used throughout the JDK. >>>>>>>> >>>>>>>>> Thoughts? >>>>>>>> >>>>>>>> I think we need to understand the problems on Windows that >>>>>>>> prompted all this. Then I think we need to look at exactly how >>>>>>>> jni.h and JNIEXPORT etc are being used and understand whether >>>>>>>> this is truly an exported interface or not. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>> >>>>> >>> > From mvala at redhat.com Mon Dec 17 06:32:22 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 17 Dec 2018 07:32:22 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> Message-ID: Hi, thanks Doug, this is nice reduction. Here's the new webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.03/ Just a nitpick, issue is in using linked-list in buckets. The same is used for both HashMap and LinkedHashMap, so mentioning just LinkedHashMap might be confising. I've updated the comment s/LinkedHashMap/linked-list buckets/. I'm just running tier1 tests and benchmarks. On 12/16/18 3:23 PM, Doug Lea wrote: > > On 12/14/18 1:37 AM, Michal Vala wrote: >> Thanks Martin for finding this serious issue and the testcase. >> > > Sorry that I wasn't paying attention to this and so forced Martin to > discover the hard way that because of LinkeHashMap, you can't skip > doubling steps (at least not without a lot of rework). Also, the > documentation should have mentioned this. A simpler way to reduce > overhead in the case at hand is just to loop in putMapEntries: > > --- HashMap.java.~1.9.~ 2018-11-11 15:43:24.982878495 -0500 > +++ HashMap.java 2018-12-16 09:05:48.924727867 -0500 > @@ -502,8 +502,13 @@ > if (t > threshold) > threshold = tableSizeFor(t); > } > - else if (s > threshold) > - resize(); > + else { > + // Because of LinkedHashMap constraints, we cannot > + // expand all at once, but can reduce total resize > + // effort by repeated doubling now vs later > + while (table.length < MAXIMUM_CAPACITY && s > threshold) > + resize(); > + } > for (Map.Entry e : m.entrySet()) { > K key = e.getKey(); > V value = e.getValue(); > -- Michal Vala OpenJDK QE Red Hat Czech From philipp.kunz at paratix.ch Mon Dec 17 06:42:51 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 17 Dec 2018 07:42:51 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> Message-ID: <1545028971.2502.6.camel@paratix.ch> Hi Roger, Thank you very much for your review and the feedback. Please find my comments below and a new patch attached. Philipp On Wed, 2018-12-12 at 10:52 -0500, Roger Riggs wrote: > ????Hi Phillip, > > ???? > > ????Sorry, got busy... > > ???? > > ????Can you rebase the patch to the current repo, it did not apply > ????cleanly. > > ???? > > ????I know you are focused on removing the deprecation, but a few > ????localized improvements > > ????would be good. > > ???? > > ????In Attributes.java : 346-337, it uses StringBuffer, please change > it > ????to StringBuilder. > > ????? Unless thread safety is an issue, StringBuilder is recommended, > it > ????is > > ????? slightly more efficient since it does no synchronization. I did deliberately not touch the StringBuffer in the previous patch but fully agree now I know it has a chance to be accepted. Would you accept to replace StringBuffer with plain string concatenation after http://op enjdk.java.net/jeps/280 which was not in place at the time those StringBuffers were introduced? > ???? > > ????- And the StringBuilder should be sized when it is created, to > avoid > ????needing to resize it later. > > ????? Using a single StringBuilder all the entries, using > setLength(0), > ????would save allocating > > ????? for each entry. Jep 280 would also avoid having to size the buffers far as I understand. > ???? > > ?????- check the indentation @line 308-20 and 311. The indentation was weird, 5 instead of 4 spaces on some lines and I re-indented only the lines I touched anyway in the previous patch. Now, some lines appear changed only due to the indentation. After the StringBuffer removal only two of them are left in the current patch and certainly don't add significantly many unrelated changed lines now any more. > ???? > > ????In Manifest.java: > > ?????- write72 method? !String.isEmpty() is preferred over the > .length() > ????> 0. ok > ?????- if the line is empty, should it write the LINE_BREAK_BYTES??? > > ?????? A blank line in the manifest may be seen as significant. Before the patch, a line break was always added to the end of the StringBuffer after passing to make72Safe and before writing it. Now with the previous patch, write72 added it. Altogether makes no difference. But after reconsidering your point, I found a clearer approach, I hope, than passing an empty string for having a line break requested to be output which now also seems to me having been not the most obvious way and more like a kind of a hack before. In the course of that change I also renamed write72 to println and println72 and also added a test for it. Hope you also like it better that way. > ???? > > ?????- in the write method: Change StringBuffer to StringBuilder > > ???? > > ?????- The javadoc links to MANIFEST_VERSION and SIGNATURE_VERSION > ????should use "#". > > ???????? * {@link Attributes.Name#MANIFEST_VERSION} or > > ???????? * {@link Attributes.Name#SIGNATURE_VERSION} must be set in removed it again because it applies more to bug 8196371 or 6910466 > ???? > > ????Thanks, Roger > > ???? > > ???? > > ????On 12/04/2018 03:34 AM, Philipp Kunz > ??????wrote: > > ???? > ???? > > ?????? > > ??????Hi Roger, > > ?????? > > > > ?????? > > ??????I'm afraid the previous patch missed the tests, should be > > ????????included this time. > > ?????? > > > > ?????? > > ??????The intention of the patch is to solve only bug 8066619 about > > ????????deprecation. I sincerely hope the changes are neutral. > > ?????? > > > > ?????? > > ??????The new ValueUtf8Coding test heavily coincides/overlaps with > > ????????6202130 which is why I mentioned it. I'm however not > > satisfied > > ????????that that test alone also completely solves 6202130 because > > ????????6202130 has or might have implications with breaking > > characters > > ????????encoded in UTF-8 with more than one bytes across a line > > break > > ????????onto a continuation line which is not part of the current > > patch > > ????????proposed for 8066619. At some point I proposed > > ValueUtf8Coding > > ????????with only removing the comments from the implementation in > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/0 > > 56166.html > > ????????but I have changed my mind since then and think now 6202130 > > ????????should also change the implementation not to break lines > > inside > > ????????of multi-byte characters which is not part of the current > > patch > > ????????and is probably easier after the current patch if necessary > > at > > ????????all. Both 6202130 and the current patch for 8066619 here > > touch > > ????????the UTF-8 coding of manifests and which ever is solved > > first > > ????????should add a corresponding test because no such test exists > > yet > > ????????I believe. Worth to mention are > > ????????test/jdk/tools/launcher/DiacriticTest.java and > > ????????test/jdk/tools/launcher/UnicodeTest.java both of which test > > the > > ????????JVM launch and have a somewhat different purpose. I haven't > > ????????found any other test for the specifically changed lines of > > code > > ????????apart from probably many tests that use manifests > > indirectly in > > ????????some form.? > > ?????? > > > > ?????? > > ??????Regards, > > ??????Philipp > > ?????? > > > > ?????? > > ?????? > > > > ?????? > > ??????On Mon, 2018-12-03 at 16:43 -0500, Roger Riggs wrote: > > ?????? > > > ????????Hi Phillip, > > > > > > The amount detail obscures the general purpose. > > > And there appears to be more than 1. > > > The Jira issue IDs mentioned are 8066619 and 6202130. > > > > > > Is this functionally neutral and only fixes the deprecations? > > > > > > There is a mention that a test is needed for multi-byte chars, > > > but a test > > > is not included.? Is there an existing test for that? > > > > > > Its probably best to identify the main functional improvement > > > (multi-byte) > > > and fix the deprecation as a side effect. > > > > > > Thanks for digging through the issues and the explanations; > > > it will take a bit of study to unravel and understand everything > > > in this? > > > changeset. > > > > > > Regards, Roger > > > > > > > > > On 12/01/2018 06:49 AM, Philipp Kunz wrote: > > > > Find the proposed patch attached. Some comments and > > > > explanations, here: > > > > > > > > There is a quite interesting implementation in Manifest and > > > > Attributes > > > > worth quite some explanation. The way it used to work before > > > > was: > > > > > > > > 1. put manifest header name, colon and space into a > > > > StringBuffer > > > > -> the buffer now contains a string of characters each high- > > > > byte of > > > > which is zero as explained later why this is important. the > > > > high-bytes > > > > are zero because the set of allowed characters is very limited > > > > to ":", > > > > " ", "a" - "z", "A" - "Z", "0" - "9", "_", and "-" according to > > > > Attributes.Name#hash(String) so far with only the name and the > > > > separator and yet without the values. > > > > > > > > 2. if the value is not null, encode it in UTF-8 into a byte > > > > array and > > > > instantiate a String with it using deprecated > > > > String#String(byte[],int,int,int) resulting in a String with > > > > the same > > > > length as the byte array before holding one byte in each > > > > character's > > > > low-byte. This makes a difference for characters encoded with > > > > more than > > > > one byte in UTF-8. The new String is potentially longer than > > > > the > > > > original value. > > > > > > > > 3.?if the value is not null, append value to buffer. The one > > > > UTF-8 > > > > encoded byte per character from the appended string is > > > > preserved also > > > > in the buffer along with the previous buffer contents. > > > > > > > > 3alt. if the value is null, add "null" to the buffer. See > > > > java.lang.AbstractStringBuilder#append(String). Neither of the > > > > characters of "null" has a non-zero high-byte encoded as UTF-16 > > > > chars. > > > > > > > > 4. make72Safe inserts line breaks with continuation spaces. > > > > Note that > > > > the buffer here contains only one byte per character because > > > > all high- > > > > bytes are still zero so that line.length() and > > > > line.insert(index, ...) > > > > effectively operate with byte offsets and not characters. > > > > > > > > 5. buffer.toString() > > > > > > > > 6. DataOutputStream#writeBytes(String). First of all read the > > > > JavaDoc > > > > comment for it, which explains it all: > > > > ?????Writes out the string to the underlying output stream as a > > > > ?????sequence of bytes. Each character in the string is written > > > > out, in > > > > ?????sequence, by discarding its high eight bits. If no > > > > exception is > > > > ?????thrown, the counter written is incremented by > > > > the > > > > ?????length of s > > > > This restores the earlier UTF-8 encoding correctly. > > > > > > > > The topic has been discussed and mentioned already in > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/0 > > > > 52946.ht > > > > ml > > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > > > > String(byte[],int,int,int) works "well" or "well enough" only > > > > together > > > > with DataOutputStream#writeBytes(String). When removing > > > > String(byte[],int,int,int) from Manifest and Attributes because > > > > deprecated, it makes no sense to keep using > > > > DataOutputStream#writeBytes(String) either. > > > > > > > > For the same reason as?String#String(byte[],int,int,int) has > > > > been > > > > deprecated, I suggest to also deprecate > > > > java.io.DataOutput#writeBytes(String) as a separate issue. This > > > > might > > > > relate to https://bugs.openjdk.java.net/browse/JDK-6400767 but > > > > that one > > > > came to a different conclusion some ten years ago. > > > > > > > > I preferred to stick with the DataOutputStream even though not > > > > strictly > > > > necessary any more. It is and has been in the API of Attributes > > > > (unfortunately not private) and should better not be removed by > > > > changing the parameter type. Same for > > > > Manifest#make72Safe(StringBuffer) > > > > which I deprecated rather than having removed. Someone could > > > > have > > > > extended a class from Manifest and use such a method and when > > > > changing > > > > the signature it could no longer even compile in a far-fetched > > > > case. > > > > > > > > LINE_BREAK, CONTINUATION_SPACE, LINE_BREAK_BYTES, and > > > > LINE_BREAK_WITH_CONTINUATION_SPACE_BYTES should prevent having > > > > to > > > > invoke getBytes(UTF_8) over and over again on "\r\n" and "\r\n > > > > " with > > > > the idea to slightly improve performance this way. I figured it > > > > does > > > > not need JavaDoc comments but would be happy to add them if > > > > desired. > > > > > > > > I removed "XXX Need to handle UTF8 values." from Manifest#read > > > > after > > > > adding a test for it in ValueUtf8Coding. This change and test > > > > also > > > > relate to bug 6202130 but does not solve that one completely. > > > > ValueUtf8Coding demonstrates that Manifest can read UTF-8 > > > > encoded > > > > values which is a necessary test case to cover for this patch > > > > here. > > > > ValueUtf8Coding is the same test as already submitted and > > > > suggested > > > > earlier. See > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Octob > > > > er/threa > > > > d.html#55848 > > > > > > > > Indentation in Attributes#write(DataOutputStream) was five > > > > spaces on > > > > most lines. I?fixed indentation only on the lines changed > > > > anyway. > > > > > > > > I replaced String#String(byte[],int,int,String) with > > > > String#String(byte[],int,int,java.nio.charset.StandardCharsets. > > > > UTF_8) > > > > which as a difference does not declare to throw a > > > > java.io.UnsupportedEncodingException. That also replaced "UTF8" > > > > as a > > > > charset name which I would consider not optimal regarding > > > > sun.nio.cs.UTF_8#UTF_8() and sun.nio.cs.UTF_8#historicalName(). > > > > > > > > In my opinion there is still some duplicated or at least very > > > > similar > > > > code in Manifest#write, Attributes#writeMain, and > > > > Attributes#write but > > > > I preferred to change less rather than more and not to further > > > > refactor > > > > and re-combine it. > > > > > > > > In EmptyKeysAndValues and NullKeysAndValues tests I tried to > > > > demonstrate that the changed implementation does not change > > > > behaviour > > > > also in edge cases. I would have expected not having to test > > > > all these > > > > cases but then I realized it was possible to test and is > > > > therefore > > > > possible in a real use case as well however far-fetched. At > > > > least the > > > > > > > > ?????if (value != null) { > > > > > > > > lines (three times) most obviously demand to test the null > > > > value cases. > > > > > > > > I'm looking curiously forward to any kind of feedback or > > > > opinion. > > > > > > > > Philipp > > > > > > > > > ?????? > > > > ???? > > ???? > > ?? > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 30058 bytes Desc: not available URL: From claes.redestad at oracle.com Mon Dec 17 07:06:10 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Dec 2018 08:06:10 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <1545028971.2502.6.camel@paratix.ch> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> Message-ID: On 2018-12-17 07:42, Philipp Kunz wrote: > I did deliberately not touch the StringBuffer in the previous patch but > fully agree now I know it has a chance to be accepted. Would you accept > to replace StringBuffer with plain string concatenation afterhttp://op > enjdk.java.net/jeps/280 which was not in place at the time those > StringBuffers were introduced? Unfortunately JEP 280-style indified string concatenation is not enabled in the java.base module to avoid bootstrap issues. That said, even if you could benefit from ISC here, StringBuilders are likely to be better when building up your string using loops and method calls, unless there's a simple way to reduce it all down to a single concatenation expression (no passing the builder to another method, no loops etc). /Claes From christoph.langer at sap.com Mon Dec 17 08:28:43 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 Dec 2018 08:28:43 +0000 Subject: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests Message-ID: Hi, when working with jdk.zipfs, I found some opportunity for cleanups. I'd like to contribute this independently from my other thread regarding Posix permissions in zip files (http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056426.html). So, please help to review the cleanup. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215472.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215472 Thanks Christoph From sverre.moe at gmail.com Mon Dec 17 10:31:39 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 17 Dec 2018 11:31:39 +0100 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> <9775097f-9642-990e-793d-48b8ed373b20@oracle.com> Message-ID: I have discovered a bug with the jpackage created application image. It does not pass any --arguments to the application. The application.cfg contains the arguments, but the native binary does not pass them to the application. [ArgOptions] --laf=nimbus --test1=value1 --test2=value2 /Sverre Den s?n. 16. des. 2018 kl. 20:28 skrev Sverre Moe : > > Den s?n. 16. des. 2018 kl. 19:32 skrev Andy Herrick : > > > > > > On 12/15/2018 12:44 PM, Andy Herrick wrote: > > While investigating this, I found undocumented functionality left over > > from JavaFXPackager that may be the root of these class-path messages. > > > > This is both dangerous and powerful, and will require some discussion > > before we either remove it or enhance and document it. > > > > The functionality is as follows: > > > > if file ./package/windows/menu.iss exists, ./package/windows/menu.iss > > will be used instead of > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/template.iss. > > > > also if ./package/windows/menu.ico exists, it will be used instead of > > config/awt.ico (or instead of javalogo_white_48.ico when no --icon is > > given). > > > > The bmp used in inno setup can be replaced either by adding > > package/windows/menu-setup-icon.bmp, or by modifying the appropriate > > line in ./package/windows/menu.iss > > Yes, this is same as it was for javapackager, but having the > package/ placed on project root is not ideal. > It seem jpackage has changed the directory structure a little, now > using just package instead of package/. > > > As I said we will need to discuss this internally, and we may choose to > > just remove it, but as pointed out above, there are other installer > > parameters (mostly included in the various templates) that a user may > > wish to customize, for which there are no CLI options. > > I would not think removing these resource override to be a good idea. > The default templates may not always suffice. > > An --app-release would be very useful, specially in addition to the > --app-version. > Release information in the version will work for DEB, but will fail > for RPM since '-' is not allowed. > > > Although the current behavior of reading resources from > > "./package// is not > > really acceptable, adding a CLI option such as --resources-override > > might be possible. > > I second an CLI option that would specify where these resources are. > > Currently we are preprocessing these resources to replace strings such > as project name, version, etc. > src/main/deploy/package/linux > build/deploy/package/linux > > /Sverre From claes.redestad at oracle.com Mon Dec 17 10:38:07 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Dec 2018 11:38:07 +0100 Subject: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests In-Reply-To: References: Message-ID: Hi Christoph, I believe the convention in the OpenJDK sources is to sort static imports after non-static, so changing to the other way around in a few places adds inconsistencies. In ZipFileSystem you remove the unused method releaseDeflater - to me this indicates the resource pooling is actually broken? I.e., shouldn't EntryOutputStreamDef return its Deflater to the cache when it's closed, similar to how the anonymous InflaterInputStream in getInputStream does it? As it's currently implemented the deflaters list will always be empty and no Deflater returned, so could go the other way and remove that cache if caching Deflaters isn't useful. Otherwise looks good to me. /Claes On 2018-12-17 09:28, Langer, Christoph wrote: > Hi, > > when working with jdk.zipfs, I found some opportunity for cleanups. I'd like to contribute this independently from my other thread regarding Posix permissions in zip files (http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056426.html). So, please help to review the cleanup. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215472.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215472 > > Thanks > Christoph > From sverre.moe at gmail.com Mon Dec 17 11:14:40 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 17 Dec 2018 12:14:40 +0100 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> <5e87b3ce-2e7a-f761-29de-f4894826bcba@oracle.com> <9775097f-9642-990e-793d-48b8ed373b20@oracle.com> Message-ID: One more thing discovered: Even though the version is defined in DEB control file, the deb bundler does not use it for the deb file name. The RPM bundler does it right. It uses the version and release specified in the RPM spec file. application-1.0-deb application-1.2.3-rc1.rpm A workaround is to set the --app-version CLI option. /Sverre Den man. 17. des. 2018 kl. 11:31 skrev Sverre Moe : > > I have discovered a bug with the jpackage created application image. > It does not pass any --arguments to the application. > The application.cfg contains the arguments, but the native binary does > not pass them to the application. > [ArgOptions] > --laf=nimbus > --test1=value1 > --test2=value2 > > /Sverre > > Den s?n. 16. des. 2018 kl. 20:28 skrev Sverre Moe : > > > > Den s?n. 16. des. 2018 kl. 19:32 skrev Andy Herrick : > > > > > > > > > On 12/15/2018 12:44 PM, Andy Herrick wrote: > > > While investigating this, I found undocumented functionality left over > > > from JavaFXPackager that may be the root of these class-path messages. > > > > > > This is both dangerous and powerful, and will require some discussion > > > before we either remove it or enhance and document it. > > > > > > The functionality is as follows: > > > > > > if file ./package/windows/menu.iss exists, ./package/windows/menu.iss > > > will be used instead of > > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/template.iss. > > > > > > also if ./package/windows/menu.ico exists, it will be used instead of > > > config/awt.ico (or instead of javalogo_white_48.ico when no --icon is > > > given). > > > > > > The bmp used in inno setup can be replaced either by adding > > > package/windows/menu-setup-icon.bmp, or by modifying the appropriate > > > line in ./package/windows/menu.iss > > > > Yes, this is same as it was for javapackager, but having the > > package/ placed on project root is not ideal. > > It seem jpackage has changed the directory structure a little, now > > using just package instead of package/. > > > > > As I said we will need to discuss this internally, and we may choose to > > > just remove it, but as pointed out above, there are other installer > > > parameters (mostly included in the various templates) that a user may > > > wish to customize, for which there are no CLI options. > > > > I would not think removing these resource override to be a good idea. > > The default templates may not always suffice. > > > > An --app-release would be very useful, specially in addition to the > > --app-version. > > Release information in the version will work for DEB, but will fail > > for RPM since '-' is not allowed. > > > > > Although the current behavior of reading resources from > > > "./package// is not > > > really acceptable, adding a CLI option such as --resources-override > > > might be possible. > > > > I second an CLI option that would specify where these resources are. > > > > Currently we are preprocessing these resources to replace strings such > > as project name, version, etc. > > src/main/deploy/package/linux > build/deploy/package/linux > > > > /Sverre From Roger.Riggs at oracle.com Mon Dec 17 14:47:01 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 17 Dec 2018 09:47:01 -0500 Subject: JDK-8165199: UUID.fromString(str) compliance checking? In-Reply-To: <6941f27d-b84b-8a16-f67b-550d3a7c6f42@oracle.com> References: <6941f27d-b84b-8a16-f67b-550d3a7c6f42@oracle.com> Message-ID: <58307315-e74e-c352-db3e-4a47350d3488@oracle.com> Hi, I could imagine a more performant implementation as Claes suggested by expecting the format and only those characters defined by the rfc 4122. And it could retain compatibility by faulting back to the current implementation for other formats and characters outside of those in the rfc. But it would only be worthwhile if the performance improvement was significant and worth having two copies of the code. $.02, Roger On 12/15/2018 01:22 PM, Joe Darcy wrote: > Hello, > > On 12/14/2018 2:00 PM, Andrew Leonard wrote: >> Yes, this was my concern, source compatibility... >> With the current implementation it is not too harmful to "sloppy" app >> code. If it's not causing any other underlying "bug" then I would be >> tempted to leave this "sleeping dog..." > > > To use language precisely, the kind of compatibly at issue here is > *behavioral* compatibility.? From the definitions used by in the CSR > process: > > "For Java programs, there are three main categories of compatibility: > > ??? Source: Source compatibility concerns translating Java source code > into class files. > > ??? Binary: Binary compatibility is defined in The Java Language > Specification as preserving the ability to link without error. > > ??? Behavioral: Behavioral compatibility includes the semantics of the > code that is executed at runtime." > > https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility > > Since the proposed change would only impact the implementation and not > the method signatures, etc. it is a behavioral compatibility concern. > > Given the length of time the existing behavior has been present, I > would be hesitant to change it now. > > HTH, > > -Joe > From mvala at redhat.com Mon Dec 17 15:40:01 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 17 Dec 2018 16:40:01 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> Message-ID: <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> All tests I've run passed, benchmarks show ~15% performance boost for putAllWithBigMapToNonEmptyMap. On 12/17/18 7:32 AM, Michal Vala wrote: > Hi, > > thanks Doug, this is nice reduction. > > Here's the new webrev: > http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.03/ > > Just a nitpick, issue is in using linked-list in buckets. The same is used for > both HashMap and LinkedHashMap, so mentioning just LinkedHashMap might be > confising. I've updated the comment s/LinkedHashMap/linked-list buckets/. > > I'm just running tier1 tests and benchmarks. > > On 12/16/18 3:23 PM, Doug Lea wrote: >> >> On 12/14/18 1:37 AM, Michal Vala wrote: >>> Thanks Martin for finding this serious issue and the testcase. >>> >> >> Sorry that I wasn't paying attention to this and so forced Martin to >> discover the hard way that because of LinkeHashMap, you can't skip >> doubling steps (at least not without a lot of rework). Also, the >> documentation should have mentioned this. A simpler way to reduce >> overhead in the case at hand is just to loop in putMapEntries: >> >> --- HashMap.java.~1.9.~??? 2018-11-11 15:43:24.982878495 -0500 >> +++ HashMap.java??? 2018-12-16 09:05:48.924727867 -0500 >> @@ -502,8 +502,13 @@ >> ????????????????? if (t > threshold) >> ????????????????????? threshold = tableSizeFor(t); >> ????????????? } >> -??????????? else if (s > threshold) >> -??????????????? resize(); >> +??????????? else { >> +??????????????? // Because of LinkedHashMap constraints, we cannot >> +??????????????? // expand all at once, but can reduce total resize >> +??????????????? // effort by repeated doubling now vs later >> +??????????????? while (table.length threshold) >> +??????????????????? resize(); >> +??????????? } >> ????????????? for (Map.Entry e : m.entrySet()) { >> ????????????????? K key = e.getKey(); >> ????????????????? V value = e.getValue(); >> > -- Michal Vala OpenJDK QE Red Hat Czech From Roger.Riggs at oracle.com Mon Dec 17 17:12:20 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 17 Dec 2018 12:12:20 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <1545028971.2502.6.camel@paratix.ch> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> Message-ID: <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> Hi Philipp, Manifest.java: ?- Line 258: creating a new array for two characters on each call isn't as efficient as: ??? out.write('\r'); ??? out.write('\n'). The new test that need internal access can gain that access by adding: ?? @modules java.base/java.util.jar:+open That instructs testng to add the correct command line switches. Then you can remove --illegal-access=warn and the tests will work. In the test ValueUtf8Coding, just a mention of a method to create a string with repeats. ???? "-".repeat(80); On 12/17/2018 01:42 AM, Philipp Kunz wrote: > Hi Roger, > > Thank you very much for your review and the feedback. Please find my > comments below and a new patch attached. > > Philipp > > > On Wed, 2018-12-12 at 10:52 -0500, Roger Riggs wrote: >> Hi Phillip, >> >> Sorry, got busy... >> >> Can you rebase the patch to the current repo, it did not apply cleanly. >> >> I know you are focused on removing the deprecation, but a few >> localized improvements >> would be good. >> >> In Attributes.java : 346-337, it uses StringBuffer, please change it >> to StringBuilder. >> ? Unless thread safety is an issue, StringBuilder is recommended, it is >> ? slightly more efficient since it does no synchronization. > I did deliberately not touch the StringBuffer in the previous patch > but fully agree now I know it has a chance to be accepted. Would you > accept to replace StringBuffer with plain string concatenation after > http://openjdk.java.net/jeps/280 which was not in place at the time > those StringBuffers were introduced? Using "+" concat is fine. >> >> - And the StringBuilder should be sized when it is created, to avoid >> needing to resize it later. >> ? Using a single StringBuilder all the entries, using setLength(0), >> would save allocating >> ? for each entry. > Jep 280 would also avoid having to size the buffers far as I understand. >> >> ?- check the indentation @line 308-20 and 311. > The indentation was weird, 5 instead of 4 spaces on some lines and I > re-indented only the lines I touched anyway in the previous patch. > Now, some lines appear changed only due to the indentation. After the > StringBuffer removal only two of them are left in the current patch > and certainly don't add significantly many unrelated changed lines now > any more. ok >> >> In Manifest.java: >> ?- write72 method? !String.isEmpty() is preferred over the .length() > 0. > ok >> ?- if the line is empty, should it write the LINE_BREAK_BYTES? >> ?? A blank line in the manifest may be seen as significant. > Before the patch, a line break was always added to the end of the > StringBuffer after passing to make72Safe and before writing it. Now > with the previous patch, write72 added it. Altogether makes no > difference. But after reconsidering your point, I found a clearer > approach, I hope, than passing an empty string for having a line break > requested to be output which now also seems to me having been not the > most obvious way and more like a kind of a hack before. In the course > of that change I also renamed write72 to println and println72 and > also added a test for it. Hope you also like it better that way. ?- Line 257:? println() always makes me think of the system specific line separator. ???? I'd name it writeln() and write72ln.? I think, write is clearer that it is bytes being written with ???? no charset implications. >> >> ?- in the write method: Change StringBuffer to StringBuilder >> >> ?- The javadoc links to MANIFEST_VERSION and SIGNATURE_VERSION should >> use "#". >> ???? * {@link Attributes.Name#MANIFEST_VERSION} or >> ???? * {@link Attributes.Name#SIGNATURE_VERSION} must be set in > removed it again because it applies more to bug 8196371 or 6910466 ok Thanks, Roger >> >> Thanks, Roger >> >> >> On 12/04/2018 03:34 AM, Philipp Kunz wrote: >>> Hi Roger, >>> >>> I'm afraid the previous patch missed the tests, should be included >>> this time. >>> >>> The intention of the patch is to solve only bug 8066619 about >>> deprecation. I sincerely hope the changes are neutral. >>> >>> The new ValueUtf8Coding test heavily coincides/overlaps with 6202130 >>> which is why I mentioned it. I'm however not satisfied that that >>> test alone also completely solves 6202130 because 6202130 has or >>> might have implications with breaking characters encoded in UTF-8 >>> with more than one bytes across a line break onto a continuation >>> line which is not part of the current patch proposed for 8066619. At >>> some point I proposed ValueUtf8Coding with only removing the >>> comments from the implementation in >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056166.html >>> but I have changed my mind since then and think now 6202130 should >>> also change the implementation not to break lines inside of >>> multi-byte characters which is not part of the current patch and is >>> probably easier after the current patch if necessary at all. Both >>> 6202130 and the current patch for 8066619 here touch the UTF-8 >>> coding of manifests and which ever is solved first should add a >>> corresponding test because no such test exists yet I believe. Worth >>> to mention are test/jdk/tools/launcher/DiacriticTest.java and >>> test/jdk/tools/launcher/UnicodeTest.java both of which test the JVM >>> launch and have a somewhat different purpose. I haven't found any >>> other test for the specifically changed lines of code apart from >>> probably many tests that use manifests indirectly in some form. >>> >>> Regards, >>> Philipp >>> >>> >>> On Mon, 2018-12-03 at 16:43 -0500, Roger Riggs wrote: >>>> Hi Phillip, >>>> >>>> The amount detail obscures the general purpose. >>>> And there appears to be more than 1. >>>> The Jira issue IDs mentioned are 8066619 and 6202130. >>>> >>>> Is this functionally neutral and only fixes the deprecations? >>>> >>>> There is a mention that a test is needed for multi-byte chars, but a test >>>> is not included.? Is there an existing test for that? >>>> >>>> Its probably best to identify the main functional improvement (multi-byte) >>>> and fix the deprecation as a side effect. >>>> >>>> Thanks for digging through the issues and the explanations; >>>> it will take a bit of study to unravel and understand everything in this >>>> changeset. >>>> >>>> Regards, Roger >>>> >>>> >>>> On 12/01/2018 06:49 AM, Philipp Kunz wrote: >>>>> Find the proposed patch attached. Some comments and explanations, >>>>> here: There is a quite interesting implementation in Manifest and >>>>> Attributes worth quite some explanation. The way it used to work >>>>> before was: 1. put manifest header name, colon and space into a >>>>> StringBuffer -> the buffer now contains a string of characters >>>>> each high-byte of which is zero as explained later why this is >>>>> important. the high-bytes are zero because the set of allowed >>>>> characters is very limited to ":", " ", "a" - "z", "A" - "Z", "0" >>>>> - "9", "_", and "-" according to Attributes.Name#hash(String) so >>>>> far with only the name and the separator and yet without the >>>>> values. 2. if the value is not null, encode it in UTF-8 into a >>>>> byte array and instantiate a String with it using deprecated >>>>> String#String(byte[],int,int,int) resulting in a String with the >>>>> same length as the byte array before holding one byte in each >>>>> character's low-byte. This makes a difference for characters >>>>> encoded with more than one byte in UTF-8. The new String is >>>>> potentially longer than the original value. 3.?if the value is not >>>>> null, append value to buffer. The one UTF-8 encoded byte per >>>>> character from the appended string is preserved also in the buffer >>>>> along with the previous buffer contents. 3alt. if the value is >>>>> null, add "null" to the buffer. See >>>>> java.lang.AbstractStringBuilder#append(String). Neither of the >>>>> characters of "null" has a non-zero high-byte encoded as UTF-16 >>>>> chars. 4. make72Safe inserts line breaks with continuation spaces. >>>>> Note that the buffer here contains only one byte per character >>>>> because all high- bytes are still zero so that line.length() and >>>>> line.insert(index, ...) effectively operate with byte offsets and >>>>> not characters. 5. buffer.toString() 6. >>>>> DataOutputStream#writeBytes(String). First of all read the JavaDoc >>>>> comment for it, which explains it all: Writes out the string to >>>>> the underlying output stream as a ????sequence of bytes. Each >>>>> character in the string is written out, in ????sequence, by >>>>> discarding its high eight bits. If no exception is ????thrown, the >>>>> counter written is incremented by the ????length of >>>>> s This restores the earlier UTF-8 encoding correctly. >>>>> The topic has been discussed and mentioned already in >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052946.ht >>>>> ml https://bugs.openjdk.java.net/browse/JDK-6202130 >>>>> String(byte[],int,int,int) works "well" or "well enough" only >>>>> together with DataOutputStream#writeBytes(String). When removing >>>>> String(byte[],int,int,int) from Manifest and Attributes because >>>>> deprecated, it makes no sense to keep using >>>>> DataOutputStream#writeBytes(String) either. For the same reason >>>>> as?String#String(byte[],int,int,int) has been deprecated, I >>>>> suggest to also deprecate java.io.DataOutput#writeBytes(String) as >>>>> a separate issue. This might relate to >>>>> https://bugs.openjdk.java.net/browse/JDK-6400767 but that one came >>>>> to a different conclusion some ten years ago. I preferred to stick >>>>> with the DataOutputStream even though not strictly necessary any >>>>> more. It is and has been in the API of Attributes (unfortunately >>>>> not private) and should better not be removed by changing the >>>>> parameter type. Same for Manifest#make72Safe(StringBuffer) which I >>>>> deprecated rather than having removed. Someone could have extended >>>>> a class from Manifest and use such a method and when changing the >>>>> signature it could no longer even compile in a far-fetched case. >>>>> LINE_BREAK, CONTINUATION_SPACE, LINE_BREAK_BYTES, and >>>>> LINE_BREAK_WITH_CONTINUATION_SPACE_BYTES should prevent having to >>>>> invoke getBytes(UTF_8) over and over again on "\r\n" and "\r\n " >>>>> with the idea to slightly improve performance this way. I figured >>>>> it does not need JavaDoc comments but would be happy to add them >>>>> if desired. I removed "XXX Need to handle UTF8 values." from >>>>> Manifest#read after adding a test for it in ValueUtf8Coding. This >>>>> change and test also relate to bug 6202130 but does not solve that >>>>> one completely. ValueUtf8Coding demonstrates that Manifest can >>>>> read UTF-8 encoded values which is a necessary test case to cover >>>>> for this patch here. ValueUtf8Coding is the same test as already >>>>> submitted and suggested earlier. See >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/threa >>>>> d.html#55848 Indentation in Attributes#write(DataOutputStream) was >>>>> five spaces on most lines. I?fixed indentation only on the lines >>>>> changed anyway. I replaced String#String(byte[],int,int,String) >>>>> with >>>>> String#String(byte[],int,int,java.nio.charset.StandardCharsets.UTF_8) >>>>> which as a difference does not declare to throw a >>>>> java.io.UnsupportedEncodingException. That also replaced "UTF8" as >>>>> a charset name which I would consider not optimal regarding >>>>> sun.nio.cs.UTF_8#UTF_8() and sun.nio.cs.UTF_8#historicalName(). In >>>>> my opinion there is still some duplicated or at least very similar >>>>> code in Manifest#write, Attributes#writeMain, and Attributes#write >>>>> but I preferred to change less rather than more and not to further >>>>> refactor and re-combine it. In EmptyKeysAndValues and >>>>> NullKeysAndValues tests I tried to demonstrate that the changed >>>>> implementation does not change behaviour also in edge cases. I >>>>> would have expected not having to test all these cases but then I >>>>> realized it was possible to test and is therefore possible in a >>>>> real use case as well however far-fetched. At least the if (value >>>>> != null) { lines (three times) most obviously demand to test the >>>>> null value cases. I'm looking curiously forward to any kind of >>>>> feedback or opinion. Philipp >>>> >>>> >> From swpalmer at gmail.com Mon Dec 17 17:29:24 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 17 Dec 2018 12:29:24 -0500 Subject: jpackage EA Build 0 In-Reply-To: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: <0AB94445-2AEE-48FC-8C15-D5931F2B4B69@gmail.com> Building a non-modular app on macOS: In the output folder I find a .dmg file and a .pkg file. However, the .dmg produced contains both the application bundle AND the .pkg installer. It should not contain the .pkg Scott > On Dec 14, 2018, at 7:46 AM, Andy Herrick wrote: > > I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ > > This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, > > This build is intended for developers interested in jpackage, and is provided as a convenience so that they don't need to build from the source code (branch="JDK-8200758-branch"). > > Warning: This build is based on an incomplete version of JDK 12 . > > Please send feedback via e-mail to core-libs-dev at openjdk.java.net > > /Andy > From mandy.chung at oracle.com Mon Dec 17 17:43:12 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Dec 2018 09:43:12 -0800 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: Message-ID: <6bbd7cfd-3a00-e358-7571-864ec42c6d4a@oracle.com> On 12/15/18 1:40 AM, Alan Bateman wrote: > This is test only change to fix a few tests that don't have complete > @modules or --add-exports options and so fail when running jtreg with > vmoption:--illegal-access=deny. > > The only change that might not be obvious is to > langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test > creates a custom class loader to load the CreateSymbols tool from the > make tree. jtreg doesn't know how to export packages to the unnamed > module of custom class loaders so the test is changed to open the > packages to the test and then pass on the rights to the unnamed module > of the custom class loader. > > http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html Looks good to me. Mandy From swpalmer at gmail.com Mon Dec 17 17:45:36 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 17 Dec 2018 12:45:36 -0500 Subject: jpackage EA Build 0 In-Reply-To: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: I finally got to the point where I can play with this? I?m just using trial and error, trying to figure out what to do based on the output of package --help and responding to error messages to guide me. I?ve already used jlink to create a runtime (including JavaFX) that I want to use with my non-modular application. I?ve put a bunch of files that my application requires in an ?app? folder /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/bin/jpackage create-installer --input /Users/scott/dev/AdminApp/build/image/app, --runtime-image /Users/scott/dev/AdminApp/build/image/runtime --output /Users/scott/dev/AdminApp/build/installer --build-root /Users/scott/dev/AdminApp/build/tmpInst --name "Server Admin" --main-jar /Users/scott/dev/AdminApp/build/libs/AdminApp-1.0.4.jar ?class my.company.serveradmin.ServerAdminApp Bundler Mac App Store Ready Bundler skipped because of a configuration problem: java.lang.RuntimeException: File /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does not belong to /Users/scott/dev/AdminApp/build/image/app Bundler DMG Installer skipped because of a configuration problem: java.lang.RuntimeException: File /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does not belong to /Users/scott/dev/AdminApp/build/image/app Bundler PKG Installer skipped because of a configuration problem: java.lang.RuntimeException: File /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does not belong to /Users/scott/dev/AdminApp/build/image/app I don?t understand the error message. What is it complaining about? I figured out that I was using the wrong value for the --main-jar .. I needed the name relative to my input folder, so I changed that and it produced output, but the error message I got above was not at all helpful. Then I looked at the directory structure of the application bundle. My input directory looked like app/ libs/ But the ?libs? subfolder was missing from the produced bundle. All the jars that were in it were placed directly in the ?Java? folder of the app bundle. So then I added a README.txt file under /app as a sibling of the libs folder. That caused the bundled structure to match what I had, with a README.txt and ?libs? folder containing all my jars, all located in the ?Java? folder of the application bundle. I think that inconsistent layout should be corrected. It would be good to document what is expected in the input directory, how those files are used, and where they end up in the output directory. --icon says it takes the icon file name (not a path), but I don?t want to install the icon file as a separate discrete file in my application, so where is it looking for it? I complete example for each of the sample usages shown by "package --help" would go a long way. Scott > On Dec 14, 2018, at 7:46 AM, Andy Herrick wrote: > > I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ > > This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, > > This build is intended for developers interested in jpackage, and is provided as a convenience so that they don't need to build from the source code (branch="JDK-8200758-branch"). > > Warning: This build is based on an incomplete version of JDK 12 . > > Please send feedback via e-mail to core-libs-dev at openjdk.java.net > > /Andy > From jonathan.gibbons at oracle.com Mon Dec 17 18:41:51 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 17 Dec 2018 10:41:51 -0800 Subject: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: Message-ID: <4951e90a-06af-1192-f215-1b71160427e3@oracle.com> The change to the langtools test looks OK -- Jon On 12/15/18 1:40 AM, Alan Bateman wrote: > This is test only change to fix a few tests that don't have complete > @modules or --add-exports options and so fail when running jtreg with > vmoption:--illegal-access=deny. > > The only change that might not be obvious is to > langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test > creates a custom class loader to load the CreateSymbols tool from the > make tree. jtreg doesn't know how to export packages to the unnamed > module of custom class loaders so the test is changed to open the > packages to the test and then pass on the rights to the unnamed module > of the custom class loader. > > http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html > > -Alan From james.laskey at oracle.com Mon Dec 17 19:19:37 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 17 Dec 2018 15:19:37 -0400 Subject: RFR - CSR JDK-8215499 - String::indent inconsistency with blank lines Message-ID: <468570A0-73A9-44BC-92E3-2A57DE350DC2@oracle.com> Please review CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 Thank you. ? Jim From lance.andersen at oracle.com Mon Dec 17 20:03:27 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 17 Dec 2018 15:03:27 -0500 Subject: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests In-Reply-To: References: Message-ID: <247E396D-3C1B-4C4C-897D-54A749AEB6D6@oracle.com> HI Christoph > On Dec 17, 2018, at 5:38 AM, Claes Redestad wrote: > > Hi Christoph, > > I believe the convention in the OpenJDK sources is to sort static > imports after non-static, so changing to the other way around in a few > places adds inconsistencies. > > In ZipFileSystem you remove the unused method releaseDeflater - to me > this indicates the resource pooling is actually broken? I.e., shouldn't > EntryOutputStreamDef return its Deflater to the cache when it's closed, > similar to how the anonymous InflaterInputStream in getInputStream does > it? As it's currently implemented the deflaters list will always be > empty and no Deflater returned, so could go the other way and remove > that cache if caching Deflaters isn't useful. Yes I would leave this for now, make a note to look at this further and deal with it separate from this change Also in ZipFileSystem, I would instead of removing line 2115, I would either keep it and remove the other references to version() in writeLOC, or make the change in writeCEN so that the usage of version is consistent. Best Lance > > Otherwise looks good to me. > > /Claes > > On 2018-12-17 09:28, Langer, Christoph wrote: >> Hi, >> when working with jdk.zipfs, I found some opportunity for cleanups. I'd like to contribute this independently from my other thread regarding Posix permissions in zip files (http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056426.html). So, please help to review the cleanup. >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215472.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215472 >> Thanks >> Christoph Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From andy.herrick at oracle.com Mon Dec 17 22:39:37 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 17 Dec 2018 17:39:37 -0500 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: <29a40245-522b-85a5-2c84-47b4725821e5@oracle.com> On 12/17/2018 12:45 PM, Scott Palmer wrote: > I finally got to the point where I can play with this? > > I?m just using trial and error, trying to figure out what to do based > on the output of package --help and responding to error messages to > guide me. > > I?ve already used jlink to create a runtime (including JavaFX) that I > want to use with my non-modular application. ?I?ve put a bunch of > files that my application requires in an ?app? folder > > /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/bin/jpackage > create-installer --input?/Users/scott/dev/AdminApp/build/image/app, > --runtime-image?/Users/scott/dev/AdminApp/build/image/runtime > --output?/Users/scott/dev/AdminApp/build/installer > --build-root?/Users/scott/dev/AdminApp/build/tmpInst --name "Server > Admin" > --main-jar?/Users/scott/dev/AdminApp/build/libs/AdminApp-1.0.4.jar??class?my.company.serveradmin.ServerAdminApp > > > Bundler Mac App Store Ready Bundler skipped because of a configuration > problem: java.lang.RuntimeException:?File > /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does > not belong to?/Users/scott/dev/AdminApp/build/image/app > Bundler DMG Installer skipped because of a configuration problem: > java.lang.RuntimeException: > File?/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods > does not belong to?/Users/scott/dev/AdminApp/build/image/app > Bundler PKG Installer skipped because of a configuration problem: > java.lang.RuntimeException: > File?/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods > does not belong to?/Users/scott/dev/AdminApp/build/image/app > OK - I can now get this error when specifying an absolute path to the main jar (even if it is within the input dir). I will fix this messaging. > > I don?t understand the error message. ?What is it complaining about? > > I figured out that I was using the wrong value for the --main-jar .. I > needed the name relative to my input folder, so I changed that and it > produced output, but the error message I got above was not at all helpful. > > Then I looked at the directory structure of the application bundle. > ?My input directory looked like > > app/ > ? ?libs/ > ? ? ? > > But the ?libs? subfolder was missing from the produced bundle. All the > jars that were in it were placed directly in the ?Java? folder of the > app bundle. > > So then I added a README.txt file under /app as a sibling of the libs > folder. ?That caused the bundled structure to match what I had, with a > README.txt and ?libs? folder containing all my jars, all located in > the ?Java? folder of the application bundle. > I think that inconsistent layout should be corrected. > > It would be good to document what is expected in the input directory, > ?how those files are used, and where they end up in the output > directory. ?--icon says it takes the icon file name (not a path), but > I don?t want to install the icon file as a separate discrete file in > my application, so where is it looking for it? This is wrong in the help output - will fix. the value of the --icon option is a path, either absolute or relative to the working directory jpackage is run from.? It need not be in the --input dir, or listed in the --files option. /Andy > I complete example for each of the sample usages shown by "package > --help" would go a long way. > > > Scott > From stuart.marks at oracle.com Mon Dec 17 22:43:23 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 17 Dec 2018 14:43:23 -0800 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: References: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> <636451fa-45b8-1861-999a-c3fd3a26673c@oracle.com> Message-ID: Hi Kishor, No problem about the delay; I've certainly contributed to delays myself. And certainly I have an unbounded queue of things I'm working on myself at the moment. And no, it's not too late for this work! In the past, if you missed a JDK deadline, you might have to wait three years for the next major JDK release (one in which specification changes were allowed). In the new release cadence, the next "feature" release is only six months after the previous one, so effectively there is always the possibility to get changes into the "next" JDK. Looking forward to your draft. s'marks On 12/13/18 7:19 AM, Kishor Gollapalliwar wrote: > Hello Stuart, > > Forgive me for delayed response. > I was not well for a week, due to which lot of work got queued up in office. > It took a while to sort it out. > > Your guidance was really helpful. > And by end of this week I'll share first patch, containing document > enhancements for SortedSet class. > > Hope I'm not too late. > > Thanks, > Kishor Gollapalliwar > > On Fri 30 Nov, 2018, 10:22 Stuart Marks wrote: > > On 11/1/18 8:12 PM, Kishor Gollapalliwar wrote: > > Thank you for providing this opportunity. I'm up for this challenge and I'd > > love to take this task. The only huddle would be, how to proceed, ie > planning > > things step by step, as this is my first time. If you can help me with the > > planning, I'll do the rest and fix these issues. > > Hi, sorry for the delay. I had a couple conferences and then some vacation. > > This issue comes up periodically. Consider this Stack Overflow question > and this > answer in particular: > > https://stackoverflow.com/a/53375284/1441122 > > It quotes the relevant part of the TreeSet spec (which is also in the > SortedSet > interface): > > > Note that the ordering maintained by a sorted set (whether or not an > explicit > > comparator is provided) must be consistent with equals if the sorted set is > > to correctly implement the Set interface. (See the Comparable interface or > > Comparator interface for a precise definition of consistent with equals.) > > This is so because the Set interface is defined in terms of the equals > > operation, but a sorted set performs all element comparisons using its > > compareTo (or compare) method, so two elements that are deemed equal by this > > method are, from the standpoint of the sorted set, equal. The behavior of a > > sorted set is well-defined even if its ordering is inconsistent with equals; > > it just fails to obey the general contract of the Set interface. > > What's missing here are 1) a clear statement that membership in a > SortedSet is > determined by the comparison method, and 2) a crisp definition of "comparison > method". > > Various places in the spec mention something like "the Comparator's compare() > method, if there is a comparator method, otherwise the compareTo() method > if the > set is using the elements' natural order...." The term "comparison method" > should be defined early on so that it can be used in later parts of the spec, > avoiding the comparator/natural-order awkwardness. > > Then, it should be specified that the comparison method 1) determines > membership > in the set as well as 2) ordering of set iteration, subsetting, etc. This > overlaps some with the first two paragraphs of the SortedSet class spec. > > Regarding membership, the Set interface says: > > > sets contain no pair of elements e1 and e2 such that e1.equals(e2) > > SortedSet should have something similar, e.g., > > > SortedSets contain no pair of elements e1 and e2 such that e1 CMP e2 == 0 > > where "CMP" is the "comparison method". (You don't have to use this notation, > but the idea is that there is no pair of elements in the set for which the > comparison method returns zero.) > > Only at this point should the "consistent with equals" discussion be > introduced. > The problem with the existing text is that it introduces the "consistent with > equals" topic, and then only incidentally mentions that set membership is > determined by "equality" according to the comparison method instead of > equals(). > > That's the first step, which basically amounts to rewriting the first three > paragraphs of the SortedSet class specification. The subsequent steps are: > > 2) Reconcile class doc of SortedSet subtypes, e.g. NavigableSet, TreeSet, > possibly ConcurrentSkipListSet. > > 3) Audit all method specs of all classes and reconcile them with the class > specs. A starting point for methods to look at is in this bug: > > https://bugs.openjdk.java.net/browse/JDK-8190545 > > 4) 5) 6) Similar steps as above for the SortedMap family. > > ** > > I'd suggest just starting off with the first step instead of trying to do > it all > at once. Don't worry about posting webrevs or specdiffs yet; just send a > patch > or even plain text of the draft to the list and I'll start reviewing it. > > Thanks, > > s'marks > From andrewluotechnologies at outlook.com Tue Dec 18 00:12:00 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 18 Dec 2018 00:12:00 +0000 Subject: Adding Path-based constructors to various classes Message-ID: Many classes such as: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html have constructors that use the File API or String but no constructor that takes Path. Is there any interest in adding these? The reason I ask this is because we now encourage new code to use Path instead of File, so having to do .toFile() in many places can seems unnecessary. Then again, this is a minor annoyance, but I think it is a useful addition. What do you guys think? Thanks, -Andrew From david.holmes at oracle.com Tue Dec 18 00:39:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 10:39:34 +1000 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> Message-ID: <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: > On 12/11/18 4:03 AM, David Holmes wrote: >> Hi Dmitry, >> >> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>> Hello, >>> >>> Please review a small fix in java_md_solinux.c: continuation is not >>> truly compatible with pthread_create start_routine's signature but we >>> control what actually happens. So it makes sense to add intermediate >>> void* cast to silence the error. >> >> I'd be tempted to fix the signature and get rid of all the casts. > > David, the signature is a signature of > > int JNICALL JavaMain(void * _args) > > It would be fun to change it. But still on Windows it is correctly > passed to _beginthreadex() and then return code is extracted with > GetExitCodeThread(). In case we want it to return void* the cast will > move there. I think the current double cast is truly ugly and an ifdef for windows, or a cast for Windows only would be an improvement. But I won't impose that on you just to silence gcc 8. Cheers, David > -Dmitry > >> >> Cheers, >> David >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>> testing: submit repo >>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>> >>> -Dmitry >>> From brian.burkhalter at oracle.com Tue Dec 18 00:47:17 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 17 Dec 2018 16:47:17 -0800 Subject: Adding Path-based constructors to various classes In-Reply-To: References: Message-ID: (looping in nio-dev) Hi Andrew, The NIO APIs (Java 1.4) were intended to supplement the pre-existing Java I/O APIs and this effort was continued in the NIO.2 APIs (Java 7). The Path interface is part of the latter. My impression is that the intent was more to supersede the older APIs than to enhance them to coexist better with the new ones. The addition for example of the constructors you suggest therefore would not be encouraged despite the convenience they might afford in some situations. There are others on these mailing lists however who know the historical context of this area better than I do and who I expect will chime in with a better answer. Thanks, Brian > On Dec 17, 2018, at 4:12 PM, Andrew Luo wrote: > > Many classes such as: > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html > > have constructors that use the File API or String but no constructor that takes Path. Is there any interest in adding these? The reason I ask this is because we now encourage new code to use Path instead of File, so having to do .toFile() in many places can seems unnecessary. Then again, this is a minor annoyance, but I think it is a useful addition. What do you guys think? From andrewluotechnologies at outlook.com Tue Dec 18 00:56:59 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 18 Dec 2018 00:56:59 +0000 Subject: Adding Path-based constructors to various classes In-Reply-To: References: Message-ID: Hi Brian, Thanks for your thoughts on this. I agree that if a class is superseded by a newer NIO.2 class with Path APIs, we should not add the Path-based APIs to the older class, but I do not believe there are NIO.2 replacements that supersede ZipFile. I also don't believe that there are any NIO.2 APIs that supersede RandomAccessFile either, but I could be wrong. Thanks, -Andrew From: Brian Burkhalter Sent: Monday, December 17, 2018 4:47 PM To: Andrew Luo ; nio-dev Cc: Core-Libs-Dev Subject: Re: Adding Path-based constructors to various classes (looping in nio-dev) Hi Andrew, The NIO APIs (Java 1.4) were intended to supplement the pre-existing Java I/O APIs and this effort was continued in the NIO.2 APIs (Java 7). The Path interface is part of the latter. My impression is that the intent was more to supersede the older APIs than to enhance them to coexist better with the new ones. The addition for example of the constructors you suggest therefore would not be encouraged despite the convenience they might afford in some situations. There are others on these mailing lists however who know the historical context of this area better than I do and who I expect will chime in with a better answer. Thanks, Brian On Dec 17, 2018, at 4:12 PM, Andrew Luo > wrote: Many classes such as: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html have constructors that use the File API or String but no constructor that takes Path. Is there any interest in adding these? The reason I ask this is because we now encourage new code to use Path instead of File, so having to do .toFile() in many places can seems unnecessary. Then again, this is a minor annoyance, but I think it is a useful addition. What do you guys think? From brian.burkhalter at oracle.com Tue Dec 18 01:00:28 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 17 Dec 2018 17:00:28 -0800 Subject: Adding Path-based constructors to various classes In-Reply-To: References: Message-ID: <9B8DC831-8468-4782-AA9C-CF4EE1CF0067@oracle.com> Hi Andrew, java.nio.channels.FileChannel pretty much covers RandomAccessFile, I think. The ZipFile case is something else, not really in I/O. Thanks, Brian > On Dec 17, 2018, at 4:56 PM, Andrew Luo wrote: > > Hi Brian, > > Thanks for your thoughts on this. I agree that if a class is superseded by a newer NIO.2 class with Path APIs, we should not add the Path-based APIs to the older class, but I do not believe there are NIO.2 replacements that supersede ZipFile. I also don?t believe that there are any NIO.2 APIs that supersede RandomAccessFile either, but I could be wrong. > > Thanks, > > -Andrew > > From: Brian Burkhalter > > Sent: Monday, December 17, 2018 4:47 PM > To: Andrew Luo >; nio-dev > > Cc: Core-Libs-Dev > > Subject: Re: Adding Path-based constructors to various classes > > (looping in nio-dev) > > Hi Andrew, > > The NIO APIs (Java 1.4) were intended to supplement the pre-existing Java I/O APIs and this effort was continued in the NIO.2 APIs (Java 7). The Path interface is part of the latter. My impression is that the intent was more to supersede the older APIs than to enhance them to coexist better with the new ones. The addition for example of the constructors you suggest therefore would not be encouraged despite the convenience they might afford in some situations. There are others on these mailing lists however who know the historical context of this area better than I do and who I expect will chime in with a better answer. > > Thanks, > > Brian > > > On Dec 17, 2018, at 4:12 PM, Andrew Luo > wrote: > > Many classes such as: > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html > > have constructors that use the File API or String but no constructor that takes Path. Is there any interest in adding these? The reason I ask this is because we now encourage new code to use Path instead of File, so having to do .toFile() in many places can seems unnecessary. Then again, this is a minor annoyance, but I think it is a useful addition. What do you guys think? From kishor.gollapalliwar at gmail.com Tue Dec 18 02:47:54 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Tue, 18 Dec 2018 08:17:54 +0530 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: References: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> <636451fa-45b8-1861-999a-c3fd3a26673c@oracle.com> Message-ID: Hello Stuart, Kindly find the diff file attached for your reference. Request you to review and provide your feedback. Once we finalize SortedSet, I'll start to enhance TreeSet documentation. Thank you, Kishor Gollapalliwar On Tue, Dec 18, 2018 at 4:13 AM Stuart Marks wrote: > Hi Kishor, > > No problem about the delay; I've certainly contributed to delays myself. > And certainly I have an unbounded queue of things I'm working on myself at > the moment. > > And no, it's not too late for this work! In the past, if you missed a JDK > deadline, you might have to wait three years for the next major JDK release > (one in which specification changes were allowed). In the new release > cadence, the next "feature" release is only six months after the previous > one, so effectively there is always the possibility to get changes into the > "next" JDK. > > Looking forward to your draft. > > s'marks > > > On 12/13/18 7:19 AM, Kishor Gollapalliwar wrote: > > Hello Stuart, > > Forgive me for delayed response. > I was not well for a week, due to which lot of work got queued up in > office. It took a while to sort it out. > > Your guidance was really helpful. > And by end of this week I'll share first patch, containing document > enhancements for SortedSet class. > > Hope I'm not too late. > > Thanks, > Kishor Gollapalliwar > > On Fri 30 Nov, 2018, 10:22 Stuart Marks >> On 11/1/18 8:12 PM, Kishor Gollapalliwar wrote: >> > Thank you for providing this opportunity. I'm up for this challenge and >> I'd >> > love to take this task. The only huddle would be, how to proceed, ie >> planning >> > things step by step, as this is my first time. If you can help me with >> the >> > planning, I'll do the rest and fix these issues. >> >> Hi, sorry for the delay. I had a couple conferences and then some >> vacation. >> >> This issue comes up periodically. Consider this Stack Overflow question >> and this >> answer in particular: >> >> https://stackoverflow.com/a/53375284/1441122 >> >> It quotes the relevant part of the TreeSet spec (which is also in the >> SortedSet >> interface): >> >> > Note that the ordering maintained by a sorted set (whether or not an >> explicit >> > comparator is provided) must be consistent with equals if the sorted >> set is >> > to correctly implement the Set interface. (See the Comparable interface >> or >> > Comparator interface for a precise definition of consistent with >> equals.) >> > This is so because the Set interface is defined in terms of the equals >> > operation, but a sorted set performs all element comparisons using its >> > compareTo (or compare) method, so two elements that are deemed equal by >> this >> > method are, from the standpoint of the sorted set, equal. The behavior >> of a >> > sorted set is well-defined even if its ordering is inconsistent with >> equals; >> > it just fails to obey the general contract of the Set interface. >> >> What's missing here are 1) a clear statement that membership in a >> SortedSet is >> determined by the comparison method, and 2) a crisp definition of >> "comparison >> method". >> >> Various places in the spec mention something like "the Comparator's >> compare() >> method, if there is a comparator method, otherwise the compareTo() method >> if the >> set is using the elements' natural order...." The term "comparison >> method" >> should be defined early on so that it can be used in later parts of the >> spec, >> avoiding the comparator/natural-order awkwardness. >> >> Then, it should be specified that the comparison method 1) determines >> membership >> in the set as well as 2) ordering of set iteration, subsetting, etc. This >> overlaps some with the first two paragraphs of the SortedSet class spec. >> >> Regarding membership, the Set interface says: >> >> > sets contain no pair of elements e1 and e2 such that e1.equals(e2) >> >> SortedSet should have something similar, e.g., >> >> > SortedSets contain no pair of elements e1 and e2 such that e1 CMP e2 == >> 0 >> >> where "CMP" is the "comparison method". (You don't have to use this >> notation, >> but the idea is that there is no pair of elements in the set for which >> the >> comparison method returns zero.) >> >> Only at this point should the "consistent with equals" discussion be >> introduced. >> The problem with the existing text is that it introduces the "consistent >> with >> equals" topic, and then only incidentally mentions that set membership is >> determined by "equality" according to the comparison method instead of >> equals(). >> >> That's the first step, which basically amounts to rewriting the first >> three >> paragraphs of the SortedSet class specification. The subsequent steps are: >> >> 2) Reconcile class doc of SortedSet subtypes, e.g. NavigableSet, TreeSet, >> possibly ConcurrentSkipListSet. >> >> 3) Audit all method specs of all classes and reconcile them with the >> class >> specs. A starting point for methods to look at is in this bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8190545 >> >> 4) 5) 6) Similar steps as above for the SortedMap family. >> >> ** >> >> I'd suggest just starting off with the first step instead of trying to do >> it all >> at once. Don't worry about posting webrevs or specdiffs yet; just send a >> patch >> or even plain text of the draft to the list and I'll start reviewing it. >> >> Thanks, >> >> s'marks >> > -- Thanks & Regards, *Kishor Golapelliwar,* The ability to convert ideas to things is the secret to outward success. -------------- next part -------------- A non-text attachment was scrubbed... Name: SortedSet.diff Type: text/x-patch Size: 3626 bytes Desc: not available URL: From priya.lakshmi.muthuswamy at oracle.com Tue Dec 18 05:23:53 2018 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 18 Dec 2018 10:53:53 +0530 Subject: RFR: 8214570 : Use {@systemProperty} for definitions of system properties Message-ID: <2af2f47c-2f22-2c6e-b8ee-65226a6e0e70@oracle.com> Hi, Kindly review the changes for https://bugs.openjdk.java.net/browse/JDK-8214570 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8214570/webrev.00/ Thanks, Priya From philipp.kunz at paratix.ch Tue Dec 18 06:15:37 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 18 Dec 2018 07:15:37 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> Message-ID: <1545113737.2502.8.camel@paratix.ch> Thanks for pointing out about ISC. I replaced it with StringBuilders but now I don't know with what capacity to initialize. Also the previous code does not reveal a conscious choice about the buffer capacity. So I?arbitrarily chose 72 as an initial capacity which is one line. Any suggestions? Ideally I would have preferred to use the same single StringBuilder for writing the whole Manifest but it cannot be easily passed from one method to another down the stack because adding it as a parameter to existing methods would change API not absolutely hidden (just like for example make72Safe only deprecated rather than removed). Otherwise I would probably have also replaced DataOutputStream with a custom one somewhat similar to Manifest.FastInputStream that counts bytes and adds line breaks accordingly which would make String concatenation completely redundant. The main intention is still to resolve the deprecation and hence I figure it might be good enough if the result is at least as good as the previous version. Does that convince or make any sense? Find another patch attached. On Mon, 2018-12-17 at 08:06 +0100, Claes Redestad wrote: > On 2018-12-17 07:42, Philipp Kunz wrote: > > I did deliberately not touch the StringBuffer in the previous patch > > but > > fully agree now I know it has a chance to be accepted. Would you > > accept > > to replace StringBuffer with plain string concatenation afterhttp:/ > > /op > > enjdk.java.net/jeps/280 which was not in place at the time those > > StringBuffers were introduced? > > Unfortunately JEP 280-style indified string concatenation is not > enabled > in the java.base module to avoid bootstrap issues. > > That said, even if you could benefit from ISC here, StringBuilders > are > likely to be better when building up your string using loops and > method > calls, unless there's a simple way to reduce it all down to a single > concatenation expression (no passing the builder to another method, > no > loops etc). > > /Claes -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 30857 bytes Desc: not available URL: From philipp.kunz at paratix.ch Tue Dec 18 07:15:02 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 18 Dec 2018 08:15:02 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> Message-ID: <1545117302.2502.10.camel@paratix.ch> Thanks. Find a new patch attached. On Mon, 2018-12-17 at 12:12 -0500, Roger Riggs wrote: > ????Hi Philipp, > > ???? > > ????Manifest.java: > > ???? > > ?????- Line 258: creating a new array for two characters on each call > ????isn't as efficient as: > > ??????? out.write('\r');? > > ??????? out.write('\n'). > > ???? > > ????The new test that need internal access can gain that access by > ????adding: > > ?????? @modules java.base/java.util.jar:+open > > ???? > > ????That instructs testng to add the correct command line switches. > > ????Then you can remove --illegal-access=warn and the tests will > work. > > ???? > > ??????? > > ????In the test ValueUtf8Coding, just a mention of a method to create > a > ????string with repeats. > > ???????? "-".repeat(80); -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 30775 bytes Desc: not available URL: From Alan.Bateman at oracle.com Tue Dec 18 07:21:46 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Dec 2018 07:21:46 +0000 Subject: RFR: 8214570 : Use {@systemProperty} for definitions of system properties In-Reply-To: <2af2f47c-2f22-2c6e-b8ee-65226a6e0e70@oracle.com> References: <2af2f47c-2f22-2c6e-b8ee-65226a6e0e70@oracle.com> Message-ID: <85116d83-7d73-4fbe-fa17-f9f0ab729d87@oracle.com> This looks okay to me (cc'ing security-dev as that is where the smart card I/O API is maintained) On 18/12/2018 05:23, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review the changes for > https://bugs.openjdk.java.net/browse/JDK-8214570 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8214570/webrev.00/ > > Thanks, > Priya > > From ivan.gerasimov at oracle.com Tue Dec 18 10:42:21 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 18 Dec 2018 02:42:21 -0800 Subject: RFR 6996807 : FieldReflectorKey hash code computation can be improved Message-ID: <489a4621-b763-8d8e-f4d0-4d611eb4f196@oracle.com> Hello! FieldReflectorKey class contains a combined-string representation of the fields (their names and signatures). This string is used for calculating the hash code and comparing two FieldReflectorKey objects for equality, which is expensive. It is proposed to store the names and signatures (which are likely to be interned) in an array an use this array for both tasks utilizing Arrays.hashCode() and Arrays.equals(). BUGURL: https://bugs.openjdk.java.net/browse/JDK-6996807 WEBREV: http://cr.openjdk.java.net/~igerasim/6996807/00/webrev/ Would you please help review the fix? -- With kind regards, Ivan Gerasimov From christoph.langer at sap.com Tue Dec 18 13:44:56 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Dec 2018 13:44:56 +0000 Subject: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests In-Reply-To: <247E396D-3C1B-4C4C-897D-54A749AEB6D6@oracle.com> References: <247E396D-3C1B-4C4C-897D-54A749AEB6D6@oracle.com> Message-ID: <846e3c3c8a3546379c00103f08a1b8a6@sap.com> Hi Claes, Hi Lance, thanks for reviewing my patch. > I believe the convention in the OpenJDK sources is to sort static > imports after non-static, so changing to the other way around in a few > places adds inconsistencies. I was unaware of this but it seems that's the way most files are structured (though you'll find exceptions from that rule). I adapted my change. > In ZipFileSystem you remove the unused method releaseDeflater - to me > this indicates the resource pooling is actually broken? I.e., shouldn't > EntryOutputStreamDef return its Deflater to the cache when it's closed, > similar to how the anonymous InflaterInputStream in getInputStream does > it? As it's currently implemented the deflaters list will always be > empty and no Deflater returned, so could go the other way and remove > that cache if caching Deflaters isn't useful. You are right. I think this is a flaw of the change for 8034802 [1] [2]. I added the call to releaseDeflater() in the close method of EntryOutputStreamDef. > Also in ZipFileSystem, ?I would instead of removing line 2115, I would either > keep it and remove the other references to version() in writeLOC, or make > the change in ?writeCEN so that the usage of version is consistent. Good catch, I've updated this for consistency. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215472.1/ Are you good with it? I'll run jtreg tests before pushing... Thanks Christoph [1] http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5 [2] https://bugs.openjdk.java.net/browse/JDK-8034802 From daniel.fuchs at oracle.com Tue Dec 18 14:57:46 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 18 Dec 2018 15:57:46 +0100 Subject: RFR: 8213402: [Testbug] java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates an invalid nest relationship Message-ID: <4a1f312f-33e2-30b6-46af-c995b533b283@oracle.com> Hi, Please find below a fix for: 8213402: [Testbug] java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates an invalid nest relationship https://bugs.openjdk.java.net/browse/JDK-8213402 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8213402/webrev.01/ These tests use a CustomSystemClassLoader to load custom LoggerFinder subclasses so that they can assign them special privileges. But because these sub classes are static inner classes of the main test class it creates an invalid nest relationship for the nestmates implementation in project valhalla. The fix is very simple: I have refactored the tests to extract the custom LoggerFinder classes as top level classes. I have verified that the modified test pass in the nestmates branch of valhalla repo - where it used to fail. best regards, -- daniel From jonathan.gibbons at oracle.com Tue Dec 18 15:17:47 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 18 Dec 2018 07:17:47 -0800 Subject: Adding Path-based constructors to various classes In-Reply-To: <9B8DC831-8468-4782-AA9C-CF4EE1CF0067@oracle.com> References: <9B8DC831-8468-4782-AA9C-CF4EE1CF0067@oracle.com> Message-ID: <61b98500-a7e4-b9b4-b1e7-105aef6e91cc@oracle.com> Zip files are now accessible through the zipfs NIO FileSystem provider. -- Jon On 12/17/18 5:00 PM, Brian Burkhalter wrote: > Hi Andrew, > > java.nio.channels.FileChannel pretty much covers RandomAccessFile, I think. The ZipFile case is something else, not really in I/O. > > Thanks, > > Brian > >> On Dec 17, 2018, at 4:56 PM, Andrew Luo wrote: >> >> Hi Brian, >> >> Thanks for your thoughts on this. I agree that if a class is superseded by a newer NIO.2 class with Path APIs, we should not add the Path-based APIs to the older class, but I do not believe there are NIO.2 replacements that supersede ZipFile. I also don?t believe that there are any NIO.2 APIs that supersede RandomAccessFile either, but I could be wrong. >> >> Thanks, >> >> -Andrew >> >> From: Brian Burkhalter > >> Sent: Monday, December 17, 2018 4:47 PM >> To: Andrew Luo >; nio-dev > >> Cc: Core-Libs-Dev > >> Subject: Re: Adding Path-based constructors to various classes >> >> (looping in nio-dev) >> >> Hi Andrew, >> >> The NIO APIs (Java 1.4) were intended to supplement the pre-existing Java I/O APIs and this effort was continued in the NIO.2 APIs (Java 7). The Path interface is part of the latter. My impression is that the intent was more to supersede the older APIs than to enhance them to coexist better with the new ones. The addition for example of the constructors you suggest therefore would not be encouraged despite the convenience they might afford in some situations. There are others on these mailing lists however who know the historical context of this area better than I do and who I expect will chime in with a better answer. >> >> Thanks, >> >> Brian >> >> >> On Dec 17, 2018, at 4:12 PM, Andrew Luo > wrote: >> >> Many classes such as: >> >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html >> >> have constructors that use the File API or String but no constructor that takes Path. Is there any interest in adding these? The reason I ask this is because we now encourage new code to use Path instead of File, so having to do .toFile() in many places can seems unnecessary. Then again, this is a minor annoyance, but I think it is a useful addition. What do you guys think? From Roger.Riggs at oracle.com Tue Dec 18 15:38:01 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2018 10:38:01 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <1545117302.2502.10.camel@paratix.ch> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> Message-ID: Hi Philipp, I'm satisfied with this update. BTW, your workspace may be a bit out of date, the patch did not merge without warnings. For convenience of other reviewers, here a webrev: ?http://cr.openjdk.java.net/~rriggs/webrev-8066619-3.patch/ Thanks, Roger On 12/18/2018 02:15 AM, Philipp Kunz wrote: > Thanks. Find a new patch attached. > > On Mon, 2018-12-17 at 12:12 -0500, Roger Riggs wrote: >> Hi Philipp, >> >> Manifest.java: >> >> ?- Line 258: creating a new array for two characters on each call >> isn't as efficient as: >> ??? out.write('\r'); >> ??? out.write('\n'). >> >> The new test that need internal access can gain that access by adding: >> ?? @modules java.base/java.util.jar:+open >> >> That instructs testng to add the correct command line switches. >> Then you can remove --illegal-access=warn and the tests will work. >> >> >> In the test ValueUtf8Coding, just a mention of a method to create a >> string with repeats. >> ???? "-".repeat(80); >> From kasperni at gmail.com Tue Dec 18 15:49:01 2018 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 18 Dec 2018 16:49:01 +0100 Subject: Adding Path-based constructors to various classes In-Reply-To: References: Message-ID: Hi, I don't know if it makes sense at this time. But if File and Path had both implemented CharSequence. We could just accept a CharSequence for every method that needs a path/file. Allowing to parse along either a File, Path or String. I've have done myself in some APIs that uses tree-based structures. Where I had a generic TreePath interface extending CharSequence. And then every method operating on a path would just receive a CharSequence path. Accepting both Strings and Treepaths. /Kasper On Tue, 18 Dec 2018 at 01:47, Brian Burkhalter wrote: > (looping in nio-dev) > > Hi Andrew, > > The NIO APIs (Java 1.4) were intended to supplement the pre-existing Java > I/O APIs and this effort was continued in the NIO.2 APIs (Java 7). The Path > interface is part of the latter. My impression is that the intent was more > to supersede the older APIs than to enhance them to coexist better with the > new ones. The addition for example of the constructors you suggest > therefore would not be encouraged despite the convenience they might afford > in some situations. There are others on these mailing lists however who > know the historical context of this area better than I do and who I expect > will chime in with a better answer. > > Thanks, > > Brian > > > On Dec 17, 2018, at 4:12 PM, Andrew Luo < > andrewluotechnologies at outlook.com> wrote: > > > > Many classes such as: > > > > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html > < > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html > > > > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html > < > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html > > > > > > have constructors that use the File API or String but no constructor > that takes Path. Is there any interest in adding these? The reason I ask > this is because we now encourage new code to use Path instead of File, so > having to do .toFile() in many places can seems unnecessary. Then again, > this is a minor annoyance, but I think it is a useful addition. What do > you guys think? > > From dmitry.chuyko at bell-sw.com Tue Dec 18 15:56:44 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 18 Dec 2018 18:56:44 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> Message-ID: <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> On 12/18/18 3:39 AM, David Holmes wrote: > On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >> On 12/11/18 4:03 AM, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>> Hello, >>>> >>>> Please review a small fix in java_md_solinux.c: continuation is not >>>> truly compatible with pthread_create start_routine's signature but >>>> we control what actually happens. So it makes sense to add >>>> intermediate void* cast to silence the error. >>> >>> I'd be tempted to fix the signature and get rid of all the casts. >> >> David, the signature is a signature of >> >> int JNICALL JavaMain(void * _args) >> >> It would be fun to change it. But still on Windows it is correctly >> passed to _beginthreadex() and then return code is extracted with >> GetExitCodeThread(). In case we want it to return void* the cast will >> move there. > > I think the current double cast is truly ugly and an ifdef for > windows, or a cast for Windows only would be an improvement. I agree. Maybe making a wrapper function is not so ugly. If there are no objections to changing beginning of the call stack it is quite easy to implement. For consistency it may be done for all 3 points (posix unix, posix mac, windows) or just for posix ones. It looks like ifdef should be better as long as there are already OS-specific parts in libjli. Again, if there are no objections to have different JavaMain signatures on different platforms. In this case there won't be a signature cast for Windows. -Dmitry > > But I won't impose that on you just to silence gcc 8. > > Cheers, > David > >> -Dmitry >> >>> >>> Cheers, >>> David >>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>> testing: submit repo >>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>> >>>> -Dmitry >>>> From GROEGES at uk.ibm.com Tue Dec 18 16:44:15 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Tue, 18 Dec 2018 16:44:15 +0000 Subject: Proposal: ArrayList constructor perforrmance improvement Message-ID: Hi all, I am proposing an enhancement to ArrayList.java to improve its performance. ArrayList has a constructor which takes an arbitrary Collection as a parameter. This constructor will create an iterator over the collection and it will add each entry returned to the ArrayList. We have found that quite a lot of the time the object passed as a parameter is in fact an instance of ArrayList. In the case of an ArrayList it is possible to significantly increase the performance of the method since there is no need for an iterator - the backing array can be directly copied. I would like to propose the following change: webrev: http://cr.openjdk.java.net/~sgroeger/perf/arraylist/webrev.00/ hg diff: diff -r 086dfcfc3731 src/java.base/share/classes/java/util/ArrayList.java --- a/src/java.base/share/classes/java/util/ArrayList.java Thu Dec 13 08:36:10 2018 +0100 +++ b/src/java.base/share/classes/java/util/ArrayList.java Tue Dec 18 11:35:22 2018 +0000 @@ -176,15 +176,21 @@ * @throws NullPointerException if the specified collection is null */ public ArrayList(Collection c) { - elementData = c.toArray(); - if ((size = elementData.length) != 0) { - // defend against c.toArray (incorrectly) not returning Object[] - // (see e.g. https://bugs.openjdk.java.net/browse/JDK-6260652 ) - if (elementData.getClass() != Object[].class) - elementData = Arrays.copyOf(elementData, size, Object[].class); + if (c instanceof ArrayList) { + elementData = new Object[((ArrayList)c).elementData.length]; + System.arraycopy(((ArrayList)c).elementData, 0, elementData, 0, ((ArrayList)c).elementData.length); + size = ((ArrayList)c).size; } else { - // replace with empty array. - this.elementData = EMPTY_ELEMENTDATA; + elementData = c.toArray(); + if ((size = elementData.length) != 0) { + // defend against c.toArray (incorrectly) not returning Object[] + // (see e.g. https://bugs.openjdk.java.net/browse/JDK-6260652) + if (elementData.getClass() != Object[].class) + elementData = Arrays.copyOf(elementData, size, Object[].class); + } else { + // replace with empty array. + this.elementData = EMPTY_ELEMENTDATA; + } } } due to the re-indentation the diff looks more complicated that it actually is, the the change just adds this: + if (c instanceof ArrayList) { + elementData = new Object[((ArrayList)c).elementData.length]; + System.arraycopy(((ArrayList)c).elementData, 0, elementData, 0, ((ArrayList)c).elementData.length); + size = ((ArrayList)c).size; I have a JMH test that tests the creation of a new ArrayList, using a separate ArrayList of different sizes then adds an items to the new ArrayList. http://cr.openjdk.java.net/~sgroeger/perf/arraylist/ArrayListBenchmark.java Test results from running the above JMH test are: With Oracle OpenJDK12 Without performance change Benchmark (size) Mode Cnt Score Error Units ArrayListBenchmark.construct_new_array_list 10 thrpt 25 388.212 ? 23.110 ops/s ArrayListBenchmark.construct_new_array_list 100 thrpt 25 90.208 ? 7.995 ops/s ArrayListBenchmark.construct_new_array_list 1000 thrpt 25 23.289 ? 1.687 ops/s ArrayListBenchmark.construct_new_array_list 10000 thrpt 25 7.659 ? 0.560 ops/s With performance change Benchmark (size) Mode Cnt Score Error Units ArrayListBenchmark.construct_new_array_list 10 thrpt 25 562.678 ? 37.370 ops/s ArrayListBenchmark.construct_new_array_list 100 thrpt 25 119.791 ? 13.232 ops/s ArrayListBenchmark.construct_new_array_list 1000 thrpt 25 33.811 ? 3.812 ops/s ArrayListBenchmark.construct_new_array_list 10000 thrpt 25 10.889 ? 0.564 ops/s Results of the JTReg test for jdk/java/util/ArayList are the same with and without the performance change. Any comments would be gratefully received. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mandy.chung at oracle.com Tue Dec 18 17:16:57 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Dec 2018 09:16:57 -0800 Subject: RFR: 8213402: [Testbug] java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates an invalid nest relationship In-Reply-To: <4a1f312f-33e2-30b6-46af-c995b533b283@oracle.com> References: <4a1f312f-33e2-30b6-46af-c995b533b283@oracle.com> Message-ID: <56e559ef-a859-4c0a-d679-c120f783db63@oracle.com> On 12/18/18 6:57 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8213402: [Testbug] > java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest > creates an invalid nest relationship > https://bugs.openjdk.java.net/browse/JDK-8213402 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8213402/webrev.01/ > Looks good to me.??? Thanks for cleaning up this test. Mandy From martinrb at google.com Tue Dec 18 17:23:38 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Dec 2018 09:23:38 -0800 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: Message-ID: This is no question that we can optimize the case of ArrayList -> ArrayList, but what about all the other Collection implementations? ArrayDeque and CopyOnWriteArrayList come to mind. ArrayList is a popular class to use for making copies of Collections. Where do you stop? A pathological subclass of ArrayList could decide to not store elements in the backing array, with ensuing breakage. The blessed solution to the list copy problem is probably List.copyOf https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/List.html#copyOf(java.util.Collection) which might do the optimization you're hoping for. On Tue, Dec 18, 2018 at 8:47 AM Steve Groeger wrote: > Hi all, > > I am proposing an enhancement to ArrayList.java to improve its > performance. > > ArrayList has a constructor which takes an arbitrary Collection as a > parameter. This constructor will create an iterator over the collection > and it will add each entry returned to the ArrayList. > > We have found that quite a lot of the time the object passed as a > parameter is in fact an instance of ArrayList. > In the case of an ArrayList it is possible to significantly increase the > performance of the method since there is no need for an iterator - the > backing array can be directly copied. > > I would like to propose the following change: > > webrev: > http://cr.openjdk.java.net/~sgroeger/perf/arraylist/webrev.00/ > > hg diff: > > diff -r 086dfcfc3731 src/java.base/share/classes/java/util/ArrayList.java > --- a/src/java.base/share/classes/java/util/ArrayList.java Thu Dec 13 > 08:36:10 2018 +0100 > +++ b/src/java.base/share/classes/java/util/ArrayList.java Tue Dec 18 > 11:35:22 2018 +0000 > @@ -176,15 +176,21 @@ > * @throws NullPointerException if the specified collection is null > */ > public ArrayList(Collection c) { > - elementData = c.toArray(); > - if ((size = elementData.length) != 0) { > - // defend against c.toArray (incorrectly) not returning > Object[] > - // (see e.g. https://bugs.openjdk.java.net/browse/JDK-6260652 > ) > - if (elementData.getClass() != Object[].class) > - elementData = Arrays.copyOf(elementData, size, > Object[].class); > + if (c instanceof ArrayList) { > + elementData = new Object[((ArrayList)c).elementData.length]; > + System.arraycopy(((ArrayList)c).elementData, 0, elementData, > 0, ((ArrayList)c).elementData.length); > + size = ((ArrayList)c).size; > } else { > - // replace with empty array. > - this.elementData = EMPTY_ELEMENTDATA; > + elementData = c.toArray(); > + if ((size = elementData.length) != 0) { > + // defend against c.toArray (incorrectly) not returning > Object[] > + // (see e.g. > https://bugs.openjdk.java.net/browse/JDK-6260652) > + if (elementData.getClass() != Object[].class) > + elementData = Arrays.copyOf(elementData, size, > Object[].class); > + } else { > + // replace with empty array. > + this.elementData = EMPTY_ELEMENTDATA; > + } > } > } > > due to the re-indentation the diff looks more complicated that it actually > is, the the change just adds this: > > + if (c instanceof ArrayList) { > + elementData = new Object[((ArrayList)c).elementData.length]; > + System.arraycopy(((ArrayList)c).elementData, 0, elementData, > 0, ((ArrayList)c).elementData.length); > + size = ((ArrayList)c).size; > > I have a JMH test that tests the creation of a new ArrayList, using a > separate ArrayList of different sizes then adds an items to the new > ArrayList. > http://cr.openjdk.java.net/~sgroeger/perf/arraylist/ArrayListBenchmark.java > > Test results from running the above JMH test are: > With Oracle OpenJDK12 > > Without performance change > Benchmark (size) Mode Cnt Score > Error Units > ArrayListBenchmark.construct_new_array_list 10 thrpt 25 388.212 ? > 23.110 ops/s > ArrayListBenchmark.construct_new_array_list 100 thrpt 25 90.208 ? > 7.995 ops/s > ArrayListBenchmark.construct_new_array_list 1000 thrpt 25 23.289 ? > 1.687 ops/s > ArrayListBenchmark.construct_new_array_list 10000 thrpt 25 7.659 ? > 0.560 ops/s > > With performance change > Benchmark (size) Mode Cnt Score > Error Units > ArrayListBenchmark.construct_new_array_list 10 thrpt 25 562.678 ? > 37.370 ops/s > ArrayListBenchmark.construct_new_array_list 100 thrpt 25 119.791 ? > 13.232 ops/s > ArrayListBenchmark.construct_new_array_list 1000 thrpt 25 33.811 ? > 3.812 ops/s > ArrayListBenchmark.construct_new_array_list 10000 thrpt 25 10.889 ? > 0.564 ops/s > > Results of the JTReg test for jdk/java/util/ArayList are the same with > and without the performance change. > > Any comments would be gratefully received. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > From Alan.Bateman at oracle.com Tue Dec 18 17:24:41 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Dec 2018 17:24:41 +0000 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: Message-ID: <1b5a7241-1864-dab4-f449-64c7dab4b909@oracle.com> On 18/12/2018 16:44, Steve Groeger wrote: > Hi all, > > I am proposing an enhancement to ArrayList.java to improve its > performance. > > ArrayList has a constructor which takes an arbitrary Collection as a > parameter. This constructor will create an iterator over the collection > and it will add each entry returned to the ArrayList. > > We have found that quite a lot of the time the object passed as a > parameter is in fact an instance of ArrayList. > In the case of an ArrayList it is possible to significantly increase the > performance of the method since there is no need for an iterator - the > backing array can be directly copied. > ArrayList is not final so it's possible someone has extended it to use something other than elementData. It might be safer to use the class identity rather than instanceof. -Alan From jason_mehrens at hotmail.com Tue Dec 18 17:58:16 2018 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 18 Dec 2018 17:58:16 +0000 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: Message-ID: Hi Steve, >ArrayList has a constructor which takes an arbitrary Collection as a >parameter. This constructor will create an iterator over the collection >;and it will add each entry returned to the ArrayList. >We have found that quite a lot of the time the object passed as a >parameter is in fact an instance of ArrayList. >In the case of an ArrayList it is possible to significantly increase the >performance of the method since there is no need for an iterator - the >backing array can be directly copied. Maybe I'm looking at a different version of the ArrayList source code but it seems that the ArrayList constructor calls c.toArray(). If the given Collection is an ArrayList then that will call the overridden ArrayList.toArray which directly copies the backing array once and doesn't create an iterator. I would assume that most collections provide an optimized toArray(). Jason From brian.burkhalter at oracle.com Tue Dec 18 18:03:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 18 Dec 2018 10:03:35 -0800 Subject: 8183912: java.math.BigDecimal.movePointLeft() should return this if called with zero argument Message-ID: <0756E49E-FCE9-4DBB-B3E1-7D4F67442F67@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8183912 For the patch included below, the JMH benchmark MovePointLeftZero attached to the above issue, when run with options "-f 1 -wi 5 -w 5 -i 10 -r 10" (one fork, five warmup iterations of five seconds each, ten measurement iterations of ten seconds each), shows an order of magnitude (10X) throughput improvement for a zero left shift. The effect on the positive left shift case appears to be at the level of measurement noise. Thanks, Brian --- a/src/java.base/share/classes/java/math/BigDecimal.java +++ b/src/java.base/share/classes/java/math/BigDecimal.java @@ -2871,6 +2871,8 @@ * @throws ArithmeticException if scale overflows. */ public BigDecimal movePointLeft(int n) { + if (n == 0) return this; + // Cannot use movePointRight(-n) in case of n==Integer.MIN_VALUE int newScale = checkScale((long)scale + n); BigDecimal num = new BigDecimal(intVal, intCompact, newScale, 0); @@ -2893,6 +2895,8 @@ * @throws ArithmeticException if scale overflows. */ public BigDecimal movePointRight(int n) { + if (n == 0) return this; + // Cannot use movePointLeft(-n) in case of n==Integer.MIN_VALUE int newScale = checkScale((long)scale - n); BigDecimal num = new BigDecimal(intVal, intCompact, newScale, 0); From Roger.Riggs at oracle.com Tue Dec 18 18:55:33 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2018 13:55:33 -0500 Subject: 8183912: java.math.BigDecimal.movePointLeft() should return this if called with zero argument In-Reply-To: <0756E49E-FCE9-4DBB-B3E1-7D4F67442F67@oracle.com> References: <0756E49E-FCE9-4DBB-B3E1-7D4F67442F67@oracle.com> Message-ID: <399ad211-5c17-e395-9e97-4a30ec15772a@oracle.com> +1, Hard to argue with +10x.? :) Roger On 12/18/2018 01:03 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8183912 > > For the patch included below, the JMH benchmark MovePointLeftZero attached to the above issue, when run with options "-f 1 -wi 5 -w 5 -i 10 -r 10" (one fork, five warmup iterations of five seconds each, ten measurement iterations of ten seconds each), shows an order of magnitude (10X) throughput improvement for a zero left shift. The effect on the positive left shift case appears to be at the level of measurement noise. > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/math/BigDecimal.java > +++ b/src/java.base/share/classes/java/math/BigDecimal.java > @@ -2871,6 +2871,8 @@ > * @throws ArithmeticException if scale overflows. > */ > public BigDecimal movePointLeft(int n) { > + if (n == 0) return this; > + > // Cannot use movePointRight(-n) in case of n==Integer.MIN_VALUE > int newScale = checkScale((long)scale + n); > BigDecimal num = new BigDecimal(intVal, intCompact, newScale, 0); > @@ -2893,6 +2895,8 @@ > * @throws ArithmeticException if scale overflows. > */ > public BigDecimal movePointRight(int n) { > + if (n == 0) return this; > + > // Cannot use movePointLeft(-n) in case of n==Integer.MIN_VALUE > int newScale = checkScale((long)scale - n); > BigDecimal num = new BigDecimal(intVal, intCompact, newScale, 0); > From swpalmer at gmail.com Tue Dec 18 19:45:03 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 18 Dec 2018 14:45:03 -0500 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: Message-ID: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> > On Dec 18, 2018, at 12:58 PM, Jason Mehrens wrote: > > Hi Steve, > >> ArrayList has a constructor which takes an arbitrary Collection as a >> parameter. This constructor will create an iterator over the collection >> ;and it will add each entry returned to the ArrayList. > >> We have found that quite a lot of the time the object passed as a >> parameter is in fact an instance of ArrayList. > >> In the case of an ArrayList it is possible to significantly increase the >> performance of the method since there is no need for an iterator - the >> backing array can be directly copied. > > Maybe I'm looking at a different version of the ArrayList source code but it seems that the ArrayList constructor calls c.toArray(). If the given Collection is an ArrayList then that will call the overridden ArrayList.toArray which directly copies the backing array once and doesn't create an iterator. I would assume that most collections provide an optimized toArray(). > > Jason That makes sense, but the benchmarks show a notable improvement. It is worth taking a closer look to see what is going on to account for that. toArray uses: Arrays.copyOf(elementData, size); which *should* be faster than: elementData = new Object[((ArrayList)c).elementData.length]; System.arraycopy(((ArrayList)c).elementData, 0, elementData, 0, ((ArrayList)c).elementData.length); I say should be faster, because, unlike ?new?, internally it think it is an intrinsic that is able to get away with not zeroing the destination array prior to copying. Otherwise it is basically the same implementation, with a test to choose between new or Array.newInstance for creating the array. I wouldn?t think that test could account for the performance difference, but that?s why it needs a closer look IMO. Scott From lance.andersen at oracle.com Tue Dec 18 21:10:34 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 18 Dec 2018 16:10:34 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> Message-ID: <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> Hi Philipp, A question as to why for tests such as: ??????? @Test public void testMainAttributesHeaderNameEmpty() throws Exception { Manifest mf = new Manifest(); mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0"); mf.getMainAttributes().put(EMPTY_NAME, SOME_VALUE); try { mf = writeAndRead(mf); fail(); } catch ( /* out: */ IOException e) { return; // ok, was always like this } } ?????????? Is there a reason you did not use @Test(expectedExceptions = IOException.class) It just seems to make the test a bit more readable Best Lance > On Dec 18, 2018, at 10:38 AM, Roger Riggs wrote: > > Hi Philipp, > > I'm satisfied with this update. > > BTW, your workspace may be a bit out of date, the patch did not merge without warnings. > > For convenience of other reviewers, here a webrev: > http://cr.openjdk.java.net/~rriggs/webrev-8066619-3.patch/ > > Thanks, Roger > > > On 12/18/2018 02:15 AM, Philipp Kunz wrote: >> Thanks. Find a new patch attached. >> >> On Mon, 2018-12-17 at 12:12 -0500, Roger Riggs wrote: >>> Hi Philipp, >>> >>> Manifest.java: >>> >>> - Line 258: creating a new array for two characters on each call isn't as efficient as: >>> out.write('\r'); >>> out.write('\n'). >>> >>> The new test that need internal access can gain that access by adding: >>> @modules java.base/java.util.jar:+open >>> >>> That instructs testng to add the correct command line switches. >>> Then you can remove --illegal-access=warn and the tests will work. >>> >>> >>> In the test ValueUtf8Coding, just a mention of a method to create a string with repeats. >>> "-".repeat(80); >>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Tue Dec 18 21:29:11 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Dec 2018 13:29:11 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> Message-ID: We have changes in jsr166 CVS ready for going into openjdk https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/HashMap-resize/index.html (except for the microbenchmark, which doesn't fit into our pipeline at the moment). Pardon the fiddling ... --- Let's check in this order: + while (s > threshold && table.length < MAXIMUM_CAPACITY) --- Let's add more HashMap pseudo-methods to the test: + + Object[] table(HashMap map) { + try { + return (Object[]) TABLE.get(map); + } catch (Throwable t) { throw new AssertionError(t); } + } + + int capacity(HashMap map) { + return table(map).length; + } and some more assertions: + @Test + public void capacityTest() { + HashMap map = new HashMap<>(); + assertNull(table(map)); + + map.put(1, 1); + assertEquals(capacity(map), 16); + + map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> i, i -> i))); + assertEquals(capacity(map), 128); + } I did my own TODO to randomize testBug8210280 On Mon, Dec 17, 2018 at 7:40 AM Michal Vala wrote: > All tests I've run passed, benchmarks show ~15% performance boost for > putAllWithBigMapToNonEmptyMap. > > On 12/17/18 7:32 AM, Michal Vala wrote: > > Hi, > > > > thanks Doug, this is nice reduction. > > > > Here's the new webrev: > > http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.03/ > > > > Just a nitpick, issue is in using linked-list in buckets. The same is > used for > > both HashMap and LinkedHashMap, so mentioning just LinkedHashMap might > be > > confising. I've updated the comment s/LinkedHashMap/linked-list buckets/. > > > > I'm just running tier1 tests and benchmarks. > > > > On 12/16/18 3:23 PM, Doug Lea wrote: > >> > >> On 12/14/18 1:37 AM, Michal Vala wrote: > >>> Thanks Martin for finding this serious issue and the testcase. > >>> > >> > >> Sorry that I wasn't paying attention to this and so forced Martin to > >> discover the hard way that because of LinkeHashMap, you can't skip > >> doubling steps (at least not without a lot of rework). Also, the > >> documentation should have mentioned this. A simpler way to reduce > >> overhead in the case at hand is just to loop in putMapEntries: > >> > >> --- HashMap.java.~1.9.~ 2018-11-11 15:43:24.982878495 -0500 > >> +++ HashMap.java 2018-12-16 09:05:48.924727867 -0500 > >> @@ -502,8 +502,13 @@ > >> if (t > threshold) > >> threshold = tableSizeFor(t); > >> } > >> - else if (s > threshold) > >> - resize(); > >> + else { > >> + // Because of LinkedHashMap constraints, we cannot > >> + // expand all at once, but can reduce total resize > >> + // effort by repeated doubling now vs later > >> + while (table.length < MAXIMUM_CAPACITY && s > > threshold) > >> + resize(); > >> + } > >> for (Map.Entry e : > m.entrySet()) { > >> K key = e.getKey(); > >> V value = e.getValue(); > >> > > > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > From martinrb at google.com Tue Dec 18 21:38:39 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Dec 2018 13:38:39 -0800 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> Message-ID: On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen wrote: > > > Is there a reason you did not use > > @Test(expectedExceptions = IOException.class) > > It just seems to make the test a bit more readable > > That construct has lost popularity over the past decade, sort of like inheritance is no longer considered a silver bullet. From jason_mehrens at hotmail.com Tue Dec 18 21:49:10 2018 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 18 Dec 2018 21:49:10 +0000 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> References: , <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> Message-ID: The reason the patched code is faster is because it will avoid an array resize that is triggered in the benchmark by: "// once a new ArrayList is created add a new element al.add(new Integer(900));" http://cr.openjdk.java.net/~sgroeger/perf/arraylist/ArrayListBenchmark.java If you look at the patch, it is over provisioning the backing array by using "elements.length" (elementData = new Object[((ArrayList)c).elementData.length];) instead of "size". The toArray call uses size and then the benchmark adds one element to trigger the resize. Not sure if over provisioning the backing array is the right choice. I tend to lean towards the current paradigm of exact sizing on copy. Jason From stuart.marks at oracle.com Tue Dec 18 22:01:30 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 18 Dec 2018 14:01:30 -0800 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: Message-ID: <95fe3fb0-e313-391d-9e82-dafedb1b1079@oracle.com> On 12/18/18 9:23 AM, Martin Buchholz wrote: > The blessed solution to the list copy problem is probably List.copyOf > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/List.html#copyOf(java.util.Collection) > which might do the optimization you're hoping for. List.copyOf is fine, but note that it returns an instance of an unmodifiable List. The main optimization it does is that if it's asked to make a copy of an already-unmodifiable list, it simply returns its argument. If you want an actual ArrayList instead of an unmodifiable list, of course you'll have to use the ArrayList copy constructor or some variation. s'marks From stuart.marks at oracle.com Wed Dec 19 00:03:07 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 18 Dec 2018 16:03:07 -0800 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> Message-ID: <53c22b3c-5bee-3ab7-1417-80228892ee19@oracle.com> On 12/18/18 1:49 PM, Jason Mehrens wrote: > The reason the patched code is faster is because it will avoid an array resize that is triggered in the benchmark by: > "// once a new ArrayList is created add a new element > al.add(new Integer(900));" > http://cr.openjdk.java.net/~sgroeger/perf/arraylist/ArrayListBenchmark.java > > If you look at the patch, it is over provisioning the backing array by using "elements.length" (elementData = new Object[((ArrayList)c).elementData.length];) > instead of "size". The toArray call uses size and then the benchmark adds one element to trigger the resize. Yep, that's the reason. I was arriving at the same conclusion but you beat me to it. I modified the patch to base the length of elementData on 'size' instead of the other elementData.length, and also to preserve the EMPTY_ELEMENTDATA sentinel: @@ -176,6 +176,15 @@ * @throws NullPointerException if the specified collection is null */ public ArrayList(Collection c) { + if (c.getClass() == ArrayList.class) { + ArrayList other = (ArrayList)c; + int sz = other.size; + if ((size = sz) == 0) { + elementData = EMPTY_ELEMENTDATA; + } else { + elementData = Arrays.copyOf(other.elementData, sz); + } + } else { elementData = c.toArray(); if ((size = elementData.length) != 0) { // defend against c.toArray (incorrectly) not returning Object[] and some quick benchmark runs don't show any improvement over the baseline. Well, there might be a tiny improvement, but it's well within the margin of error, so I'm not sure. > Not sure if over provisioning the backing array is the right choice. I tend to lean towards the current paradigm of exact sizing on copy. I agree, I don't think we want to change this behavior. There may be applications that rely on the exact size, e.g. to release memory by making a copy of a list after having removed a lot of elements. s'marks From martinrb at google.com Wed Dec 19 01:01:50 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Dec 2018 17:01:50 -0800 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: <53c22b3c-5bee-3ab7-1417-80228892ee19@oracle.com> References: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> <53c22b3c-5bee-3ab7-1417-80228892ee19@oracle.com> Message-ID: Sorry for not having remembered the history. Having ArrayList(Collection) delegate to toArray was done for performance and robustness. We don't want to change the "trimming" behavior of collection copying, because trimming by copying is a common idiom (we never added trimming methods to all the collection classes). We seem to be in agreement that we should not change anything here. From jason_mehrens at hotmail.com Wed Dec 19 04:53:36 2018 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 19 Dec 2018 04:53:36 +0000 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> <53c22b3c-5bee-3ab7-1417-80228892ee19@oracle.com>, Message-ID: >Sorry for not having remembered the history. **Start the wavy motion effect because we are going back in time! ====== Date: Wed, 27 Sep 2006 16:49:47 -0700 From: Martin Buchholz Subject: 6347106 (coll) Make ArrayList(Collection) more threadsafe Sender: To: Jason Mehrens Hi Jason, Thanks for the SDN comment. I updated 4759223 and 4918916. I closed 4759223 as a dup of 6347106, but 4918916 is still an issue (although I should probably close as Not a Defect, following Josh). ====== So most of the history is in the following: https://bugs.openjdk.java.net/browse/JDK-4918916 https://bugs.openjdk.java.net/browse/JDK-4759223 https://bugs.openjdk.java.net/browse/JDK-6347106 Yes I still have this email and that Sun Ultra 20 from the Mustang Regressions challenge :) Jason From david.holmes at oracle.com Wed Dec 19 06:15:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Dec 2018 16:15:32 +1000 Subject: RFR: 8213402: [Testbug] java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates an invalid nest relationship In-Reply-To: <4a1f312f-33e2-30b6-46af-c995b533b283@oracle.com> References: <4a1f312f-33e2-30b6-46af-c995b533b283@oracle.com> Message-ID: <47a131c2-30e9-2e73-d354-12c350bd3f38@oracle.com> Looks good. Thanks for fixing this Daniel! David On 19/12/2018 12:57 am, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8213402: [Testbug] > java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates > an invalid nest relationship > https://bugs.openjdk.java.net/browse/JDK-8213402 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8213402/webrev.01/ > > These tests use a CustomSystemClassLoader to load custom LoggerFinder > subclasses so that they can assign them special privileges. > > But because these sub classes are static inner classes of the main > test class it creates an invalid nest relationship for the > nestmates implementation in project valhalla. > > The fix is very simple: I have refactored the tests to extract > the custom LoggerFinder classes as top level classes. > I have verified that the modified test pass in the nestmates > branch of valhalla repo - where it used to fail. > > > best regards, > > -- daniel From philipp.kunz at paratix.ch Wed Dec 19 06:24:24 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 19 Dec 2018 07:24:24 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> Message-ID: <1545200664.2502.16.camel@paratix.ch> now with assertThrows. Find a new patch attached. On Tue, 2018-12-18 at 13:38 -0800, Martin Buchholz wrote: > On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen .com> > wrote: > > > > > Is there a reason you did not use > > > > @Test(expectedExceptions = IOException.class) > > > > It just seems to make the test a bit more readable > > > > That construct has lost popularity over the past decade, sort of > > like > > inheritance is no longer considered a silver bullet. -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 30012 bytes Desc: not available URL: From david.holmes at oracle.com Wed Dec 19 06:27:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Dec 2018 16:27:19 +1000 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> Message-ID: <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: > On 12/18/18 3:39 AM, David Holmes wrote: >> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>> On 12/11/18 4:03 AM, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>> Hello, >>>>> >>>>> Please review a small fix in java_md_solinux.c: continuation is not >>>>> truly compatible with pthread_create start_routine's signature but >>>>> we control what actually happens. So it makes sense to add >>>>> intermediate void* cast to silence the error. >>>> >>>> I'd be tempted to fix the signature and get rid of all the casts. >>> >>> David, the signature is a signature of >>> >>> int JNICALL JavaMain(void * _args) >>> >>> It would be fun to change it. But still on Windows it is correctly >>> passed to _beginthreadex() and then return code is extracted with >>> GetExitCodeThread(). In case we want it to return void* the cast will >>> move there. >> >> I think the current double cast is truly ugly and an ifdef for >> windows, or a cast for Windows only would be an improvement. > > I agree. Maybe making a wrapper function is not so ugly. If there are no > objections to changing beginning of the call stack it is quite easy to > implement. For consistency it may be done for all 3 points (posix unix, > posix mac, windows) or just for posix ones. > > It looks like ifdef should be better as long as there are already > OS-specific parts in libjli. Again, if there are no objections to have > different JavaMain signatures on different platforms. In this case there > won't be a signature cast for Windows. How about setting #define THREAD_FUNC_RETURN int in windows/java_md.h. Then: #ifndef THREAD_FUNC_RETURN #define THREAD_FUNC_RETURN void* #endif in java.h (after the other includes). Then: THREAD_FUNC_RETURN JNICALL JavaMain(void * _args) in java.c. ? Cheers, David > > -Dmitry > >> >> But I won't impose that on you just to silence gcc 8. >> >> Cheers, >> David >> >>> -Dmitry >>> >>>> >>>> Cheers, >>>> David >>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>> testing: submit repo >>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>> >>>>> -Dmitry >>>>> From mvala at redhat.com Wed Dec 19 06:47:57 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 19 Dec 2018 07:47:57 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> Message-ID: <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Randomized test is not deterministic now. Can we have also original one? On 12/18/18 10:29 PM, Martin Buchholz wrote: > We have changes in jsr166 CVS ready for going into openjdk > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/HashMap-resize/index.html > (except for the microbenchmark, which doesn't fit into our pipeline at the > moment). > Pardon the fiddling ... > --- > Let's check in this order: > > + while (s > threshold && table.length < MAXIMUM_CAPACITY) > > --- > Let's add more HashMap pseudo-methods to the test: > > + > + Object[] table(HashMap map) { > + try { > + return (Object[]) TABLE.get(map); > + } catch (Throwable t) { throw new AssertionError(t); } > + } > + > + int capacity(HashMap map) { > + return table(map).length; > + } > > > and some more assertions: > > + @Test > + public void capacityTest() { > + HashMap map = new HashMap<>(); > + assertNull(table(map)); > + > + map.put(1, 1); > + assertEquals(capacity(map), 16); > + > + map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> > i, i -> i))); > + assertEquals(capacity(map), 128); > + } > > > I did my own TODO to randomize testBug8210280 > > On Mon, Dec 17, 2018 at 7:40 AM Michal Vala wrote: > >> All tests I've run passed, benchmarks show ~15% performance boost for >> putAllWithBigMapToNonEmptyMap. >> >> On 12/17/18 7:32 AM, Michal Vala wrote: >>> Hi, >>> >>> thanks Doug, this is nice reduction. >>> >>> Here's the new webrev: >>> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.03/ >>> >>> Just a nitpick, issue is in using linked-list in buckets. The same is >> used for >>> both HashMap and LinkedHashMap, so mentioning just LinkedHashMap might >> be >>> confising. I've updated the comment s/LinkedHashMap/linked-list buckets/. >>> >>> I'm just running tier1 tests and benchmarks. >>> >>> On 12/16/18 3:23 PM, Doug Lea wrote: >>>> >>>> On 12/14/18 1:37 AM, Michal Vala wrote: >>>>> Thanks Martin for finding this serious issue and the testcase. >>>>> >>>> >>>> Sorry that I wasn't paying attention to this and so forced Martin to >>>> discover the hard way that because of LinkeHashMap, you can't skip >>>> doubling steps (at least not without a lot of rework). Also, the >>>> documentation should have mentioned this. A simpler way to reduce >>>> overhead in the case at hand is just to loop in putMapEntries: >>>> >>>> --- HashMap.java.~1.9.~ 2018-11-11 15:43:24.982878495 -0500 >>>> +++ HashMap.java 2018-12-16 09:05:48.924727867 -0500 >>>> @@ -502,8 +502,13 @@ >>>> if (t > threshold) >>>> threshold = tableSizeFor(t); >>>> } >>>> - else if (s > threshold) >>>> - resize(); >>>> + else { >>>> + // Because of LinkedHashMap constraints, we cannot >>>> + // expand all at once, but can reduce total resize >>>> + // effort by repeated doubling now vs later >>>> + while (table.length < MAXIMUM_CAPACITY && s > >> threshold) >>>> + resize(); >>>> + } >>>> for (Map.Entry e : >> m.entrySet()) { >>>> K key = e.getKey(); >>>> V value = e.getValue(); >>>> >>> >> >> -- >> Michal Vala >> OpenJDK QE >> Red Hat Czech >> > -- Michal Vala OpenJDK QE Red Hat Czech From xueming.shen at gmail.com Wed Dec 19 07:15:06 2018 From: xueming.shen at gmail.com (Xueming Shen) Date: Tue, 18 Dec 2018 23:15:06 -0800 Subject: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests In-Reply-To: <846e3c3c8a3546379c00103f08a1b8a6@sap.com> References: <247E396D-3C1B-4C4C-897D-54A749AEB6D6@oracle.com> <846e3c3c8a3546379c00103f08a1b8a6@sap.com> Message-ID: <6b71deaa-671f-242d-d837-9792b97d140b@gmail.com> On 12/18/18 5:44 AM, Langer, Christoph wrote: > >> In ZipFileSystem you remove the unused method releaseDeflater - to me >> this indicates the resource pooling is actually broken? I.e., shouldn't >> EntryOutputStreamDef return its Deflater to the cache when it's closed, >> similar to how the anonymous InflaterInputStream in getInputStream does >> it? As it's currently implemented the deflaters list will always be >> empty and no Deflater returned, so could go the other way and remove >> that cache if caching Deflaters isn't useful. > You are right. I think this is a flaw of the change for 8034802 [1] [2]. I added the call to releaseDeflater() in the close method of EntryOutputStreamDef. > > My bad. Adding the logic back looks fine. In latest implementation the EntryOutputStreamDef is only created/used in sync() to write out any updated/compressed entry, which means there is actually only one deflater is being used at a time during the sync(), so you can just have one deflater and then reset it before passing on to the next entry write. And in fact even the EOSDef is really not necessary. I was working on that ... but somehow I dropped the ball during copy/ paste :-( ended up using the deflater from the cache but failed to return it back. Anyway. It's fine to keep current deflater cache mechanism, but it might be worth considering to "inline" the EntryOutputStreamDef logic and/or remove the deflater cache at all in the future. -Sherman From joel.borggren.franck at gmail.com Wed Dec 19 09:11:33 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Wed, 19 Dec 2018 10:11:33 +0100 Subject: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: Hi Liam, This makes sense to me. Since nestingForType is used to navigate scoping/nesting in more cases than owner type and javac seem to be inconsistent with regards to locations (see [1] for example), will this break or fix something else? [1] https://bugs.openjdk.java.net/browse/JDK-8148504 cheers /Joel On Wed, Dec 12, 2018 at 10:41 PM Liam Miller-Cushon wrote: > > On Fri, Dec 7, 2018 at 5:02 PM Liam Miller-Cushon wrote: > > > I rebased the webrev, and made some additional improvements and > > simplifications: > > http://cr.openjdk.java.net/~cushon/8198526/webrev.01/ > > > > The spec issue has been resolved (JDK-8215035), so this change is ready for > review. From christoph.langer at sap.com Wed Dec 19 10:14:51 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Dec 2018 10:14:51 +0000 Subject: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests In-Reply-To: <6b71deaa-671f-242d-d837-9792b97d140b@gmail.com> References: <247E396D-3C1B-4C4C-897D-54A749AEB6D6@oracle.com> <846e3c3c8a3546379c00103f08a1b8a6@sap.com> <6b71deaa-671f-242d-d837-9792b97d140b@gmail.com> Message-ID: <3a8081a2187f44a580a885c7ba125775@sap.com> Hi Sherman, thanks for the confirmation. Further refactoring regarding Deflator caching can be done with a separate issue. So, hearing no objections I'll push the patch once my testing is done. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Xueming Shen > Sent: Mittwoch, 19. Dezember 2018 08:15 > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs > and tests > > > On 12/18/18 5:44 AM, Langer, Christoph wrote: > > > >> In ZipFileSystem you remove the unused method releaseDeflater - to me > >> this indicates the resource pooling is actually broken? I.e., shouldn't > >> EntryOutputStreamDef return its Deflater to the cache when it's closed, > >> similar to how the anonymous InflaterInputStream in getInputStream > does > >> it? As it's currently implemented the deflaters list will always be > >> empty and no Deflater returned, so could go the other way and remove > >> that cache if caching Deflaters isn't useful. > > You are right. I think this is a flaw of the change for 8034802 [1] [2]. I added > the call to releaseDeflater() in the close method of EntryOutputStreamDef. > > > > > My bad. Adding the logic back looks fine. In latest implementation the > EntryOutputStreamDef > > is only created/used in sync() to write out any updated/compressed > entry, which means there > > is actually only one deflater is being used at a time during the sync(), > so you can just have one > > deflater and then reset it before passing on to the next entry write. > And in fact even the EOSDef > > is really not necessary. I was working on that ... but somehow I dropped > the ball during copy/ > > paste :-( ended up using the deflater from the cache but failed to > return it back. > > > Anyway. It's fine to keep current deflater cache mechanism, but it might > be worth considering > > to "inline" the EntryOutputStreamDef logic and/or remove the deflater > cache at all in the future. > > > -Sherman From GROEGES at uk.ibm.com Wed Dec 19 10:14:26 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 19 Dec 2018 10:14:26 +0000 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> <53c22b3c-5bee-3ab7-1417-80228892ee19@oracle.com>, Message-ID: Jason & Stuart, Yes, the intent was to leave the backing array the same size in order to avoid to have the resize of it when a new element is added. So, if someone wanted to reduce the size of the backing array then they could use the ArrayList.trimToSize() method. However, if you are saying (in another post - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057560.html ) that the 'trimming' of the backing array on a copy is intentional and that you are OK with a subsequent addition then resizing the backing array again - causing 2 resize operations, then this makes this performance change a moot issue. I can also see that not trimming on a copy is a change in the behavior and could cause problems with existing usages of this behavior. I thank you for all your comments and suggestions but it seems this change will not be suitable. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jason Mehrens To: Martin Buchholz , Stuart Marks Cc: core-libs Date: 19/12/2018 04:54 Subject: Re: Proposal: ArrayList constructor perforrmance improvement Sent by: "core-libs-dev" >Sorry for not having remembered the history. **Start the wavy motion effect because we are going back in time! ====== Date: Wed, 27 Sep 2006 16:49:47 -0700 From: Martin Buchholz Subject: 6347106 (coll) Make ArrayList(Collection) more threadsafe Sender: To: Jason Mehrens Hi Jason, Thanks for the SDN comment. I updated 4759223 and 4918916. I closed 4759223 as a dup of 6347106, but 4918916 is still an issue (although I should probably close as Not a Defect, following Josh). ====== So most of the history is in the following: https://bugs.openjdk.java.net/browse/JDK-4918916 https://bugs.openjdk.java.net/browse/JDK-4759223 https://bugs.openjdk.java.net/browse/JDK-6347106 Yes I still have this email and that Sun Ultra 20 from the Mustang Regressions challenge :) Jason Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From martinrb at google.com Wed Dec 19 13:47:29 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Dec 2018 05:47:29 -0800 Subject: Proposal: ArrayList constructor perforrmance improvement In-Reply-To: References: <54BC3FFD-67C6-4C9E-8518-BDC93BBE1251@gmail.com> <53c22b3c-5bee-3ab7-1417-80228892ee19@oracle.com> Message-ID: Thanks as always to Jason, our master Historian. On Wed, Dec 19, 2018 at 2:14 AM Steve Groeger wrote: > > Yes, the intent was to leave the backing array the same size in order to > avoid to have the resize of it when a new element is added. > So, if someone wanted to reduce the size of the backing array then they > could use the ArrayList.trimToSize() method. If you knew you wanted to add exactly one element after making a copy, an (distasteful but effective) performance hack might be to add the element to the source ArrayList, copy using ArrayList(Collection) and then remove the element from the source. From martinrb at google.com Wed Dec 19 14:01:19 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Dec 2018 06:01:19 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Message-ID: On Tue, Dec 18, 2018 at 10:48 PM Michal Vala wrote: > Randomized test is not deterministic now. Can we have also original one? > We may have an irreconcilable difference of testing philosophy. (yes, mainstream testing thought has embraced determinism) From alexey.ivanov at oracle.com Wed Dec 19 14:23:50 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 19 Dec 2018 14:23:50 +0000 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> Message-ID: <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> Any volunteers from core-libs and serviceability to review? Regards, Alexey On 12/12/2018 16:43, Magnus Ihse Bursie wrote: > > On 2018-12-12 17:38, Alexey Ivanov wrote: >> Hi all, >> >> I have updated the summary of JDK-8214122 and the subject accordingly. >> >> Could you please review the following fix? >> >> https://bugs.openjdk.java.net/browse/JDK-8214122 >> webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > Looks good to me. > > /Magnus >> >> *Root cause* >> jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 >> bit Windows according to the name decorations [1] for __stdcall [2] >> calling conventions. >> >> *Fix* >> On 32 bit Windows, look up the decorated name, >> _jdwpTransport_OnLoad at 16, first; if not found, look up the >> undecorated name, jdwpTransport_OnLoad. >> >> >> Regards, >> Alexey >> >> [1] >> https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC >> [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 >> >> On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 18:16, Alexey Ivanov wrote: >>>> Hi Simon, >>>> >>>> Thank you for your comments. >>>> >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>>> >>>> Indeed, it looks much cleaner. >>> Yes! This seems like the correct fix. >>> >>> Ship it! :) >>> >>> /Magnus >>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 11/12/2018 16:43, Simon Tooke wrote: >>>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>>> Hi everyone, >>>>>> >>>>>> I came up with the following patch: >>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>>> >>>>>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>>> other platforms the code remains as it is now. >>>>>> >>>>>> jshell starts successfully with this fix; an IDE debugger works >>>>>> as well. >>>>>> >>>>> I am not a reviewer, but this patch only works for the specific case >>>>> under discussion; the '@16' refers to the reserved stack size in the >>>>> Pascal calling convention.? So, the patch only works for 16 bytes of >>>>> parameters.? To be generic, the routine needs to have the stack size >>>>> passed in by the caller.? If a generic fix isn't desired (and I >>>>> hope it >>>>> is), I'd prefer to see the caller simply pass the decorated or >>>>> undecorated name depending on the Win32/64 defines. >>>>> >>>>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>>> (jdwpTransport_OnLoad_t) >>>>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>>> >>>>> >>>>> Thanks, >>>>> -Simon >>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>>> >>>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>>> options: >>>>>>>> >>>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>>> source file; >>>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>>>> with fallback to undecorated one. >>>>>>> Yes. >>>>>>> >>>>>>> I think the correct solution here is 2. >>>> >>> >> > From mvala at redhat.com Wed Dec 19 14:40:00 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 19 Dec 2018 15:40:00 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Message-ID: On 12/19/18 3:01 PM, Martin Buchholz wrote: > On Tue, Dec 18, 2018 at 10:48 PM Michal Vala wrote: > >> Randomized test is not deterministic now. Can we have also original one? >> > > We may have an irreconcilable difference of testing philosophy. > (yes, mainstream testing thought has embraced determinism) > Sure, that's probably true. All I'm asking is to have one more deterministic test which run few milliseconds. It's much easier to debug what is happening than randomized one. When someone will go with similar approach as I did first, this test stops him for sure and he/she will have faster feedback what's wrong. -- Michal Vala OpenJDK QE Red Hat Czech From martinrb at google.com Wed Dec 19 14:47:46 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Dec 2018 06:47:46 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Message-ID: Let's add whitebox tests for initial capacity and LinkedHashMap, as with ConcurrentHashMap's whitebox tests. --- src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 18 Dec 2018 20:21:24 -0000 1.1 +++ src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 19 Dec 2018 14:35:50 -0000 @@ -27,7 +27,11 @@ import java.lang.invoke.MethodType; import java.lang.invoke.VarHandle; import java.util.HashMap; +import java.util.LinkedHashMap; +import java.util.List; import java.util.Map; +import java.util.concurrent.ThreadLocalRandom; +import java.util.function.Supplier; import java.util.stream.IntStream; import static java.util.stream.Collectors.toMap; @@ -42,6 +46,7 @@ * @run testng WhiteBoxResizeTest */ public class WhiteBoxResizeTest { + final ThreadLocalRandom rnd = ThreadLocalRandom.current(); final MethodHandle TABLE_SIZE_FOR; final VarHandle THRESHOLD; final VarHandle TABLE; @@ -91,14 +96,36 @@ } @Test - public void capacityTest() { - HashMap map = new HashMap<>(); + public void capacityTestDefaultConstructor() { + capacityTestDefaultConstructor(new HashMap<>()); + capacityTestDefaultConstructor(new LinkedHashMap<>()); + } + + void capacityTestDefaultConstructor(HashMap map) { assertNull(table(map)); map.put(1, 1); - assertEquals(capacity(map), 16); + assertEquals(capacity(map), 16); // default initial capacity map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> i, i -> i))); assertEquals(capacity(map), 128); } + + @Test + public void capacityTestInitialCapacity() { + int initialCapacity = rnd.nextInt(1, 256); + List>> suppliers = List.of( + () -> new HashMap<>(initialCapacity), + () -> new HashMap<>(initialCapacity, 0.75f), + () -> new LinkedHashMap<>(initialCapacity), + () -> new LinkedHashMap<>(initialCapacity, 0.75f)); + + for (Supplier> supplier : suppliers) { + HashMap map = supplier.get(); + assertNull(table(map)); + + map.put(1, 1); + assertEquals(capacity(map), tableSizeFor(initialCapacity)); + } + } } From javalists at cbfiddle.com Wed Dec 19 14:54:10 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 19 Dec 2018 06:54:10 -0800 Subject: enhanced for loop with multiple iteration variables Message-ID: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> Has any consideration been given to supporting iterators that provide more than one iteration variable in the enhanced for loop? Obvious uses would be maps (keys and values) and lists (indexes and values). I have in mind keeping the syntactic sugar approach by using one or more extensions of the Iterator/Iterable interfaces, such as, for example: interface Iterator2 extends Iterator { E2 get2(); } with the extra methods providing the values for the extra variables (associated with the previous call to next). Extending interfaces is not required, but it makes the trailing variables optional, which might be useful. For example, the same iterator could provide values or values and keys. The fact that this approach only works for a fixed set of numbers of variables does not bother me unduly. Alan From Roger.Riggs at oracle.com Wed Dec 19 14:56:23 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 19 Dec 2018 09:56:23 -0500 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Message-ID: <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> Hi Martin, It is also useful and conventional to print the seed of the random so that if necessary it can be reproduced. Roger On 12/19/2018 09:01 AM, Martin Buchholz wrote: > On Tue, Dec 18, 2018 at 10:48 PM Michal Vala wrote: > >> Randomized test is not deterministic now. Can we have also original one? >> > We may have an irreconcilable difference of testing philosophy. > (yes, mainstream testing thought has embraced determinism) From chris.hegarty at oracle.com Wed Dec 19 15:01:42 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 19 Dec 2018 15:01:42 +0000 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Message-ID: <99811982-F278-493C-ABEF-CEA24E1FE7AC@oracle.com> Martin, Is it possible to use the the JDK?s test library jdk.test.lib.RandomFactory, so that the initial seed is captured and repayable. Also, please add the jtreg key so that the test is identifiable as using randomness: `@key randomness` . -Chris. > On 19 Dec 2018, at 14:47, Martin Buchholz wrote: > > Let's add whitebox tests for initial capacity and LinkedHashMap, as with > ConcurrentHashMap's whitebox tests. > > --- src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 18 Dec 2018 > 20:21:24 -0000 1.1 > +++ src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 19 Dec 2018 > 14:35:50 -0000 > @@ -27,7 +27,11 @@ > import java.lang.invoke.MethodType; > import java.lang.invoke.VarHandle; > import java.util.HashMap; > +import java.util.LinkedHashMap; > +import java.util.List; > import java.util.Map; > +import java.util.concurrent.ThreadLocalRandom; > +import java.util.function.Supplier; > import java.util.stream.IntStream; > > import static java.util.stream.Collectors.toMap; > @@ -42,6 +46,7 @@ > * @run testng WhiteBoxResizeTest > */ > public class WhiteBoxResizeTest { > + final ThreadLocalRandom rnd = ThreadLocalRandom.current(); > final MethodHandle TABLE_SIZE_FOR; > final VarHandle THRESHOLD; > final VarHandle TABLE; > @@ -91,14 +96,36 @@ > } > > @Test > - public void capacityTest() { > - HashMap map = new HashMap<>(); > + public void capacityTestDefaultConstructor() { > + capacityTestDefaultConstructor(new HashMap<>()); > + capacityTestDefaultConstructor(new LinkedHashMap<>()); > + } > + > + void capacityTestDefaultConstructor(HashMap map) { > assertNull(table(map)); > > map.put(1, 1); > - assertEquals(capacity(map), 16); > + assertEquals(capacity(map), 16); // default initial capacity > > map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> i, i > -> i))); > assertEquals(capacity(map), 128); > } > + > + @Test > + public void capacityTestInitialCapacity() { > + int initialCapacity = rnd.nextInt(1, 256); > + List>> suppliers = List.of( > + () -> new HashMap<>(initialCapacity), > + () -> new HashMap<>(initialCapacity, 0.75f), > + () -> new LinkedHashMap<>(initialCapacity), > + () -> new LinkedHashMap<>(initialCapacity, 0.75f)); > + > + for (Supplier> supplier : suppliers) { > + HashMap map = supplier.get(); > + assertNull(table(map)); > + > + map.put(1, 1); > + assertEquals(capacity(map), tableSizeFor(initialCapacity)); > + } > + } > } From daniel.daugherty at oracle.com Wed Dec 19 15:05:42 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2018 10:05:42 -0500 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> Message-ID: <8d177aef-2735-52e5-f46d-3f946d4fa284@oracle.com> On 12/19/18 9:23 AM, Alexey Ivanov wrote: > Any volunteers from core-libs and serviceability to review? How about former Serviceability Team members? :-) Alan B. and I both used to be on the Serviceability Team... And Alan B. is a current member of Core Libs... > webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ src/jdk.jdwp.agent/share/native/libjdwp/transport.c ??? No comments. The code appears to do what is described in this (very long) review thread. I don't believe we (Oracle) have any Win32 test setups for the jdk/jdk repo so this isn't a change that someone from Oracle can do additional testing on. Thumbs up! Dan > > Regards, > Alexey > > On 12/12/2018 16:43, Magnus Ihse Bursie wrote: >> >> On 2018-12-12 17:38, Alexey Ivanov wrote: >>> Hi all, >>> >>> I have updated the summary of JDK-8214122 and the subject accordingly. >>> >>> Could you please review the following fix? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >> Looks good to me. >> >> /Magnus >>> >>> *Root cause* >>> jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 >>> bit Windows according to the name decorations [1] for __stdcall [2] >>> calling conventions. >>> >>> *Fix* >>> On 32 bit Windows, look up the decorated name, >>> _jdwpTransport_OnLoad at 16, first; if not found, look up the >>> undecorated name, jdwpTransport_OnLoad. >>> >>> >>> Regards, >>> Alexey >>> >>> [1] >>> https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC >>> [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 >>> >>> On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 18:16, Alexey Ivanov wrote: >>>>> Hi Simon, >>>>> >>>>> Thank you for your comments. >>>>> >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>>>> >>>>> Indeed, it looks much cleaner. >>>> Yes! This seems like the correct fix. >>>> >>>> Ship it! :) >>>> >>>> /Magnus >>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 11/12/2018 16:43, Simon Tooke wrote: >>>>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> I came up with the following patch: >>>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>>>> >>>>>>> It specifically addresses the problem in JDK-8214122 where on 32 >>>>>>> bit >>>>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>>>> other platforms the code remains as it is now. >>>>>>> >>>>>>> jshell starts successfully with this fix; an IDE debugger works >>>>>>> as well. >>>>>>> >>>>>> I am not a reviewer, but this patch only works for the specific case >>>>>> under discussion; the '@16' refers to the reserved stack size in the >>>>>> Pascal calling convention.? So, the patch only works for 16 bytes of >>>>>> parameters.? To be generic, the routine needs to have the stack size >>>>>> passed in by the caller.? If a generic fix isn't desired (and I >>>>>> hope it >>>>>> is), I'd prefer to see the caller simply pass the decorated or >>>>>> undecorated name depending on the Win32/64 defines. >>>>>> >>>>>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>>>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>>>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>>>> (jdwpTransport_OnLoad_t) >>>>>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>>>> >>>>>> >>>>>> Thanks, >>>>>> -Simon >>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>>>> >>>>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>>>> options: >>>>>>>>> >>>>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>>>> source file; >>>>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>>>>> with fallback to undecorated one. >>>>>>>> Yes. >>>>>>>> >>>>>>>> I think the correct solution here is 2. >>>>> >>>> >>> >> > > From chris.hegarty at oracle.com Wed Dec 19 15:06:20 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 19 Dec 2018 15:06:20 +0000 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <99811982-F278-493C-ABEF-CEA24E1FE7AC@oracle.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <99811982-F278-493C-ABEF-CEA24E1FE7AC@oracle.com> Message-ID: > On 19 Dec 2018, at 15:01, Chris Hegarty wrote: > > Martin, > > Is it possible to use the the JDK?s test library jdk.test.lib.RandomFactory, > so that the initial seed is captured and rep*l*ayable. -Chris. From martinrb at google.com Wed Dec 19 15:15:56 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Dec 2018 07:15:56 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> Message-ID: On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: > Hi Martin, > > It is also useful and conventional to print the seed of the random > so that if necessary it can be reproduced. > For many years, we've been using ThreadLocalRandom for testing, and that does not allow setting a seed. I remain unconvinced that saving a seed has value in the real world. When a randomized test fails, running it with sufficient iterations has always worked for me. From martinrb at google.com Wed Dec 19 15:18:13 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Dec 2018 07:18:13 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: <99811982-F278-493C-ABEF-CEA24E1FE7AC@oracle.com> References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <99811982-F278-493C-ABEF-CEA24E1FE7AC@oracle.com> Message-ID: On Wed, Dec 19, 2018 at 7:01 AM Chris Hegarty wrote: > > Also, please add the jtreg key so that the test is identifiable as using > randomness: `@key randomness` . > Done, but I remain unconvinced of the value of doing so. From alexey.ivanov at oracle.com Wed Dec 19 15:28:19 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 19 Dec 2018 15:28:19 +0000 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <8d177aef-2735-52e5-f46d-3f946d4fa284@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> <8d177aef-2735-52e5-f46d-3f946d4fa284@oracle.com> Message-ID: <10f87cd8-86bf-e1d4-ae33-7e1c34a1c633@oracle.com> Thank you, Daniel, for your quick review. On 19/12/2018 15:05, Daniel D. Daugherty wrote: > On 12/19/18 9:23 AM, Alexey Ivanov wrote: >> Any volunteers from core-libs and serviceability to review? > > How about former Serviceability Team members? :-) Alan B. and I > both used to be on the Serviceability Team... And Alan B. is a > current member of Core Libs... That's fine, I guess. :-) > > > webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > > src/jdk.jdwp.agent/share/native/libjdwp/transport.c > ??? No comments. > > The code appears to do what is described in this (very long) review > thread. I don't believe we (Oracle) have any Win32 test setups for > the jdk/jdk repo so this isn't a change that someone from Oracle can > do additional testing on. That's true. I ran all the builds with tier3 testing, just in case. I also verified locally that jshell.exe and debugger start successfully in Win32 build. -- Alexey > > Thumbs up! > > Dan > > >> >> Regards, >> Alexey >> >> On 12/12/2018 16:43, Magnus Ihse Bursie wrote: >>> >>> On 2018-12-12 17:38, Alexey Ivanov wrote: >>>> Hi all, >>>> >>>> I have updated the summary of JDK-8214122 and the subject accordingly. >>>> >>>> Could you please review the following fix? >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>> Looks good to me. >>> >>> /Magnus >>>> >>>> *Root cause* >>>> jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 >>>> bit Windows according to the name decorations [1] for __stdcall [2] >>>> calling conventions. >>>> >>>> *Fix* >>>> On 32 bit Windows, look up the decorated name, >>>> _jdwpTransport_OnLoad at 16, first; if not found, look up the >>>> undecorated name, jdwpTransport_OnLoad. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> [1] >>>> https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC >>>> [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 >>>> >>>> On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-11 18:16, Alexey Ivanov wrote: >>>>>> Hi Simon, >>>>>> >>>>>> Thank you for your comments. >>>>>> >>>>>> The updated webrev: >>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>>>>> >>>>>> Indeed, it looks much cleaner. >>>>> Yes! This seems like the correct fix. >>>>> >>>>> Ship it! :) >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 11/12/2018 16:43, Simon Tooke wrote: >>>>>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I came up with the following patch: >>>>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>>>>> >>>>>>>> It specifically addresses the problem in JDK-8214122 where on >>>>>>>> 32 bit >>>>>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>>>>> other platforms the code remains as it is now. >>>>>>>> >>>>>>>> jshell starts successfully with this fix; an IDE debugger works >>>>>>>> as well. >>>>>>>> >>>>>>> I am not a reviewer, but this patch only works for the specific >>>>>>> case >>>>>>> under discussion; the '@16' refers to the reserved stack size in >>>>>>> the >>>>>>> Pascal calling convention.? So, the patch only works for 16 >>>>>>> bytes of >>>>>>> parameters.? To be generic, the routine needs to have the stack >>>>>>> size >>>>>>> passed in by the caller.? If a generic fix isn't desired (and I >>>>>>> hope it >>>>>>> is), I'd prefer to see the caller simply pass the decorated or >>>>>>> undecorated name depending on the Win32/64 defines. >>>>>>> >>>>>>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>>>>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>>>>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>>>>> (jdwpTransport_OnLoad_t) >>>>>>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> -Simon >>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>>>>> >>>>>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>>>>> options: >>>>>>>>>> >>>>>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>>>>> source file; >>>>>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for >>>>>>>>>> Win32 >>>>>>>>>> with fallback to undecorated one. >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>> I think the correct solution here is 2. >>>>>> >>>>> >>>> >>> >> >> > From mvala at redhat.com Wed Dec 19 17:07:21 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 19 Dec 2018 18:07:21 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> Message-ID: <3bfbfab9-dd95-601c-7c52-fdd8ab9fca38@redhat.com> I was thinking about testing resizing with items in buckets. Test like this. Can you please include it to changeset? (I can see you have prepared full webrev from changeset, so I'm not posting new one.) @Test public void resizeInternalTableWithBucketsTest() { Map m = new HashMap(); // Default size of HashMap table is 16. Make sure there are multiple items in one bucket. for (int i = 0; i < 4; i++) { m.put((i * 16) + 7, 1); } Map m2 = new HashMap(); for (int i = 0; i < 64; i++) { m2.put(-i, 2); } // put bigger map to ensure multiple resizing m.putAll(m2); // all original items should be there and properly rehashed for (int i = 0; i < 4; i++) { assertEquals(m.get((i * 16) + 7), 1); } } On 12/19/18 3:47 PM, Martin Buchholz wrote: > Let's add whitebox tests for initial capacity and LinkedHashMap, as with > ConcurrentHashMap's whitebox tests. > > --- src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 18 Dec 2018 > 20:21:24 -0000 1.1 > +++ src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 19 Dec 2018 > 14:35:50 -0000 > @@ -27,7 +27,11 @@ > import java.lang.invoke.MethodType; > import java.lang.invoke.VarHandle; > import java.util.HashMap; > +import java.util.LinkedHashMap; > +import java.util.List; > import java.util.Map; > +import java.util.concurrent.ThreadLocalRandom; > +import java.util.function.Supplier; > import java.util.stream.IntStream; > > import static java.util.stream.Collectors.toMap; > @@ -42,6 +46,7 @@ > * @run testng WhiteBoxResizeTest > */ > public class WhiteBoxResizeTest { > + final ThreadLocalRandom rnd = ThreadLocalRandom.current(); > final MethodHandle TABLE_SIZE_FOR; > final VarHandle THRESHOLD; > final VarHandle TABLE; > @@ -91,14 +96,36 @@ > } > > @Test > - public void capacityTest() { > - HashMap map = new HashMap<>(); > + public void capacityTestDefaultConstructor() { > + capacityTestDefaultConstructor(new HashMap<>()); > + capacityTestDefaultConstructor(new LinkedHashMap<>()); > + } > + > + void capacityTestDefaultConstructor(HashMap map) { > assertNull(table(map)); > > map.put(1, 1); > - assertEquals(capacity(map), 16); > + assertEquals(capacity(map), 16); // default initial capacity > > map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> i, i > -> i))); > assertEquals(capacity(map), 128); > } > + > + @Test > + public void capacityTestInitialCapacity() { > + int initialCapacity = rnd.nextInt(1, 256); > + List>> suppliers = List.of( > + () -> new HashMap<>(initialCapacity), > + () -> new HashMap<>(initialCapacity, 0.75f), > + () -> new LinkedHashMap<>(initialCapacity), > + () -> new LinkedHashMap<>(initialCapacity, 0.75f)); > + > + for (Supplier> supplier : suppliers) { > + HashMap map = supplier.get(); > + assertNull(table(map)); > + > + map.put(1, 1); > + assertEquals(capacity(map), tableSizeFor(initialCapacity)); > + } > + } > } > -- Michal Vala OpenJDK QE Red Hat Czech From mvala at redhat.com Wed Dec 19 17:32:30 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 19 Dec 2018 18:32:30 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> Message-ID: <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> On 12/19/18 4:15 PM, Martin Buchholz wrote: > On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: > >> Hi Martin, >> >> It is also useful and conventional to print the seed of the random >> so that if necessary it can be reproduced. >> > > For many years, we've been using ThreadLocalRandom for testing, and that > does not allow setting a seed. > > I remain unconvinced that saving a seed has value in the real world. When > a randomized test fails, running it with sufficient iterations has always > worked for me. > What's the reason behind using ThreadLocalRandom? In my opinion, reproducing the issue is key. One failure of randomized test run might be caused by one issue, second run due to another issue. How we reproduce then and how we know even how many issues we have? When we're running random tests until it pass, it might even hide the issue. They sure have good value on reveal the issue, but then we have to know how to reproduce and what we're searching for. If this case would not require ThreadLocalRandom and Random is enough, I'd like to use that because of benefits I've mentioned. -- Michal Vala OpenJDK QE Red Hat Czech From cushon at google.com Wed Dec 19 19:19:41 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 19 Dec 2018 11:19:41 -0800 Subject: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: Hi Joel, I think this fix is appropriate for the other uses of nestingForType. The underlying problem here is the treatment of nested types in general, which directly affects getAnnotatedOwnerType, but also applies to the examples in JDK-8066967. I added an additional test based on the one in JDK-8066967: http://cr.openjdk.java.net/~cushon/8198526/webrev.02/ Re: JDK-8148504, javac consistently emits type_path_kind=1 entries for nested types when there are multiple parts for which type annotations are admissable. That wasn't consistent with JVMS 11, which expects type_path_kind=1 entries for all nested types (regardless of whether the enclosing type is admissable for annotations). The resolution was to update the spec in JDK-8215035 and leave javac's behaviour unchanged, and this change is updating reflection to be consistent with the updated spec and the existing javac behaviour. From james.laskey at oracle.com Wed Dec 19 19:47:54 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 19 Dec 2018 15:47:54 -0400 Subject: RFR - CSR JDK-8215490 Remove String::align Message-ID: CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 Thank you. Cheers, ? Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html From james.laskey at oracle.com Wed Dec 19 20:13:18 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 19 Dec 2018 16:13:18 -0400 Subject: RFR - JDK-8215493 String::indent inconsistency with blank lines Message-ID: Please review these changes for jdk 12. webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html There is inconsistency with regards to blank lines and indentation. Adding indent space ignores blank lines, where subtraction indentation white space does not ignore blank lines. The solution is to remove the condition "Blank lines are unaffected" from the specification with appropriate changes to the implementation. Thank you. Cheers, ? Jim CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 From merkel05 at gmail.com Wed Dec 19 20:50:51 2018 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Wed, 19 Dec 2018 21:50:51 +0100 Subject: Type variable information is not always maintained for anonymous classes In-Reply-To: <23a18f59-b3f9-4d6a-1e74-39f5ef87d57c@oracle.com> References: <707b29c2-630b-6d47-425a-1ea745a78f7f@oracle.com> <23a18f59-b3f9-4d6a-1e74-39f5ef87d57c@oracle.com> Message-ID: Hi, Coming back to the topic, I feel like I need some help. Below is a stack trace so things would be easier to explain: "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at sun.reflect.generics.scope.ClassScope.computeEnclosingScope(ClassScope.java:51) at sun.reflect.generics.scope.AbstractScope.getEnclosingScope(AbstractScope.java:77) at sun.reflect.generics.scope.AbstractScope.lookup(AbstractScope.java:95) at sun.reflect.generics.factory.CoreReflectionFactory.findTypeVariable(CoreReflectionFactory.java:110) at sun.reflect.generics.visitor.Reifier.visitTypeVariableSignature(Reifier.java:165) at sun.reflect.generics.tree.TypeVariableSignature.accept(TypeVariableSignature.java:43) at sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68) at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138) at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49) at sun.reflect.generics.repository.ClassRepository.computeSuperclass(ClassRepository.java:104) at sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:86) at java.lang.Class.getGenericSuperclass(Class.java:955) at Bug8213465.printIt(Bug8213465.java:15) at Bug8213465.lambda$main$0(Bug8213465.java:8) at Bug8213465$$Lambda$1.1229416514.run(Unknown Source:-1) at Bug8213465.main(Bug8213465.java:9) ClassScope in our case is created by the CoreReflectionFactory, when Class#getGenericSuperclass being called. Creation is triggered, when type variable lookup happens. Class Scope in our case is the scope of anonymous class. Since type variable is not defined on the anonymous class, lookup is delegated to the enclosing scope, which is the lambda's scope i.e. MethodScope. As you see, I have a breakpoint at the ClassScope.java:51 which is ``` Method m = receiver.getEnclosingMethod(); ``` Lambda obviously doesn't declare the type variable => the next scope that would be queried is the lambda's enclosing scope which is the class scope. That ends up with the DummyScope and at Reifier.java:69 a null value is being placed into the Type[0]. All the way down that results in the type variable being resolved to null. The problem here is that type variable is declared at the method which encloses lambda, so that is the place where the problem comes in - we should somehow query the `main` method (in the example) for it's type variable declaration. I've tried to query it with some sort of stack walking. That I've tried at the ClassScope:51, so simply check if the method returned by the `getEnclosingMethod()` is synthetic, then use stack walker to baktrack. That is not working, since I there's no way to retain method arguments. Thus it wouldn't work for overloaded methods. I've searched through the `Method` class and found `Method#root` property. Could you please shine a light on it? Maybe we could harness it for lambdas to find the lambda's enclosing method? The other way I thought of is whether it make sense to add a new `Method#getEnclosingMethod` method, that in case of synthetic methods would return non-null method, which encloses it. So it seems a bit cumbersome, but I really need a bit of advise here. If anyone wants to participate and has some time, your thoughts would be of the great value! Thanks, Sergei On Tue, 11 Dec 2018 at 08:20, David Holmes wrote: > On 11/12/2018 4:27 pm, Sergei Ustimenko wrote: > > Hi David, > > > > Thanks for checking it, I'll continue working on it then. > > Just wondering if you have any thoughts on how fix would > > look like. > > No. I tried tracking through the Java code to see how this works but the > path is too long and convoluted :( The information is correct in the > classfile, but somewhere along the way the nature of the enclosing type > affects the answer that is produced. See ParameterizedTypeImpl and how > it gets created by CoreReflectionFactory. > > BTW as far as I can see it is not allowed for that method to produce > null: the type array can be empty, or creating it can throw an > exception, but otherwise the entries cannot be null. > > Cheers, > David > > > Regards, > > Sergei > > > > On Tue, 11 Dec 2018 at 02:34, David Holmes > > wrote: > > > > Hi Sergey, > > > > I've had a look and I don't think this issue is relevant to > > JDK-8171335. > > The problem seems to occur when you have a "hidden" enclosing context > > for the type, and that doesn't change with JDK-8171335. > > > > David > > > > On 9/12/2018 6:04 am, Sergey wrote: > > > Hi David, > > > > > > Thanks for pointing that out! > > > > > > >We need to see how this example work in that case. > > > > > > I guess anyone involved could have straight away two > > > test cases: one from the bug itself and another from the > > > observation above. > > > > > > In any case. looking forward for that being fixed. I would > > > also be happy to be able to help with anything if needed. > > > > > > Thanks and regards, > > > Sergei > > > > > > On Sat, 8 Dec 2018 at 12:03, David Holmes > > > > > > >> wrote: > > > > > > Hi Sergey, > > > > > > Just FYI we're in the process of moving away from using > anonymous > > > classes for lambda's to using an extended Lookup.defineClass > > API - see: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171335 > > > > > > this is being done under Project Valhalla, with current work > > in the > > > nestmates branch. > > > > > > We need to see how this example work in that case. > > > > > > Cheers, > > > David > > > From vicente.romero at oracle.com Wed Dec 19 21:27:32 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 19 Dec 2018 16:27:32 -0500 Subject: RFR: JDK-8215648: remove equals and hashCode implementations from j.l.i.VarHandle Message-ID: Please review fix for [1] at [2]. The fx is basically removing the implementation of methods VarHandle::equals and VarHandle::hashCode to make var handles consistent with method handles which don't override the default implementation for these methods, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8215648 [2] http://cr.openjdk.java.net/~vromero/8215648/webrev.00/ From vicente.romero at oracle.com Wed Dec 19 21:34:02 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 19 Dec 2018 16:34:02 -0500 Subject: RFR: JDK-8215648: remove equals and hashCode implementations from j.l.i.VarHandle In-Reply-To: References: Message-ID: <0ec9fc25-16c0-a5d6-9a99-b25a80b63074@oracle.com> Please review also the related CSR: https://bugs.openjdk.java.net/browse/JDK-8215649 Thanks, Vicente On 12/19/18 4:27 PM, Vicente Romero wrote: > Please review fix for [1] at [2]. The fx is basically removing the > implementation of methods VarHandle::equals and VarHandle::hashCode to > make var handles consistent with method handles which don't override > the default implementation for these methods, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8215648 > [2] http://cr.openjdk.java.net/~vromero/8215648/webrev.00/ From swpalmer at gmail.com Wed Dec 19 21:57:02 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 19 Dec 2018 16:57:02 -0500 Subject: jpackage EA Build 0 In-Reply-To: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: If the main jar is in a subfolder the .cfg file is written incorrectly leading to: Error: Could not find or load main class Caused by: java.lang.ClassNotFoundException: Which I only found by manually running: ./MyApp.app/Contents/MacOS/MyApp as double clicking doesn?t seem to show that output anywhere (I tried to find it in the Console.app output, but didn?t). In my case the main jar is in a ?libs? subfolder. The image is built correctly, with the subfolder under the ?Java? folder in the Mac application bundle. However, the cfg file had: app.mainjar=MyMainJar-1.0.0.jar instead of: app.mainjar=libs/MyMainJar-1.0.0.jar When I manually made that edit, it started to work. Scott > On Dec 14, 2018, at 7:46 AM, Andy Herrick wrote: > > I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ > > This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, > > This build is intended for developers interested in jpackage, and is provided as a convenience so that they don't need to build from the source code (branch="JDK-8200758-branch"). > > Warning: This build is based on an incomplete version of JDK 12 . > > Please send feedback via e-mail to core-libs-dev at openjdk.java.net > > /Andy > From vicente.romero at oracle.com Wed Dec 19 21:58:35 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 19 Dec 2018 16:58:35 -0500 Subject: RFR - CSR JDK-8215490 Remove String::align In-Reply-To: References: Message-ID: <34553658-3b02-85b3-d40b-b1ced6a1f795@oracle.com> looks good, Vicente On 12/19/18 2:47 PM, Jim Laskey wrote: > CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 > > Thank you. > > Cheers, > > ? Jim > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 > webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html > From mandy.chung at oracle.com Wed Dec 19 22:08:47 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Dec 2018 14:08:47 -0800 Subject: RFR: JDK-8215648: remove equals and hashCode implementations from j.l.i.VarHandle In-Reply-To: References: Message-ID: Looks fine to me. Mandy On 12/19/18 1:27 PM, Vicente Romero wrote: > Please review fix for [1] at [2]. The fx is basically removing the > implementation of methods VarHandle::equals and VarHandle::hashCode to > make var handles consistent with method handles which don't override > the default implementation for these methods, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8215648 > [2] http://cr.openjdk.java.net/~vromero/8215648/webrev.00/ From brian.burkhalter at oracle.com Thu Dec 20 04:01:00 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 19 Dec 2018 20:01:00 -0800 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) Message-ID: https://bugs.openjdk.java.net/browse/JDK-8215441 This issue was filed to cover improving the uniformity of randomly generated BigIntegers. It is not intended to resolve [1] which is deliberately left open. The proposed patch implements a modified version of the ?workaround? suggested in [1]. The problem is that the magnitude of the random BigInteger is created from a sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any of these bytes is zero is small so the distribution of the resulting random BigIntegers is skewed towards values close to the maximum bit size ?numBits? specified to the constructor. The workaround suggested in [1] is to randomly change numBits to the value numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround is nextInt(numBits) which is incorrect as the parameter is an exclusive upper bound.) This greatly improves the uniformity of the distribution. A remaining problem however is that now the very largest numbers in the interval [0,2^numBits) are underrepresented. A modification of this approach is to increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 [4]. This was empirically observed to improve the underrepresentation of the largest values. The distribution of the random BigIntegers was estimated using [5]. For a given maximum bit length, bin size, and number of random values to generate, this creates a histogram and calculates the coefficient of variation of the numbers generated. The histogram bin at index zero represents the largest valued bin in the result. The count in a given histogram bin is the number of values for which that bin is the leftmost (largest valued) with at least one non-zero bit. The bin of maximum index represents zero. Results for the current and two modified approaches for 256 bits with a 1-bit bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be observed, the original histogram is clustered towards the largest possible value 2^numBits - 1, and the coefficient of variation is small. The results for the two variants of the patch show a flattened distribution, i.e., more uniform, and a significantly larger coefficient of variation. The second approach shows better flattening of both ends of the histogram. These results are samples only but are exemplary of the results observed over numerous runs of this code. The test ModPow is modified as the modPow() method throws an ArithmeticException for a zero modulus. The current algorithm never generates a random BigInteger equal to zero however so that exception never occurs. That is not the case for either modified version. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8146153 [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[]) [3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/ [4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/ [5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java [6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt [7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt [8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt [9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt [10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt [11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt From philipp.kunz at paratix.ch Thu Dec 20 06:11:22 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 20 Dec 2018 07:11:22 +0100 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> <1545174048.2502.12.camel@paratix.ch> Message-ID: <1545286282.2502.20.camel@paratix.ch> Hi Roger, I guess I followed it up this time now. I guess my previous patches were actually based on 54aafb3ba9ab from September 25. And Eclipse never told me...In difference to the webrev one more line was intended to be removed: @SuppressWarnings("deprecation") at Manifest#read. New patch attached. Philipp On Wed, 2018-12-19 at 09:44 -0500, Roger Riggs wrote: > ????Hi, > > ???? > > ????On 12/18/2018 06:00 PM, Philipp Kunz > ??????wrote: > > ???? > ???? > > ?????? > > ??????Hi Roger > > ?????? > > > > ?????? > > ??????I believe my patch was based on the version at http://hg.open > > jdk.java.net/jdk/jdk/rev/e84983c2735e. > > ????????What kind of warnings did you get or what could I have > > missed? > > ???? > > ???? > > ????When I apply the patch over that version or head, I get errors. > > ???? > > ????The Attributes.java I have at that version has an additional read > ????method from: > > ????8207768: Improve exception messages during manifest parsing of > jar > ????archives? > > ????commit 51879:6ffa38b8da65f346f04f0ee16487cdc6127b5732? > > ????Author: mbaesken? > > ????Date: 9/12/18 5:13 AM > ????/* > ?* Reads attributes from the specified input stream. > ?* XXX Need to handle UTF8 values. > ?*/ > void read(Manifest.FastInputStream is, byte[] lbuf) throws > IOException { > ????read(is, lbuf, null, 0); > } > > @SuppressWarnings("deprecation") > int read(Manifest.FastInputStream is, byte[] lbuf, String filename, > int lineNumber) throws IOException { > ????String name = null, value; > > ????The reject is because the trailing context does not match; the > ????reject patch is attached. > > ????The messages are: > > ????applying 8066619-4.patch > > ??????patching file > ??????src/java.base/share/classes/java/util/jar/Attributes.java > > ??????Hunk #5 FAILED at 342 > > ??????Hunk #7 succeeded at 421 with fuzz 2 (offset 10 lines). > > ??????1 out of 7 hunks FAILED -- saving rejects to file > ??????src/java.base/share/classes/java/util/jar/Attributes.java.rej > > ??????patching file > ??????src/java.base/share/classes/java/util/jar/Manifest.java > > ??????Hunk #1 succeeded at 37 with fuzz 2 (offset 1 lines). > > ??????Hunk #3 succeeded at 230 with fuzz 1 (offset 54 lines). > > ??????patch failed, unable to continue (try -v) > > ??????patch failed, rejects left in working directory > > ??????errors during apply, please fix and qrefresh 8066619-4.patch > > ???? > ????A bit puzzling... > > ???? > > ????Thanks, Roger > > ???? > > ???? > > ?????? > > > > ?????? > > ??????Philipp > > ?????? > > > > ?????? > > ?????? > > > > ?????? > > ??????On Tue, 2018-12-18 at 10:38 -0500, Roger Riggs wrote: > > ?????? > > > ?Hi Philipp, > > > > > > ???????? > > > > > > ????????I'm satisfied with this update. > > > > > > ???????? > > > > > > ????????BTW, your workspace may be a bit out of date, the patch > > > did not > > > ????????merge without warnings. > > > > > > ???????? > > > > > > ????????For convenience of other reviewers, here a webrev: > > > > > > ?????????http://cr.openjdk.java.net/~rriggs/webrev-8066619-3.patc > > > h/ > > > > > > ???????? > > > > > > ????????Thanks, Roger > > > > > > ???????? > > > > > > ???????? > > > > > > ???????? > > > > > > ???????? > > > ?????? > > > > ???? > > ???? > > ?? > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8066619.patch Type: text/x-patch Size: 30276 bytes Desc: not available URL: From joel.borggren.franck at gmail.com Thu Dec 20 08:22:07 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Thu, 20 Dec 2018 09:22:07 +0100 Subject: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: Hi Liam, I read the spec bugs, we had a similar discussion a few years ago about the scoping. Given how all implementations of javac have behaved for the last 4 years or so, I agree this is the right fix. Thanks for the extra test. Ship it! cheers /Joel On Wed, Dec 19, 2018 at 8:19 PM Liam Miller-Cushon wrote: > > Hi Joel, > > I think this fix is appropriate for the other uses of nestingForType. > > The underlying problem here is the treatment of nested types in general, which directly affects getAnnotatedOwnerType, but also applies to the examples in JDK-8066967. > > I added an additional test based on the one in JDK-8066967: > http://cr.openjdk.java.net/~cushon/8198526/webrev.02/ > > Re: JDK-8148504, javac consistently emits type_path_kind=1 entries for nested types when there are multiple parts for which type annotations are admissable. That wasn't consistent with JVMS 11, which expects type_path_kind=1 entries for all nested types (regardless of whether the enclosing type is admissable for annotations). The resolution was to update the spec in JDK-8215035 and leave javac's behaviour unchanged, and this change is updating reflection to be consistent with the updated spec and the existing javac behaviour. From ecki at zusammenkunft.net Thu Dec 20 12:58:05 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 20 Dec 2018 12:58:05 +0000 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) In-Reply-To: References: Message-ID: Hm strange, never saw it this way. Would other types have the same problem (should be visible in your histogram for long as well, right?) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Brian Burkhalter Gesendet: Donnerstag, Dezember 20, 2018 8:03 AM An: core-libs-dev Betreff: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) https://bugs.openjdk.java.net/browse/JDK-8215441 This issue was filed to cover improving the uniformity of randomly generated BigIntegers. It is not intended to resolve [1] which is deliberately left open. The proposed patch implements a modified version of the ?workaround? suggested in [1]. The problem is that the magnitude of the random BigInteger is created from a sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any of these bytes is zero is small so the distribution of the resulting random BigIntegers is skewed towards values close to the maximum bit size ?numBits? specified to the constructor. The workaround suggested in [1] is to randomly change numBits to the value numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround is nextInt(numBits) which is incorrect as the parameter is an exclusive upper bound.) This greatly improves the uniformity of the distribution. A remaining problem however is that now the very largest numbers in the interval [0,2^numBits) are underrepresented. A modification of this approach is to increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 [4]. This was empirically observed to improve the underrepresentation of the largest values. The distribution of the random BigIntegers was estimated using [5]. For a given maximum bit length, bin size, and number of random values to generate, this creates a histogram and calculates the coefficient of variation of the numbers generated. The histogram bin at index zero represents the largest valued bin in the result. The count in a given histogram bin is the number of values for which that bin is the leftmost (largest valued) with at least one non-zero bit. The bin of maximum index represents zero. Results for the current and two modified approaches for 256 bits with a 1-bit bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be observed, the original histogram is clustered towards the largest possible value 2^numBits - 1, and the coefficient of variation is small. The results for the two variants of the patch show a flattened distribution, i.e., more uniform, and a significantly larger coefficient of variation. The second approach shows better flattening of both ends of the histogram. These results are samples only but are exemplary of the results observed over numerous runs of this code. The test ModPow is modified as the modPow() method throws an ArithmeticException for a zero modulus. The current algorithm never generates a random BigInteger equal to zero however so that exception never occurs. That is not the case for either modified version. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8146153 [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[]) [3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/ [4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/ [5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java [6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt [7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt [8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt [9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt [10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt [11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt From lance.andersen at oracle.com Thu Dec 20 14:17:47 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 20 Dec 2018 09:17:47 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <1545200664.2502.16.camel@paratix.ch> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> <1545200664.2502.16.camel@paratix.ch> Message-ID: Hi Philipp, The tests look better. Any chance you can post the webrev in the future vs the patch as it makes it easer to review. Best Lance > On Dec 19, 2018, at 1:24 AM, Philipp Kunz wrote: > > now with assertThrows. Find a new patch attached. > > On Tue, 2018-12-18 at 13:38 -0800, Martin Buchholz wrote: >> On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen > >> wrote: >> >>> >>> >>> >>> Is there a reason you did not use >>> >>> @Test(expectedExceptions = IOException.class) >>> >>> It just seems to make the test a bit more readable >>> >>> That construct has lost popularity over the past decade, sort of like >> >> inheritance is no longer considered a silver bullet. > <8066619.patch> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From adam.petcher at oracle.com Thu Dec 20 15:15:53 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 20 Dec 2018 10:15:53 -0500 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) In-Reply-To: References: Message-ID: I'm not sure what the problem is. If X is uniform, then "the number of leading zero bits" of X is exponential. The probability of getting a "small" number, in which the first (say) 32 bits are 0 is 2^-32. If this is what is measured by the histrogram[5], then the current implementation looks correct to me. On 12/19/2018 11:01 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8215441 > > This issue was filed to cover improving the uniformity of randomly generated BigIntegers. It is not intended to resolve [1] which is deliberately left open. The proposed patch implements a modified version of the ?workaround? suggested in [1]. > > The problem is that the magnitude of the random BigInteger is created from a sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any of these bytes is zero is small so the distribution of the resulting random BigIntegers is skewed towards values close to the maximum bit size ?numBits? specified to the constructor. > > The workaround suggested in [1] is to randomly change numBits to the value numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround is nextInt(numBits) which is incorrect as the parameter is an exclusive upper bound.) This greatly improves the uniformity of the distribution. A remaining problem however is that now the very largest numbers in the interval [0,2^numBits) are underrepresented. A modification of this approach is to increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 [4]. This was empirically observed to improve the underrepresentation of the largest values. > > The distribution of the random BigIntegers was estimated using [5]. For a given maximum bit length, bin size, and number of random values to generate, this creates a histogram and calculates the coefficient of variation of the numbers generated. The histogram bin at index zero represents the largest valued bin in the result. The count in a given histogram bin is the number of values for which that bin is the leftmost (largest valued) with at least one non-zero bit. The bin of maximum index represents zero. > > Results for the current and two modified approaches for 256 bits with a 1-bit bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be observed, the original histogram is clustered towards the largest possible value 2^numBits - 1, and the coefficient of variation is small. The results for the two variants of the patch show a flattened distribution, i.e., more uniform, and a significantly larger coefficient of variation. The second approach shows better flattening of both ends of the histogram. These results are samples only but are exemplary of the results observed over numerous runs of this code. > > The test ModPow is modified as the modPow() method throws an ArithmeticException for a zero modulus. The current algorithm never generates a random BigInteger equal to zero however so that exception never occurs. That is not the case for either modified version. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8146153 > [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[]) > [3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/ > [4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/ > [5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java > [6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt > [7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt > [8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt > [9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt > [10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt > [11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt From peter.levart at gmail.com Thu Dec 20 15:21:45 2018 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 20 Dec 2018 16:21:45 +0100 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) In-Reply-To: References: Message-ID: Hi Brian, I don't quite understand this reasoning. I need some explanation... You are talking about the distribution of BigInteger values (not the bit lengths of the values), obtained with constructor BigInteger(int, java.util.Random) for which the javadoc says: ???? * Constructs a randomly generated BigInteger, uniformly distributed over ???? * the range 0 to (2{@code numBits} - 1), inclusive. ???? * The uniformity of the distribution assumes that a fair source of random ???? * bits is provided in {@code rnd}.? Note that this constructor always ???? * constructs a non-negative BigInteger. I think that the javadoc meant to say that the *values* of the BigIntegers constructed are uniformly distributed... On 12/20/18 5:01 AM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8215441 > > This issue was filed to cover improving the uniformity of randomly generated BigIntegers. It is not intended to resolve [1] which is deliberately left open. The proposed patch implements a modified version of the ?workaround? suggested in [1]. > > The problem is that the magnitude of the random BigInteger is created from a sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any of these bytes is zero is small It should be 1/256 right? If the bytes returned by Random.nextBytes() are good random bytes, they are independent and their distribution is uniform. So the likelihood of an individual byte being 0 is approximately the same as the likelihood of it being any particular other byte value. As there are 256 different values a byte can have, this amounts to 1/256... > so the distribution of the resulting random BigIntegers is skewed towards values close to the maximum bit size ?numBits? specified to the constructor. I think that's a normal consequence of uniform distribution of values. The "bit length" of a BigInteger value is the index of its highest 1 bit (+1 counted from lowest bit0). Say you produce a uniformly distributed random BigInteger in range 0 ... 2^8 - 1 (the bitLength constructor parameter being 8 in this case) The probability that you get an integer with "bit length" of 8 is 1/2 (that's the probability of a uniformly distributed 8 bit integer having the highest bit 1)... 1XXXXXXX The probability that you get an integer with "bit lenght" of 7 is 1/4 (that's the probability of a uniformly distributed 8 bit integer having the highest bit 0 and the next to highest bit 1)... 01XXXXXX Probability you get bit length 6 is 1/8 ... 001XXXXX Probability you get bit length 5 is 1/16 ... 0001XXXX Probability you get bit length 4 is 1/32 ... 00001XXX Probability you get bit length 3 is 1/64 ... 000001XX Probability you get bit length 2 is 1/128 ... 0000001X Probability you get bit length 1 is 1/256 ... (the probability of getting value 1) ... 00000001 Probability you get bit length 0 is 1/256 ... (the probability of getting value 0) ... 00000000 In general, the probability that you get an integer with bit length N is equal to the probability that you get an integer with bit length < N. The probability that you get 0 from BigInteger random constructor when you pass to it numBits is 1/(2^numBits). When you choose 256 for numBits, that's a very slim probability. Practically zero. Let alone when you choose 4096. > > The workaround suggested in [1] is to randomly change numBits to the value numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround is nextInt(numBits) which is incorrect as the parameter is an exclusive upper bound.) This greatly improves the uniformity of the distribution. A remaining problem however is that now the very largest numbers in the interval [0,2^numBits) are underrepresented. A modification of this approach is to increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 [4]. This was empirically observed to improve the underrepresentation of the largest values. > > The distribution of the random BigIntegers was estimated using [5]. For a given maximum bit length, bin size, and number of random values to generate, this creates a histogram and calculates the coefficient of variation of the numbers generated. The histogram bin at index zero represents the largest valued bin in the result. The count in a given histogram bin is the number of values for which that bin is the leftmost (largest valued) with at least one non-zero bit. The bin of maximum index represents zero. What exactly are you trying to show with this code? I'm strugling to understand it... If you wanted to show the distribution of BigInteger values into equally sized bins by the value (each bin representing the sub-interval in the interval 0 ... 2^numBits -1) then the code would be much simpler. But you are trying to show something else... What is that? Regards, Peter From Roger.Riggs at oracle.com Thu Dec 20 15:50:07 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 20 Dec 2018 10:50:07 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> <1545200664.2502.16.camel@paratix.ch> Message-ID: <513d9500-a1d1-f6b7-166d-91794c1b7bee@oracle.com> Hi Lance, Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-8066619-5.patch/ Phillip does not yet have access to cr.openjdk.java.net. $.02, Roger On 12/20/2018 09:17 AM, Lance Andersen wrote: > Hi Philipp, > > The tests look better. Any chance you can post the webrev in the future vs the patch as it makes it easer to review. > > Best > Lance >> On Dec 19, 2018, at 1:24 AM, Philipp Kunz wrote: >> >> now with assertThrows. Find a new patch attached. >> >> On Tue, 2018-12-18 at 13:38 -0800, Martin Buchholz wrote: >>> On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen > >>> wrote: >>> >>>> >>>> >>>> Is there a reason you did not use >>>> >>>> @Test(expectedExceptions = IOException.class) >>>> >>>> It just seems to make the test a bit more readable >>>> >>>> That construct has lost popularity over the past decade, sort of like >>> inheritance is no longer considered a silver bullet. >> <8066619.patch> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Roger.Riggs at oracle.com Thu Dec 20 16:10:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 20 Dec 2018 11:10:27 -0500 Subject: RFR - JDK-8215493 String::indent inconsistency with blank lines In-Reply-To: References: Message-ID: Hi Jim, Is there a missing test?? I'd expect to see a corresponding test change also. otherwise, looks fine. Regards, Roger On 12/19/2018 03:13 PM, Jim Laskey wrote: > Please review these changes for jdk 12. > > webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html > > There is inconsistency with regards to blank lines and indentation. Adding indent space ignores blank lines, where subtraction indentation white space does not ignore blank lines. The solution is to remove the condition "Blank lines are unaffected" from the specification with appropriate changes to the implementation. > > Thank you. > > Cheers, > > ? Jim > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 > JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 > > From james.laskey at oracle.com Thu Dec 20 16:46:15 2018 From: james.laskey at oracle.com (James Laskey) Date: Thu, 20 Dec 2018 12:46:15 -0400 Subject: RFR - JDK-8215493 String::indent inconsistency with blank lines In-Reply-To: References: Message-ID: It?s there. AlignIndent.java. Sent from my iPhone > On Dec 20, 2018, at 12:10 PM, Roger Riggs wrote: > > Hi Jim, > > Is there a missing test? I'd expect to see a corresponding test change also. > > otherwise, looks fine. > > Regards, Roger > > >> On 12/19/2018 03:13 PM, Jim Laskey wrote: >> Please review these changes for jdk 12. >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html >> >> There is inconsistency with regards to blank lines and indentation. Adding indent space ignores blank lines, where subtraction indentation white space does not ignore blank lines. The solution is to remove the condition "Blank lines are unaffected" from the specification with appropriate changes to the implementation. >> >> Thank you. >> >> Cheers, >> >> ? Jim >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 >> >> > From joe.darcy at oracle.com Thu Dec 20 16:50:57 2018 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 20 Dec 2018 08:50:57 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> Message-ID: <04f05958-4e5f-bc36-7e29-87326f455801@oracle.com> Hello, For some other libs test using randomness, we've been able to track down and fix bugs only after a seed value was printed and usable for reproducing the problem, see the history of: * JDK-6854417: "testbug: java/util/regex/RegExTest.java fails intermittently." * JDK-8022224: Rare bug in JISAutodetect charset detected by FindDecoderBugs test The bad values which trigger the bug might only a very small subset of the full space. For the latter bug which was tracked down once the seed made the situation reproducible, see this comment from Martin in 2015 :-) > Sherman: Thanks for fixing this.? I've observed this in the wild a > couple of times myself. > > (Although flaky tests are annoying, finding actual bugs makes it so > worth it!) http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034836.html Please using the testing randomness library and the randomness jtreg keyword. The keyword helps guide failure analysis. Thanks, -Joe On 12/19/2018 7:15 AM, Martin Buchholz wrote: > On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: > >> Hi Martin, >> >> It is also useful and conventional to print the seed of the random >> so that if necessary it can be reproduced. >> > For many years, we've been using ThreadLocalRandom for testing, and that > does not allow setting a seed. > > I remain unconvinced that saving a seed has value in the real world. When > a randomized test fails, running it with sufficient iterations has always > worked for me. From Roger.Riggs at oracle.com Thu Dec 20 16:52:10 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 20 Dec 2018 11:52:10 -0500 Subject: RFR - JDK-8215493 String::indent inconsistency with blank lines In-Reply-To: References: Message-ID: <07f97c2e-f728-696a-418c-728cce0656de@oracle.com> Thanks, looks fine.? Roger On 12/20/2018 11:46 AM, James Laskey wrote: > It?s there. AlignIndent.java. > > Sent from my iPhone > >> On Dec 20, 2018, at 12:10 PM, Roger Riggs wrote: >> >> Hi Jim, >> >> Is there a missing test? I'd expect to see a corresponding test change also. >> >> otherwise, looks fine. >> >> Regards, Roger >> >> >>> On 12/19/2018 03:13 PM, Jim Laskey wrote: >>> Please review these changes for jdk 12. >>> >>> webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html >>> >>> There is inconsistency with regards to blank lines and indentation. Adding indent space ignores blank lines, where subtraction indentation white space does not ignore blank lines. The solution is to remove the condition "Blank lines are unaffected" from the specification with appropriate changes to the implementation. >>> >>> Thank you. >>> >>> Cheers, >>> >>> ? Jim >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 >>> >>> From brian.burkhalter at oracle.com Thu Dec 20 17:08:04 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 20 Dec 2018 09:08:04 -0800 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) In-Reply-To: References: Message-ID: <53674885-97D6-415D-B221-BFCFD67CADD7@oracle.com> Thanks for the comments. It looks like I got this completely wrong. For some reason I was thinking that the distribution of bit lengths should be uniform which is patently incorrect. Consider the example of a four bit integer. The possible values are 1111 1110 1101 1100 1011 1010 1001 1000 0111 0110 0101 0100 0011 0010 0001 0000 Half of the values have bit length 4, 25% have bit length 2, etc. Re-running my test code shows pretty much this sort of distribution of the bit lengths. It looks like the likelihood of bit lengths from the largest length downward is a geometric sequence with initial value 0.5 for the largest bit length and common ratio 0.5. So I concur with Adam that the current implementation looks correct. Therefore I think that [1] should be withdrawn and [2] closed as not an issue. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8215441 [2] https://bugs.openjdk.java.net/browse/JDK-8146153 From brian.burkhalter at oracle.com Thu Dec 20 17:12:30 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 20 Dec 2018 09:12:30 -0800 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) In-Reply-To: <53674885-97D6-415D-B221-BFCFD67CADD7@oracle.com> References: <53674885-97D6-415D-B221-BFCFD67CADD7@oracle.com> Message-ID: Correction: Half have bit length 4, 25% 3, ... > On Dec 20, 2018, at 9:08 AM, Brian Burkhalter wrote: > > Half of the values have bit length 4, 25% have bit length 2, etc. From douglas.surber at oracle.com Thu Dec 20 17:18:44 2018 From: douglas.surber at oracle.com (Douglas Surber) Date: Thu, 20 Dec 2018 09:18:44 -0800 Subject: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) In-Reply-To: References: Message-ID: <5A07BF27-A3D5-4CEF-AA70-381E30AA9C35@oracle.com> I wrote the following simple test case to look at the uniformity of the distribution. I don't see any problem running it up to 4096 buckets. Admittedly I did not do any statistical tests on the buckets but by eye they look uniformly distributed. public static void main(String[] args) throws Throwable { SecureRandom sr = SecureRandom.getInstance("SHA1PRNG"); final int nBits = 4096; final int nBuckets = 128; final int count = 100000; Pair[] buckets = new Pair[nBuckets]; BigInteger max = BigInteger.TWO.pow(nBits); BigInteger limit = max; BigInteger step = limit.divide(BigInteger.valueOf(buckets.length)); for (int i = 0; i < buckets.length; i++) buckets[i] = new Pair(limit = limit.subtract(step)); for (int i = 0; i < count; ++i) { // biased towards high numbers. never chooses below a high limit BigInteger number = new BigInteger(nBits, sr); int j; for (j = 0; buckets[j].limit.compareTo(number) > 0; j++) {} buckets[j].count++; } for (int i = buckets.length; i > 0; i--) System.out.print(buckets[i-1].count + (i%8==0 ? "\n" : "\t")); System.out.println(); } Douglas From cushon at google.com Thu Dec 20 17:48:59 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 20 Dec 2018 09:48:59 -0800 Subject: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: Thanks for the review! On Thu, Dec 20, 2018 at 12:22 AM Joel Borggr?n-Franck < joel.borggren.franck at gmail.com> wrote: > Hi Liam, > > I read the spec bugs, we had a similar discussion a few years ago > about the scoping. Given how all implementations of javac have behaved > for the last 4 years or so, I agree this is the right fix. Thanks for > the extra test. > > Ship it! > > cheers > /Joel > > On Wed, Dec 19, 2018 at 8:19 PM Liam Miller-Cushon > wrote: > > > > Hi Joel, > > > > I think this fix is appropriate for the other uses of nestingForType. > > > > The underlying problem here is the treatment of nested types in general, > which directly affects getAnnotatedOwnerType, but also applies to the > examples in JDK-8066967. > > > > I added an additional test based on the one in JDK-8066967: > > http://cr.openjdk.java.net/~cushon/8198526/webrev.02/ > > > > Re: JDK-8148504, javac consistently emits type_path_kind=1 entries for > nested types when there are multiple parts for which type annotations are > admissable. That wasn't consistent with JVMS 11, which expects > type_path_kind=1 entries for all nested types (regardless of whether the > enclosing type is admissable for annotations). The resolution was to update > the spec in JDK-8215035 and leave javac's behaviour unchanged, and this > change is updating reflection to be consistent with the updated spec and > the existing javac behaviour. > From Roger.Riggs at oracle.com Thu Dec 20 21:40:48 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 20 Dec 2018 16:40:48 -0500 Subject: RFR: 8170769 Provide a simple hexdump facility for binary data In-Reply-To: <5D024752-B1D2-43F7-AD90-17C86EB1CE38@oracle.com> References: <5BF813FE.8060708@oracle.com> <189C66DA-0E13-4107-9A42-D11122E19396@oracle.com> <5B7150BC-40AD-4E0F-A933-16E331BF313E@oracle.com> <4a09a553-a4c5-9a01-62a5-26583545bf07@oracle.com> <01C3CC6C-F645-40E3-A9FD-04017843F6F1@oracle.com> <33d0efad-60d8-4f41-f741-dcbc44b38da0@oracle.com> <5D024752-B1D2-43F7-AD90-17C86EB1CE38@oracle.com> Message-ID: <6b710c8a-b875-6fb9-560e-a3a9887e8ba8@oracle.com> Hi Vincent, This looks good. The doc for HEXDUMP_FORMATTER should include an example of the formatting. Its easier to see it than to reconstruct it from the example code. like: ??? 00000000? 61 62 63 64 65 66 67 68? 69 6a 6b 6c 6d 6e 6f 70 |abcdefghijklmnop| ??? 00000010? 71 72 73 74 75 76 77 78? 79 7a??????????????????? |qrstuvwxyz| I'm not sure the reference to hexdump(1) is useful, it could be removed without loss of precision or usefulness. Thanks, Roger On 12/12/2018 01:21 PM, Vincent Ryan wrote: > FYI I?ve updated the webrev/javadoc with latest edits including the 2 new ByteBuffer methods: > > http://cr.openjdk.java.net/~vinnie/8170769/webrev.09/ > http://cr.openjdk.java.net/~vinnie/8170769/javadoc.09/api/java.base/java/util/HexFormat.html > (NOTE: internal link to HexFormat.Formatter class is currently broken) > > > If that is an acceptable compromise then I believe all outstanding issues have now been addressed. > Thanks to all those who provided review comments. > > >> On 12 Dec 2018, at 12:32, Vincent Ryan wrote: >> >> Thanks for your proposal. >> Comments below. >> >>> On 12 Dec 2018, at 02:35, Stuart Marks wrote: >>> >>> >>> >>> On 12/11/18 1:21 PM, Vincent Ryan wrote: >>>> My preference is for PrintStream rather than Writer, for the same reason as Roger: it?s more convenient >>>> for handling System.out. Does that address your concern? >>> PrintStream is fine with me. >>> >>>> I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte charset so some 0x8X characters >>>> Will trigger the multi-byte sequence and will end up being misinterpreted. Hence my rather awkward conversion to a String. >>>> Is there a better way? >>> In toPrintableString(), >>> >>> 259 StringBuilder printable = new StringBuilder(toIndex - fromIndex); >>> 260 for (int i = fromIndex; i < toIndex; i++) { >>> 261 if (bytes[i] > 0x1F && bytes[i] < 0x7F) { >>> 262 printable.append((char) bytes[i]); >>> 263 } else if (bytes[i] > (byte)0x9F && bytes[i] <= (byte)0xFF) { >>> 264 printable.append(new String(new byte[]{bytes[i]}, ISO_8859_1)); >>> 265 >>> 266 } else { >>> 267 printable.append('.'); >>> 268 } >>> 269 } >>> >>> It works to cast ASCII bytes char, because the 7-bit ASCII range overlaps the low 7 bits of the UTF-16 char range. The bytes values of ISO 8859-1 overlap the low 8 bits of UTF-16, so casts work for them too. >>> >>> For any other charset, you'd need to do codeset conversion. But you're cleverly supporting only ISO 8859-1, so you don't have to do any conversion. :-) >>> >>>> I?m not sure I?ve addressed your concern regarding IOExceptions - can you elaborate? >>> Taking out the OutputStream overloads addressed my concerns. In at least one case the code would wrap the OutputStream into a PrintStream, print stuff to it, and then throw away the PrintStream. If an output error occurred, any error state in the PrintStream would also be thrown away. The creation of the PrintStream wrapper would also use the system's default charset instead of letting the caller control it. >>> >>> The dump() overloads now all take PrintStream, so it's the caller's responsibility to ensure that the PrintStream is using the right charset and to check for errors after. So this is all OK now. >>> >>> Note that the internal getPrintStream(), to wrap an OutputStream in a PrintStream, is now obsolete and can be removed. >>> >>> (Oh, I see Roger has said much the same things. Oh well, the peril of parallel reviews.) >>> >>> ** >>> >>>> BTW updated webrev/javadoc available: >>>> http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/ >>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html >>> Now we have a somewhat unsatisfying asymmetry in the APIs. >>> >>> There are four kinds of inputs: >>> >>> 1. byte[] >>> 2. byte[] subrange >>> 3. InputStream >>> 4. ByteBuffer >>> >>> and two kinds of outputs: >>> >>> 1. PrintStream >>> 2. Stream >>> >>> and two variations of formatters: >>> >>> 1. default formatter >>> 2. custom formatter + chunk size >>> >>> This is a total of 16 combinations. But there are only eight methods: three PrintStream methods with choice of input, two stream-output methods using the default formatter, and three stream-output methods using custom chunk+formatter. >>> >>> You don't have to provide ALL combinations, but what's here is an odd subset with some apparently arbitrary choices. For example, if I have a ByteBuffer and I want to dump it to System.out using default formatting, I have to go the Stream.forEachOrdered route AND provide the default chunk size and formatter. >>> >>> HexFormat.dumpAsStream(buf, DEFAULT_CHUNK_SIZE, HEXDUMP_FORMATTER) >>> .forEachOrdered(System.out::println); >>> >>> These aren't huge deals, but they're easily stumbled over. >>> >>> One approach to organizing this is to have a HexFormat instance that contains the setup information and then to have instance methods that either update the setup or perform conversion and output. I'd use static factory methods instead of constructors. For example, you could do this: >>> >>> static factories methods: >>> - from(byte[]) >>> - from(byte[], fromIndex, toIndex) >>> - from(InputStream) >>> - from(ByteBuffer) >>> >>> formatter setup instance methods: >>> - format(chunksize, formatter) >>> >>> output: >>> - void dump(PrintStream) >>> - Stream stream() >>> >>> Using this approach my example from above could be performed as follows: >>> >>> HexFormat.from(buf).dump(System.out); >>> >>> Note, I'm not saying that you HAVE to do it this way. (In particular, the naming could use work.) This is quite possibly overkill. But it's something you might consider, as it gets you all 16 combinations using seven methods, compared to the eight static methods in the current proposal that cover only half of the combinations. >>> >>> Alternatively, pare down the set of static methods to a bare minimum. Provide one that can do everything, and then provide one or two more that are essentially the same as the first but with some hardwired defaults. For example, to help minimize things, you can wrap a ByteBuffer around a byte array subrange, or get an InputStream from a byte array subrange. But you can't get an InputStream from a ByteBuffer or vice-versa, without a lot of work. >>> >>> (I haven't looked at the to* or from* methods.) >>> >>> s?marks >> Your chaining approach has merit and the method chaining is attractive but it would be a significant change to the API at this advanced stage. >> >> I agree that there are gaps in the combinations and perhaps that could be addressed by introducing a few convenience methods. >> I think ByteBuffer is under-represented and propose adding the following two methods to handle the simplified, default cases: >> >> public static Stream dumpAsStream(ByteBuffer buffer) >> >> public static void dump(ByteBuffer buffer, PrintStream out) >> >> >> That would be 10 combos for 10 methods versus 16 combos for 7 methods which is still not full coverage but perhaps more methods could >> be added in the future if there is demand for them. >> >> >> >> From lance.andersen at oracle.com Thu Dec 20 21:53:05 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 20 Dec 2018 16:53:05 -0500 Subject: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes In-Reply-To: <513d9500-a1d1-f6b7-166d-91794c1b7bee@oracle.com> References: <1543664955.2437.5.camel@paratix.ch> <1543912487.2437.16.camel@paratix.ch> <85c64c99-36fe-f31a-0aec-9b6cc3e41a44@oracle.com> <1545028971.2502.6.camel@paratix.ch> <2a631c34-d3dc-6db7-3f7c-c9e73c7e13bd@oracle.com> <1545117302.2502.10.camel@paratix.ch> <6E1DE5B5-FAFC-482E-8090-6B857F1CAAA4@oracle.com> <1545200664.2502.16.camel@paratix.ch> <513d9500-a1d1-f6b7-166d-91794c1b7bee@oracle.com> Message-ID: <2A3BA42E-4454-4814-B46E-617710781426@oracle.com> Hi Roger, Thank you. I am OK with the current version of the patch. Happy Holidays! Best Lance > On Dec 20, 2018, at 10:50 AM, Roger Riggs wrote: > > Hi Lance, > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-8066619-5.patch/ > > Phillip does not yet have access to cr.openjdk.java.net. > > $.02, Roger > > On 12/20/2018 09:17 AM, Lance Andersen wrote: >> Hi Philipp, >> >> The tests look better. Any chance you can post the webrev in the future vs the patch as it makes it easer to review. >> >> Best >> Lance >>> On Dec 19, 2018, at 1:24 AM, Philipp Kunz wrote: >>> >>> now with assertThrows. Find a new patch attached. >>> >>> On Tue, 2018-12-18 at 13:38 -0800, Martin Buchholz wrote: >>>> On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen > >>>> wrote: >>>> >>>>> >>>>> >>>>> Is there a reason you did not use >>>>> >>>>> @Test(expectedExceptions = IOException.class) >>>>> >>>>> It just seems to make the test a bit more readable >>>>> >>>>> That construct has lost popularity over the past decade, sort of like >>>> inheritance is no longer considered a silver bullet. >>> <8066619.patch> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From scolebourne at joda.org Thu Dec 20 22:21:17 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 20 Dec 2018 22:21:17 +0000 Subject: RFR - CSR JDK-8215490 Remove String::align In-Reply-To: References: Message-ID: Is String::transform going to be removed as well given the removal of raw strings and its controversial nature? Stephen On Wed, 19 Dec 2018 at 19:50, Jim Laskey wrote: > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 > > Thank you. > > Cheers, > > ? Jim > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 > webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html > From brian.goetz at oracle.com Thu Dec 20 22:50:15 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 20 Dec 2018 17:50:15 -0500 Subject: enhanced for loop with multiple iteration variables In-Reply-To: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> Message-ID: <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> For Map, you can do: ??? for (Map.Entry e : map.entrySet()) { ... } and you're already there. On 12/19/2018 9:54 AM, Alan Snyder wrote: > Has any consideration been given to supporting iterators that provide more than one iteration variable in the enhanced for loop? > > Obvious uses would be maps (keys and values) and lists (indexes and values). > > I have in mind keeping the syntactic sugar approach by using one or more extensions of the Iterator/Iterable interfaces, such as, for example: > > interface Iterator2 extends Iterator { > E2 get2(); > } > > with the extra methods providing the values for the extra variables (associated with the previous call to next). > > Extending interfaces is not required, but it makes the trailing variables optional, which might be useful. For example, the same iterator could provide values or values and keys. > > The fact that this approach only works for a fixed set of numbers of variables does not bother me unduly. > > Alan > From forax at univ-mlv.fr Thu Dec 20 23:00:34 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 21 Dec 2018 00:00:34 +0100 (CET) Subject: enhanced for loop with multiple iteration variables In-Reply-To: <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> Message-ID: <1754329726.1013464.1545346834867.JavaMail.zimbra@u-pem.fr> or map.forEach((key, value) -> { ... }); R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Alan Snyder" , "core-libs-dev" > Envoy?: Jeudi 20 D?cembre 2018 23:50:15 > Objet: Re: enhanced for loop with multiple iteration variables > For Map, you can do: > > ??? for (Map.Entry e : map.entrySet()) { ... } > > and you're already there. > > > > On 12/19/2018 9:54 AM, Alan Snyder wrote: >> Has any consideration been given to supporting iterators that provide more than >> one iteration variable in the enhanced for loop? >> >> Obvious uses would be maps (keys and values) and lists (indexes and values). >> >> I have in mind keeping the syntactic sugar approach by using one or more >> extensions of the Iterator/Iterable interfaces, such as, for example: >> >> interface Iterator2 extends Iterator { >> E2 get2(); >> } >> >> with the extra methods providing the values for the extra variables (associated >> with the previous call to next). >> >> Extending interfaces is not required, but it makes the trailing variables >> optional, which might be useful. For example, the same iterator could provide >> values or values and keys. >> >> The fact that this approach only works for a fixed set of numbers of variables >> does not bother me unduly. >> >> Alan From brian.burkhalter at oracle.com Fri Dec 21 00:36:33 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 20 Dec 2018 16:36:33 -0800 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException Message-ID: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8215759 http://cr.openjdk.java.net/~bpb/8215759/webrev.00/ Although highly unlikely, the modulus parameter of modPow() can be zero which would provoke an ArithmeticException. Unsure whether I need this bug ID in the @bug list. Thanks, Brian From javalists at cbfiddle.com Fri Dec 21 02:19:14 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 20 Dec 2018 18:19:14 -0800 Subject: enhanced for loop with multiple iteration variables In-Reply-To: <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> Message-ID: <4AA5A92A-A2A0-4423-9596-ED203651FC65@cbfiddle.com> RIght, but I don?t see that as a general solution. Its also a bit kludgy, like saying that methods need only one parameter because you can always pass a data object. > On Dec 20, 2018, at 2:50 PM, Brian Goetz wrote: > > For Map, you can do: > > for (Map.Entry e : map.entrySet()) { ... } > > and you're already there. > > > > On 12/19/2018 9:54 AM, Alan Snyder wrote: >> Has any consideration been given to supporting iterators that provide more than one iteration variable in the enhanced for loop? >> >> Obvious uses would be maps (keys and values) and lists (indexes and values). >> >> I have in mind keeping the syntactic sugar approach by using one or more extensions of the Iterator/Iterable interfaces, such as, for example: >> >> interface Iterator2 extends Iterator { >> E2 get2(); >> } >> >> with the extra methods providing the values for the extra variables (associated with the previous call to next). >> >> Extending interfaces is not required, but it makes the trailing variables optional, which might be useful. For example, the same iterator could provide values or values and keys. >> >> The fact that this approach only works for a fixed set of numbers of variables does not bother me unduly. >> >> Alan >> > From javalists at cbfiddle.com Fri Dec 21 02:20:46 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 20 Dec 2018 18:20:46 -0800 Subject: enhanced for loop with multiple iteration variables In-Reply-To: <1754329726.1013464.1545346834867.JavaMail.zimbra@u-pem.fr> References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> <1754329726.1013464.1545346834867.JavaMail.zimbra@u-pem.fr> Message-ID: Lambdas are clean, but limited in current Java compared to nested blocks. Are full featured lambdas on the horizon? If not, then we still need loops and iterators. Alan > On Dec 20, 2018, at 3:00 PM, Remi Forax wrote: > > or > map.forEach((key, value) -> { > ... > }); > > R?mi > > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Alan Snyder" , "core-libs-dev" >> Envoy?: Jeudi 20 D?cembre 2018 23:50:15 >> Objet: Re: enhanced for loop with multiple iteration variables > >> For Map, you can do: >> >> for (Map.Entry e : map.entrySet()) { ... } >> >> and you're already there. >> >> >> >> On 12/19/2018 9:54 AM, Alan Snyder wrote: >>> Has any consideration been given to supporting iterators that provide more than >>> one iteration variable in the enhanced for loop? >>> >>> Obvious uses would be maps (keys and values) and lists (indexes and values). >>> >>> I have in mind keeping the syntactic sugar approach by using one or more >>> extensions of the Iterator/Iterable interfaces, such as, for example: >>> >>> interface Iterator2 extends Iterator { >>> E2 get2(); >>> } >>> >>> with the extra methods providing the values for the extra variables (associated >>> with the previous call to next). >>> >>> Extending interfaces is not required, but it makes the trailing variables >>> optional, which might be useful. For example, the same iterator could provide >>> values or values and keys. >>> >>> The fact that this approach only works for a fixed set of numbers of variables >>> does not bother me unduly. >>> >>> Alan > From deepak.kejriwal at oracle.com Fri Dec 21 09:49:51 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 21 Dec 2018 01:49:51 -0800 (PST) Subject: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties Message-ID: Hi all, Please review the fix for following issues:- https://bugs.openjdk.java.net/browse/JDK-8214567 https://bugs.openjdk.java.net/browse/JDK-8214569 Below is the webrev for above issues: http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.00/ Regards, Deepak From Alan.Bateman at oracle.com Fri Dec 21 09:55:01 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Dec 2018 09:55:01 +0000 Subject: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties In-Reply-To: References: Message-ID: On 21/12/2018 09:49, Deepak Kejriwal wrote: > Hi all, > > > > Please review the fix for following issues:- > > > > https://bugs.openjdk.java.net/browse/JDK-8214567 > > https://bugs.openjdk.java.net/browse/JDK-8214569 > > > > Below is the webrev for above issues: > > > > http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.00/ > These look okay except for ClassLoader where it might be cleaner to re-format the paragraph so there isn't one long line sticking out. -Alan From christoph.langer at sap.com Fri Dec 21 10:41:18 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Dec 2018 10:41:18 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) Message-ID: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> Hi folks, getting back to the topic of adding POSIX file permission support to jdk.zipfs... I think as we are now in the early stages of JDK13, it's a good point in time to get some (hopefully final) activity on that one. In the last review discussions you were asking me to provide some write-up of the proposal. Therefore I updated the CSR. It should now be a valid document for discussing the whole proposal, comprising the problem to solve, the proposed solution and its specification as well as addressing some concerns. And to get it clear: This item is only about jdk.zipfs. It is really independent of potential enhancements for java.util.zip or the jartool. So, I gently ask you to review the CSR. As for the implementation: I've worked on it together with Volker and will post an update soon. Thanks and Best regards Christoph > -----Original Message----- > From: Chris Hegarty > Sent: Montag, 5. November 2018 17:19 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; security-dev at openjdk.java.net; Xueming Shen > > Cc: nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > > On 05/11/18 15:59, Alan Bateman wrote: > > On 05/11/2018 13:05, Langer, Christoph wrote: > >> > >>... > >> > > I think you'll need to do a write-up of the overall proposal so that > > folks can jump in and point out the implications. It's not easy to do > > this in a code review of a small piece of the solution. > > Right, that's the main motivation for my previous questions. It is good > to get a *complete* view of what is intended before reviewing the code. > ( Sorry, if I've missed some of the previous context ). > > -Chris. From Alan.Bateman at oracle.com Fri Dec 21 11:16:44 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Dec 2018 11:16:44 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> Message-ID: <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> On 21/12/2018 10:41, Langer, Christoph wrote: > Hi folks, > > getting back to the topic of adding POSIX file permission support to jdk.zipfs... I think as we are now in the early stages of JDK13, it's a good point in time to get some (hopefully final) activity on that one. > > In the last review discussions you were asking me to provide some write-up of the proposal. > Therefore I updated the CSR. It should now be a valid document for discussing the whole proposal, comprising the problem to solve, the proposed solution and its specification as well as addressing some concerns. > > And to get it clear: This item is only about jdk.zipfs. It is really independent of potential enhancements for java.util.zip or the jartool. So, I gently ask you to review the CSR. > > As for the implementation: I've worked on it together with Volker and will post an update soon. > Adding support for POSIX file permissions to the zip APIs is problematic as we've been discussing here. There are security concerns and also concerns that how it interacts with JAR files and signed JAR in particular. I don't disagree that we can come to agreement on zipfs supporting a solution but I think we need to get the bigger picture on where this is going first. If the piece to change the java.util.zip APIs is dropped then it would make these discussions a lot simpler as it removes most of the security issues from the table. -Alan From christoph.langer at sap.com Fri Dec 21 13:43:13 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Dec 2018 13:43:13 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: Hi Alan, > Adding support for POSIX file permissions to the zip APIs is problematic > as we've been discussing here. There are security concerns and also > concerns that how it interacts with JAR files and signed JAR in > particular. I don't disagree that we can come to agreement on zipfs > supporting a solution but I think we need to get the bigger picture on > where this is going first. If the piece to change the java.util.zip APIs > is dropped then it would make these discussions a lot simpler as it > removes most of the security issues from the table. Yes, please consider changes to java.util.zip APIs as dropped. At least for the moment. I'm not saying I won't ever get back to that topic but maybe an enhancement of jdk.zipfs is already sufficient to provide the required Posix permission support for the Java platform. Best regards Christoph From christoph.langer at sap.com Fri Dec 21 14:31:11 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Dec 2018 14:31:11 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi all, here comes the updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/ I've rebased the change to the current state of the JDK depot. Thanks to Volker, the test has been enhanced and now also tests more copy operations (from zip file system to zip file system and from zip file system to default file system and back). The points below were also addressed: > ZipFileAttributeView.java > - can you please throw an AssertionError() for the default branch in > the switch expression in the "ZipFileAttributeView.name()". The default branch will return "basic". Looking at the code it should not be jumped to anyway. > ZipFileSystem.java > - please also put @Override annotations on the method implementations > from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and > a comment at the place where the implementation of the > "PosixFileAttributes" methods starts. Done, I also reordered the methods - first "basic" then "posix" then "zip". > ZipUtils.java > - just a question: isn't it possible to reuse > sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding > constants from sun.nio.fs.UnixConstants instead of redefining them > here? You could export them from java.base to jdk.zipfs but the > problem is probably that at least sun.nio.fs.UnixConstants is a > generated class which only gets generated on Unix systems, right ? You've already answered yourself ?? These classes only exist on Unix type JDKs. > ZipFileAttributes.java > - it seems a little odd that you've added "setPermissions()" to > ZipFileAttributes. All the attribute classes (i.e. > BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it > possible to implement "ZipFileAttributeView.setPermissions()" by > calling "path.setPermissions()" (as this is done in > "ZipFileAttributeView.setTimes()") and handle everything in > ZipFileSyste (as this is done with "setTimes()"). Good catch & thanks for providing the better implementation. I think this version is quite final now and thoroughly tested. I hope to get some valid reviews soon... Thanks Christoph From Roger.Riggs at oracle.com Fri Dec 21 14:52:15 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 21 Dec 2018 09:52:15 -0500 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException In-Reply-To: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> References: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> Message-ID: <82be9eb2-e3a8-2858-b350-f03f05e6d78c@oracle.com> Hi Brian, The changes look fine. Adding the bugid to @bug helps close the loop, the test failed, a bug was fixed. Happy Holidays, Roger On 12/20/2018 07:36 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8215759 > http://cr.openjdk.java.net/~bpb/8215759/webrev.00/ > > Although highly unlikely, the modulus parameter of modPow() can be zero which would provoke an ArithmeticException. > Unsure whether I need this bug ID in the @bug list. > > Thanks, > > Brian From naoto.sato at oracle.com Fri Dec 21 15:05:50 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 21 Dec 2018 07:05:50 -0800 Subject: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties In-Reply-To: References: Message-ID: Reviewed these and they look good. src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java src/java.base/share/classes/java/util/Currency.java src/java.base/share/classes/java/util/PropertyResourceBundle.java src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java Naoto On 12/21/18 1:49 AM, Deepak Kejriwal wrote: > Hi all, > > > > Please review the fix for following issues:- > > > > https://bugs.openjdk.java.net/browse/JDK-8214567 > > https://bugs.openjdk.java.net/browse/JDK-8214569 > > > > Below is the webrev for above issues: > > > > http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.00/ > > > > Regards, > > Deepak > From peter.levart at gmail.com Fri Dec 21 16:15:10 2018 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Dec 2018 17:15:10 +0100 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException In-Reply-To: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> References: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> Message-ID: <8ecf677b-16d4-c380-1b2d-5d2f09f85766@gmail.com> Hi Brian, This is really highly unlikely (1 in 2^800). In fact, it was not possible for this particular test to produce zero BigInteger. That's because the test uses a pseudo-random generator with deterministic algorithm and it uses a constant seed to initialize it before generating the next 2000 BigInteger random numbers with magnitude 0 ... 2^800 - 1: ? 33???????? Random rnd = new Random(1234); ? 34 ? 35???????? for (int i=0; i<2000; i++) { ? 36???????????? BigInteger m = new BigInteger(800, rnd); So if this test didn't fail with zero BigInteger when it is was run for the 1st time, then it can't fail in any other run, because the random numbers produced are the same in any run. But for the sake of correctness, let's pretend that the numbers are really random. Why pretend? Why not make them really random? By using SecureRandom instead with really random seed? Is it important for such test to be deterministic? Perhaps, so it can be re-executed with repeatable results in case it fails. So the middle ground would be to make the test undeterministic, but repeatable. By calculating a really random seed (using SecureRandom) and use that seed in a known deterministic pseudo-random generator (java.util.Random) while printing the used seed to the output log before executing the the test logic. In case the test fails, it can be repeated by providing the seed from the log of the failed execution... Just thinking loud. Not suggesting you really do anything like that to this test... Regards, Peter On 12/21/18 1:36 AM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8215759 > http://cr.openjdk.java.net/~bpb/8215759/webrev.00/ > > Although highly unlikely, the modulus parameter of modPow() can be zero which would provoke an ArithmeticException. > Unsure whether I need this bug ID in the @bug list. > > Thanks, > > Brian From brian.burkhalter at oracle.com Fri Dec 21 16:22:00 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Dec 2018 08:22:00 -0800 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException In-Reply-To: <8ecf677b-16d4-c380-1b2d-5d2f09f85766@gmail.com> References: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> <8ecf677b-16d4-c380-1b2d-5d2f09f85766@gmail.com> Message-ID: <8D1916F9-B9CA-4AEE-B6F5-7CC158069CE5@oracle.com> Hi Peter, > On Dec 21, 2018, at 8:15 AM, Peter Levart wrote: > > This is really highly unlikely (1 in 2^800). In fact, it was not possible for this particular test to produce zero BigInteger. That's because the test uses a pseudo-random generator with deterministic algorithm and it uses a constant seed to initialize it before generating the next 2000 BigInteger random numbers with magnitude 0 ... 2^800 - 1: > > 33 Random rnd = new Random(1234); > 34 > 35 for (int i=0; i<2000; i++) { > 36 BigInteger m = new BigInteger(800, rnd); > > So if this test didn't fail with zero BigInteger when it is was run for the 1st time, then it can't fail in any other run, because the random numbers produced are the same in any run. You might be correct for numBits == 800, but if one changes 800 to 8 it fails the first time. > But for the sake of correctness, let's pretend that the numbers are really random. Why pretend? Why not make them really random? By using SecureRandom instead with really random seed? > > Is it important for such test to be deterministic? Perhaps, so it can be re-executed with repeatable results in case it fails. > > So the middle ground would be to make the test undeterministic, but repeatable. By calculating a really random seed (using SecureRandom) and use that seed in a known deterministic pseudo-random generator (java.util.Random) while printing the used seed to the output log before executing the the test logic. In case the test fails, it can be repeated by providing the seed from the log of the failed execution... > > Just thinking loud. Not suggesting you really do anything like that to this test? Probably you are correct however about the randomness. It should be changed to use RandomFactory. Thanks, Brian From volker.simonis at gmail.com Fri Dec 21 16:34:22 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Dec 2018 17:34:22 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi Christoph, thanks for updating the change. I think it is in a good state now and ready to go! Also the documentation in the CSR for this issue ( https://bugs.openjdk.java.net/browse/JDK-8213082) is greatly appreciated and answers all the questions which have been raised so far. So if there are still any open questions I'd recommend that any potential reviewer consults the CSR at https://bugs.openjdk.java.net/browse/JDK-8213082 first. Thank you and best regards, Volker On Fri, Dec 21, 2018 at 3:31 PM Langer, Christoph wrote: > Hi all, > > here comes the updated webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/ > > I've rebased the change to the current state of the JDK depot. Thanks to > Volker, the test has been enhanced and now also tests more copy operations > (from zip file system to zip file system and from zip file system to > default file system and back). > > The points below were also addressed: > > > ZipFileAttributeView.java > > - can you please throw an AssertionError() for the default branch in > > the switch expression in the "ZipFileAttributeView.name()". > > The default branch will return "basic". Looking at the code it should not > be jumped to anyway. > > > ZipFileSystem.java > > - please also put @Override annotations on the method implementations > > from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and > > a comment at the place where the implementation of the > > "PosixFileAttributes" methods starts. > > Done, I also reordered the methods - first "basic" then "posix" then "zip". > > > ZipUtils.java > > - just a question: isn't it possible to reuse > > sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding > > constants from sun.nio.fs.UnixConstants instead of redefining them > > here? You could export them from java.base to jdk.zipfs but the > > problem is probably that at least sun.nio.fs.UnixConstants is a > > generated class which only gets generated on Unix systems, right ? > > You've already answered yourself ?? These classes only exist on Unix type > JDKs. > > > ZipFileAttributes.java > > - it seems a little odd that you've added "setPermissions()" to > > ZipFileAttributes. All the attribute classes (i.e. > > BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it > > possible to implement "ZipFileAttributeView.setPermissions()" by > > calling "path.setPermissions()" (as this is done in > > "ZipFileAttributeView.setTimes()") and handle everything in > > ZipFileSyste (as this is done with "setTimes()"). > > Good catch & thanks for providing the better implementation. > > > I think this version is quite final now and thoroughly tested. I hope to > get some valid reviews soon... > > Thanks > Christoph > > From mandy.chung at oracle.com Fri Dec 21 16:34:39 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 21 Dec 2018 08:34:39 -0800 Subject: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties In-Reply-To: References: Message-ID: <1df81a35-10b6-d75f-13d4-0fa0fc643a83@oracle.com> On 12/21/18 1:49 AM, Deepak Kejriwal wrote: > Hi all, > > Please review the fix for following issues:- > > https://bugs.openjdk.java.net/browse/JDK-8214567 > > https://bugs.openjdk.java.net/browse/JDK-8214569 > > Below is the webrev for above issues: > > http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.00/ > Looks okay. Like Alan suggests, reformating line 1867 in ClassLoader.java? to avoid that single long line sticking out would be good. Mandy From brian.burkhalter at oracle.com Fri Dec 21 16:36:37 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Dec 2018 08:36:37 -0800 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException In-Reply-To: <8D1916F9-B9CA-4AEE-B6F5-7CC158069CE5@oracle.com> References: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> <8ecf677b-16d4-c380-1b2d-5d2f09f85766@gmail.com> <8D1916F9-B9CA-4AEE-B6F5-7CC158069CE5@oracle.com> Message-ID: I updated the test to use RandomFactory: http://cr.openjdk.java.net/~bpb/8215759/webrev.01/ Thanks, Brian > On Dec 21, 2018, at 8:22 AM, Brian Burkhalter wrote: > > Probably you are correct however about the randomness. It should be changed to use RandomFactory. From volker.simonis at gmail.com Fri Dec 21 16:43:14 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Dec 2018 17:43:14 +0100 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: Hi Alan, thanks for looking at this issue. I've dived into the ZipFS implementation during the last weeks and together with Christoph we've extended and improved both the implementation the test coverage. As Christoph already emphasized, this change is only for improving jdk.nio.zipfs without any side effects on java.util.zip and java.util.jar. Please find my comments for the CSR below (for some reason I couldn't add them to the CSR directly). I'd really appreciate if you could reconsider reviewing Christoph's change ("RFR 8213031: (zipfs) Add support for POSIX file permissions") and CSR. Thank you, Volker ============================================= I've thoroughly looked at this proposal and honestly speaking, I don't think that we even need a CSR for the proposed enhancement. Only the implementation of some classes in the `jdk.nio.zipfs` package are changed but no publicly exported API's. As Christoph emphasized, the proposed changes **only** affect the Zip File System as implemented in the `jdk.nio.zipfs` package. It doesn't touch neither the implementation nor the behavior of any of the classes in the `java.util.zip` or `java.util.jar` packages. Previous reviewers of this CSR and of the corresponding change JDK-8213031 raised some concerns regarding the security implication of this change - especially in the context of signed jars. I've looked at these concerns but I couldn't find any evidence for problems because: - no exposed JAR functionality is affected by these changes (because that is handled by the implementation in `java.util.zip` and `java.util.jar`) - Jar signing doesn't take file attributes into account (even not the basic attributes like the modification time). It only hashes the file contents. You can already now use external zip tools to update the attributes of files in a signed archive without affecting the validity of the signature. For all these reasons I've reviewed this CSR and I kindly ask you to approve it. On Fri, Dec 21, 2018 at 2:43 PM Langer, Christoph wrote: > > Hi Alan, > > > Adding support for POSIX file permissions to the zip APIs is problematic > > as we've been discussing here. There are security concerns and also > > concerns that how it interacts with JAR files and signed JAR in > > particular. I don't disagree that we can come to agreement on zipfs > > supporting a solution but I think we need to get the bigger picture on > > where this is going first. If the piece to change the java.util.zip APIs > > is dropped then it would make these discussions a lot simpler as it > > removes most of the security issues from the table. > > Yes, please consider changes to java.util.zip APIs as dropped. At least for the moment. I'm not saying I won't ever get back to that topic but maybe an enhancement of jdk.zipfs is already sufficient to provide the required Posix permission support for the Java platform. > > Best regards > Christoph > From joe.darcy at oracle.com Fri Dec 21 17:45:48 2018 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 21 Dec 2018 09:45:48 -0800 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: <04f9501d-4a4d-be0e-74ff-0c9dd4978dc6@oracle.com> Hello, On 12/21/2018 8:43 AM, Volker Simonis wrote: > Hi Alan, > > thanks for looking at this issue. I've dived into the ZipFS > implementation during the last weeks and together with Christoph we've > extended and improved both the implementation the test coverage. As > Christoph already emphasized, this change is only for improving > jdk.nio.zipfs without any side effects on java.util.zip and > java.util.jar. > > Please find my comments for the CSR below (for some reason I couldn't > add them to the CSR directly). > To leave a comment on a CSR, using the "Comment" button at the top of the page or hit "Edit", rather than the "Comment" button at the bottom of the page (known bug). HTH, -Joe From stuart.marks at oracle.com Fri Dec 21 19:49:03 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 21 Dec 2018 11:49:03 -0800 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException In-Reply-To: References: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> <8ecf677b-16d4-c380-1b2d-5d2f09f85766@gmail.com> <8D1916F9-B9CA-4AEE-B6F5-7CC158069CE5@oracle.com> Message-ID: On 12/21/18 8:36 AM, Brian Burkhalter wrote: > I updated the test to use RandomFactory: > > http://cr.openjdk.java.net/~bpb/8215759/webrev.01/ Oddly enough, changing this to use RandomFactory instead of the fixed seed makes it MORE likely that the random modulus will be zero. But this is OK, since your original change prevents zero from occurring. Even if this test were to continue to use a fixed seed, I'd still be in favor of the change that prevents zero from occurring. Even though that couldn't happen in the original test, it would be a possibility if the source of randomness were changed in future maintenance and that maintainer didn't notice that zero would result in an error. In any case, the change looks fine. s'marks From brian.burkhalter at oracle.com Fri Dec 21 20:59:03 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Dec 2018 12:59:03 -0800 Subject: 8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException In-Reply-To: References: <0E8E7064-DA9E-4FC0-8C59-D22054DD281F@oracle.com> <8ecf677b-16d4-c380-1b2d-5d2f09f85766@gmail.com> <8D1916F9-B9CA-4AEE-B6F5-7CC158069CE5@oracle.com> Message-ID: <14113821-D75D-41BF-B70D-A24A02EA38A8@oracle.com> HI Stuart, > On Dec 21, 2018, at 11:49 AM, Stuart Marks wrote: > > On 12/21/18 8:36 AM, Brian Burkhalter wrote: >> I updated the test to use RandomFactory: >> http://cr.openjdk.java.net/~bpb/8215759/webrev.01/ > > Oddly enough, changing this to use RandomFactory instead of the fixed seed makes it MORE likely that the random modulus will be zero. But this is OK, since your original change prevents zero from occurring. Right. > Even if this test were to continue to use a fixed seed, I'd still be in favor of the change that prevents zero from occurring. Even though that couldn't happen in the original test, it would be a possibility if the source of randomness were changed in future maintenance and that maintainer didn't notice that zero would result in an error. > > In any case, the change looks fine. Thanks, Brian From stuart.marks at oracle.com Fri Dec 21 22:34:16 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 21 Dec 2018 14:34:16 -0800 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: References: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> <636451fa-45b8-1861-999a-c3fd3a26673c@oracle.com> Message-ID: <591dcb90-91f2-3bab-846a-747308ff84d7@oracle.com> Hi Kishor, I took a look at the patch you sent. It looks like it was created against an older repository, paerhaps jdk8u-dev. We don't make spec changes to the older releases. Please base your changes on the latest mainline repository, which is http://hg.openjdk.java.net/jdk/jdk/ Notably, the source file hierarchy has been reorganized since jdk8u. Even after accounting for filenames, the patch didn't apply, because conflicting changes had been introduced, mainly changes from to {@code} markup. The latter is now preferred for introducing code fragments in javadoc. Also use

    instead of
    to denote paragraphs, consistent with the rest of the javadoc in this file. (Tip: for attaching files that are primarily text -- including patches -- use a .txt suffix. While non-txt attachments often make it through email, they tend to get corrupted in the archives. Unfortunately, few people use .txt suffixes, so there are lots of corrupted attachments in the OpenJDK mail archives.) ** All that aside, the patch was basically a replacement for the first three paragraphs of the SortedSet class doc and as such wasn't difficult to deal with. Comments on the new text follow. > * A comparison method is either {@link Comparator#compare} or > * {@link Comparable#compareTo}, implemented by elements of this {@link Set}.

    The rule for javadoc is that the first sentence (actually sentence fragment) of a doc comment is considered as summary text for the class and is pulled into various index pages. So, keep the initial sentence fragment as it is. It's indeed good practice to introduce a term's definition ("comparison method") before its first use, but it can't displace the summary sentence. > * A {@link Set} that additionally provides ordering on its elements, using The original text said "total ordering". Not sure why this is changed simply to "ordering". The term "total ordering" has a precise definition and is important for this specification. > * comparison method. Client must provide comparison method either by making set > * elements {@link Comparable} or providing custom {@link Comparator} while set creation > * eg, {@linkplain TreeSet#TreeSet(Comparator)}. Furthermore, all set elements must be It's incorrect that the *client must provide* a Comparator or use Comparable elements. The original wording said that a Comparator is "typically provided" at construction time. The JDK implementations of SortedSet such as TreeSet and ConcurrentSkipListSet allow for this. However, it's reasonable for a subclass to provide its own comparison method, or for it to provide some other means (possibly implicitly) of selecting a comparison method, so it's not the case that the client must provide the comparison method. For the definition of "comparison method" it would be nice to define it as e1.compareTo(e2) if the elements are Comparable, or as compare(e1, e2) if a Comparator is in use. That way, these method names need not be repeated later, as they are in the original text. > * mutually comparable, that is comparison method must not throw > * ClassCastException for any two elements. Several additional operations are > * provided to take advantage of the ordering. (This interface is the set analogue of > * {@link SortedMap}.)

    The sentence from the original text, The set's iterator will traverse the set in ascending element order. seems to have been deleted. This is a very important part of the specification! It must remain. Another sentence from the original, regarding mutual comparability, Attempts to violate this restriction will cause the offending method or constructor invocation to throw a {@code ClassCastException}. has also been deleted. This is important too. In this case the issue is what happens if the elements aren't mutually comparable. Without this assertion, a SortedSet implementation would be free to ignore ClassCastExceptions. This sentence is important because it requires that proper SortedSet implementations propagate these exceptions to the caller. The "Attempts to violate" wording from the original is a bit odd, though. Not only is it possible to attempt to violate the restriction, such attempts will always succeed! I'd reword this to say "Violations of this restriction...." > * Unlike other {@link Set} implementations, eligibility of an element is decided by > * comparison method and not using {@link Object#equals}. OK, but "eligibility" needs to be defined. A Set has the invariant that no has no pair of elements e1 and e2 such that e1.equals(e2). A similar statement should be made here for SortedSet, except using the comparison method instead of equals(). > * The equals must > * be consistent with comparison method, ie if elementA is equals to elementB (according > * to equals), comparison method must return 0 (zero) for them and vice versa. If two > * elements are not equal (according to equals method), but returns 0 (zero) when > * compared (using comparison method) will be considered equal.

    This is unfortunately not correct at all. It's NOT a requirement that the comparison method be consistent with equals. You have to read the original text carefully to understand what it's saying. It does not say, Note that the ordering maintained by a sorted set...must be consistent with equals. Instead, it says, Note that the ordering maintained by a sorted set...must be consistent with equals if the sorted set is to correctly implement the Set interface. It's not terribly clear what this means -- which is one of the reasons this specification needs work -- but it's clear that consistency with equals is a conditional, not absolute requirement. The original spec attempts to clarify this (not very successfully, in my opinion) by later stating: The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the {@code Set} interface. There are a bunch of things going on here all at once. Let me try to unpack them. 1. Set has a well-defined behavior based on equals() 2. SortedSet has a well-defined behavior based on its comparison method, assuming the comparison method itself is well-behaved 3. the well-behavedness of a comparison method is defined in the Comparable and Comparator interface specifications 4. a comparison method is consistent with equals iff it returns zero when equals() returns true 5. a well-behaved comparison method need not be consistent with equals 6. it is strongly recommended that comparison methods be consistent with equals 7. a SortedSet conforms to the general contract of Set iff the SortedSet's comparison method is consistent with equals (Not all of this needs to be said in this specification; some of it is in the Set specification and some in the Comparator/Comparable specifications) Note that it is NOT AN ERROR for a comparison method to be inconsistent with equals. But what are the consequences of a comparison method being inconsistent with equals? If this occurs, the SortedSet still has well-defined and correct behavior according to its own specification, but it violates the specification requirements imposed by its superinterface Set. (Briefly restated, if a SortedSet uses a comparison method that is inconsistent with equals, it is not Liskov-substitutable for a Set.) That's what this section is trying to say. It's really trying to thread a needle. It's describing a situation that is unusual and that might result in unexpected behavior, but one that is not incorrect and one that isn't illegal. ** So, what next? You probably have to start over, given that you need to switch over to work against the mainline source base anyway. I'd suggest starting from the existing text and working on a single issue, such as the definition of "comparison method". Work a definition of this into the first paragraph, and then edit the subsequent paragraphs to use "comparison method" instead of the clumsy compareTo-or-compare text that occurs later on. This will help set up for subsequent revisions, including the "consistent with equals" discussion and the definition of eligibility for set membership. Thanks, s'marks From andrewluotechnologies at outlook.com Sat Dec 22 03:19:22 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sat, 22 Dec 2018 03:19:22 +0000 Subject: [PATCH] Remove unused variables in io_util_md.c handleLseek Message-ID: While looking through this code debugging another issue I noticed there were some extra unused local variables. Patch is inline below. Thanks, -Andrew diff --git a/src/java.base/windows/native/libjava/io_util_md.c b/src/java.base/windows/native/libjava/io_util_md.c --- a/src/java.base/windows/native/libjava/io_util_md.c +++ b/src/java.base/windows/native/libjava/io_util_md.c @@ -559,8 +559,6 @@ handleLseek(FD fd, jlong offset, jint whence) { LARGE_INTEGER pos, distance; - DWORD lowPos = 0; - long highPos = 0; DWORD op = FILE_CURRENT; HANDLE h = (HANDLE)fd; From forax at univ-mlv.fr Sun Dec 23 10:57:15 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 23 Dec 2018 11:57:15 +0100 (CET) Subject: enhanced for loop with multiple iteration variables In-Reply-To: References: <6FCA90E1-EE80-4F5F-84BB-102ABF0588B0@cbfiddle.com> <6548d44a-3c8f-3f1f-8160-4bd425e9da0c@oracle.com> <1754329726.1013464.1545346834867.JavaMail.zimbra@u-pem.fr> Message-ID: <729024926.1305975.1545562635579.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Snyder" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Vendredi 21 D?cembre 2018 03:20:46 > Objet: Re: enhanced for loop with multiple iteration variables > Lambdas are clean, but limited in current Java compared to nested blocks. > > Are full featured lambdas on the horizon? not in the immediate future, co-routine, sealed class, record, pattern matching, value type and reified generics are the next features. > > If not, then we still need loops and iterators. > > Alan R?mi > > > > >> On Dec 20, 2018, at 3:00 PM, Remi Forax wrote: >> >> or >> map.forEach((key, value) -> { >> ... >> }); >> >> R?mi >> >> ----- Mail original ----- >>> De: "Brian Goetz" >>> ?: "Alan Snyder" , "core-libs-dev" >>> >>> Envoy?: Jeudi 20 D?cembre 2018 23:50:15 >>> Objet: Re: enhanced for loop with multiple iteration variables >> >>> For Map, you can do: >>> >>> for (Map.Entry e : map.entrySet()) { ... } >>> >>> and you're already there. >>> >>> >>> >>> On 12/19/2018 9:54 AM, Alan Snyder wrote: >>>> Has any consideration been given to supporting iterators that provide more than >>>> one iteration variable in the enhanced for loop? >>>> >>>> Obvious uses would be maps (keys and values) and lists (indexes and values). >>>> >>>> I have in mind keeping the syntactic sugar approach by using one or more >>>> extensions of the Iterator/Iterable interfaces, such as, for example: >>>> >>>> interface Iterator2 extends Iterator { >>>> E2 get2(); >>>> } >>>> >>>> with the extra methods providing the values for the extra variables (associated >>>> with the previous call to next). >>>> >>>> Extending interfaces is not required, but it makes the trailing variables >>>> optional, which might be useful. For example, the same iterator could provide >>>> values or values and keys. >>>> >>>> The fact that this approach only works for a fixed set of numbers of variables >>>> does not bother me unduly. >>>> >>>> Alan From andy.herrick at oracle.com Sun Dec 23 13:25:58 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 23 Dec 2018 08:25:58 -0500 Subject: jpackage EA Build 0 In-Reply-To: References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: <18428e07-a146-5d56-57ab-c90d3153b350@oracle.com> When there is a --files arg this works as expected, all jars are added to the classpath in the config file. When there is no --files arg, only the jar files at the top level of the input dir are added to the classpath in the config file. I filed? bug JDK-8215900 and will be fixing soon. /Andy On 12/19/2018 4:57 PM, Scott Palmer wrote: > If the main jar is in a subfolder the .cfg file is written incorrectly leading to: > > Error: Could not find or load main class > Caused by: java.lang.ClassNotFoundException: > > Which I only found by manually running: > > ./MyApp.app/Contents/MacOS/MyApp > > as double clicking doesn?t seem to show that output anywhere (I tried to find it in the Console.app output, but didn?t). > > In my case the main jar is in a ?libs? subfolder. The image is built correctly, with the subfolder under the ?Java? folder in the Mac application bundle. However, the cfg file had: > > app.mainjar=MyMainJar-1.0.0.jar > > instead of: > > app.mainjar=libs/MyMainJar-1.0.0.jar > > > When I manually made that edit, it started to work. > > > Scott > > >> On Dec 14, 2018, at 7:46 AM, Andy Herrick wrote: >> >> I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ >> >> This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, >> >> This build is intended for developers interested in jpackage, and is provided as a convenience so that they don't need to build from the source code (branch="JDK-8200758-branch"). >> >> Warning: This build is based on an incomplete version of JDK 12 . >> >> Please send feedback via e-mail to core-libs-dev at openjdk.java.net >> >> /Andy >> From clement at unportant.info Sun Dec 23 19:06:07 2018 From: clement at unportant.info (=?ISO-8859-1?Q?Cl=E9ment?= MATHIEU) Date: Sun, 23 Dec 2018 20:06:07 +0100 Subject: UnicodeDecoder U+FFFE handling Message-ID: Hi, I am wondering if UnicodeDecoder handling of U+FFFE is compliant with current Unicode specification. Supsicious code is: if (c == REVERSED_MARK) { // A reversed BOM cannot occur within middle of stream return CoderResult.malformedForLength(2); } Up to Unicode 6.3 Unicode specification said that U+FFFE is a non character and that non characters "should never been interchanged". Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8 (Unicode 6.2). However, Unicode 7 changed that and now says: Applications are free to use any of these noncharacter code points internally. They have no standard interpretation when exchanged outside the context of internal use. However, they are not illegal in interchange, nor does their presence cause Unicode text to be ill-formed. [...] They are not prohibited from occurring in valid Unicode strings which happen to be in terchanged. [...]. If a noncharacter is received in open interchange, an application is not required to interpret it in any way. It is good practice, however, to recognize it as a noncharacter and to take appropriate action, such as replacing it with U+FFFD replacement character, to indicate the problem in the text. It is not recommended to simpl y delete noncharacter code points from such text, because of the potential security issues caused by deleting uninterpreted characters. See: - http://www.unicode.org/versions/corrigendum9.html - https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7) Do you think that returning CR_MALFORMED is still OK? Regards, Cl?ment MATHIEU From deepak.kejriwal at oracle.com Mon Dec 24 09:17:30 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 24 Dec 2018 01:17:30 -0800 (PST) Subject: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties In-Reply-To: <1df81a35-10b6-d75f-13d4-0fa0fc643a83@oracle.com> References: <1df81a35-10b6-d75f-13d4-0fa0fc643a83@oracle.com> Message-ID: <22241019-cffb-4305-adf6-9a0d531e913c@default> Hi Mandy / Alan, ? Thanks for review. I have modified the ClassLoader.java as per the given comments. ? Please find updated version of webrev:- ? http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.01/ ? Regards, Deepak ? From: Mandy Chung Sent: Friday, December 21, 2018 10:05 PM To: Deepak Kejriwal Cc: core-libs-dev Subject: Re: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties ? ? On 12/21/18 1:49 AM, Deepak Kejriwal wrote: Hi all, ? Please review the fix for following issues:- ? https://bugs.openjdk.java.net/browse/JDK-8214567 ? https://bugs.openjdk.java.net/browse/JDK-8214569 ? Below is the webrev for above issues: ? http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.00/ ? Looks okay. Like Alan suggests, reformating line 1867 in ClassLoader.java? to avoid that single long line sticking out would be good. Mandy From philipp.kunz at paratix.ch Mon Dec 24 22:42:47 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 24 Dec 2018 23:42:47 +0100 Subject: Wrong statement suspected in jar.html Message-ID: <1545691367.2502.23.camel@paratix.ch> Hi, https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature-val idation says: When the jar tool is used to add files, the manifest file is changed (s ections are added to it for the new files), but the signature file is n ot. It appears to me that using the jar tool to add files to a jar file does not change the jar manifest. The jar manifest is changed by the jarsigner tool when signing the jar. I haven't found the sources of that referenced jar.html and therefore I'm not sure whether my concern still currently applies or has been fixed since JDK 10. I'm also not sure where and how to report this issue. I'd be glad if someone could point me to the right place or forward this message accordingly. A suggested alternative for the sentence in question might be to delete it without replacement. In my opinion, the remaining text would look fine like this: One reason the digest value of the manifest file that is stored in the x-Digest-Manifest attribute may not equal the digest value of the current manifest file is that one or more files were added to the JAR file (using the jar tool) after the signature (and thus the signature file) was generated. A verification is still considered successful if none of the files that were in the JAR file when the signature was generated have been changed since then, which is the case if the digest values in the non-header sections of the signature file equal the digest values of the corresponding sections in the manifest file. When at it already, let me mention that I'm not entirely sure if the term "non-header sections" fits the context optimally. What about "individual sections" or "source file information sections" instead? Philipp From weijun.wang at oracle.com Tue Dec 25 00:37:06 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Dec 2018 08:37:06 +0800 Subject: Wrong statement suspected in jar.html In-Reply-To: <1545691367.2502.23.camel@paratix.ch> References: <1545691367.2502.23.camel@paratix.ch> Message-ID: <4441ACBD-3D02-425C-99BF-21CCDA904AB3@oracle.com> More precisely, it should be something like: If the JAR file is resigned by a different signer after new files were added, the manifest file is changed (sections are added to it for the new files) and a new signature file is created, but the original signature file is unchanged. According to spec of Manifest, the "header" is called the main attributes and all the others manifest entries. And yes, this is the correct mail list to talk about this issue. I also have no idea where the source of that tooldoc is. Someone on the list should know. Thanks, Max > On Dec 25, 2018, at 6:42 AM, Philipp Kunz wrote: > > Hi, > > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature-val > idation says: > When the jar tool is used to add files, the manifest file is changed > (s > ections are added to it for the new files), but the signature file is > n > ot. > > It appears to me that using the jar tool to add files to a jar file > does not change the jar manifest. The jar manifest is changed by the > jarsigner tool when signing the jar. > > I haven't found the sources of that referenced jar.html and therefore > I'm not sure whether my concern still currently applies or has been > fixed since JDK 10. > > I'm also not sure where and how to report this issue. I'd be glad if > someone could point me to the right place or forward this message > accordingly. > > A suggested alternative for the sentence in question might be to delete > it without replacement. In my opinion, the remaining text would look > fine like this: > One reason the digest value of the manifest file that is stored in the > x-Digest-Manifest attribute may not equal the digest value of the > current manifest file is that one or more files were added to the JAR > file (using the jar tool) after the signature (and thus the signature > file) was generated. A verification is still considered successful if > none of the files that were in the JAR file when the signature was > generated have been changed since then, which is the case if the digest > values in the non-header sections of the signature file equal the > digest values of the corresponding sections in the manifest file. > > When at it already, let me mention that I'm not entirely sure if the > term "non-header sections" fits the context optimally. What about > "individual sections" or "source file information sections" instead? > > Philipp From philipp.kunz at paratix.ch Tue Dec 25 09:27:01 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 25 Dec 2018 10:27:01 +0100 Subject: Wrong statement suspected in jar.html In-Reply-To: <4441ACBD-3D02-425C-99BF-21CCDA904AB3@oracle.com> References: <1545691367.2502.23.camel@paratix.ch> <4441ACBD-3D02-425C-99BF-21CCDA904AB3@oracle.com> Message-ID: <1545730021.2502.25.camel@paratix.ch> Hi Max, Your proposed sentence looks good to me. Certainly better than removing it. Two points that could hardly be less important: I'm not native English but the word "resign" came to my attention. A look into a dictionary told me it already has a meaning completely unrelated to signing. Would a hyphen help as in "re-sign"? Or maybe something like "signed again afterwards"? It might have struck me as well unjustified. You may be right about referring to main attributes as manifest header but I did not find such a definition or explanation in https://docs.oracle.com/javase/10/docs/specs/jar/jar.html. To some extent the way it is now, I still think, in my opinion, the term "header" in "non-header section" is ambiguous and confusing. Philipp On Tue, 2018-12-25 at 08:37 +0800, Weijun Wang wrote: > More precisely, it should be something like: > > If the JAR file is resigned by a different signer after new files > were added, the manifest file is changed (sections are added to it > for the new files) and a new signature file is created, but the > original signature file is unchanged. > > According to spec of Manifest, the "header" is called the main > attributes and all the others manifest entries. > > And yes, this is the correct mail list to talk about this issue. I > also have no idea where the source of that tooldoc is. Someone on the > list should know. > > Thanks, > Max > > > On Dec 25, 2018, at 6:42 AM, Philipp Kunz > > wrote: > > > > Hi, > > > > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature > > -val > > idation says: > > When the jar tool is used to add files, the manifest file is > > changed? > > (s > > ections are added to it for the new files), but the signature file > > is? > > n > > ot. > > > > It appears to me that using the jar tool to add files to a jar file > > does not change the jar manifest. The jar manifest is changed by > > the > > jarsigner tool when signing the jar. > > > > I haven't found the sources of that referenced jar.html and > > therefore > > I'm not sure whether my concern still currently applies or has been > > fixed since JDK 10. > > > > I'm also not sure where and how to report this issue. I'd be glad > > if > > someone could point me to the right place or forward this message > > accordingly. > > > > A suggested alternative for the sentence in question might be to > > delete > > it without replacement. In my opinion, the remaining text would > > look > > fine like this: > > One reason the digest value of the manifest file that is stored in > > the > > x-Digest-Manifest attribute may not equal the digest value of the > > current manifest file is that one or more files were added to the > > JAR > > file (using the jar tool) after the signature (and thus the > > signature > > file) was generated. A verification is still considered successful > > if > > none of the files that were in the JAR file when the signature was > > generated have been changed since then, which is the case if the > > digest > > values in the non-header sections of the signature file equal the > > digest values of the corresponding sections in the manifest file. > > > > When at it already, let me mention that I'm not entirely sure if > > the > > term "non-header sections" fits the context optimally. What about > > "individual sections" or "source file information sections" > > instead? > > > > Philipp From weijun.wang at oracle.com Tue Dec 25 09:33:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Dec 2018 17:33:19 +0800 Subject: Wrong statement suspected in jar.html In-Reply-To: <1545730021.2502.25.camel@paratix.ch> References: <1545691367.2502.23.camel@paratix.ch> <4441ACBD-3D02-425C-99BF-21CCDA904AB3@oracle.com> <1545730021.2502.25.camel@paratix.ch> Message-ID: > On Dec 25, 2018, at 5:27 PM, Philipp Kunz wrote: > > Hi Max, > Your proposed sentence looks good to me. Certainly better than removing > it. Two points that could hardly be less important: > > I'm not native English but the word "resign" came to my attention. A > look into a dictionary told me it already has a meaning completely > unrelated to signing. Would a hyphen help as in "re-sign"? Or maybe > something like "signed again afterwards"? It might have struck me as > well unjustified. Good catch. Neither am I a native English speaker and I think "re-sign" is good. > > You may be right about referring to main attributes as manifest header > but I did not find such a definition or explanation in > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html. > To some extent the way it is now, I still think, in my opinion, the > term "header" in "non-header section" is ambiguous and confusing. The doc does have "Main Attributes" and "Per-Entry Attributes". But maybe if someone is able to understand the sign and re-sign change, there is no difficulty understanding these different sections. --Max > > Philipp > > > On Tue, 2018-12-25 at 08:37 +0800, Weijun Wang wrote: >> More precisely, it should be something like: >> >> If the JAR file is resigned by a different signer after new files >> were added, the manifest file is changed (sections are added to it >> for the new files) and a new signature file is created, but the >> original signature file is unchanged. >> >> According to spec of Manifest, the "header" is called the main >> attributes and all the others manifest entries. >> >> And yes, this is the correct mail list to talk about this issue. I >> also have no idea where the source of that tooldoc is. Someone on the >> list should know. >> >> Thanks, >> Max >> >>> On Dec 25, 2018, at 6:42 AM, Philipp Kunz >>> wrote: >>> >>> Hi, >>> >>> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature >>> -val >>> idation says: >>> When the jar tool is used to add files, the manifest file is >>> changed >>> (s >>> ections are added to it for the new files), but the signature file >>> is >>> n >>> ot. >>> >>> It appears to me that using the jar tool to add files to a jar file >>> does not change the jar manifest. The jar manifest is changed by >>> the >>> jarsigner tool when signing the jar. >>> >>> I haven't found the sources of that referenced jar.html and >>> therefore >>> I'm not sure whether my concern still currently applies or has been >>> fixed since JDK 10. >>> >>> I'm also not sure where and how to report this issue. I'd be glad >>> if >>> someone could point me to the right place or forward this message >>> accordingly. >>> >>> A suggested alternative for the sentence in question might be to >>> delete >>> it without replacement. In my opinion, the remaining text would >>> look >>> fine like this: >>> One reason the digest value of the manifest file that is stored in >>> the >>> x-Digest-Manifest attribute may not equal the digest value of the >>> current manifest file is that one or more files were added to the >>> JAR >>> file (using the jar tool) after the signature (and thus the >>> signature >>> file) was generated. A verification is still considered successful >>> if >>> none of the files that were in the JAR file when the signature was >>> generated have been changed since then, which is the case if the >>> digest >>> values in the non-header sections of the signature file equal the >>> digest values of the corresponding sections in the manifest file. >>> >>> When at it already, let me mention that I'm not entirely sure if >>> the >>> term "non-header sections" fits the context optimally. What about >>> "individual sections" or "source file information sections" >>> instead? >>> >>> Philipp From lance.andersen at oracle.com Tue Dec 25 18:06:08 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 25 Dec 2018 13:06:08 -0500 Subject: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties In-Reply-To: <22241019-cffb-4305-adf6-9a0d531e913c@default> References: <1df81a35-10b6-d75f-13d4-0fa0fc643a83@oracle.com> <22241019-cffb-4305-adf6-9a0d531e913c@default> Message-ID: <0D77717A-8D90-4720-A4C4-F7EAF4A82DA5@oracle.com> Hi Deeoak, The changes look fine. Happy Holidays > On Dec 24, 2018, at 4:17 AM, Deepak Kejriwal wrote: > > Hi Mandy / Alan, > > > > Thanks for review. I have modified the ClassLoader.java as per the given comments. > > > > Please find updated version of webrev:- > > > > http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.01/ > > > > Regards, > > Deepak > > > > From: Mandy Chung > Sent: Friday, December 21, 2018 10:05 PM > To: Deepak Kejriwal > Cc: core-libs-dev > Subject: Re: [12] RFR: 8214567 and 8214569: Use {@systemProperty} for definitions of system properties > > > > > > On 12/21/18 1:49 AM, Deepak Kejriwal wrote: > > Hi all, > > Please review the fix for following issues:- > > https://bugs.openjdk.java.net/browse/JDK-8214567 > > https://bugs.openjdk.java.net/browse/JDK-8214569 > > Below is the webrev for above issues: > > http://cr.openjdk.java.net/~rpatil/8214567%2b8214569/webrev.00/ > > > > Looks okay. > > Like Alan suggests, reformating line 1867 in ClassLoader.java to avoid that single long line sticking out would be good. > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From weijun.wang at oracle.com Wed Dec 26 00:40:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Dec 2018 08:40:05 +0800 Subject: Wrong statement suspected in jar.html In-Reply-To: <4441ACBD-3D02-425C-99BF-21CCDA904AB3@oracle.com> References: <1545691367.2502.23.camel@paratix.ch> <4441ACBD-3D02-425C-99BF-21CCDA904AB3@oracle.com> Message-ID: <297CD7BB-BAE7-42ED-961E-5B289196F983@oracle.com> I was told that the source in an internal repo. It's not a part of OpenJDK and we will fix it. Thanks, Max > On Dec 25, 2018, at 8:37 AM, Weijun Wang wrote: > > And yes, this is the correct mail list to talk about this issue. I also have no idea where the source of that tooldoc is. Someone on the list should know. From amaembo at gmail.com Sun Dec 30 02:11:56 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 30 Dec 2018 09:11:56 +0700 Subject: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode() In-Reply-To: References: <6659b8fb-f9e0-2197-34b6-d635033a4916@oracle.com> <01cc8978-e528-b07d-58ef-e998d23d5b43@oracle.com> <25109081544556351@myt5-b94652e6921b.qloud-c.yandex.net> Message-ID: Hello! I managed to push the change by myself: http://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 This is my first push in a committer role. Hopefully I did not mess anything up. With best regards, Tagir Valeev. On Thu, Dec 13, 2018 at 12:33 PM Tagir Valeev wrote: > > Hello, Zheka! > > I'm not sure whether it's possible to commit a patch which is > partially contributed by another person. Probably you should submit it > separately? Also for complete patch a testcase would be necessary. > > With best regards, > Tagir Valeev. > On Thu, Dec 13, 2018 at 11:48 AM Zheka Kozlov wrote: > > > > OK, this is a fixed version: > > > > @Override > > public void forEach(Consumer action) { > > Objects.requireNonNull(action); > > final int n = this.n; > > final E e = this.element; > > for (int i = 0; i < n; i++) { > > action.accept(e); > > } > > } > > > > Tagir, can you add this to your patch? I signed the OCA. > > > > > > ??, 12 ???. 2018 ?. ? 11:25, Martin Buchholz : > >> > >> I used to believe that, but apparently I was wrong. > >> https://openjdk.markmail.org/thread/rfqfultw35i2az45 > >> > >> On Tue, Dec 11, 2018 at 8:14 PM Zheka Kozlov wrote: > >>> > >>> Would be better to add @Stable to the fields instead? (`n` and `element` are final, so @Stable is OK here) > >>> > >>> ??, 12 ???. 2018 ?. ? 11:02, Martin Buchholz : > >>>>> > >>>>> In performance critical code, we don't trust hotspot to not reload final fields. Other forEach methods do this, e.g. > >>>> > >>>> > >>>> final Object[] es = queue; > >>>> for (int i = 0, n = size; i < n; i++) > >>>> action.accept((E) es[i]); > >>>> From sergei.tsypanov at yandex.ru Sun Dec 30 07:23:15 2018 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Sun, 30 Dec 2018 09:23:15 +0200 Subject: latest changes in java.lang.Class In-Reply-To: <18296701545994298@iva3-2961a207771d.qloud-c.yandex.net> Message-ID: <16834491546154595@sas1-ea1d14049a51.qloud-c.yandex.net> Hi, looking into Class::methodToString I've found some changes done into it recently in JDK 11 repository. Currently the method looks like this: private String methodToString(String name, Class[] argTypes) { ??? StringBuilder sb = new StringBuilder(); ??? sb.append(getName() + "." + name + "("); ??? if (argTypes != null) { ??????? Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). ??????????? collect(Collectors.joining(",")); ??? } ??? sb.append(")"); ??? return sb.toString(); } Here result of Stream.collect() is ignored, i. e. even when condition argTypes != null is true nothing is appended to sb. It seems in this case we either don?t need this `if` branch or need to append to sb. Am I missing something? Kind regards, Sergey Tsypanov From andrewluotechnologies at outlook.com Sun Dec 30 12:16:32 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sun, 30 Dec 2018 12:16:32 +0000 Subject: latest changes in java.lang.Class In-Reply-To: <16834491546154595@sas1-ea1d14049a51.qloud-c.yandex.net> References: <18296701545994298@iva3-2961a207771d.qloud-c.yandex.net> <16834491546154595@sas1-ea1d14049a51.qloud-c.yandex.net> Message-ID: Stream.of should not be used with null. https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html#of-T- I think you'd be right if it were Stream.ofNullable, and there does appear to be a bug in that code (never appended to sb) - thanks for pointing that out... Thanks, -Andrew -----Original Message----- From: core-libs-dev On Behalf Of ?????? ??????? Sent: Saturday, December 29, 2018 11:23 PM To: core-libs-dev Subject: latest changes in java.lang.Class Hi, looking into Class::methodToString I've found some changes done into it recently in JDK 11 repository. Currently the method looks like this: private String methodToString(String name, Class[] argTypes) { ??? StringBuilder sb = new StringBuilder(); ??? sb.append(getName() + "." + name + "("); ??? if (argTypes != null) { ??????? Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). ??????????? collect(Collectors.joining(",")); ??? } ??? sb.append(")"); ??? return sb.toString(); } Here result of Stream.collect() is ignored, i. e. even when condition argTypes != null is true nothing is appended to sb. It seems in this case we either don?t need this `if` branch or need to append to sb. Am I missing something? Kind regards, Sergey Tsypanov From swpalmer at gmail.com Sun Dec 30 17:00:56 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 30 Dec 2018 12:00:56 -0500 Subject: latest changes in java.lang.Class In-Reply-To: References: <18296701545994298@iva3-2961a207771d.qloud-c.yandex.net> <16834491546154595@sas1-ea1d14049a51.qloud-c.yandex.net> Message-ID: The string concatenation nested in the append argument is also strange. Won?t javac make an new StringBuilder to handle that? And single character appends should be done with chars ?.? not strings ?.? Scott > On Dec 30, 2018, at 7:16 AM, Andrew Luo wrote: > > Stream.of should not be used with null. > > https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html#of-T- > > I think you'd be right if it were Stream.ofNullable, and there does appear to be a bug in that code (never appended to sb) - thanks for pointing that out... > > Thanks, > > -Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of ?????? ??????? > Sent: Saturday, December 29, 2018 11:23 PM > To: core-libs-dev > Subject: latest changes in java.lang.Class > > Hi, > > looking into Class::methodToString I've found some changes done into it recently in JDK 11 repository. > > Currently the method looks like this: > > private String methodToString(String name, Class[] argTypes) { > StringBuilder sb = new StringBuilder(); > sb.append(getName() + "." + name + "("); > if (argTypes != null) { > Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). > collect(Collectors.joining(",")); > } > sb.append(")"); > return sb.toString(); > } > > Here result of Stream.collect() is ignored, i. e. even when condition argTypes != null is true nothing is appended to sb. > It seems in this case we either don?t need this `if` branch or need to append to sb. > > Am I missing something? > > Kind regards, > Sergey Tsypanov