From stuart.marks at oracle.com Fri Mar 1 02:43:44 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 28 Feb 2019 18:43:44 -0800 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams Message-ID: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Hi all, Please review and comment on this proposal to allow Stream instances to be used in enhanced-for ("for-each") loops. Abstract Occasionally it's useful to iterate a Stream using a conventional loop. However, the Stream interface doesn't implement Iterable, and therefore streams cannot be used with the enhanced-for statement. This is a proposal to remedy that situation by introducing a new interface IterableOnce that is a subtype of Iterable, and then retrofitting the Stream interface to implement it. Other JDK classes will also be retrofitted to implement IterableOnce. Full Proposal: http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html Bug report: https://bugs.openjdk.java.net/browse/JDK-8148917 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ Note, this changeset isn't ready to push yet. In particular, it has no tests yet. However, the implementation is so simple that I figured I should include it. Comments on the specification wording are also welcome. Thanks, s'marks From alexander.matveev at oracle.com Fri Mar 1 04:56:49 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 28 Feb 2019 20:56:49 -0800 Subject: RFR: JDK-8219889 : Update jpackage tests for JDK-8219678 changes Message-ID: <47ab7977-e251-755c-9be1-689bce9eb7f6@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Remove JPackageCreateImageOverwriteTest and JPackageCreateImageStripNativeCommandsTest. - Remove usage of --overwrite. [1] https://bugs.openjdk.java.net/browse/JDK-8219889 [2] http://cr.openjdk.java.net/~almatvee/8219889/webrev.00/ Thanks, Alexander From amaembo at gmail.com Fri Mar 1 05:34:02 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 1 Mar 2019 12:34:02 +0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: Hello! The proposal looks good to me. In particular it's very nice to have this properly (ability to iterate only once) to be encoded in the type system. This could be helpful for static analysis tools to warn when IterableOnce is reused. Scanner case looks funny. In general such pattern could be applied to every Iterator implementor. As for Streams, I worry a little that people would prefer for(T t : stream) {...} over stream.forEach(t -> ...) even when forEach works perfectly. The Stream.iterator() implementation produces some amount of unnecessary garbage. At least it would be nice to add special case into Spliterators#iterator(java.util.Spliterator) to reduce number of wrappers if stream was directly created from an iterator or collection: --- src/java.base/share/classes/java/util/Spliterators.java (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) +++ src/java.base/share/classes/java/util/Spliterators.java (date 1551417931182) @@ -665,6 +665,24 @@ */ public static Iterator iterator(Spliterator spliterator) { Objects.requireNonNull(spliterator); + if (spliterator instanceof IteratorSpliterator) { + @SuppressWarnings("unchecked") + IteratorSpliterator wrapper = (IteratorSpliterator) spliterator; + wrapper.estimateSize(); // force initialization + Iterator it = Objects.requireNonNull(wrapper.it); + // Avoid exposing the remove() method of original iterator; too bad there's no way to avoid this if remove() is not implemented :( + return new Iterator<>() { + @Override + public boolean hasNext() { + return it.hasNext(); + } + + @Override + public T next() { + return it.next(); + } + }; + } class Adapter implements Iterator, Consumer { boolean valueReady = false; T nextElement; Of course this could be done later as separate enhancement. On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: > > Hi all, > > Please review and comment on this proposal to allow Stream instances to be used > in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream using a conventional loop. However, > the Stream interface doesn't implement Iterable, and therefore streams cannot be > used with the enhanced-for statement. This is a proposal to remedy that > situation by introducing a new interface IterableOnce that is a subtype of > Iterable, and then retrofitting the Stream interface to implement it. Other JDK > classes will also be retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no tests > yet. However, the implementation is so simple that I figured I should include > it. Comments on the specification wording are also welcome. > > Thanks, > > s'marks From amaembo at gmail.com Fri Mar 1 05:54:04 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 1 Mar 2019 12:54:04 +0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: One more alternative which could be considered (though it requires a language change) is to allow the inference of Iterable type for enhanced for when iteration value is a function expression and iteration parameter type is explicitly specified as T. In this case for(T t : stream::iterator) {} would be a valid syntax. Also people could use enhanced for with any iterator they already have like for(T t : () -> iterator) {}. Instead of for (; it.hasNext() ; ) { T t = it.next(); ... }. It looks better than allowing to specify iterator directly (like for(T t : stream.iterator())) as this could break some programs where the same class implements Iterator and Iterable. With best regards, Tagir Valeev. On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: > > Hi all, > > Please review and comment on this proposal to allow Stream instances to be used > in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream using a conventional loop. However, > the Stream interface doesn't implement Iterable, and therefore streams cannot be > used with the enhanced-for statement. This is a proposal to remedy that > situation by introducing a new interface IterableOnce that is a subtype of > Iterable, and then retrofitting the Stream interface to implement it. Other JDK > classes will also be retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no tests > yet. However, the implementation is so simple that I figured I should include > it. Comments on the specification wording are also welcome. > > Thanks, > > s'marks From adam.farley at uk.ibm.com Fri Mar 1 10:31:30 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 1 Mar 2019 10:31:30 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Mandy, Historically, the bigger the change I propose, the more months it takes the OpenJDK community to approve. I'm not sure I can justify adding an entire class to test a very specific case. Additionally, HasFields seems excessively complex. I don't understand why it feels the need to spend 34 lines of code parsing, processing, and storing 20 minimal variables it already has. Seems like an informative comment, followed by a littany of "cases.add..." would have been a simpler choice. Could you tell me if I'm missing something? Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 21/02/2019 17:37:54: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 21/02/2019 17:41 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > > On 2/14/19 3:16 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > Apologies for the delay. > > Same here as I returned from vacation yesterday. > > > Could you review this cdiff as a proposal for the jtreg test? > > > > Made sense to modify the existing test set for MethodHandle rather than > > add a new one. > > Yes it'd be better if you extend the MethodHandlesGeneralTest and > MethodHandlesTest to test the write access. > > To add the test cases properly, MethodHandlesTest.HasFields > should be modified to include the read-only fields. It might > be cleaner to add a new HasReadOnlyFields class and maybe a new > TEST_SET_ACCESSIBLE bit that requests to call setAccessible(true) > and testSetter expects unreflectSetter to throw exception on > static final fields (possibly additional bits might be needed). > > Mandy > 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 christoph.langer at sap.com Fri Mar 1 10:34:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Mar 2019 10:34:38 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> Message-ID: <88a4a568362a42858671678271295195@sap.com> Hi Alan, thanks for diving into this and giving a comprehensive summary. I've just read it in detail now - and as always, it contains some very good findings and suggestions. I'll try to work these in and send an update in the next days. Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Montag, 25. Februar 2019 09:31 > To: Langer, Christoph > Cc: nio-dev ; Java Core Libs dev at openjdk.java.net> > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > On 21/02/2019 15:04, Langer, Christoph wrote: > > Hi Alan, > > > > here is the next > iteration:http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ > > > > I focused on your comments regarding implementation details: > > > > : > > Are there other major implementation points left? If not I guess we should > start refining the documentation... > > I think it would be useful to write down a summary of the proposal as > there are several detailed points that we've been discussing in this > thread that reviewers will need to understand the proposal before diving > into the implementation/patch.? This might also help getting the javadoc > aligned, and eventually the CSR. Here's where I think we are: > > 1. By default, a zip file system will have no support for the "posix" > and "owner" views of file attributes, this means the following will fail > with UOE: > > ? PosixFileAttributes attrs = Files.readAttributes(file, > PosixFileAttributes.class); > > and the zip file system's supportedFileAttributView method will not > include "posix". > > 2. Creating a zip file system with configuration parameter XXX set to > "true" will create the zip file system that supports > PosixFileAttributeView (and FileOwnerAttributeView). The current patch > names the configuration parameter "posix". That name might be misleading > as a configuration parameter as it conveys more than it actually does. > Something like "enablePosixFileAttributes" clear conveys that it enables > support for POSIX file attribute but might be a better wordy. > > The value in the configuration map is documented as Boolean but I think > we are allowing it to be the string representation of a Boolean, meaning > it can be "true" or "false" like we have with the "create" parameter. > > 3. The map of configurations parameters can optionally include the > parameters "defaultOwner", "defaultGroup", and "defaultPermissions" with > the default owner/group/permissions to return. These names seem okay to > me. > > For the owner/group, the parameter type can be > UserPrincipal/GroupPrincipal or strings. If the value is a String then > we need to decide if there is any validation. If I read the current > patch correctly then it doesn't do any validation - that might be okay > but minimally maybe we should disallow the empty string. > > If the defaultXXX parameters aren't present then the zip file > owner/group would be a sensible default. If the zip file is on a file > store that supports FileOwnerAttributeView then we've got the owner. If > the file store supports PosixFileAttributeView then we have a group > owner. If PosixFileAttributeView is not supported then using the owner > as the group is okay. I see the current patch as a fallback to fallback > to "" but I'd prefer not have that because it will be > very confusing to diagnose if there are issues. > > For defaultPermissions, the value is a Set or the > string representation. In the implementation, initPermissions can be > changed to use PosixFilePermissions.fromString as it does the > translation that we need. > > 4. As an alternative to the type safe access that PosixFileAttributeView > provides, the proposal is to document the "zip" view of file attributes. > Initially, it will admit to one file attribute for the permissions. The > current patch uses the name "storedPermissions" but it might be simpler > to use "permissions" so that "zip:permissions" and "posix:permissions" > are the same when the zip entry has permissions. With this support you > can write code like this: > ??? Set perms = (Set) > Files.getAttribute(file, "zip:permissions"); > > The cast is ugly of course but that's the consequence of not exposing > ZipFileAttributes in the API so there is no type token to specify on the > RHS. > > Documenting the "zip" view brings up a few issues, e.g. will > Files.readAttributes(file, "zip:*") reveal more than "permissions". For > this API it is okay for the map to attributes beyond the specified list. > > 5. There will be no support for specifying as POSIX FileAttribute to > createFile or createDirectory to atomically set the permissions when > creating a new file/directory, UOE will thrown as is is now. > > Is this a reasonable summary? > > -Alan From deepak.kejriwal at oracle.com Fri Mar 1 10:44:00 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 1 Mar 2019 02:44:00 -0800 (PST) Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat Message-ID: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> Hi All, Please review the back port of fix for JDK-8217609 to 8u-dev:- JBS report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.openjdk.java.net/browse/JDK- 8217609 Webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/ Master bug change set: http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17 Summary: Fix is backported from JDK 13 to JDK 8u and is not a clean backport. Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses version 33. Below are the differences between 8u and 13:- . The "jp.xml" version of JDK 8u does not contains "" node (). Therefore "N" which is part of fix is not added to file. . I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java" for JDK 8u. It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)" o The test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..). o The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras". The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u. Regards, Deepak From adinn at redhat.com Fri Mar 1 11:05:56 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 1 Mar 2019 11:05:56 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> Message-ID: <63686f52-532d-73be-85ea-3362fe346a3b@redhat.com> Hi Alan, On 17/02/2019 17:37, Alan Bateman wrote: > On 15/02/2019 17:13, Chris Hegarty wrote: >> : >> I see that there are changes to the Java SE Platform, namely to the >> MapMode constructor and an overload of MappedByteBuffer::force. I see >> these more as "enablers" in support of this feature ( rather than the >> core of the feature itself ). They can happen as part of the same >> changeset, or could possibly be pushed separately upfront. >> > Yes, the 2-arg force method is useful on its own and could be done in > advance (if Andrew wants). There are several detailed API issues with > this method but we should be able to agree those quickly (Andrew - these > are issues due to MBB being a ByteBuffer so we have to sort out - long > from/to vs. int index/size, the upper bound check against the limit > rather the capacity, and IAE vs. IIOBE - I'll put these in another > mail). Making map mode extensible is also something that can be done in > advance. The only piece that is would make it SE scope is the isSync > (was isPersistent) method but I don't think it is strictly needed to be > exposed initially. Having dealt with the above issues (including removing the isSync method) I have reclassified the scope of the JEP to JDK. I would like now to submit this JEP and begin review of the implementation patches. In particular, I'd like to proceed with the preparatory patches to i) make map mode extensible and ii) overload force. Is it ok to go ahead with this? 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 andy.herrick at oracle.com Fri Mar 1 13:23:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 1 Mar 2019 08:23:46 -0500 Subject: RFR: JDK-8219889 : Update jpackage tests for JDK-8219678 changes In-Reply-To: <47ab7977-e251-755c-9be1-689bce9eb7f6@oracle.com> References: <47ab7977-e251-755c-9be1-689bce9eb7f6@oracle.com> Message-ID: looks good - thanks /Andy On 2/28/2019 11:56 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Remove JPackageCreateImageOverwriteTest and > JPackageCreateImageStripNativeCommandsTest. > - Remove usage of --overwrite. > > [1] https://bugs.openjdk.java.net/browse/JDK-8219889 > > [2] http://cr.openjdk.java.net/~almatvee/8219889/webrev.00/ > > Thanks, > Alexander From aph at redhat.com Fri Mar 1 14:45:30 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Mar 2019 14:45:30 +0000 Subject: [8u-dev] Request for Approval: Backport of JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: References: <93782021-9223-428c-93d6-63d314c2d7ad@default> Message-ID: <45f0e8be-3fa3-ea3c-a3ae-61b76c0bcc6d@redhat.com> On 2/28/19 12:04 PM, Hohensee, Paul wrote: > I added the 'jdk8u-fix-request' tag to these issues. All should now be approved. -- 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 Fri Mar 1 15:34:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Mar 2019 15:34:49 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <63686f52-532d-73be-85ea-3362fe346a3b@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <63686f52-532d-73be-85ea-3362fe346a3b@redhat.com> Message-ID: <8a8bf163-c2f2-5272-0414-849b8dcceb2d@oracle.com> On 01/03/2019 11:05, Andrew Dinn wrote: > : > Having dealt with the above issues (including removing the isSync > method) I have reclassified the scope of the JEP to JDK. > > I would like now to submit this JEP and begin review of the > implementation patches. In particular, I'd like to proceed with the > preparatory patches to i) make map mode extensible and ii) overload > force. Is it ok to go ahead with this? > I haven't had time to look at the update webrev and wording in the JEP but "the plan" that we've converged on here seems good to me as the 2-arg force is usual on its own and having MapMode be extensible is consistent with the other extension points in this API. -Alan. From gnu.andrew at redhat.com Fri Mar 1 15:39:27 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Mar 2019 15:39:27 +0000 Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> Message-ID: On Fri, 1 Mar 2019 at 10:47, Deepak Kejriwal wrote: > > Hi All, > > > > Please review the back port of fix for JDK-8217609 to 8u-dev:- > > > > JBS report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.openjdk.java.net/browse/JDK- 8217609 > > Webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/ > > Master bug change set: http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17 > > Summary: > Fix is backported from JDK 13 to JDK 8u and is not a clean backport. Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses version 33. Below are the differences between 8u and 13:- > > . The "jp.xml" version of JDK 8u does not contains "" node (). Therefore "N" which is part of fix is not added to file. > > . I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java" for JDK 8u. It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)" > > o The test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..). > > o The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras". The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u. > > Regards, > > Deepak > > Patch looks good to me. Is there a bug/patch to backport to fix the CLDR converter in OpenJDK 8, so japanese.long.Eras are included? JDK-8217609 should have the label 'jdk8u-fix-request' added so it can be approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From henry.jen at oracle.com Fri Mar 1 15:45:58 2019 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 1 Mar 2019 07:45:58 -0800 Subject: RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris) In-Reply-To: References: Message-ID: <30CF8EDF-A04E-43B3-A45B-1B155752D0C2@oracle.com> Ping! Any thought on this webrev restore the way for Solaris LD_LIBRARY_PATH_64 handling? Cheers, Henry > On Feb 13, 2019, at 9:37 AM, Henry Jen wrote: > > Hi, > > Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when LD_LIBRARY_PATH_64 is set, we setup LD_LIBRARY_PATH based on that value and unset LD_LIBRARY_PATH_64 in the relaunched process. > > Same approach was used before JDK-6367077, and the override is expected behavior on Solaris 64-bit as stated in Solaris 64-bit Developer's Guide[2], > "The 64-bit dynamic linker's search path can be completely overridden using the LD_LIBRARY_PATH_64 environment variable." > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/8217216/0/webrev/ > [2] https://docs.oracle.com/cd/E19455-01/806-0477/dev-env-7/index.html > From naoto.sato at oracle.com Fri Mar 1 17:37:25 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 1 Mar 2019 09:37:25 -0800 Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> Message-ID: <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com> Hi Deepak, A few comments on the JapaneseEraNameTest: - Please indent code blocks accordingly, i.e., names object declaration (line 47-51), for loop in the main() (line 56,59,60). - If you are commenting out the case for LONG, please address the reason with the comment (the following explanation will do) - If the above issue is specific to 8u, and not related to the new era, file a separate issue for 8u. Naoto On 3/1/19 2:44 AM, Deepak Kejriwal wrote: > Hi All, > > > > Please review the back port of fix for JDK-8217609 to 8u-dev:- > > > > JBS report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.openjdk.java.net/browse/JDK- 8217609 > > Webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/ > > Master bug change set: http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17 > > Summary: > Fix is backported from JDK 13 to JDK 8u and is not a clean backport. Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses version 33. Below are the differences between 8u and 13:- > > . The "jp.xml" version of JDK 8u does not contains "" node (). Therefore "N" which is part of fix is not added to file. > > . I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java" for JDK 8u. It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)" > > o The test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..). > > o The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras". The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u. > > Regards, > > Deepak > > > From Michael.Rasmussen at roguewave.com Fri Mar 1 17:43:24 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Fri, 1 Mar 2019 17:43:24 +0000 Subject: Re changes from JDK-8068498, but docs everywhere still referencing line.separator system property Message-ID: Hi, When?JDK-8068498?was implemented (in JDK9), it simply changed PrintWriter and BufferedWriter to use System.lineSeparator(), but the spec for the classes and methods still mentions line.separator system property, thus giving the impression that changing that system property has an impact. I know that JDK-8068498?was there to counter people from doing stuff like: System.setProperty("line.separator", "\n"); unixBW = new BufferedWriter(...) But according to the javadoc for BufferedWriter, the value of that property should impact how the writer works. This also applies to a method like Files.write(path, lines), where .newLine() is implicitly called after each element in the lines Iterable, and again the line.separator system property is explicitly mentioned in the spec for that method. The spec for these classes and methods should probably be updated to reference System.lineSeparator() instead? /Michael From mandy.chung at oracle.com Fri Mar 1 17:50:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 1 Mar 2019 17:50:49 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Hi Adam, You can add a new test for this specific test case. MethodHandlesGeneralTest is a general test that you either update it to fit in existing testing framework or add a new test which will be simpler for you. Please include the test in the webrev for easier review. Mandy On 3/1/19 2:31 AM, Adam Farley8 wrote: > Hi Mandy, > > Historically, the bigger the change I propose, the more months it takes > the OpenJDK community to approve. > > I'm not sure I can justify adding an entire class to test a very > specific case. > > Additionally, HasFields seems excessively complex. I don't understand > why it feels the > need to spend 34 lines of code parsing, processing, and storing 20 > minimal variables it already has. > > Seems like an informative comment, followed by a littany of > "cases.add..." would have been a simpler choice. > > Could you tell me if I'm missing something? > > Best Regards > > Adam Farley > IBM Runtimes > > > Mandy Chung wrote on 21/02/2019 17:37:54: > >> From: Mandy Chung >> To: Adam Farley8 >> Cc: core-libs-dev >> Date: 21/02/2019 17:41 >> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails >> to throw IllegalAccessException for final fields >> >> Hi Adam, >> >> On 2/14/19 3:16 AM, Adam Farley8 wrote: >> > Hi Mandy, >> > >> > Apologies for the delay. >> >> Same here as I returned from vacation yesterday. >> >> > Could you review this cdiff as a proposal for the jtreg test? >> > >> > Made sense to modify the existing test set for MethodHandle rather than >> > add a new one. >> >> Yes it'd be better if you extend the MethodHandlesGeneralTest and >> MethodHandlesTest to test the write access. >> >> To add the test cases properly, MethodHandlesTest.HasFields >> should be modified to include the read-only fields. ?It might >> be cleaner to add a new HasReadOnlyFields class and maybe a new >> TEST_SET_ACCESSIBLE bit that requests to call setAccessible(true) >> and testSetter expects unreflectSetter to throw exception on >> static final fields (possibly additional bits might be needed). >> >> Mandy >> > > 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 Mar 1 17:59:48 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 1 Mar 2019 12:59:48 -0500 Subject: Re changes from JDK-8068498, but docs everywhere still referencing line.separator system property In-Reply-To: References: Message-ID: <853f03bc-1bc2-d2c4-41bf-c62b7ea8960b@oracle.com> Hi Michael, Created: 8219992 Correct the documentation of PrintWriter to refer System.lineSeparator Given the caching of the system property value is unspecified, the current text is not completely wrong.? The value used is taken from line.separator but its initial value, not dynamically. Thanks, Roger On 3/1/19 12:43 PM, Michael Rasmussen wrote: > Hi, > > When?JDK-8068498?was implemented (in JDK9), it simply changed PrintWriter and BufferedWriter to use System.lineSeparator(), but the spec for the classes and methods still mentions line.separator system property, thus giving the impression that changing that system property has an impact. > I know that JDK-8068498?was there to counter people from doing stuff like: > System.setProperty("line.separator", "\n"); > unixBW = new BufferedWriter(...) > > But according to the javadoc for BufferedWriter, the value of that property should impact how the writer works. > This also applies to a method like Files.write(path, lines), where .newLine() is implicitly called after each element in the lines Iterable, and again the line.separator system property is explicitly mentioned in the spec for that method. > > The spec for these classes and methods should probably be updated to reference System.lineSeparator() instead? > > /Michael From roger.riggs at oracle.com Fri Mar 1 18:27:12 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 1 Mar 2019 13:27:12 -0500 Subject: RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris) In-Reply-To: <30CF8EDF-A04E-43B3-A45B-1B155752D0C2@oracle.com> References: <30CF8EDF-A04E-43B3-A45B-1B155752D0C2@oracle.com> Message-ID: <30e94474-4d86-dc2b-d255-2cbb042b7aee@oracle.com> Hi Henry, The change looks ok, Reviewed. (I'm not that familiar with Solaris). Thanks, Roger On 3/1/19 10:45 AM, Henry Jen wrote: > Ping! > > Any thought on this webrev restore the way for Solaris LD_LIBRARY_PATH_64 handling? > > Cheers, > Henry > > >> On Feb 13, 2019, at 9:37 AM, Henry Jen wrote: >> >> Hi, >> >> Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when LD_LIBRARY_PATH_64 is set, we setup LD_LIBRARY_PATH based on that value and unset LD_LIBRARY_PATH_64 in the relaunched process. >> >> Same approach was used before JDK-6367077, and the override is expected behavior on Solaris 64-bit as stated in Solaris 64-bit Developer's Guide[2], >> "The 64-bit dynamic linker's search path can be completely overridden using the LD_LIBRARY_PATH_64 environment variable." >> >> Cheers, >> Henry >> >> [1] http://cr.openjdk.java.net/~henryjen/8217216/0/webrev/ >> [2] https://docs.oracle.com/cd/E19455-01/806-0477/dev-env-7/index.html >> From stuart.marks at oracle.com Fri Mar 1 23:25:24 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 1 Mar 2019 15:25:24 -0800 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <45f6f33b-6050-bd19-8ff5-08f5285393d3@oracle.com> > The proposal looks good to me. In particular it's very nice to have > this properly (ability to iterate only once) to be encoded in the type > system. This could be helpful for static analysis tools to warn when > IterableOnce is reused. Thanks! It would be good to see what you can come up with respect to static analysis. I had speculated about this some, but you're much closer to this than I am. > Scanner case looks funny. In general such pattern could be applied to > every Iterator implementor. Yes, Scanner is rather an outlier with respect to Iterator. There are of course a lot of Iterator implementations, but (at least in the JDK) most of them are internal classes that can only be instantiated by calling a method -- typically but not always the iterator() method. There are only a few cases where an API *class* implements Iterator and where it's likely that calling code would get an instance of Iterator separately from iterating over it. Scanner was the only one I found in the JDK where it seemed reasonable to want to iterate it using an enhanced-for loop. > As for Streams, I worry a little that people would prefer for(T t : > stream) {...} over stream.forEach(t -> ...) even when forEach works > perfectly. Possibly. Of all the stream operations, forEach() is the one that's the easiest to learn but among the least useful. There's a certain kind of error where someone new to streams will try to put too much work into a forEach() operation and be frustrated because they can't modify local variables, break early, etc. The usual remedy is to recast such tasks to use reduction instead. I guess the risk is that the person would instead switch to a for-loop and then conclude, Why bother with this streams stuff? I think at this point there are enough streams tutorials and Stack Overflow Q&A on this topic that this won't be a very big problem. > The Stream.iterator() implementation produces some amount > of unnecessary garbage. At least it would be nice to add special case > into Spliterators#iterator(java.util.Spliterator) to > reduce number of wrappers if stream was directly created from an > iterator or collection: ... > Of course this could be done later as separate enhancement. Yes, I think this would be good to investigate and optimize if it proves to be a problem. On 2/28/19 9:54 PM, Tagir Valeev wrote: > One more alternative which could be considered (though it requires a > language change) is to allow the inference of Iterable type for > enhanced for when iteration value is a function expression and > iteration parameter type is explicitly specified as T. In this case > for(T t : stream::iterator) {} would be a valid syntax. Also people > could use enhanced for with any iterator they already have like for(T > t : () -> iterator) {}. Instead of for (; it.hasNext() ; ) { T t = > it.next(); ... }. It looks better than allowing to specify iterator > directly (like for(T t : stream.iterator())) as this could break some > programs where the same class implements Iterator and Iterable. This was noticed and discussed fairly early on (way back in 2012!) and it turns out to be more complicated than it appears at first glance. See these threads from lambda-dev: http://mail.openjdk.java.net/pipermail/lambda-dev/2012-August/005717.html http://mail.openjdk.java.net/pipermail/lambda-dev/2012-September/005749.html See in particular the messages from Maurizio. There is also reference to the original Java 5 design discussions that ruled out Iterator in the RHS of the enhanced-for loop. TL;DR the reason is that they didn't want the RHS expression to have a side effect of draining the Iterator. s'marks From forax at univ-mlv.fr Sat Mar 2 21:19:48 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 2 Mar 2019 22:19:48 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> Hi Stuart, Stream.iterator() can be really really slow, it uses a pull semantics while the whole Stream push values. When designing it, the lambda EG saw it as an "escape hatch" in order to interropt with a legacy code than require an Iterator and not more. This proposal has the side effect of making Stream more different from its primitive counterpart IntStream, LongStream and DoubleStream which may be problematic because we are trying to introduce reified generics as part of Valhalla (there is a recent mail of Brian about not adding methods to OptionalInt for the same reason). And, the real issue is how to deal with checked exceptions inside the Stream API, i would prefer to fix that issue instead of trying to find a way to workaround it. regards, R?mi ----- Mail original ----- > De: "Stuart Marks" > ?: "core-libs-dev" > Envoy?: Vendredi 1 Mars 2019 03:43:44 > Objet: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hi all, > > Please review and comment on this proposal to allow Stream instances to be used > in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream using a conventional loop. However, > the Stream interface doesn't implement Iterable, and therefore streams cannot be > used with the enhanced-for statement. This is a proposal to remedy that > situation by introducing a new interface IterableOnce that is a subtype of > Iterable, and then retrofitting the Stream interface to implement it. Other JDK > classes will also be retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no tests > yet. However, the implementation is so simple that I figured I should include > it. Comments on the specification wording are also welcome. > > Thanks, > > s'marks From andy.herrick at oracle.com Sun Mar 3 15:34:44 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 3 Mar 2019 10:34:44 -0500 Subject: RFR: JDK-8219679: Help text changes in jpackage Message-ID: <50b6f8d5-186c-eb5b-bc2a-b64056f7595f@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8219679 [2] http://cr.openjdk.java.net/~herrick/8219679/ /Andy From andy.herrick at oracle.com Sun Mar 3 15:48:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 3 Mar 2019 10:48:46 -0500 Subject: RFR: JDK-8219678: CLI changes in jpackage Message-ID: <2fc23923-53d4-cd5b-0852-897d6de48c11@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This change modifies the CLI and other behavior as described in [1] [1] https://bugs.openjdk.java.net/browse/JDK-8219678 [2] http://cr.openjdk.java.net/~herrick/8219678/ /Andy From augustnagro at gmail.com Mon Mar 4 00:35:57 2019 From: augustnagro at gmail.com (August Nagro) Date: Sun, 3 Mar 2019 18:35:57 -0600 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Hi everyone, My implementation is at https://github.com/AugustNagro/presize-collectors-bench and I have a webrev here: http://august.nagro.us/presized-collectors/webrev/. The changes that I made were: - Add `default IntFunction sizedSupplier()` to Collector - Add 2 new Collector.of helper methods taking a sized supplier - Update the applicable collectors in Collectors to provide a sizedSupplier - Have ReferencePipeline & ReduceOps call sizedSupplier when appropriate Some notes/questions I have: - I considered adding Collector.Characteristics.PRESIZEABLE, but figured it was not needed given that sizedSupplier should always delegate to supplier. - Collector.sizedSupplier could be a LongFunction instead of IntFunction (since Sink.begin provides long sizes), but every Collection type I've looked at uses int for initialCapacity, so I think IntFunction makes more sense. - StringJoiner should be updated to take an initalCapacity (should I commit this change in the webrev, or leave for another enhancement?) - What tests should I add for this enhancement? There are some benchmarks in the github repo. I was initially surprised when I saw that my bare-bones parallel stream did not have a throughput improvement like the serial one, but after doing some debugging I think it is from Collector.combiner dominating the runtime. Regards, August On Thu, Feb 28, 2019 at 12:56 AM Tagir Valeev wrote: > Hello! > > I wouldn't use presized HashSet, because you never know how many > duplicates are expected. What if the input stream has a million of > elements, but only two of them are distinct? Do you really want to allocate > a hash table for million elements in advance? > > For toMap() without custom supplier and merger preallocation sounds > reasonable as in this case duplicating key is an exceptional case, so we > may expect a specific number of elements. > > ??, 28 ????. 2019 ?., 11:38 August Nagro augustnagro at gmail.com: > >> Tagir, >> >> Great to see the validating benchmarks. >> >> > I think it's the best solution given the fact that very few collectors may >> benefit from the exact known size, and this benefit usually disappears >> when collectors are composed (e.g. using groupingBy: downstream toList() >> would not win anything if it provides a sizedSupplier). >> >> I would like to see your benchmarks for that statement too. After all, >> Hashmap, HashSet, etc all have presizing constructors, aren't those there >> for a reason? >> >> So I am still convinced that presizing is important for other collector >> types, including custom collectors. Although I'm open to having my mind >> changed. >> >> I'm happy to contribute an implementation as well, I was hoping that >> this this (smallish) patch would help me learn the OpenJdk process and make >> future contributions easier! >> >> - August >> >> On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev wrote: >> >>> Hello! >>> >>> > A less intrusive API direction might be a version of Collector whose >>> > supplier function took a size-estimate argument; this might even help >>> in >>> > parallel since it allows for intermediate results to start with a >>> better >>> > initial size guess. (And this could be implemented as a default that >>> > delegates to the existing supplier.) Still, not really sure this >>> > carries its weight. >>> >>> It's interesting that such optimization is possible without API >>> change, using the "hidden knowledge". >>> While public API stays the same, the collect method implementation may >>> check if custom >>> non-public Collector implementation is supplied, and in this case may >>> use the sized supplier. >>> I think it's the best solution given the fact that very few collectors >>> may benefit from the exact >>> known size, and this benefit usually disappears when collectors are >>> composed (e.g. using groupingBy: >>> downstream toList() would not win anything if it provides a >>> sizedSupplier). >>> >>> I created a quick patch and launched a quick benchmark like this: >>> return new SplittableRandom(0).ints(length, 0, >>> 100).boxed().collect(Collectors.toList()); >>> For length = 100, 10000, 1000000 >>> >>> Here's results for vanilla 13-ea+8: >>> length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 B/op >>> length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = >>> 169280 B/op >>> length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc >>> rate = 14586750 B/op >>> >>> Patched: >>> length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op >>> length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = >>> 40368 B/op >>> length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc >>> rate = 4000382 B/op >>> >>> As you can see, exact allocation really helps to reduce alloc pressure >>> and produces better performance for big lists. >>> >>> If such kind of patch is acceptable for Stream API, I can file a >>> ticket and submit a webrev. >>> >>> With best regards, >>> Tagir Valeev >>> >>> The patch follows: >>> >>> --- src/java.base/share/classes/java/util/stream/Collectors.java >>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >>> +++ src/java.base/share/classes/java/util/stream/Collectors.java >>> (revision 53626+:e2fc434b410a+) >>> @@ -50,6 +50,7 @@ >>> import java.util.function.BinaryOperator; >>> import java.util.function.Consumer; >>> import java.util.function.Function; >>> +import java.util.function.IntFunction; >>> import java.util.function.Predicate; >>> import java.util.function.Supplier; >>> import java.util.function.ToDoubleFunction; >>> @@ -194,23 +195,34 @@ >>> */ >>> static class CollectorImpl implements Collector { >>> private final Supplier supplier; >>> + private final IntFunction sizedSupplier; >>> private final BiConsumer accumulator; >>> private final BinaryOperator combiner; >>> private final Function finisher; >>> private final Set characteristics; >>> >>> CollectorImpl(Supplier supplier, >>> + IntFunction sizedSupplier, >>> BiConsumer accumulator, >>> BinaryOperator combiner, >>> Function finisher, >>> Set characteristics) { >>> this.supplier = supplier; >>> + this.sizedSupplier = sizedSupplier; >>> this.accumulator = accumulator; >>> this.combiner = combiner; >>> this.finisher = finisher; >>> this.characteristics = characteristics; >>> } >>> >>> + CollectorImpl(Supplier supplier, >>> + BiConsumer accumulator, >>> + BinaryOperator combiner, >>> + Function finisher, >>> + Set characteristics) { >>> + this(supplier, null, accumulator, combiner, finisher, >>> characteristics); >>> + } >>> + >>> CollectorImpl(Supplier supplier, >>> BiConsumer accumulator, >>> BinaryOperator combiner, >>> @@ -228,6 +240,10 @@ >>> return supplier; >>> } >>> >>> + IntFunction sizedSupplier() { >>> + return sizedSupplier; >>> + } >>> + >>> @Override >>> public BinaryOperator combiner() { >>> return combiner; >>> @@ -275,8 +291,11 @@ >>> */ >>> public static >>> Collector> toList() { >>> - return new CollectorImpl<>((Supplier>) >>> ArrayList::new, List::add, >>> + return new CollectorImpl<>((Supplier>) ArrayList::new, >>> + ArrayList::new, >>> + List::add, >>> (left, right) -> { >>> left.addAll(right); return left; }, >>> + castingIdentity(), >>> CH_ID); >>> } >>> >>> Index: src/java.base/share/classes/java/util/stream/ReduceOps.java >>> IDEA additional info: >>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>> <+>UTF-8 >>> =================================================================== >>> --- src/java.base/share/classes/java/util/stream/ReduceOps.java >>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >>> +++ src/java.base/share/classes/java/util/stream/ReduceOps.java >>> (revision 53626+:e2fc434b410a+) >>> @@ -36,6 +36,7 @@ >>> import java.util.function.BinaryOperator; >>> import java.util.function.DoubleBinaryOperator; >>> import java.util.function.IntBinaryOperator; >>> +import java.util.function.IntFunction; >>> import java.util.function.LongBinaryOperator; >>> import java.util.function.ObjDoubleConsumer; >>> import java.util.function.ObjIntConsumer; >>> @@ -155,13 +156,20 @@ >>> public static TerminalOp >>> makeRef(Collector collector) { >>> Supplier supplier = >>> Objects.requireNonNull(collector).supplier(); >>> + @SuppressWarnings("unchecked") >>> + IntFunction sizedSupplier = collector instanceof >>> Collectors.CollectorImpl ? >>> + ((Collectors.CollectorImpl) >>> collector).sizedSupplier() : null; >>> BiConsumer accumulator = collector.accumulator(); >>> BinaryOperator combiner = collector.combiner(); >>> class ReducingSink extends Box >>> implements AccumulatingSink { >>> @Override >>> public void begin(long size) { >>> - state = supplier.get(); >>> + if (sizedSupplier != null && size >= 0 && size <= >>> Integer.MAX_VALUE) { >>> + state = sizedSupplier.apply((int) size); >>> + } else { >>> + state = supplier.get(); >>> + } >>> } >>> >>> @Override >>> >> From amaembo at gmail.com Mon Mar 4 03:08:16 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 4 Mar 2019 10:08:16 +0700 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Hello August. I'm not supporting the proposed spec change, but I have few comments about implementation (in case OpenJDK reviewers would support it). 1. joining(): Setting initial StringBuilder size to the number of characters which is equivalent to the number of stream elements would be a good idea only under assumption that every stream element has the length 1. Which is wrong in 99.9% of real-life cases. 2. flatMapping(), filtering(): Bypassing the original size to the downstream collector is plain wrong here as number of resulting elements can be either bigger (in flatMapping case) or arbitrarily smaller (in both cases) than the stream size. In the latter case you may just waste big amount of memory: a stream of million elements could be collapsed to 1-2 elements, but you would still allocate an ArrayList of a million of elements. 3. toMap(): a HashMap constructor parameter is an initial capacity, not the number of elements. Supplying it and ignoring the load factor you may force the HashMap to resize the table once which is suboptimal. You should pass an estimated number of elements divided by default load factor (and check corner cases as well). 4. teeing(): you defer null-check to the actual call of supplier or sizedSupplier. This is very bad as broken collector (e.g. returning null from sizedSupplier) may not fail fast for a long time if it's never used for sized stream. 5. ReduceOps: also you defer a null-check and capture not the function, but Collector object itself. This produces subtle behavioral change for no reason. 6. ReferencePipeline::collect: I don't see why such huge change is necessary. With best regards, Tagir Valeev. On Mon, Mar 4, 2019 at 7:36 AM August Nagro wrote: > > Hi everyone, > > My implementation is at https://github.com/AugustNagro/presize-collectors-bench and I have a webrev here: http://august.nagro.us/presized-collectors/webrev/. > > The changes that I made were: > > Add `default IntFunction sizedSupplier()` to Collector > Add 2 new Collector.of helper methods taking a sized supplier > Update the applicable collectors in Collectors to provide a sizedSupplier > Have ReferencePipeline & ReduceOps call sizedSupplier when appropriate > > Some notes/questions I have: > > I considered adding Collector.Characteristics.PRESIZEABLE, but figured it was not needed given that sizedSupplier should always delegate to supplier. > Collector.sizedSupplier could be a LongFunction instead of IntFunction (since Sink.begin provides long sizes), but every Collection type I've looked at uses int for initialCapacity, so I think IntFunction makes more sense. > StringJoiner should be updated to take an initalCapacity (should I commit this change in the webrev, or leave for another enhancement?) > What tests should I add for this enhancement? > > There are some benchmarks in the github repo. I was initially surprised when I saw that my bare-bones parallel stream did not have a throughput improvement like the serial one, but after doing some debugging I think it is from Collector.combiner dominating the runtime. > > Regards, > > August > > On Thu, Feb 28, 2019 at 12:56 AM Tagir Valeev wrote: >> >> Hello! >> >> I wouldn't use presized HashSet, because you never know how many duplicates are expected. What if the input stream has a million of elements, but only two of them are distinct? Do you really want to allocate a hash table for million elements in advance? >> >> For toMap() without custom supplier and merger preallocation sounds reasonable as in this case duplicating key is an exceptional case, so we may expect a specific number of elements. >> >> ??, 28 ????. 2019 ?., 11:38 August Nagro augustnagro at gmail.com: >>> >>> Tagir, >>> >>> Great to see the validating benchmarks. >>> >>> > I think it's the best solution given the fact that very few collectors may benefit from the exact known size, and this benefit usually disappears when collectors are composed (e.g. using groupingBy: downstream toList() would not win anything if it provides a sizedSupplier). >>> >>> I would like to see your benchmarks for that statement too. After all, Hashmap, HashSet, etc all have presizing constructors, aren't those there for a reason? >>> >>> So I am still convinced that presizing is important for other collector types, including custom collectors. Although I'm open to having my mind changed. >>> >>> I'm happy to contribute an implementation as well, I was hoping that this this (smallish) patch would help me learn the OpenJdk process and make future contributions easier! >>> >>> - August >>> >>> On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev wrote: >>>> >>>> Hello! >>>> >>>> > A less intrusive API direction might be a version of Collector whose >>>> > supplier function took a size-estimate argument; this might even help in >>>> > parallel since it allows for intermediate results to start with a better >>>> > initial size guess. (And this could be implemented as a default that >>>> > delegates to the existing supplier.) Still, not really sure this >>>> > carries its weight. >>>> >>>> It's interesting that such optimization is possible without API >>>> change, using the "hidden knowledge". >>>> While public API stays the same, the collect method implementation may >>>> check if custom >>>> non-public Collector implementation is supplied, and in this case may >>>> use the sized supplier. >>>> I think it's the best solution given the fact that very few collectors >>>> may benefit from the exact >>>> known size, and this benefit usually disappears when collectors are >>>> composed (e.g. using groupingBy: >>>> downstream toList() would not win anything if it provides a sizedSupplier). >>>> >>>> I created a quick patch and launched a quick benchmark like this: >>>> return new SplittableRandom(0).ints(length, 0, >>>> 100).boxed().collect(Collectors.toList()); >>>> For length = 100, 10000, 1000000 >>>> >>>> Here's results for vanilla 13-ea+8: >>>> length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 B/op >>>> length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = >>>> 169280 B/op >>>> length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc >>>> rate = 14586750 B/op >>>> >>>> Patched: >>>> length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op >>>> length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = 40368 B/op >>>> length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc >>>> rate = 4000382 B/op >>>> >>>> As you can see, exact allocation really helps to reduce alloc pressure >>>> and produces better performance for big lists. >>>> >>>> If such kind of patch is acceptable for Stream API, I can file a >>>> ticket and submit a webrev. >>>> >>>> With best regards, >>>> Tagir Valeev >>>> >>>> The patch follows: >>>> >>>> --- src/java.base/share/classes/java/util/stream/Collectors.java >>>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >>>> +++ src/java.base/share/classes/java/util/stream/Collectors.java >>>> (revision 53626+:e2fc434b410a+) >>>> @@ -50,6 +50,7 @@ >>>> import java.util.function.BinaryOperator; >>>> import java.util.function.Consumer; >>>> import java.util.function.Function; >>>> +import java.util.function.IntFunction; >>>> import java.util.function.Predicate; >>>> import java.util.function.Supplier; >>>> import java.util.function.ToDoubleFunction; >>>> @@ -194,23 +195,34 @@ >>>> */ >>>> static class CollectorImpl implements Collector { >>>> private final Supplier supplier; >>>> + private final IntFunction sizedSupplier; >>>> private final BiConsumer accumulator; >>>> private final BinaryOperator combiner; >>>> private final Function finisher; >>>> private final Set characteristics; >>>> >>>> CollectorImpl(Supplier supplier, >>>> + IntFunction sizedSupplier, >>>> BiConsumer accumulator, >>>> BinaryOperator combiner, >>>> Function finisher, >>>> Set characteristics) { >>>> this.supplier = supplier; >>>> + this.sizedSupplier = sizedSupplier; >>>> this.accumulator = accumulator; >>>> this.combiner = combiner; >>>> this.finisher = finisher; >>>> this.characteristics = characteristics; >>>> } >>>> >>>> + CollectorImpl(Supplier supplier, >>>> + BiConsumer accumulator, >>>> + BinaryOperator combiner, >>>> + Function finisher, >>>> + Set characteristics) { >>>> + this(supplier, null, accumulator, combiner, finisher, >>>> characteristics); >>>> + } >>>> + >>>> CollectorImpl(Supplier supplier, >>>> BiConsumer accumulator, >>>> BinaryOperator combiner, >>>> @@ -228,6 +240,10 @@ >>>> return supplier; >>>> } >>>> >>>> + IntFunction sizedSupplier() { >>>> + return sizedSupplier; >>>> + } >>>> + >>>> @Override >>>> public BinaryOperator combiner() { >>>> return combiner; >>>> @@ -275,8 +291,11 @@ >>>> */ >>>> public static >>>> Collector> toList() { >>>> - return new CollectorImpl<>((Supplier>) >>>> ArrayList::new, List::add, >>>> + return new CollectorImpl<>((Supplier>) ArrayList::new, >>>> + ArrayList::new, >>>> + List::add, >>>> (left, right) -> { >>>> left.addAll(right); return left; }, >>>> + castingIdentity(), >>>> CH_ID); >>>> } >>>> >>>> Index: src/java.base/share/classes/java/util/stream/ReduceOps.java >>>> IDEA additional info: >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>>> <+>UTF-8 >>>> =================================================================== >>>> --- src/java.base/share/classes/java/util/stream/ReduceOps.java >>>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >>>> +++ src/java.base/share/classes/java/util/stream/ReduceOps.java >>>> (revision 53626+:e2fc434b410a+) >>>> @@ -36,6 +36,7 @@ >>>> import java.util.function.BinaryOperator; >>>> import java.util.function.DoubleBinaryOperator; >>>> import java.util.function.IntBinaryOperator; >>>> +import java.util.function.IntFunction; >>>> import java.util.function.LongBinaryOperator; >>>> import java.util.function.ObjDoubleConsumer; >>>> import java.util.function.ObjIntConsumer; >>>> @@ -155,13 +156,20 @@ >>>> public static TerminalOp >>>> makeRef(Collector collector) { >>>> Supplier supplier = Objects.requireNonNull(collector).supplier(); >>>> + @SuppressWarnings("unchecked") >>>> + IntFunction sizedSupplier = collector instanceof >>>> Collectors.CollectorImpl ? >>>> + ((Collectors.CollectorImpl) >>>> collector).sizedSupplier() : null; >>>> BiConsumer accumulator = collector.accumulator(); >>>> BinaryOperator combiner = collector.combiner(); >>>> class ReducingSink extends Box >>>> implements AccumulatingSink { >>>> @Override >>>> public void begin(long size) { >>>> - state = supplier.get(); >>>> + if (sizedSupplier != null && size >= 0 && size <= >>>> Integer.MAX_VALUE) { >>>> + state = sizedSupplier.apply((int) size); >>>> + } else { >>>> + state = supplier.get(); >>>> + } >>>> } >>>> >>>> @Override From augustnagro at gmail.com Mon Mar 4 06:18:22 2019 From: augustnagro at gmail.com (August Nagro) Date: Mon, 4 Mar 2019 00:18:22 -0600 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Tagir, I slapped my forehead when I saw that StringBuilder's initialCapacity is the number of chars, and not added elements! The CollectorOp class I added for ReferencePipeline.collect(Collector) is so a concurrent + unordered collector may be pre-sized. I thought it was needed for completeness (let concurrent collectors benefit from pre-sizing just like serial). But maybe not worth the change? I hope I can change your mind about the spec change. We agree that pre-sizing collections is important, and the benchmarks show that Streams supporting pre-sizing can reduce allocations (up to 60% for ArrayLists) while often improving throughput. The question then is if the ends are worth the means? Take a look at this (non-exhaustive) list of Collections that stand to benefit from having Collector.sizedSupplier(): - Eclipse Collections. The library provides its own Collectors2 utility class [1], and the authors have high performance / low memory usage as a goal. - MutableList - Used in Collectors2.toList(). Collector.sizedSupplier() could be specified with Lists.mutable.ofInitialCapacity(int). - BooleanArrayList(int initialCapacity) - HashBag(int size) - BooleanList, IntList, etc. - Guava. A quick google search found libraries like https://github.com/yanaga/guava-stream that aggregate Collectors for guava collections. - The FutureJoiner I shared earlier - JDK classes that don't have Collectors factory method (ex. ArrayDeque(int numElements)) Thanks Tagir for the comments, and I updated the webrev: http://august.nagro.us/presized-collectors/webrev2/index.html - August [1]: https://www.eclipse.org/collections/javadoc/9.2.0/org/eclipse/collections/impl/collector/Collectors2.html On Sun, Mar 3, 2019 at 9:08 PM Tagir Valeev wrote: > Hello August. > > I'm not supporting the proposed spec change, but I have few comments > about implementation (in case OpenJDK reviewers would support it). > > 1. joining(): Setting initial StringBuilder size to the number of > characters which is equivalent to the number of stream elements would > be a good idea only under assumption that every stream element has the > length 1. Which is wrong in 99.9% of real-life cases. > 2. flatMapping(), filtering(): Bypassing the original size to the > downstream collector is plain wrong here as number of resulting > elements can be either bigger (in flatMapping case) or arbitrarily > smaller (in both cases) than the stream size. In the latter case you > may just waste big amount of memory: a stream of million elements > could be collapsed to 1-2 elements, but you would still allocate an > ArrayList of a million of elements. > 3. toMap(): a HashMap constructor parameter is an initial capacity, > not the number of elements. Supplying it and ignoring the load factor > you may force the HashMap to resize the table once which is > suboptimal. You should pass an estimated number of elements divided by > default load factor (and check corner cases as well). > 4. teeing(): you defer null-check to the actual call of supplier or > sizedSupplier. This is very bad as broken collector (e.g. returning > null from sizedSupplier) may not fail fast for a long time if it's > never used for sized stream. > 5. ReduceOps: also you defer a null-check and capture not the > function, but Collector object itself. This produces subtle behavioral > change for no reason. > 6. ReferencePipeline::collect: I don't see why such huge change is > necessary. > > With best regards, > Tagir Valeev. > > On Mon, Mar 4, 2019 at 7:36 AM August Nagro wrote: > > > > Hi everyone, > > > > My implementation is at > https://github.com/AugustNagro/presize-collectors-bench and I have a > webrev here: http://august.nagro.us/presized-collectors/webrev/. > > > > The changes that I made were: > > > > Add `default IntFunction sizedSupplier()` to Collector > > Add 2 new Collector.of helper methods taking a sized supplier > > Update the applicable collectors in Collectors to provide a sizedSupplier > > Have ReferencePipeline & ReduceOps call sizedSupplier when appropriate > > > > Some notes/questions I have: > > > > I considered adding Collector.Characteristics.PRESIZEABLE, but figured > it was not needed given that sizedSupplier should always delegate to > supplier. > > Collector.sizedSupplier could be a LongFunction instead of IntFunction > (since Sink.begin provides long sizes), but every Collection type I've > looked at uses int for initialCapacity, so I think IntFunction makes more > sense. > > StringJoiner should be updated to take an initalCapacity (should I > commit this change in the webrev, or leave for another enhancement?) > > What tests should I add for this enhancement? > > > > There are some benchmarks in the github repo. I was initially surprised > when I saw that my bare-bones parallel stream did not have a throughput > improvement like the serial one, but after doing some debugging I think it > is from Collector.combiner dominating the runtime. > > > > Regards, > > > > August > > > > On Thu, Feb 28, 2019 at 12:56 AM Tagir Valeev wrote: > >> > >> Hello! > >> > >> I wouldn't use presized HashSet, because you never know how many > duplicates are expected. What if the input stream has a million of > elements, but only two of them are distinct? Do you really want to allocate > a hash table for million elements in advance? > >> > >> For toMap() without custom supplier and merger preallocation sounds > reasonable as in this case duplicating key is an exceptional case, so we > may expect a specific number of elements. > >> > >> ??, 28 ????. 2019 ?., 11:38 August Nagro augustnagro at gmail.com: > >>> > >>> Tagir, > >>> > >>> Great to see the validating benchmarks. > >>> > >>> > I think it's the best solution given the fact that very few > collectors may benefit from the exact known size, and this benefit usually > disappears when collectors are composed (e.g. using groupingBy: downstream > toList() would not win anything if it provides a sizedSupplier). > >>> > >>> I would like to see your benchmarks for that statement too. After all, > Hashmap, HashSet, etc all have presizing constructors, aren't those there > for a reason? > >>> > >>> So I am still convinced that presizing is important for other > collector types, including custom collectors. Although I'm open to having > my mind changed. > >>> > >>> I'm happy to contribute an implementation as well, I was hoping that > this this (smallish) patch would help me learn the OpenJdk process and make > future contributions easier! > >>> > >>> - August > >>> > >>> On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev > wrote: > >>>> > >>>> Hello! > >>>> > >>>> > A less intrusive API direction might be a version of Collector whose > >>>> > supplier function took a size-estimate argument; this might even > help in > >>>> > parallel since it allows for intermediate results to start with a > better > >>>> > initial size guess. (And this could be implemented as a default > that > >>>> > delegates to the existing supplier.) Still, not really sure this > >>>> > carries its weight. > >>>> > >>>> It's interesting that such optimization is possible without API > >>>> change, using the "hidden knowledge". > >>>> While public API stays the same, the collect method implementation may > >>>> check if custom > >>>> non-public Collector implementation is supplied, and in this case may > >>>> use the sized supplier. > >>>> I think it's the best solution given the fact that very few collectors > >>>> may benefit from the exact > >>>> known size, and this benefit usually disappears when collectors are > >>>> composed (e.g. using groupingBy: > >>>> downstream toList() would not win anything if it provides a > sizedSupplier). > >>>> > >>>> I created a quick patch and launched a quick benchmark like this: > >>>> return new SplittableRandom(0).ints(length, 0, > >>>> 100).boxed().collect(Collectors.toList()); > >>>> For length = 100, 10000, 1000000 > >>>> > >>>> Here's results for vanilla 13-ea+8: > >>>> length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 > B/op > >>>> length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = > >>>> 169280 B/op > >>>> length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc > >>>> rate = 14586750 B/op > >>>> > >>>> Patched: > >>>> length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 > B/op > >>>> length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = > 40368 B/op > >>>> length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc > >>>> rate = 4000382 B/op > >>>> > >>>> As you can see, exact allocation really helps to reduce alloc pressure > >>>> and produces better performance for big lists. > >>>> > >>>> If such kind of patch is acceptable for Stream API, I can file a > >>>> ticket and submit a webrev. > >>>> > >>>> With best regards, > >>>> Tagir Valeev > >>>> > >>>> The patch follows: > >>>> > >>>> --- src/java.base/share/classes/java/util/stream/Collectors.java > >>>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) > >>>> +++ src/java.base/share/classes/java/util/stream/Collectors.java > >>>> (revision 53626+:e2fc434b410a+) > >>>> @@ -50,6 +50,7 @@ > >>>> import java.util.function.BinaryOperator; > >>>> import java.util.function.Consumer; > >>>> import java.util.function.Function; > >>>> +import java.util.function.IntFunction; > >>>> import java.util.function.Predicate; > >>>> import java.util.function.Supplier; > >>>> import java.util.function.ToDoubleFunction; > >>>> @@ -194,23 +195,34 @@ > >>>> */ > >>>> static class CollectorImpl implements Collector R> { > >>>> private final Supplier supplier; > >>>> + private final IntFunction sizedSupplier; > >>>> private final BiConsumer accumulator; > >>>> private final BinaryOperator combiner; > >>>> private final Function finisher; > >>>> private final Set characteristics; > >>>> > >>>> CollectorImpl(Supplier supplier, > >>>> + IntFunction sizedSupplier, > >>>> BiConsumer accumulator, > >>>> BinaryOperator combiner, > >>>> Function finisher, > >>>> Set characteristics) { > >>>> this.supplier = supplier; > >>>> + this.sizedSupplier = sizedSupplier; > >>>> this.accumulator = accumulator; > >>>> this.combiner = combiner; > >>>> this.finisher = finisher; > >>>> this.characteristics = characteristics; > >>>> } > >>>> > >>>> + CollectorImpl(Supplier supplier, > >>>> + BiConsumer accumulator, > >>>> + BinaryOperator combiner, > >>>> + Function finisher, > >>>> + Set characteristics) { > >>>> + this(supplier, null, accumulator, combiner, finisher, > >>>> characteristics); > >>>> + } > >>>> + > >>>> CollectorImpl(Supplier supplier, > >>>> BiConsumer accumulator, > >>>> BinaryOperator combiner, > >>>> @@ -228,6 +240,10 @@ > >>>> return supplier; > >>>> } > >>>> > >>>> + IntFunction sizedSupplier() { > >>>> + return sizedSupplier; > >>>> + } > >>>> + > >>>> @Override > >>>> public BinaryOperator combiner() { > >>>> return combiner; > >>>> @@ -275,8 +291,11 @@ > >>>> */ > >>>> public static > >>>> Collector> toList() { > >>>> - return new CollectorImpl<>((Supplier>) > >>>> ArrayList::new, List::add, > >>>> + return new CollectorImpl<>((Supplier>) > ArrayList::new, > >>>> + ArrayList::new, > >>>> + List::add, > >>>> (left, right) -> { > >>>> left.addAll(right); return left; }, > >>>> + castingIdentity(), > >>>> CH_ID); > >>>> } > >>>> > >>>> Index: src/java.base/share/classes/java/util/stream/ReduceOps.java > >>>> IDEA additional info: > >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > >>>> <+>UTF-8 > >>>> =================================================================== > >>>> --- src/java.base/share/classes/java/util/stream/ReduceOps.java > >>>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) > >>>> +++ src/java.base/share/classes/java/util/stream/ReduceOps.java > >>>> (revision 53626+:e2fc434b410a+) > >>>> @@ -36,6 +36,7 @@ > >>>> import java.util.function.BinaryOperator; > >>>> import java.util.function.DoubleBinaryOperator; > >>>> import java.util.function.IntBinaryOperator; > >>>> +import java.util.function.IntFunction; > >>>> import java.util.function.LongBinaryOperator; > >>>> import java.util.function.ObjDoubleConsumer; > >>>> import java.util.function.ObjIntConsumer; > >>>> @@ -155,13 +156,20 @@ > >>>> public static TerminalOp > >>>> makeRef(Collector collector) { > >>>> Supplier supplier = > Objects.requireNonNull(collector).supplier(); > >>>> + @SuppressWarnings("unchecked") > >>>> + IntFunction sizedSupplier = collector instanceof > >>>> Collectors.CollectorImpl ? > >>>> + ((Collectors.CollectorImpl) > >>>> collector).sizedSupplier() : null; > >>>> BiConsumer accumulator = > collector.accumulator(); > >>>> BinaryOperator combiner = collector.combiner(); > >>>> class ReducingSink extends Box > >>>> implements AccumulatingSink { > >>>> @Override > >>>> public void begin(long size) { > >>>> - state = supplier.get(); > >>>> + if (sizedSupplier != null && size >= 0 && size <= > >>>> Integer.MAX_VALUE) { > >>>> + state = sizedSupplier.apply((int) size); > >>>> + } else { > >>>> + state = supplier.get(); > >>>> + } > >>>> } > >>>> > >>>> @Override > From deepak.kejriwal at oracle.com Mon Mar 4 08:56:59 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 4 Mar 2019 00:56:59 -0800 (PST) Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com> References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com> Message-ID: Hi Naoto, Thanks for review. I as update the webrev as per the review comments. Please find below updated version of webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.01/ Since long and Japanese Locale issue is specific to 8u and not related to new era, I have raised a new issue JDK-8220020 for it. Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Friday, March 1, 2019 11:07 PM To: Deepak Kejriwal ; core-libs-dev ; jdk8u-dev at openjdk.java.net Subject: Re: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat Hi Deepak, A few comments on the JapaneseEraNameTest: - Please indent code blocks accordingly, i.e., names object declaration (line 47-51), for loop in the main() (line 56,59,60). - If you are commenting out the case for LONG, please address the reason with the comment (the following explanation will do) - If the above issue is specific to 8u, and not related to the new era, file a separate issue for 8u. Naoto On 3/1/19 2:44 AM, Deepak Kejriwal wrote: > Hi All, > > > > Please review the back port of fix for JDK-8217609 to 8u-dev:- > > > > JBS report: HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.open > jdk.java.net/browse/JDK- 8217609 > > Webrev: > http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/ > > Master bug change set: > http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17 > > Summary: > Fix is backported from JDK 13 to JDK 8u and is not a clean backport. > Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses > version 33. Below are the differences between 8u and 13:- > > . The "jp.xml" version of JDK 8u does not contains "" node (). Therefore "N" which is part of fix is not added to file. > > . I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java" for JDK 8u. It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)" > > o The test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..). > > o The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras". The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u. > > Regards, > > Deepak > > > From deepak.kejriwal at oracle.com Mon Mar 4 09:02:21 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 4 Mar 2019 01:02:21 -0800 (PST) Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> Message-ID: <7896d3b3-d37e-42d5-9d4c-dc8d42c23b0c@default> Hi Andrew, Thanks for review. As of now we don't which bug need to be backported to 8u for fixing CLDR convertor issue. However, I have raised a separate bug for same:- https://bugs.openjdk.java.net/browse/JDK-8220020 Regards, Deepak -----Original Message----- From: Andrew Hughes Sent: Friday, March 1, 2019 9:09 PM To: Deepak Kejriwal Cc: core-libs-dev ; jdk8u-dev Subject: Re: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat On Fri, 1 Mar 2019 at 10:47, Deepak Kejriwal wrote: > > Hi All, > > > > Please review the back port of fix for JDK-8217609 to 8u-dev:- > > > > JBS report: HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-%208217609%22https://bugs.op > enjdk.java.net/browse/JDK- 8217609 > > Webrev: > http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/ > > Master bug change set: > http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17 > > Summary: > Fix is backported from JDK 13 to JDK 8u and is not a clean backport. > Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses > version 33. Below are the differences between 8u and 13:- > > . The "jp.xml" version of JDK 8u does not contains "" node (). Therefore "N" which is part of fix is not added to file. > > . I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java" for JDK 8u. It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)" > > o The test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..). > > o The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras". The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u. > > Regards, > > Deepak > > Patch looks good to me. Is there a bug/patch to backport to fix the CLDR converter in OpenJDK 8, so japanese.long.Eras are included? JDK-8217609 should have the label 'jdk8u-fix-request' added so it can be approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=OIRLm_rdyVUfNJH3SLA-tRzXEZ3NIKC14aO9CokPvgI&m=j3CCAe0gKdZ1tUX3wqQmQH0-QEcf9c-SP_A6NIFBobU&s=taCA3iR6U95qSdORcSSBkhnzDPXZDhrUKtyZjecFOGw&e=) Web Site: https://urldefense.proofpoint.com/v2/url?u=http-3A__fuseyism.com&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=OIRLm_rdyVUfNJH3SLA-tRzXEZ3NIKC14aO9CokPvgI&m=j3CCAe0gKdZ1tUX3wqQmQH0-QEcf9c-SP_A6NIFBobU&s=qf3t66gFRZcTpETTq7B7ur6kxz7LEX2z65dog1MIlKg&e= Twitter: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_gnu-5Fandrew-5Fjava&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=OIRLm_rdyVUfNJH3SLA-tRzXEZ3NIKC14aO9CokPvgI&m=j3CCAe0gKdZ1tUX3wqQmQH0-QEcf9c-SP_A6NIFBobU&s=Kjo5wWD8vSXUKQhnMlZ9dNyEQWdR1QuHvqPAwz5hJ7c&e= PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From andrew_m_leonard at uk.ibm.com Mon Mar 4 11:30:16 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 4 Mar 2019 11:30:16 +0000 Subject: JDK-8217735: Q: Should jint be jboolean ? Message-ID: Hi, This bug raised a missmatch between the Java and JNI definition for a native method, where Java specifies "boolean" and the JNI jint. Which is right, should they match? https://bugs.openjdk.java.net/browse/JDK-8217735 One part of the JVM spec that confuses me a bit is: 2.3.4 The boolean Type Although the Java Virtual Machine defines a boolean type, it only provides very limited support for it. There are no Java Virtual Machine instructions solely dedicated to operations on boolean values. Instead, expressions in the Java programming language that operate on boolean values are compiled to use values of the Java Virtual Machine int data type. 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 Alan.Bateman at oracle.com Mon Mar 4 12:04:38 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Mar 2019 12:04:38 +0000 Subject: JDK-8217735: Q: Should jint be jboolean ? In-Reply-To: References: Message-ID: On 04/03/2019 11:30, Andrew Leonard wrote: > Hi, > > This bug raised a missmatch between the Java and JNI definition for a > native method, where Java specifies "boolean" and the JNI jint. Which is > right, should they match? > https://bugs.openjdk.java.net/browse/JDK-8217735 > It's probably best to bring this to awt-dev to get to the right people that maintain this area. -Alan From david.holmes at oracle.com Mon Mar 4 12:50:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Mar 2019 22:50:48 +1000 Subject: JDK-8217735: Q: Should jint be jboolean ? In-Reply-To: References: Message-ID: <80f727ee-4881-45bb-9172-3ed8bf2297c7@oracle.com> On 4/03/2019 9:30 pm, Andrew Leonard wrote: > Hi, > > This bug raised a missmatch between the Java and JNI definition for a > native method, where Java specifies "boolean" and the JNI jint. Which is > right, should they match? > https://bugs.openjdk.java.net/browse/JDK-8217735 Old javah generates jboolean > cat Native.java public class Native { public native boolean isTrue(boolean b); } > cat Native.h /* DO NOT EDIT THIS FILE - it is machine generated */ #include /* Header for class Native */ #ifndef _Included_Native #define _Included_Native #ifdef __cplusplus extern "C" { #endif /* * Class: Native * Method: isTrue * Signature: (Z)Z */ JNIEXPORT jboolean JNICALL Java_Native_isTrue (JNIEnv *, jobject, jboolean); #ifdef __cplusplus } #endif #endif David ----- > One part of the JVM spec that confuses me a bit is: > 2.3.4 The boolean Type > Although the Java Virtual Machine defines a boolean type, > it only provides very limited support for it. > There are no Java Virtual Machine instructions solely dedicated > to operations on boolean values. Instead, expressions in the Java > programming language that operate on boolean values are > compiled to use values of the Java Virtual Machine int data type. > > 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 andrew_m_leonard at uk.ibm.com Mon Mar 4 13:22:01 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 4 Mar 2019 13:22:01 +0000 Subject: JDK-8217735: Q: Should jint be jboolean ? In-Reply-To: <80f727ee-4881-45bb-9172-3ed8bf2297c7@oracle.com> References: <80f727ee-4881-45bb-9172-3ed8bf2297c7@oracle.com> Message-ID: Thanks David, that's a good thought, so yes jboolean looks right form that. Cheers 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: David Holmes To: Andrew Leonard , core-libs-dev Date: 04/03/2019 12:52 Subject: Re: JDK-8217735: Q: Should jint be jboolean ? On 4/03/2019 9:30 pm, Andrew Leonard wrote: > Hi, > > This bug raised a missmatch between the Java and JNI definition for a > native method, where Java specifies "boolean" and the JNI jint. Which is > right, should they match? > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8217735&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=KoeDVOc0vzvP0wizDDykj53gxMU5Zcop2nu4FsOonUQ&s=H_SBb8AJvNppMzFArFxWqfF-ss0W3le6MVndHorE7qU&e= Old javah generates jboolean > cat Native.java public class Native { public native boolean isTrue(boolean b); } > cat Native.h /* DO NOT EDIT THIS FILE - it is machine generated */ #include /* Header for class Native */ #ifndef _Included_Native #define _Included_Native #ifdef __cplusplus extern "C" { #endif /* * Class: Native * Method: isTrue * Signature: (Z)Z */ JNIEXPORT jboolean JNICALL Java_Native_isTrue (JNIEnv *, jobject, jboolean); #ifdef __cplusplus } #endif #endif David ----- > One part of the JVM spec that confuses me a bit is: > 2.3.4 The boolean Type > Although the Java Virtual Machine defines a boolean type, > it only provides very limited support for it. > There are no Java Virtual Machine instructions solely dedicated > to operations on boolean values. Instead, expressions in the Java > programming language that operate on boolean values are > compiled to use values of the Java Virtual Machine int data type. > > 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 scolebourne at joda.org Mon Mar 4 14:16:31 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 4 Mar 2019 14:16:31 +0000 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: On Fri, 1 Mar 2019 at 02:46, Stuart Marks wrote: > Please review and comment on this proposal to allow Stream instances to be used > in enhanced-for ("for-each") loops. This all seems reasonable enough though of course not ideal. My slight concern is that the terminal operation is hidden and not immediately visible, which could be surprising. I do note that streams throw a clear exception if a terminal operation is called a second time which mitigates this to some degree. The IterableOnce class-level Javadoc contradicts the method-level Javadoc. The class-level say "It is recommended that" whereas the method-level Javadoc mandates. Stephen > Abstract > > Occasionally it's useful to iterate a Stream using a conventional loop. However, > the Stream interface doesn't implement Iterable, and therefore streams cannot be > used with the enhanced-for statement. This is a proposal to remedy that > situation by introducing a new interface IterableOnce that is a subtype of > Iterable, and then retrofitting the Stream interface to implement it. Other JDK > classes will also be retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no tests > yet. However, the implementation is so simple that I figured I should include > it. Comments on the specification wording are also welcome. > > Thanks, > > s'marks From naoto.sato at oracle.com Mon Mar 4 16:27:27 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 4 Mar 2019 08:27:27 -0800 Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat In-Reply-To: References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default> <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com> Message-ID: Looks good. Naoto On 3/4/19 12:56 AM, Deepak Kejriwal wrote: > Hi Naoto, > > Thanks for review. I as update the webrev as per the review comments. Please find below updated version of webrev: > http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.01/ > > Since long and Japanese Locale issue is specific to 8u and not related to new era, I have raised a new issue JDK-8220020 for it. > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Friday, March 1, 2019 11:07 PM > To: Deepak Kejriwal ; core-libs-dev ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat > > Hi Deepak, > > A few comments on the JapaneseEraNameTest: > > - Please indent code blocks accordingly, i.e., names object declaration (line 47-51), for loop in the main() (line 56,59,60). > > - If you are commenting out the case for LONG, please address the reason with the comment (the following explanation will do) > > - If the above issue is specific to 8u, and not related to the new era, file a separate issue for 8u. > > Naoto > > On 3/1/19 2:44 AM, Deepak Kejriwal wrote: >> Hi All, >> >> >> >> Please review the back port of fix for JDK-8217609 to 8u-dev:- >> >> >> >> JBS report: HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.open >> jdk.java.net/browse/JDK- 8217609 >> >> Webrev: >> http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/ >> >> Master bug change set: >> http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17 >> >> Summary: >> Fix is backported from JDK 13 to JDK 8u and is not a clean backport. >> Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses >> version 33. Below are the differences between 8u and 13:- >> >> . The "jp.xml" version of JDK 8u does not contains "" node (). Therefore "N" which is part of fix is not added to file. >> >> . I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java" for JDK 8u. It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)" >> >> o The test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..). >> >> o The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras". The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u. >> >> Regards, >> >> Deepak >> >> >> From deepak.kejriwal at oracle.com Mon Mar 4 18:43:12 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 4 Mar 2019 10:43:12 -0800 (PST) Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era placeholder not recognized by java.text.SimpleDateFormat Message-ID: Hi All, Please approve the backport of following bugs to 8u-dev. JDK- 8217609 : New era placeholder not recognized by java.text.SimpleDateFormat JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058786.html All the related testing is done and is a pass. Regards, Deepak From brian.goetz at oracle.com Mon Mar 4 20:53:05 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 4 Mar 2019 20:53:05 +0000 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: So, unfortunately I think this particular API evolution idiom is kind of questionable. There is a new method, sizedSupplier, with a default that delegates to the unsized supplier. But, that leaves implementors in a position where they don?t really know which one to implement, and the use of characteristics to hint at which one to call is kind of convoluted. You?re focused on the benefits ? that in some cases, collection can be faster. That?s good. But one of the big costs here is that an interfaces that was simple is now considerably less so. That?s a cost; not convinced the two are in balance. > On Mar 4, 2019, at 12:35 AM, August Nagro wrote: > > Hi everyone, > > My implementation is at https://github.com/AugustNagro/presize-collectors-bench and I have a webrev here: http://august.nagro.us/presized-collectors/webrev/ . > > The changes that I made were: > Add `default IntFunction sizedSupplier()` to Collector > Add 2 new Collector.of helper methods taking a sized supplier > Update the applicable collectors in Collectors to provide a sizedSupplier > Have ReferencePipeline & ReduceOps call sizedSupplier when appropriate > Some notes/questions I have: > I considered adding Collector.Characteristics.PRESIZEABLE, but figured it was not needed given that sizedSupplier should always delegate to supplier. > Collector.sizedSupplier could be a LongFunction instead of IntFunction (since Sink.begin provides long sizes), but every Collection type I've looked at uses int for initialCapacity, so I think IntFunction makes more sense. > StringJoiner should be updated to take an initalCapacity (should I commit this change in the webrev, or leave for another enhancement?) > What tests should I add for this enhancement? > There are some benchmarks in the github repo. I was initially surprised when I saw that my bare-bones parallel stream did not have a throughput improvement like the serial one, but after doing some debugging I think it is from Collector.combiner dominating the runtime. > > Regards, > > August > > On Thu, Feb 28, 2019 at 12:56 AM Tagir Valeev > wrote: > Hello! > > I wouldn't use presized HashSet, because you never know how many duplicates are expected. What if the input stream has a million of elements, but only two of them are distinct? Do you really want to allocate a hash table for million elements in advance? > > For toMap() without custom supplier and merger preallocation sounds reasonable as in this case duplicating key is an exceptional case, so we may expect a specific number of elements. > > ??, 28 ????. 2019 ?., 11:38 August Nagro augustnagro at gmail.com : > Tagir, > > Great to see the validating benchmarks. > > > I think it's the best solution given the fact that very few collectors may benefit from the exact known size, and this benefit usually disappears when collectors are composed (e.g. using groupingBy: downstream toList() would not win anything if it provides a sizedSupplier). > > I would like to see your benchmarks for that statement too. After all, Hashmap, HashSet, etc all have presizing constructors, aren't those there for a reason? > > So I am still convinced that presizing is important for other collector types, including custom collectors. Although I'm open to having my mind changed. > > I'm happy to contribute an implementation as well, I was hoping that this this (smallish) patch would help me learn the OpenJdk process and make future contributions easier! > > - August > > On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev > wrote: > Hello! > > > A less intrusive API direction might be a version of Collector whose > > supplier function took a size-estimate argument; this might even help in > > parallel since it allows for intermediate results to start with a better > > initial size guess. (And this could be implemented as a default that > > delegates to the existing supplier.) Still, not really sure this > > carries its weight. > > It's interesting that such optimization is possible without API > change, using the "hidden knowledge". > While public API stays the same, the collect method implementation may > check if custom > non-public Collector implementation is supplied, and in this case may > use the sized supplier. > I think it's the best solution given the fact that very few collectors > may benefit from the exact > known size, and this benefit usually disappears when collectors are > composed (e.g. using groupingBy: > downstream toList() would not win anything if it provides a sizedSupplier). > > I created a quick patch and launched a quick benchmark like this: > return new SplittableRandom(0).ints(length, 0, > 100).boxed().collect(Collectors.toList()); > For length = 100, 10000, 1000000 > > Here's results for vanilla 13-ea+8: > length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 B/op > length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = > 169280 B/op > length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc > rate = 14586750 B/op > > Patched: > length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op > length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = 40368 B/op > length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc > rate = 4000382 B/op > > As you can see, exact allocation really helps to reduce alloc pressure > and produces better performance for big lists. > > If such kind of patch is acceptable for Stream API, I can file a > ticket and submit a webrev. > > With best regards, > Tagir Valeev > > The patch follows: > > --- src/java.base/share/classes/java/util/stream/Collectors.java > (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) > +++ src/java.base/share/classes/java/util/stream/Collectors.java > (revision 53626+:e2fc434b410a+) > @@ -50,6 +50,7 @@ > import java.util.function.BinaryOperator; > import java.util.function.Consumer; > import java.util.function.Function; > +import java.util.function.IntFunction; > import java.util.function.Predicate; > import java.util.function.Supplier; > import java.util.function.ToDoubleFunction; > @@ -194,23 +195,34 @@ > */ > static class CollectorImpl implements Collector { > private final Supplier supplier; > + private final IntFunction sizedSupplier; > private final BiConsumer accumulator; > private final BinaryOperator combiner; > private final Function finisher; > private final Set characteristics; > > CollectorImpl(Supplier supplier, > + IntFunction sizedSupplier, > BiConsumer accumulator, > BinaryOperator combiner, > Function finisher, > Set characteristics) { > this.supplier = supplier; > + this.sizedSupplier = sizedSupplier; > this.accumulator = accumulator; > this.combiner = combiner; > this.finisher = finisher; > this.characteristics = characteristics; > } > > + CollectorImpl(Supplier supplier, > + BiConsumer accumulator, > + BinaryOperator combiner, > + Function finisher, > + Set characteristics) { > + this(supplier, null, accumulator, combiner, finisher, > characteristics); > + } > + > CollectorImpl(Supplier supplier, > BiConsumer accumulator, > BinaryOperator combiner, > @@ -228,6 +240,10 @@ > return supplier; > } > > + IntFunction sizedSupplier() { > + return sizedSupplier; > + } > + > @Override > public BinaryOperator combiner() { > return combiner; > @@ -275,8 +291,11 @@ > */ > public static > Collector> toList() { > - return new CollectorImpl<>((Supplier>) > ArrayList::new, List::add, > + return new CollectorImpl<>((Supplier>) ArrayList::new, > + ArrayList::new, > + List::add, > (left, right) -> { > left.addAll(right); return left; }, > + castingIdentity(), > CH_ID); > } > > Index: src/java.base/share/classes/java/util/stream/ReduceOps.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/util/stream/ReduceOps.java > (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) > +++ src/java.base/share/classes/java/util/stream/ReduceOps.java > (revision 53626+:e2fc434b410a+) > @@ -36,6 +36,7 @@ > import java.util.function.BinaryOperator; > import java.util.function.DoubleBinaryOperator; > import java.util.function.IntBinaryOperator; > +import java.util.function.IntFunction; > import java.util.function.LongBinaryOperator; > import java.util.function.ObjDoubleConsumer; > import java.util.function.ObjIntConsumer; > @@ -155,13 +156,20 @@ > public static TerminalOp > makeRef(Collector collector) { > Supplier supplier = Objects.requireNonNull(collector).supplier(); > + @SuppressWarnings("unchecked") > + IntFunction sizedSupplier = collector instanceof > Collectors.CollectorImpl ? > + ((Collectors.CollectorImpl) > collector).sizedSupplier() : null; > BiConsumer accumulator = collector.accumulator(); > BinaryOperator combiner = collector.combiner(); > class ReducingSink extends Box > implements AccumulatingSink { > @Override > public void begin(long size) { > - state = supplier.get(); > + if (sizedSupplier != null && size >= 0 && size <= > Integer.MAX_VALUE) { > + state = sizedSupplier.apply((int) size); > + } else { > + state = supplier.get(); > + } > } > > @Override From mikhailo.seledtsov at oracle.com Mon Mar 4 21:57:54 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Mon, 4 Mar 2019 13:57:54 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Message-ID: <511d81a3-847c-49d0-76ff-fdc836211f37@oracle.com> Hi Igor, ? Sorry it took a while to get back to you on this one. See my comment below On 2/22/19 10:35 AM, mikhailo.seledtsov at oracle.com wrote: > Overall the change looks good; thank you Igor for doing this. I have > couple of comments: > > ? - I am in favor of the approach where we move tests first under > corresponding sub-component directories in > ??? test/hotspot sub-tree, and then figure out whether to keep them. > Even though in general I am in favor > ??? of removing tests that are obsolete or of questionable value, this > requires time, consideration and discussions. > ??? Hence, I recommend filing an RFE for that, which can be addressed > after the migration. > > ? - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime > ??? The tests should go into underlying sub-directories which best > match functional area or topic of that test. > ??? In most cases you did it in your change, but there are several > tests that your change places directly under > ???? test/hotspot/jtreg/runtime/: > > ???? ExplicitArithmeticCheck.java > ???? MonitorCacheMaybeExpand_DeadLock.java > ???? ReflectStackOverflow.java > ???? ShiftTest.java - David commented this can go under compiler (a > jit test) > ???? WideStrictInline.java I have looked at the tests in more detail, and here are my recommendation of placements: ??? ExplicitArithmeticCheck ??????? This test checks that ArithmeticException is thrown when appropriate ??????? I would recommend placing it under runtime/ErrorHandling ??? MonitorCacheMaybeExpand_DeadLock ??????? Existing folder: runtime/Thread (it does have a locking test) ??????? Or, alternatively, create a new folder: 'locking' or 'monitors' ??? ReflectStackOverflow ??????? Uses recursive reflection attempting to provoke stack overflow ??????? Can go under: runtime/reflect ??? WideStrictInline: ??????? checks for correct FP inlining by the interpreter ??????? I could not find existing sections; perhaps create 'interpreter' ??????? folder under 'runtime' Thank you, Misha > > ???? Since we plan (as discussed) to follow up this work with an RFE > to review and consider removal of old and > ???? not-that-useful tests, you could place them under 'misc' for now. > Alternatively, find the best match > ???? or create new sub-directories under runtime/ if necessary. > > > Thank you, > Misha > > > On 2/21/19 11:53 AM, Igor Ignatyev wrote: >> >>> On Feb 21, 2019, at 12:11 AM, David Holmes >>> wrote: >>> >>> Hi Igor, >>> >>> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>>> Hi all, >>>> could you please review this small patch which moves tests from >>>> test/jdk/vm? >>> I find some of these tests - the runtime ones at least - of >>> extremely dubious value. They either cover basic functionality that >>> is already well covered, or are regression tests for bugs in code >>> that hasn't existed for many many years! >> as I wrote in another related email: "one of the reason I'm proposing >> this move is exactly questionable value of these tests, I want to >> believe that having these tests in hotspot/ test directories will >> bring more attention to them from corresponding component teams and >> hence they will be removed/reworked/re-whatever faster and better. >> and I also believe that one of the reason we got duplications exactly >> because these tests were located in jdk test suite." >> >>> BTW: >>> >>> test/hotspot/jtreg/runtime/ShiftTest.java >>> >>> is actually a jit test according to the test comment. >> sure, I will move it to hotspot/compiler. >>>> there are 16 tests in test/jdk/vm directory. all but >>>> JniInvocationTest are hotspot tests, so they are moved to >>>> test/hotspot test suite; JniInvocationTest is a launcher test >>> No its a JNI invocation API test - nothing to do with our launcher. >>> It belongs in runtime/jni. But we already have tests in runtime that >>> use the JNI invocation API so this test adds no new coverage. >> this is actually was my first reaction, and I even have the webrev >> which moves it to runtime/jni, but then I looked at the associated >> bug and it is filed against tools/launcher. and I even got a false >> (as I know by now) memory that I saw JLI_ method being called from >> the test. there is actually another test >> (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which >> calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. >> >>> I really think the value of these tests needs to be examined before >>> they are brought over. >> I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep >> jdk/vm directory the more tests can end up there and the more rotten >> these tests become. >> >> Thanks, >> -- Igor >>> Thanks, >>> David >>> ----- >>> >>>> and hence it's moved to test/jdk/tools/launcher. as >>>> hotspot/compiler and hotspot/gc tests use packages, the tests moved >>>> there have been updated to have a package statement. >>>> webrev: >>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>>> testing: tier[1-2] (in progress), all the touched tests locally >>>> Thanks, >>>> -- Igor > From augustnagro at gmail.com Mon Mar 4 23:02:43 2019 From: augustnagro at gmail.com (August Nagro) Date: Mon, 4 Mar 2019 17:02:43 -0600 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: I think documentation could help this (and maybe removing the two added `of` helpers so an explicit collector must be created), but you're right about the cost. If the consensus is not to change Collector, then maybe Tagir's suggestion for internal-only change can be implemented? On Mon, Mar 4, 2019 at 2:53 PM Brian Goetz wrote: > So, unfortunately I think this particular API evolution idiom is kind of > questionable. There is a new method, sizedSupplier, with a default that > delegates to the unsized supplier. But, that leaves implementors in a > position where they don?t really know which one to implement, and the use > of characteristics to hint at which one to call is kind of convoluted. > > You?re focused on the benefits ? that in some cases, collection can be > faster. That?s good. But one of the big costs here is that an interfaces > that was simple is now considerably less so. That?s a cost; not convinced > the two are in balance. > > > On Mar 4, 2019, at 12:35 AM, August Nagro wrote: > > Hi everyone, > > My implementation is at > https://github.com/AugustNagro/presize-collectors-bench and I have a > webrev here: http://august.nagro.us/presized-collectors/webrev/. > > The changes that I made were: > > - Add `default IntFunction sizedSupplier()` to Collector > - Add 2 new Collector.of helper methods taking a sized supplier > - Update the applicable collectors in Collectors to provide a > sizedSupplier > - Have ReferencePipeline & ReduceOps call sizedSupplier when > appropriate > > Some notes/questions I have: > > - I considered adding Collector.Characteristics.PRESIZEABLE, but > figured it was not needed given that sizedSupplier should always delegate > to supplier. > - Collector.sizedSupplier could be a LongFunction instead of > IntFunction (since Sink.begin provides long sizes), but every Collection > type I've looked at uses int for initialCapacity, so I think IntFunction > makes more sense. > - StringJoiner should be updated to take an initalCapacity (should I > commit this change in the webrev, or leave for another enhancement?) > - What tests should I add for this enhancement? > > There are some benchmarks in the github repo. I was initially surprised > when I saw that my bare-bones parallel stream did not have a throughput > improvement like the serial one, but after doing some debugging I think it > is from Collector.combiner dominating the runtime. > > Regards, > > August > > On Thu, Feb 28, 2019 at 12:56 AM Tagir Valeev wrote: > >> Hello! >> >> I wouldn't use presized HashSet, because you never know how many >> duplicates are expected. What if the input stream has a million of >> elements, but only two of them are distinct? Do you really want to allocate >> a hash table for million elements in advance? >> >> For toMap() without custom supplier and merger preallocation sounds >> reasonable as in this case duplicating key is an exceptional case, so we >> may expect a specific number of elements. >> >> ??, 28 ????. 2019 ?., 11:38 August Nagro augustnagro at gmail.com: >> >>> Tagir, >>> >>> Great to see the validating benchmarks. >>> >>> > I think it's the best solution given the fact that very few collectors may >>> benefit from the exact known size, and this benefit usually disappears >>> when collectors are composed (e.g. using groupingBy: downstream >>> toList() would not win anything if it provides a sizedSupplier). >>> >>> I would like to see your benchmarks for that statement too. After all, >>> Hashmap, HashSet, etc all have presizing constructors, aren't those there >>> for a reason? >>> >>> So I am still convinced that presizing is important for other collector >>> types, including custom collectors. Although I'm open to having my mind >>> changed. >>> >>> I'm happy to contribute an implementation as well, I was hoping that >>> this this (smallish) patch would help me learn the OpenJdk process and make >>> future contributions easier! >>> >>> - August >>> >>> On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev wrote: >>> >>>> Hello! >>>> >>>> > A less intrusive API direction might be a version of Collector whose >>>> > supplier function took a size-estimate argument; this might even help >>>> in >>>> > parallel since it allows for intermediate results to start with a >>>> better >>>> > initial size guess. (And this could be implemented as a default that >>>> > delegates to the existing supplier.) Still, not really sure this >>>> > carries its weight. >>>> >>>> It's interesting that such optimization is possible without API >>>> change, using the "hidden knowledge". >>>> While public API stays the same, the collect method implementation may >>>> check if custom >>>> non-public Collector implementation is supplied, and in this case may >>>> use the sized supplier. >>>> I think it's the best solution given the fact that very few collectors >>>> may benefit from the exact >>>> known size, and this benefit usually disappears when collectors are >>>> composed (e.g. using groupingBy: >>>> downstream toList() would not win anything if it provides a >>>> sizedSupplier). >>>> >>>> I created a quick patch and launched a quick benchmark like this: >>>> return new SplittableRandom(0).ints(length, 0, >>>> 100).boxed().collect(Collectors.toList()); >>>> For length = 100, 10000, 1000000 >>>> >>>> Here's results for vanilla 13-ea+8: >>>> length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 >>>> B/op >>>> length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = >>>> 169280 B/op >>>> length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc >>>> rate = 14586750 B/op >>>> >>>> Patched: >>>> length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op >>>> length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = >>>> 40368 B/op >>>> length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc >>>> rate = 4000382 B/op >>>> >>>> As you can see, exact allocation really helps to reduce alloc pressure >>>> and produces better performance for big lists. >>>> >>>> If such kind of patch is acceptable for Stream API, I can file a >>>> ticket and submit a webrev. >>>> >>>> With best regards, >>>> Tagir Valeev >>>> >>>> The patch follows: >>>> >>>> --- src/java.base/share/classes/java/util/stream/Collectors.java >>>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >>>> +++ src/java.base/share/classes/java/util/stream/Collectors.java >>>> (revision 53626+:e2fc434b410a+) >>>> @@ -50,6 +50,7 @@ >>>> import java.util.function.BinaryOperator; >>>> import java.util.function.Consumer; >>>> import java.util.function.Function; >>>> +import java.util.function.IntFunction; >>>> import java.util.function.Predicate; >>>> import java.util.function.Supplier; >>>> import java.util.function.ToDoubleFunction; >>>> @@ -194,23 +195,34 @@ >>>> */ >>>> static class CollectorImpl implements Collector { >>>> private final Supplier supplier; >>>> + private final IntFunction sizedSupplier; >>>> private final BiConsumer accumulator; >>>> private final BinaryOperator combiner; >>>> private final Function finisher; >>>> private final Set characteristics; >>>> >>>> CollectorImpl(Supplier supplier, >>>> + IntFunction sizedSupplier, >>>> BiConsumer accumulator, >>>> BinaryOperator combiner, >>>> Function finisher, >>>> Set characteristics) { >>>> this.supplier = supplier; >>>> + this.sizedSupplier = sizedSupplier; >>>> this.accumulator = accumulator; >>>> this.combiner = combiner; >>>> this.finisher = finisher; >>>> this.characteristics = characteristics; >>>> } >>>> >>>> + CollectorImpl(Supplier supplier, >>>> + BiConsumer accumulator, >>>> + BinaryOperator combiner, >>>> + Function finisher, >>>> + Set characteristics) { >>>> + this(supplier, null, accumulator, combiner, finisher, >>>> characteristics); >>>> + } >>>> + >>>> CollectorImpl(Supplier supplier, >>>> BiConsumer accumulator, >>>> BinaryOperator combiner, >>>> @@ -228,6 +240,10 @@ >>>> return supplier; >>>> } >>>> >>>> + IntFunction sizedSupplier() { >>>> + return sizedSupplier; >>>> + } >>>> + >>>> @Override >>>> public BinaryOperator combiner() { >>>> return combiner; >>>> @@ -275,8 +291,11 @@ >>>> */ >>>> public static >>>> Collector> toList() { >>>> - return new CollectorImpl<>((Supplier>) >>>> ArrayList::new, List::add, >>>> + return new CollectorImpl<>((Supplier>) ArrayList::new, >>>> + ArrayList::new, >>>> + List::add, >>>> (left, right) -> { >>>> left.addAll(right); return left; }, >>>> + castingIdentity(), >>>> CH_ID); >>>> } >>>> >>>> Index: src/java.base/share/classes/java/util/stream/ReduceOps.java >>>> IDEA additional info: >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>>> <+>UTF-8 >>>> =================================================================== >>>> --- src/java.base/share/classes/java/util/stream/ReduceOps.java >>>> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >>>> +++ src/java.base/share/classes/java/util/stream/ReduceOps.java >>>> (revision 53626+:e2fc434b410a+) >>>> @@ -36,6 +36,7 @@ >>>> import java.util.function.BinaryOperator; >>>> import java.util.function.DoubleBinaryOperator; >>>> import java.util.function.IntBinaryOperator; >>>> +import java.util.function.IntFunction; >>>> import java.util.function.LongBinaryOperator; >>>> import java.util.function.ObjDoubleConsumer; >>>> import java.util.function.ObjIntConsumer; >>>> @@ -155,13 +156,20 @@ >>>> public static TerminalOp >>>> makeRef(Collector collector) { >>>> Supplier supplier = >>>> Objects.requireNonNull(collector).supplier(); >>>> + @SuppressWarnings("unchecked") >>>> + IntFunction sizedSupplier = collector instanceof >>>> Collectors.CollectorImpl ? >>>> + ((Collectors.CollectorImpl) >>>> collector).sizedSupplier() : null; >>>> BiConsumer accumulator = collector.accumulator(); >>>> BinaryOperator combiner = collector.combiner(); >>>> class ReducingSink extends Box >>>> implements AccumulatingSink { >>>> @Override >>>> public void begin(long size) { >>>> - state = supplier.get(); >>>> + if (sizedSupplier != null && size >= 0 && size <= >>>> Integer.MAX_VALUE) { >>>> + state = sizedSupplier.apply((int) size); >>>> + } else { >>>> + state = supplier.get(); >>>> + } >>>> } >>>> >>>> @Override >>>> >>> > From alexander.matveev at oracle.com Mon Mar 4 23:44:06 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 4 Mar 2019 15:44:06 -0800 Subject: RFR: JDK-8219679: Help text changes in jpackage In-Reply-To: <50b6f8d5-186c-eb5b-bc2a-b64056f7595f@oracle.com> References: <50b6f8d5-186c-eb5b-bc2a-b64056f7595f@oracle.com> Message-ID: <91993391-8a32-cb6e-51d9-554e10392855@oracle.com> Hi Andy, http://cr.openjdk.java.net/~herrick/8219679/webrev.02/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html Line 109: Missing ">" after main class? Line 132: additionl - > additional Otherwise looks fine. Thanks, Alexander On 3/3/2019 7:34 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > > [1] https://bugs.openjdk.java.net/browse/JDK-8219679 > > [2] http://cr.openjdk.java.net/~herrick/8219679/ > > /Andy > From jonathan.gibbons at oracle.com Mon Mar 4 23:56:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 4 Mar 2019 15:56:31 -0800 Subject: RFR: JDK-8219679: Help text changes in jpackage In-Reply-To: <50b6f8d5-186c-eb5b-bc2a-b64056f7595f@oracle.com> References: <50b6f8d5-186c-eb5b-bc2a-b64056f7595f@oracle.com> Message-ID: <449e075b-faae-4b19-a08c-5bd1205e2bb2@oracle.com> Andy, Is it something to be concerned about that you have English text directly in the source code, at CLIHelp.java, lines 57-65. Specifically, the repeated use of "and". Is that something that should be localizable? -- Jon On 3/3/19 7:34 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > > [1] https://bugs.openjdk.java.net/browse/JDK-8219679 > > [2] http://cr.openjdk.java.net/~herrick/8219679/ > > /Andy > From andy.herrick at oracle.com Tue Mar 5 01:00:24 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 4 Mar 2019 20:00:24 -0500 Subject: RFR: JDK-8219679: Help text changes in jpackage In-Reply-To: <449e075b-faae-4b19-a08c-5bd1205e2bb2@oracle.com> References: <50b6f8d5-186c-eb5b-bc2a-b64056f7595f@oracle.com> <449e075b-faae-4b19-a08c-5bd1205e2bb2@oracle.com> Message-ID: yes - I was thinking the list of extension need not be localized but didn't think of the "and" in it - will think of another way to do this. /Andy On 3/4/2019 6:56 PM, Jonathan Gibbons wrote: > Andy, > > Is it something to be concerned about that you have English text > directly in the source code, at CLIHelp.java, lines 57-65. > Specifically, the repeated use of "and". > > Is that something that should be localizable? > > -- Jon > > On 3/3/19 7:34 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219679 >> >> [2] http://cr.openjdk.java.net/~herrick/8219679/ >> >> /Andy >> From alexander.matveev at oracle.com Tue Mar 5 01:46:52 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 4 Mar 2019 17:46:52 -0800 Subject: RFR: JDK-8219678: CLI changes in jpackage In-Reply-To: <2fc23923-53d4-cd5b-0852-897d6de48c11@oracle.com> References: <2fc23923-53d4-cd5b-0852-897d6de48c11@oracle.com> Message-ID: <2d487d31-ca54-251b-9337-5be529c09b6b@oracle.com> Hi Andy, http://cr.openjdk.java.net/~herrick/8219678/webrev.03/src/jdk.jpackage/share/classes/jdk/jpackage/internal/BundlerParamInfo.java.frames.html Line 32: Do we need this import? I do not see any changes which might require it. Otherwise looks fine. Thanks, Alexander On 3/3/2019 7:48 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This change modifies the CLI and other behavior as described in [1] > > [1] https://bugs.openjdk.java.net/browse/JDK-8219678 > > [2] http://cr.openjdk.java.net/~herrick/8219678/ > > > /Andy > From andy.herrick at oracle.com Tue Mar 5 02:01:45 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 4 Mar 2019 21:01:45 -0500 Subject: RFR: JDK-8219678: CLI changes in jpackage In-Reply-To: <2d487d31-ca54-251b-9337-5be529c09b6b@oracle.com> References: <2fc23923-53d4-cd5b-0852-897d6de48c11@oracle.com> <2d487d31-ca54-251b-9337-5be529c09b6b@oracle.com> Message-ID: On 3/4/2019 8:46 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8219678/webrev.03/src/jdk.jpackage/share/classes/jdk/jpackage/internal/BundlerParamInfo.java.frames.html > > Line 32: Do we need this import? I do not see any changes which might > require it. > Thanks - I had removed that line from several other files where I didn't think it was needed - and got an error.? I must have added it to this file when restoring it in the several other files.? I will fix. /Andy > Otherwise looks fine. > > Thanks, > Alexander > > On 3/3/2019 7:48 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> This change modifies the CLI and other behavior as described in [1] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219678 >> >> [2] http://cr.openjdk.java.net/~herrick/8219678/ >> >> >> /Andy >> > From dkwakkel at gmail.com Tue Mar 5 06:11:39 2019 From: dkwakkel at gmail.com (Donald Kwakkel) Date: Tue, 5 Mar 2019 07:11:39 +0100 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: > On 02/28/2019 01:06 PM, Alan Bateman wrote: > > On 28/02/2019 20:58, Jonathan Gibbons wrote: > >> Looking at the revised JAR specification, approved in [1], it is > >> disappointing that the spec contains text which is specific to > >> a JAR file being used in a classloader: > >> > >> |The resulting URLs are inserted into the search path of the class > >> loader opening the context JAR immediately following the path of the > >> context JAR. Any duplicated URLs are omitted.| > >> > >> That text would seem not to apply to javac and other tools that may wish > >> to process the class files in a JAR file. > > That should be fixed as it should apply at compile-time too. > > > > -Alan > > |Agreed it might be good to fix it if possible. All the preceding text > is good, and can be handled by javac. The only questionable bit is the > text "Any duplicated URLs are omitted" which could be moved up a bit in > the spec to a new paragraph, and maybe rephrased to use "ignored" > instead of "omitted". If that were done, all the stuff about class > loaders could be taken as non-normative text. So if I am correct the answer to Question 2 is: Yes, behavior must be the same. What are the next steps to take for this? And can someone also answer my other questions?: Question 1: Where can I find the tests for these changes? Question 2: Where should the common code for this be located? Question 3: Is it an idea to first implement below patch and backport that, and in addition as new ticket implement the new behaviour also for javac? Question 4:Is this they way to do it, or is there a better way to provide debug information to users running javac? From openjdk at duigou.org Tue Mar 5 20:43:51 2019 From: openjdk at duigou.org (Mike Duigou) Date: Tue, 05 Mar 2019 12:43:51 -0800 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: Message-ID: <1ed0f069f30c240a629a09b0c4afc69c@duigou.org> I don't believe that I would use the proposed enhancement to the for statement. For me there is cognitive load reduction in using a symmetrical method for all iterations even if they end up being a little more complicated for individual cases. Usually, for me, I use streams. Even the more complicated patterns such as the presented example will hopefully be familiar because they are repeated in many places throughout the code. Truly unusual or unique usages are hopefully very rare. To choose between old style for, enhanced for, or streams based on which warts are to be avoided is just frustrating. Mixing idioms or required mixing of idioms produces the least satisfying result. Was the use of a particular idiom a necessity? A choice? Of no consequence? This gets harder to decode with a larger number of available idioms. I've seen library functions (usually statically imported) used for the "(Iterble) stream::iterator" construction that presented it as "iterable(stream)". Not something I would use but it seemed clean enough for those who wanted it. Cheers, Mike From naoto.sato at oracle.com Tue Mar 5 23:20:55 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 5 Mar 2019 15:20:55 -0800 Subject: [13] RFR: 8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time Message-ID: <42f5f5f7-e8bf-9d12-7bbc-0429c9312ad7@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218948 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8218948/webrev.00/ This is a follow on fix to 8217366. There are several root causes included in this bug, when the runtime supplements missing display names in non-US locales :- - Retrieve the names for the requested id first, before it maps to the canonical id, and on canonicalizing the id, use unique way (canonicalTZID()) to canonicalize. - Retrieve the names in the same manner, between DateFormatSymbols.getZoneStrings() and TimeZone.getDisplayName(). - Correctly map the Chinese locales between JDK and CLDR, in terms of Simplified/Traditional scripts. Naoto From weijun.wang at oracle.com Wed Mar 6 00:50:36 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Mar 2019 08:50:36 +0800 Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> References: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> Message-ID: <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com> The fix looks fine to me. However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy? I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer. Thanks, Max > On Mar 6, 2019, at 3:53 AM, Sean Mullan wrote: > > Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError. > > The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard). > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/ > bugid: https://bugs.openjdk.java.net/browse/JDK-8218618 > > --Sean From amaembo at gmail.com Wed Mar 6 10:10:41 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 6 Mar 2019 17:10:41 +0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: Hello! By the way one of the painful code patterns in modern Java is `for(int i = 0; i wrote: > > Hi all, > > Please review and comment on this proposal to allow Stream instances to be used > in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream using a conventional loop. However, > the Stream interface doesn't implement Iterable, and therefore streams cannot be > used with the enhanced-for statement. This is a proposal to remedy that > situation by introducing a new interface IterableOnce that is a subtype of > Iterable, and then retrofitting the Stream interface to implement it. Other JDK > classes will also be retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no tests > yet. However, the implementation is so simple that I figured I should include > it. Comments on the specification wording are also welcome. > > Thanks, > > s'marks From nishit.jain at oracle.com Wed Mar 6 11:56:24 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Wed, 6 Mar 2019 17:26:24 +0530 Subject: =?UTF-8?Q?=5b13=5d_RFR_8217254=2c_8217721=3a_CompactNumberFormat?= =?UTF-8?Q?=e2=80=8b=28=29_constructor_does_not_comply_with_spec_and_format?= =?UTF-8?Q?=e2=80=8b=28=29_method_spec_for_IAEx_is_not_complaint?= Message-ID: Hi, Please review the fix for JDK-8217254 and JDK-8217721 Bug: https://bugs.openjdk.java.net/browse/JDK-8217254 ???? https://bugs.openjdk.java.net/browse/JDK-8217721 Webrev: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.00/ Issue: The exception thrown by constructor and format() method was not compliant with the specification Fix: Updated the constructor and format method to throw exception as per the specification Regards, Nishit Jain From forax at univ-mlv.fr Wed Mar 6 12:37:37 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Mar 2019 13:37:37 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Hi Tagir, try to do it now and you will see that you can't, because you can not write Iterable yet. Once we will get generics over value types, it will be a no-brainer. R?mi ----- Mail original ----- > De: "Tagir Valeev" > ?: "Stuart Marks" > Cc: "core-libs-dev" > Envoy?: Mercredi 6 Mars 2019 11:10:41 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hello! > > By the way one of the painful code patterns in modern Java is `for(int > i = 0; i newbies and prone to errors as the variable need to be repeated three > times. Also the variable is not effectively final, despite it never > changes within the loop body, so could have been considered as > redeclared on every loop iteration (like in for-each). With the new > proposal it's possible to write `for(int i : range(0, bound).boxed())` > (assuming import static j.u.s.IntStream.range), which looks much > better, though it has obvious performance drawback. Moving > IterableOnce to BaseStream would enable to use `for(int i : range(0, > bound))` which looks even better, though again we have plenty of > garbage (but considerably less than in previous case!). I wonder > whether Java could evolve to the point where such kind of code would > be a recommended way to iterate over subsequent integer values without > any performance handicap. > > With best regards, > Tagir Valeev. > > On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: >> >> Hi all, >> >> Please review and comment on this proposal to allow Stream instances to be used >> in enhanced-for ("for-each") loops. >> >> Abstract >> >> Occasionally it's useful to iterate a Stream using a conventional loop. However, >> the Stream interface doesn't implement Iterable, and therefore streams cannot be >> used with the enhanced-for statement. This is a proposal to remedy that >> situation by introducing a new interface IterableOnce that is a subtype of >> Iterable, and then retrofitting the Stream interface to implement it. Other JDK >> classes will also be retrofitted to implement IterableOnce. >> >> Full Proposal: >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html >> >> Bug report: >> >> https://bugs.openjdk.java.net/browse/JDK-8148917 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ >> >> Note, this changeset isn't ready to push yet. In particular, it has no tests >> yet. However, the implementation is so simple that I figured I should include >> it. Comments on the specification wording are also welcome. >> >> Thanks, >> > > s'marks From swpalmer at gmail.com Wed Mar 6 14:48:47 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 6 Mar 2019 09:48:47 -0500 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: I don?t mean any offence, but I have to say, I strongly disagree with nearly everything you?ve written below. To me, the idea of making a stream of integers for a simple loop counter is hackish, confusing, verbose, and basically abusing the stream concept. The only part I agree with is that it is an obvious performance drawback as well. A counter and a stream of integers are completely different concepts and should not be confused in this manner. Scott > On Mar 6, 2019, at 5:10 AM, Tagir Valeev wrote: > > Hello! > > By the way one of the painful code patterns in modern Java is `for(int > i = 0; i newbies and prone to errors as the variable need to be repeated three > times. Also the variable is not effectively final, despite it never > changes within the loop body, so could have been considered as > redeclared on every loop iteration (like in for-each). With the new > proposal it's possible to write `for(int i : range(0, bound).boxed())` > (assuming import static j.u.s.IntStream.range), which looks much > better, though it has obvious performance drawback. Moving > IterableOnce to BaseStream would enable to use `for(int i : range(0, > bound))` which looks even better, though again we have plenty of > garbage (but considerably less than in previous case!). I wonder > whether Java could evolve to the point where such kind of code would > be a recommended way to iterate over subsequent integer values without > any performance handicap. > > With best regards, > Tagir Valeev. > > On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: >> >> Hi all, >> >> Please review and comment on this proposal to allow Stream instances to be used >> in enhanced-for ("for-each") loops. >> >> Abstract >> >> Occasionally it's useful to iterate a Stream using a conventional loop. However, >> the Stream interface doesn't implement Iterable, and therefore streams cannot be >> used with the enhanced-for statement. This is a proposal to remedy that >> situation by introducing a new interface IterableOnce that is a subtype of >> Iterable, and then retrofitting the Stream interface to implement it. Other JDK >> classes will also be retrofitted to implement IterableOnce. >> >> Full Proposal: >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html >> >> Bug report: >> >> https://bugs.openjdk.java.net/browse/JDK-8148917 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ >> >> Note, this changeset isn't ready to push yet. In particular, it has no tests >> yet. However, the implementation is so simple that I figured I should include >> it. Comments on the specification wording are also welcome. >> >> Thanks, >> >> s'marks From peter.levart at gmail.com Wed Mar 6 15:50:06 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 6 Mar 2019 16:50:06 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: Hi Stuart, According to Liskov substitution principle: ??? Subtype Requirement: Let ? ( x ) be a property provable about objects x of type T. Then ? ( y ) should be true for objects y of type S where S is a subtype of T. Let ? ( x ) for objects x of type Iterable be: "x.iterator() may be invoked multiple times, each time starting new iteration". This clearly holds. Does ? ( y ) hold for objects y of type IterableOnce? Clearly not. In this respect Iterable should be a subtype of IterableOnce and foreach loop should be retrofitted to work with IterableOnce. What do you think? Regards, Peter On 3/1/19 3:43 AM, Stuart Marks wrote: > Hi all, > > Please review and comment on this proposal to allow Stream instances > to be used in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream using a conventional > loop. However, the Stream interface doesn't implement Iterable, and > therefore streams cannot be used with the enhanced-for statement. This > is a proposal to remedy that situation by introducing a new interface > IterableOnce that is a subtype of Iterable, and then retrofitting the > Stream interface to implement it. Other JDK classes will also be > retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > ??? https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > ??? http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no > tests yet. However, the implementation is so simple that I figured I > should include it. Comments on the specification wording are also > welcome. > > Thanks, > > s'marks From adam.farley at uk.ibm.com Wed Mar 6 16:28:03 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 6 Mar 2019 16:28:03 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: Hi Mandy, The webrev has been updated with the new test: http://cr.openjdk.java.net/~afarley/8216558/webrev/ Note that I included a handful of small improvements, and that the final fields are all setAccessible by default, because (a) it seemed cleaner than adding a new control bit, and (b) nobody is meant to be changing final fields anyway. Open for review. Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 01/03/2019 17:50:49: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 01/03/2019 17:50 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > > You can add a new test for this specific test case. > MethodHandlesGeneralTest is a general test that you either update > it to fit in existing testing framework or add a new test which > will be simpler for you. Please include the test in the webrev > for easier review. > > Mandy > > On 3/1/19 2:31 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > Historically, the bigger the change I propose, the more months it takes > > the OpenJDK community to approve. > > > > I'm not sure I can justify adding an entire class to test a very > > specific case. > > > > Additionally, HasFields seems excessively complex. I don't understand > > why it feels the > > need to spend 34 lines of code parsing, processing, and storing 20 > > minimal variables it already has. > > > > Seems like an informative comment, followed by a littany of > > "cases.add..." would have been a simpler choice. > > > > Could you tell me if I'm missing something? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > Mandy Chung wrote on 21/02/2019 17:37:54: > > > >> From: Mandy Chung > >> To: Adam Farley8 > >> Cc: core-libs-dev > >> Date: 21/02/2019 17:41 > >> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > >> to throw IllegalAccessException for final fields > >> > >> Hi Adam, > >> > >> On 2/14/19 3:16 AM, Adam Farley8 wrote: > >> > Hi Mandy, > >> > > >> > Apologies for the delay. > >> > >> Same here as I returned from vacation yesterday. > >> > >> > Could you review this cdiff as a proposal for the jtreg test? > >> > > >> > Made sense to modify the existing test set for MethodHandle rather than > >> > add a new one. > >> > >> Yes it'd be better if you extend the MethodHandlesGeneralTest and > >> MethodHandlesTest to test the write access. > >> > >> To add the test cases properly, MethodHandlesTest.HasFields > >> should be modified to include the read-only fields. It might > >> be cleaner to add a new HasReadOnlyFields class and maybe a new > >> TEST_SET_ACCESSIBLE bit that requests to call setAccessible(true) > >> and testSetter expects unreflectSetter to throw exception on > >> static final fields (possibly additional bits might be needed). > >> > >> Mandy > >> > > > > 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 Wed Mar 6 17:54:41 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 6 Mar 2019 09:54:41 -0800 Subject: =?UTF-8?Q?Re=3a_=3ci18n_dev=3e_=5b13=5d_RFR_8217254=2c_8217721=3a_C?= =?UTF-8?Q?ompactNumberFormat=e2=80=8b=28=29_constructor_does_not_comply_wit?= =?UTF-8?Q?h_spec_and_format=e2=80=8b=28=29_method_spec_for_IAEx_is_not_comp?= =?UTF-8?Q?laint?= In-Reply-To: References: Message-ID: <8d2ca26c-fd85-87e7-3600-de36434612ed@oracle.com> Hi Nishit, Just one comment on j.t.CompactNumberFormat.java. At line 425, Null check can be done at the top of the method, as a parameter check, so that all the unnecessary "if-elseif" can be avoided. Others look good. Naoto On 3/6/19 3:56 AM, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8217254 and JDK-8217721 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217254 > ???? https://bugs.openjdk.java.net/browse/JDK-8217721 > > Webrev: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.00/ > > > Issue: The exception thrown by constructor and format() method was not > compliant with the specification > Fix: Updated the constructor and format method to throw exception as per > the specification > > Regards, > Nishit Jain > From raffaello.giulietti at gmail.com Wed Mar 6 19:31:24 2019 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Wed, 6 Mar 2019 20:31:24 +0100 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> Message-ID: <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> Hi, the latest version of the patch, replacing the one found at [1]. In the next days, my sponsor Brian Burkhalter will publish it as a webrev. * It adds a fast path for a large set of integer valued doubles and floats. * The comments refer to sections, tables and figures of the document [2]. Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058581.html [2] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 ---- # HG changeset patch # Date 1551899836 -3600 # Wed Mar 06 20:17:16 2019 +0100 # Node ID 085dc7813bec375fc77ab7f0adecdce9d4d03c11 # Parent 17fb726e6d8eec4acc3b3a91e63cf6d9d5ba7103 Patch to fix JDK-4511638 4511638: Double.toString(double) sometimes produces incorrect results Reviewed-by: TBD Contributed-by: Raffaello Giulietti diff --git a/src/java.base/share/classes/java/lang/Double.java b/src/java.base/share/classes/java/lang/Double.java old mode 100644 new mode 100755 --- a/src/java.base/share/classes/java/lang/Double.java +++ b/src/java.base/share/classes/java/lang/Double.java @@ -32,6 +32,7 @@ import jdk.internal.math.FloatingDecimal; import jdk.internal.math.DoubleConsts; +import jdk.internal.math.DoubleToDecimal; import jdk.internal.HotSpotIntrinsicCandidate; /** @@ -145,69 +146,120 @@ public static final Class TYPE = (Class) Class.getPrimitiveClass("double"); /** - * Returns a string representation of the {@code double} - * argument. All characters mentioned below are ASCII characters. - *
    - *
  • If the argument is NaN, the result is the string - * "{@code NaN}". - *
  • Otherwise, the result is a string that represents the sign and - * magnitude (absolute value) of the argument. If the sign is negative, - * the first character of the result is '{@code -}' - * ({@code '\u005Cu002D'}); if the sign is positive, no sign character - * appears in the result. As for the magnitude m: - *
      - *
    • If m is infinity, it is represented by the characters - * {@code "Infinity"}; thus, positive infinity produces the result - * {@code "Infinity"} and negative infinity produces the result - * {@code "-Infinity"}. - * - *
    • If m is zero, it is represented by the characters - * {@code "0.0"}; thus, negative zero produces the result - * {@code "-0.0"} and positive zero produces the result - * {@code "0.0"}. + * Returns a string rendering of the {@code double} argument. * - *
    • If m is greater than or equal to 10-3 but less - * than 107, then it is represented as the integer part of - * m, in decimal form with no leading zeroes, followed by - * '{@code .}' ({@code '\u005Cu002E'}), followed by one or - * more decimal digits representing the fractional part of m. - * - *
    • If m is less than 10-3 or greater than or - * equal to 107, then it is represented in so-called - * "computerized scientific notation." Let n be the unique - * integer such that 10n ≤ m {@literal <} - * 10n+1; then let a be the - * mathematically exact quotient of m and - * 10n so that 1 ≤ a {@literal <} 10. The - * magnitude is then represented as the integer part of a, - * as a single decimal digit, followed by '{@code .}' - * ({@code '\u005Cu002E'}), followed by decimal digits - * representing the fractional part of a, followed by the - * letter '{@code E}' ({@code '\u005Cu0045'}), followed - * by a representation of n as a decimal integer, as - * produced by the method {@link Integer#toString(int)}. + *

      The characters of the result are all drawn from the ASCII set. + *

        + *
      • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
      • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
      • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
      • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
      • A finite positive {@code v} is rendered in two stages: + *
          + *
        • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
        • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. *
        *
      - * How many digits must be printed for the fractional part of - * m or a? There must be at least one digit to represent - * the fractional part, and beyond that as many, but only as many, more - * digits as are needed to uniquely distinguish the argument value from - * adjacent values of type {@code double}. That is, suppose that - * x is the exact mathematical value represented by the decimal - * representation produced by this method for a finite nonzero argument - * d. Then d must be the {@code double} value nearest - * to x; or if two {@code double} values are equally close - * to x, then d must be one of them and the least - * significant bit of the significand of d must be {@code 0}. + * + *

      A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

      The decimal dv + * for a finite positive {@code v} is defined as follows: + *

        + *
      • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
      • Let m be the minimal length over all decimals in R. + *
      • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
      • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
      + * + *

      The (uniquely) selected decimal dv + * is then formatted. * - *

      To create localized string representations of a floating-point - * value, use subclasses of {@link java.text.NumberFormat}. + *

      Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

        + *
      • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
      • Case 0 ≤ e < 7: + *
          + *
        • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
        • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
        + *
      • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
          + *
        • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
        • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
        + *
      * - * @param d the {@code double} to be converted. - * @return a string representation of the argument. + * @param v the {@code double} to be rendered. + * @return a string rendering of the argument. */ - public static String toString(double d) { - return FloatingDecimal.toJavaFormatString(d); + public static String toString(double v) { + return DoubleToDecimal.toString(v); } /** diff --git a/src/java.base/share/classes/java/lang/Float.java b/src/java.base/share/classes/java/lang/Float.java old mode 100644 new mode 100755 --- a/src/java.base/share/classes/java/lang/Float.java +++ b/src/java.base/share/classes/java/lang/Float.java @@ -31,6 +31,7 @@ import java.util.Optional; import jdk.internal.math.FloatingDecimal; +import jdk.internal.math.FloatToDecimal; import jdk.internal.HotSpotIntrinsicCandidate; /** @@ -142,73 +143,120 @@ public static final Class TYPE = (Class) Class.getPrimitiveClass("float"); /** - * Returns a string representation of the {@code float} - * argument. All characters mentioned below are ASCII characters. - *
        - *
      • If the argument is NaN, the result is the string - * "{@code NaN}". - *
      • Otherwise, the result is a string that represents the sign and - * magnitude (absolute value) of the argument. If the sign is - * negative, the first character of the result is - * '{@code -}' ({@code '\u005Cu002D'}); if the sign is - * positive, no sign character appears in the result. As for - * the magnitude m: + * Returns a string rendering of the {@code float} argument. + * + *

        The characters of the result are all drawn from the ASCII set. *

          - *
        • If m is infinity, it is represented by the characters - * {@code "Infinity"}; thus, positive infinity produces - * the result {@code "Infinity"} and negative infinity - * produces the result {@code "-Infinity"}. - *
        • If m is zero, it is represented by the characters - * {@code "0.0"}; thus, negative zero produces the result - * {@code "-0.0"} and positive zero produces the result - * {@code "0.0"}. - *
        • If m is greater than or equal to 10-3 but - * less than 107, then it is represented as the - * integer part of m, in decimal form with no leading - * zeroes, followed by '{@code .}' - * ({@code '\u005Cu002E'}), followed by one or more - * decimal digits representing the fractional part of - * m. - *
        • If m is less than 10-3 or greater than or - * equal to 107, then it is represented in - * so-called "computerized scientific notation." Let n - * be the unique integer such that 10n ≤ - * m {@literal <} 10n+1; then let a - * be the mathematically exact quotient of m and - * 10n so that 1 ≤ a {@literal <} 10. - * The magnitude is then represented as the integer part of - * a, as a single decimal digit, followed by - * '{@code .}' ({@code '\u005Cu002E'}), followed by - * decimal digits representing the fractional part of - * a, followed by the letter '{@code E}' - * ({@code '\u005Cu0045'}), followed by a representation - * of n as a decimal integer, as produced by the - * method {@link java.lang.Integer#toString(int)}. - * + *
        • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
        • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
        • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
        • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
        • A finite positive {@code v} is rendered in two stages: + *
            + *
          • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
          • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. *
          *
        - * How many digits must be printed for the fractional part of - * m or a? There must be at least one digit - * to represent the fractional part, and beyond that as many, but - * only as many, more digits as are needed to uniquely distinguish - * the argument value from adjacent values of type - * {@code float}. That is, suppose that x is the - * exact mathematical value represented by the decimal - * representation produced by this method for a finite nonzero - * argument f. Then f must be the {@code float} - * value nearest to x; or, if two {@code float} values are - * equally close to x, then f must be one of - * them and the least significant bit of the significand of - * f must be {@code 0}. + * + *

        A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

        The decimal dv + * for a finite positive {@code v} is defined as follows: + *

          + *
        • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
        • Let m be the minimal length over all decimals in R. + *
        • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
        • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
        + * + *

        The (uniquely) selected decimal dv + * is then formatted. * - *

        To create localized string representations of a floating-point - * value, use subclasses of {@link java.text.NumberFormat}. + *

        Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
        • Case 0 ≤ e < 7: + *
            + *
          • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
          • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
          + *
        • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
            + *
          • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
          • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
          + *
        * - * @param f the float to be converted. - * @return a string representation of the argument. + * @param v the {@code float} to be rendered. + * @return a string rendering of the argument. */ - public static String toString(float f) { - return FloatingDecimal.toJavaFormatString(f); + public static String toString(float v) { + return FloatToDecimal.toString(v); } /** diff --git a/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java @@ -0,0 +1,573 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import static java.lang.Double.*; +import static java.lang.Long.*; +import static java.lang.Math.multiplyHigh; +import static jdk.internal.math.MathUtils.*; + +/** + * This class exposes a method to render a {@code double} as a string. + * + * @author Raffaello Giulietti + */ +final public class DoubleToDecimal { + /* + For full details about this code see the following references: + + [1] Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + + Divisions are avoided for the benefit of those architectures that do not + provide specific machine instructions or where they are slow. + This is discussed in section 10 of [1]. + */ + + // The precision in bits. + static final int P = 53; + + // H is as in section 8 of [1]. + static final int H = 17; + + // 10^(MIN_EXP - 1) <= MIN_VALUE < 10^MIN_EXP + static final int MIN_EXP = -323; + + // 10^(MAX_EXP - 1) <= MAX_VALUE < 10^MAX_EXP + static final int MAX_EXP = 309; + + // Exponent width in bits. + private static final int W = (Double.SIZE - 1) - (P - 1); + + // Minimum value of the exponent: -(2^(W-1)) - P + 3. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // Minimum value of the significand of a normal value: 2^(P-1). + private static final long C_MIN = 1L << P - 1; + + // Mask to extract the biased exponent. + private static final int BQ_MASK = (1 << W) - 1; + + // Mask to extract the fraction bits. + private static final long T_MASK = (1L << P - 1) - 1; + + // Used in rop(). + private static final long MASK_63 = (1L << 63) - 1; + + // Used for left-to-tight digit extraction. + private static final int MASK_28 = (1 << 28) - 1; + + // For thread-safety, each thread gets its own instance of this class. + private static final ThreadLocal threadLocal = + ThreadLocal.withInitial(DoubleToDecimal::new); + + /* + Room for the longer of the forms + -ddddd.dddddddddddd H + 2 characters + -0.00ddddddddddddddddd H + 5 characters + -d.ddddddddddddddddE-eee H + 7 characters + where there are H digits d + */ + private final byte[] buf = new byte[H + 7]; + + // Index into buf of rightmost valid character. + private int index; + + private DoubleToDecimal() { + } + + /** + * Returns a string rendering of the {@code double} argument. + * + *

        The characters of the result are all drawn from the ASCII set. + *

          + *
        • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
        • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
        • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
        • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
        • A finite positive {@code v} is rendered in two stages: + *
            + *
          • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
          • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. + *
          + *
        + * + *

        A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

        The decimal dv + * for a finite positive {@code v} is defined as follows: + *

          + *
        • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
        • Let m be the minimal length over all decimals in R. + *
        • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
        • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
        + * + *

        The (uniquely) selected decimal dv + * is then formatted. + * + *

        Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
        • Case 0 ≤ e < 7: + *
            + *
          • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
          • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
          + *
        • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
            + *
          • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
          • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
          + *
        + * + * @param v the {@code double} to be rendered. + * @return a string rendering of the argument. + */ + public static String toString(double v) { + return threadLocalInstance().toDecimal(v); + } + + private static DoubleToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(double v) { + /* + For full details see references [2] and [1]. + + Let + Q_MAX = 2^(W-1) - P + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either 2^(P-1) <= c < 2^P (normal) + or 0 < c < 2^(P-1) and q = Q_MIN (subnormal) + */ + long bits = doubleToRawLongBits(v); + long t = bits & T_MASK; + int bq = (int) (bits >>> P - 1) & BQ_MASK; + if (bq < BQ_MASK) { + index = -1; + if (bits < 0) { + append('-'); + } + if (bq != 0) { + // normal value. Here mq = -q + int mq = -Q_MIN + 1 - bq; + long c = C_MIN | t; + // The fast path discussed in section 8.3 of [1]. + if (0 < mq & mq < P) { + long f = c >> mq; + if (f << mq == c) { + return toChars(f, 0); + } + } + return toDecimal(-mq, c); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, long c) { + /* + The skeleton corresponds to figure 4 of [1]. + The efficient computations are those summarized in figure 7. + + Here's a correspondence between Java names and names in [1], + expressed as approximate LaTeX source code and informally. + Other names are identical. + cb: \bar{c} "c-bar" + cbr: \bar{c}_r "c-bar-r" + cbl: \bar{c}_l "c-bar-l" + + vb: \bar{v} "v-bar" + vbr: \bar{v}_r "v-bar-r" + vbl: \bar{v}_l "v-bar-l" + + rop: r_o' "r-o-prime" + */ + int out = (int) c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + /* + flog10pow2(e) = floor(log_10(2^e)) + flog10threeQuartersPow2(e) = floor(log_10(3/4 2^e)) + flog2pow10(e) = floor(log_2(10^e)) + */ + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 3; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 2; + } + cbl = cb - 1; + + // g1 and g0 are as in section 9.8.3, so g = g1 2^63 + g0 + long g1 = g1(-k); + long g0 = g0(-k); + + long vb = rop(g1, g0, cb << h); + long vbl = rop(g1, g0, cbl << h); + long vbr = rop(g1, g0, cbr << h); + + long s = vb >> 2; + if (s >= 100) { + /* + For n = 17, m = 1 the table in section 10 of [1] shows + s' = + floor(s / 10) = floor(s 115'292'150'460'684'698 / 2^60) = + floor(s 115'292'150'460'684'698 2^4 / 2^64) + + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + upin iff u' = sp10 10^k in Rv + wpin iff w' = tp10 10^k in Rv + See section 9.3. + */ + long sp10 = 10 * multiplyHigh(s, 115_292_150_460_684_698L << 4); + long tp10 = sp10 + 10; + boolean upin = vbl + out <= sp10 << 2; + boolean wpin = (tp10 << 2) + out <= vbr; + if (upin != wpin) { + return toChars(upin ? sp10 : tp10, k); + } + } else if (s < 10) { + switch ((int) s) { + case 4: + return toChars(49, -325); // 4.9 10^(-324) + case 9: + return toChars(99, -325); // 9.9 10^(-324) + } + } + + /* + 10 <= s < 100 or s >= 100 and u', w' not in Rv + uin iff u = s 10^k in Rv + win iff w = t 10^k in Rv + See section 9.3. + */ + long t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of u or w lies in Rv. + return toChars(uin ? s : t, k); + } + /* + Both u and w lie in Rv: determine the one closest to v. + See section 9.3. + */ + long cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + /* + Computes rop(cp g 2^(-127)), where g = g1 2^63 + g0 + See section 9.9 and figure 6 of [1]. + */ + private static long rop(long g1, long g0, long cp) { + long x1 = multiplyHigh(g0, cp); + long y0 = g1 * cp; + long y1 = multiplyHigh(g1, cp); + long z = (y0 >>> 1) + x1; + long vbp = y1 + (z >>> 63); + return vbp | (z & MASK_63) + MASK_63 >>> 63; + } + + /* + Formats the decimal f 10^e. + */ + private String toChars(long f, int e) { + /* + For details not discussed here see section 10 of [1]. + + Determine len such that + 10^(len-1) <= f < 10^len + */ + int len = flog10pow2(Long.SIZE - numberOfLeadingZeros(f)); + if (f >= pow10(len)) { + len += 1; + } + + /* + Let fp and ep be the original f and e, respectively. + Transform f and e to ensure + 10^(H-1) <= f < 10^H + fp 10^ep = f 10^(e-H) = 0.f 10^e + */ + f *= pow10(H - len); + e += len; + + /* + The toChars?() methods perform left-to-right digits extraction + using ints, provided that the arguments are limited to 8 digits. + Therefore, split the H = 17 digits of f into: + h = the most significant digit of f + m = the next 8 most significant digits of f + l = the last 8, least significant digits of f + + For n = 17, m = 8 the table in section 10 of [1] shows + floor(f / 10^8) = floor(193'428'131'138'340'668 f / 2^84) = + floor(floor(193'428'131'138'340'668 f / 2^64) / 2^20) + and for n = 9, m = 8 + floor(hm / 10^8) = floor(1'441'151'881 hm / 2^57) + */ + long hm = multiplyHigh(f, 193_428_131_138_340_668L) >>> 20; + int l = (int) (f - 100_000_000L * hm); + int h = (int) (hm * 1_441_151_881L >>> 57); + int m = (int) (hm - 100_000_000 * h); + + if (0 < e && e <= 7) { + return toChars1(h, m, l, e); + } + if (-3 < e && e <= 0) { + return toChars2(h, m, l, e); + } + return toChars3(h, m, l, e); + } + + private String toChars1(int h, int m, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + appendDigit(h); + int y = y(m); + int t; + int i = 1; + for (; i < e; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + append('.'); + for (; i <= 8; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + lowDigits(l); + return charsToString(); + } + + private String toChars2(int h, int m, int l, int e) { + // -3 < e <= 0: plain format with leading zeroes. + appendDigit(0); + append('.'); + for (; e < 0; ++e) { + appendDigit(0); + } + appendDigit(h); + append8Digits(m); + lowDigits(l); + return charsToString(); + } + + private String toChars3(int h, int m, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(m); + lowDigits(l); + exponent(e - 1); + return charsToString(); + } + + private void lowDigits(int l) { + if (l != 0) { + append8Digits(l); + } + removeTrailingZeroes(); + } + + private void append8Digits(int m) { + /* + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + int y = y(m); + for (int i = 0; i < 8; ++i) { + int t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + } + + private void removeTrailingZeroes() { + while (buf[index] == '0') { + --index; + } + // ... but do not remove the one directly to the right of '.' + if (buf[index] == '.') { + ++index; + } + } + + private int y(int a) { + /* + Algorithm 1 in [3] needs computation of + floor((a + 1) 2^n / b^k) - 1 + with a < 10^8, b = 10, k = 8, n = 28. + Noting that + (a + 1) 2^n <= 10^8 2^28 < 10^17 + For n = 17, m = 8 the table in section 10 of [1] leads to: + */ + return (int) (multiplyHigh( + (long) (a + 1) << 28, + 193_428_131_138_340_668L) >>> 20) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + int d; + if (e >= 100) { + /* + For n = 3, m = 2 the table in section 10 of [1] shows + floor(e / 100) = floor(1'311 e / 2^17) + */ + d = e * 1_311 >>> 17; + appendDigit(d); + e -= 100 * d; + } + /* + For n = 2, m = 1 the table in section 10 of [1] shows + floor(e / 10) = floor(103 e / 2^10) + */ + d = e * 103 >>> 10; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated constructor enhances performance. + */ + @SuppressWarnings("deprecation") + private String charsToString() { + return new String(buf, 0, 0, index + 1); + } + +} diff --git a/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java @@ -0,0 +1,549 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import static java.lang.Float.*; +import static java.lang.Integer.*; +import static java.lang.Math.multiplyHigh; +import static jdk.internal.math.MathUtils.*; + +/** + * This class exposes a method to render a {@code float} as a string. + * + * @author Raffaello Giulietti + */ +final public class FloatToDecimal { + /* + For full details about this code see the following references: + + [1] Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + + Divisions are avoided for the benefit of those architectures that do not + provide specific machine instructions or where they are slow. + This is discussed in section 10 of [1]. + */ + + // The precision in bits. + static final int P = 24; + + // H is as in section 8 of [1]. + static final int H = 9; + + // 10^(MIN_EXP - 1) <= MIN_VALUE < 10^MIN_EXP + static final int MIN_EXP = -44; + + // 10^(MAX_EXP - 1) <= MAX_VALUE < 10^MAX_EXP + static final int MAX_EXP = 39; + + // Exponent width in bits. + private static final int W = (Float.SIZE - 1) - (P - 1); + + // Minimum value of the exponent: -(2^(W-1)) - P + 3. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // Minimum value of the significand of a normal value: 2^(P-1). + private static final int C_MIN = 1 << P - 1; + + // Mask to extract the biased exponent. + private static final int BQ_MASK = (1 << W) - 1; + + // Mask to extract the fraction bits. + private static final int T_MASK = (1 << P - 1) - 1; + + // Used in rop(). + private static final long MASK_32 = (1L << 32) - 1; + + // Used for left-to-tight digit extraction. + private static final int MASK_28 = (1 << 28) - 1; + + // For thread-safety, each thread gets its own instance of this class. + private static final ThreadLocal threadLocal = + ThreadLocal.withInitial(FloatToDecimal::new); + + /* + Room for the longer of the forms + -ddddd.dddd H + 2 characters + -0.00ddddddddd H + 5 characters + -d.ddddddddE-ee H + 6 characters + where there are H digits d + */ + private final byte[] buf = new byte[H + 6]; + + // Index into buf of rightmost valid character. + private int index; + + private FloatToDecimal() { + } + + /** + * Returns a string rendering of the {@code float} argument. + * + *

        The characters of the result are all drawn from the ASCII set. + *

          + *
        • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
        • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
        • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
        • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
        • A finite positive {@code v} is rendered in two stages: + *
            + *
          • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
          • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. + *
          + *
        + * + *

        A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

        The decimal dv + * for a finite positive {@code v} is defined as follows: + *

          + *
        • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
        • Let m be the minimal length over all decimals in R. + *
        • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
        • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
        + * + *

        The (uniquely) selected decimal dv + * is then formatted. + * + *

        Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
        • Case 0 ≤ e < 7: + *
            + *
          • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
          • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
          + *
        • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
            + *
          • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
          • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
          + *
        + * + * @param v the {@code float} to be rendered. + * @return a string rendering of the argument. + */ + public static String toString(float v) { + return threadLocalInstance().toDecimal(v); + } + + private static FloatToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(float v) { + /* + For full details see references [2] and [1]. + + Let + Q_MAX = 2^(W-1) - P + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either 2^(P-1) <= c < 2^P (normal) + or 0 < c < 2^(P-1) and q = Q_MIN (subnormal) + */ + int bits = floatToRawIntBits(v); + int t = bits & T_MASK; + int bq = (bits >>> P - 1) & BQ_MASK; + if (bq < BQ_MASK) { + index = -1; + if (bits < 0) { + append('-'); + } + if (bq != 0) { + // normal value. Here mq = -q + int mq = -Q_MIN + 1 - bq; + int c = C_MIN | t; + // The fast path discussed in section 8.3 of [1]. + if (0 < mq & mq < P) { + int f = c >> mq; + if (f << mq == c) { + return toChars(f, 0); + } + } + return toDecimal(-mq, c); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, int c) { + /* + The skeleton corresponds to figure 4 of [1]. + The efficient computations are those summarized in figure 7. + Also check the appendix. + + Here's a correspondence between Java names and names in [1], + expressed as approximate LaTeX source code and informally. + Other names are identical. + cb: \bar{c} "c-bar" + cbr: \bar{c}_r "c-bar-r" + cbl: \bar{c}_l "c-bar-l" + + vb: \bar{v} "v-bar" + vbr: \bar{v}_r "v-bar-r" + vbl: \bar{v}_l "v-bar-l" + + rop: r_o' "r-o-prime" + */ + int out = c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + /* + flog10pow2(e) = floor(log_10(2^e)) + flog10threeQuartersPow2(e) = floor(log_10(3/4 2^e)) + flog2pow10(e) = floor(log_2(10^e)) + */ + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 34; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 33; + } + cbl = cb - 1; + + // g is as in the appendix + long g = g1(-k) + 1; + + int vb = rop(g, cb << h); + int vbl = rop(g, cbl << h); + int vbr = rop(g, cbr << h); + + int s = vb >> 2; + if (s >= 100) { + /* + For n = 9, m = 1 the table in section 10 of [1] shows + s' = + floor(s / 10) = floor(s 1'717'986'919 / 2^34) + + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + upin iff u' = sp10 10^k in Rv + wpin iff w' = tp10 10^k in Rv + See section 9.3. + */ + int sp10 = 10 * (int) (s * 1_717_986_919L >>> 34); + int tp10 = sp10 + 10; + boolean upin = vbl + out <= sp10 << 2; + boolean wpin = (tp10 << 2) + out <= vbr; + if (upin != wpin) { + return toChars(upin ? sp10 : tp10, k); + } + } else if (s < 10) { + switch (s) { + case 1: return toChars(14, -46); // 1.4 * 10^-45 + case 2: return toChars(28, -46); // 2.8 * 10^-45 + case 4: return toChars(42, -46); // 4.2 * 10^-45 + case 5: return toChars(56, -46); // 5.6 * 10^-45 + case 7: return toChars(70, -46); // 7.0 * 10^-45 + case 8: return toChars(84, -46); // 8.4 * 10^-45 + case 9: return toChars(98, -46); // 9.8 * 10^-45 + } + } + + /* + 10 <= s < 100 or s >= 100 and u', w' not in Rv + uin iff u = s 10^k in Rv + win iff w = t 10^k in Rv + See section 9.3. + */ + int t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of u or w lies in Rv. + return toChars(uin ? s : t, k); + } + /* + Both u and w lie in Rv: determine the one closest to v. + See section 9.3. + */ + int cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + /* + Computes rop(cp g 2^(-95)) + See appendix and figure 9 of [1]. + */ + private static int rop(long g, long cp) { + long x1 = multiplyHigh(g, cp); + long vbp = x1 >>> 31; + return (int) (vbp | (x1 & MASK_32) + MASK_32 >>> 32); + } + + /* + Formats the decimal f 10^e. + */ + private String toChars(int f, int e) { + /* + For details not discussed here see section 10 of [1]. + + Determine len such that + 10^(len-1) <= f < 10^len + */ + int len = flog10pow2(Integer.SIZE - numberOfLeadingZeros(f)); + if (f >= pow10(len)) { + len += 1; + } + + /* + Let fp and ep be the original f and e, respectively. + Transform f and e to ensure + 10^(H-1) <= f < 10^H + fp 10^ep = f 10^(e-H) = 0.f 10^e + */ + f *= pow10(H - len); + e += len; + + /* + The toChars?() methods perform left-to-right digits extraction + using ints, provided that the arguments are limited to 8 digits. + Therefore, split the H = 9 digits of f into: + h = the most significant digit of f + l = the last 8, least significant digits of f + + For n = 9, m = 8 the table in section 10 of [1] shows + floor(f / 10^8) = floor(1'441'151'881 f / 2^57) + */ + int h = (int) (f * 1_441_151_881L >>> 57); + int l = f - 100_000_000 * h; + + if (0 < e && e <= 7) { + return toChars1(h, l, e); + } + if (-3 < e && e <= 0) { + return toChars2(h, l, e); + } + return toChars3(h, l, e); + } + + private String toChars1(int h, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + appendDigit(h); + int y = y(l); + int t; + int i = 1; + for (; i < e; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + append('.'); + for (; i <= 8; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + removeTrailingZeroes(); + return charsToString(); + } + + private String toChars2(int h, int l, int e) { + // -3 < e <= 0: plain format with leading zeroes. + appendDigit(0); + append('.'); + for (; e < 0; ++e) { + appendDigit(0); + } + appendDigit(h); + append8Digits(l); + removeTrailingZeroes(); + return charsToString(); + } + + private String toChars3(int h, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(l); + removeTrailingZeroes(); + exponent(e - 1); + return charsToString(); + } + + private void append8Digits(int m) { + /* + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + int y = y(m); + for (int i = 0; i < 8; ++i) { + int t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + } + + private void removeTrailingZeroes() { + while (buf[index] == '0') { + --index; + } + // ... but do not remove the one directly to the right of '.' + if (buf[index] == '.') { + ++index; + } + } + + private int y(int a) { + /* + Algorithm 1 in [3] needs computation of + floor((a + 1) 2^n / b^k) - 1 + with a < 10^8, b = 10, k = 8, n = 28. + Noting that + (a + 1) 2^n <= 10^8 2^28 < 10^17 + For n = 17, m = 8 the table in section 10 of [1] leads to: + */ + return (int) (multiplyHigh( + (long) (a + 1) << 28, + 193_428_131_138_340_668L) >>> 20) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + For n = 2, m = 1 the table in section 10 of [1] shows + floor(e / 10) = floor(103 e / 2^10) + */ + int d = e * 103 >>> 10; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated constructor enhances performance. + */ + @SuppressWarnings("deprecation") + private String charsToString() { + return new String(buf, 0, 0, index + 1); + } + +} diff --git a/src/java.base/share/classes/jdk/internal/math/MathUtils.java b/src/java.base/share/classes/jdk/internal/math/MathUtils.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/MathUtils.java @@ -0,0 +1,799 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +/** + * This class exposes package private utilities for other classes. Thus, + * all methods are assumed to be invoked with correct arguments, so they are + * not checked at all. + * + * @author Raffaello Giulietti + */ +final class MathUtils { + /* + For full details about this code see the following reference: + + Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + */ + + // The minimum and maximum k + static final int MIN_K = -324; + static final int MAX_K = 292; + + // C_10 = floor(log10(2) * 2^Q_10), A_10 = floor(log10(3/4) * 2^Q_10) + private static final int Q_10 = 41; + private static final long C_10 = 661_971_961_083L; + private static final long A_10 = -274_743_187_321L; + + // C_2 = floor(log2(10) * 2^Q_2) + private static final int Q_2 = 38; + private static final long C_2 = 913_124_641_741L; + + private MathUtils() { + } + + private static final long[] pow10 = { + 1L, + 10L, + 100L, + 1_000L, + 10_000L, + 100_000L, + 1_000_000L, + 10_000_000L, + 100_000_000L, + 1_000_000_000L, + 10_000_000_000L, + 100_000_000_000L, + 1_000_000_000_000L, + 10_000_000_000_000L, + 100_000_000_000_000L, + 1_000_000_000_000_000L, + 10_000_000_000_000_000L, + 100_000_000_000_000_000L, + }; + + /** + * Returns 10{@code e}. + * + * @param e The exponent which must meet + * 0 ≤ {@code e} ≤ {@link DoubleToDecimal#H}. + * @return 10{@code e}. + */ + static long pow10(int e) { + return pow10[e]; + } + + /** + * Returns the unique integer k such that + * 10k ≤ 2{@code e} + * < 10k+1. + *

        + * The result is correct when |{@code e}| ≤ 5_456_721. + * Otherwise the result is undefined. + * + * @param e The exponent of 2, which should meet + * |{@code e}| ≤ 5_456_721 for safe results. + * @return ⌊log102{@code e}⌋. + */ + static int flog10pow2(int e) { + return (int) (e * C_10 >> Q_10); + } + + /** + * Returns the unique integer k such that + * 10k ≤ 3/4 · 2{@code e} + * < 10k+1. + *

        + * The result is correct when + * -2_956_395 ≤ {@code e} ≤ 2_500_325. + * Otherwise the result is undefined. + * + * @param e The exponent of 2, which should meet + * -2_956_395 ≤ {@code e} ≤ 2_500_325 for safe results. + * @return ⌊log10(3/4 · + * 2{@code e})⌋. + */ + static int flog10threeQuartersPow2(int e) { + return (int) (e * C_10 + A_10 >> Q_10); + } + + /** + * Returns the unique integer k such that + * 2k ≤ 10{@code e} + * < 2k+1. + *

        + * The result is correct when |{@code e}| ≤ 1_838_394. + * Otherwise the result is undefined. + * + * @param e The exponent of 10, which should meet + * |{@code e}| ≤ 1_838_394 for safe results. + * @return ⌊log210{@code e}⌋. + */ + static int flog2pow10(int e) { + return (int) (e * C_2 >> Q_2); + } + + /** + * Let 10{@code e} = β 2r, + * for the unique pair of integer r and real β meeting + * 2125 ≤ β < 2126. + * Further, let g = ⌊β⌋ + 1. + * Split g into the higher 63 bits g1 and + * the lower 63 bits g0. Thus, + * g1 = + * ⌊g 2-63⌋ + * and + * g0 = + * g - g1 263. + *

        + * This method returns g1 while + * {@link #g0(int)} returns g0. + *

        + * If needed, the exponent r can be computed as + * r = {@code flog2pow10(e)} - 125 (see {@link #flog2pow10(int)}). + * + * @param e The exponent of 10. + * @return g1 as described above. + */ + static long g1(int e) { + return g[e + MAX_K << 1]; + } + + /** + * Returns g0 as described in + * {@link #g1(int)}. + * + * @param e The exponent of 10. + * @return g0 as described in + * {@link #g1(int)}. + */ + static long g0(int e) { + return g[e + MAX_K << 1 | 1]; + } + + /** + * The precomputed values for {@link #g1(int)} and {@link #g0(int)}. + */ + private static final long[] g = { + /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL, + /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL, + /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L, + /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L, + /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL, + /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L, + /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L, + /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL, + /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L, + /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL, + /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL, + /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L, + /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL, + /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L, + /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L, + /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL, + /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L, + /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L, + /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L, + /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL, + /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L, + /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L, + /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L, + /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL, + /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L, + /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L, + /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL, + /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L, + /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L, + /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L, + /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L, + /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL, + /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL, + /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L, + /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L, + /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL, + /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L, + /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L, + /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L, + /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L, + /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L, + /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L, + /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL, + /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L, + /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L, + /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L, + /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L, + /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L, + /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L, + /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L, + /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L, + /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L, + /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL, + /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L, + /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L, + /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL, + /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L, + /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL, + /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L, + /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L, + /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL, + /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L, + /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L, + /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L, + /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL, + /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L, + /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L, + /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L, + /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL, + /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L, + /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L, + /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L, + /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L, + /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL, + /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L, + /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L, + /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL, + /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L, + /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L, + /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L, + /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L, + /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L, + /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L, + /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL, + /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL, + /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L, + /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L, + /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL, + /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL, + /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L, + /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L, + /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL, + /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L, + /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L, + /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L, + /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L, + /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL, + /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L, + /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L, + /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L, + /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L, + /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L, + /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L, + /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L, + /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L, + /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L, + /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L, + /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L, + /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L, + /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L, + /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L, + /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L, + /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL, + /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L, + /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL, + /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL, + /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L, + /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L, + /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L, + /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L, + /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L, + /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L, + /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L, + /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L, + /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L, + /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL, + /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL, + /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L, + /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL, + /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L, + /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L, + /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL, + /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L, + /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL, + /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL, + /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL, + /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL, + /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L, + /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL, + /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L, + /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL, + /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L, + /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L, + /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL, + /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL, + /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL, + /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L, + /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL, + /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L, + /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL, + /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L, + /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L, + /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL, + /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L, + /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L, + /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL, + /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L, + /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L, + /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L, + /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL, + /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL, + /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL, + /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L, + /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL, + /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L, + /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL, + /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L, + /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL, + /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL, + /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L, + /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L, + /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL, + /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL, + /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL, + /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L, + /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL, + /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL, + /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L, + /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L, + /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L, + /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L, + /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L, + /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L, + /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L, + /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL, + /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L, + /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL, + /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L, + /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L, + /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L, + /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL, + /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL, + /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL, + /* -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L, + /* -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL, + /* -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL, + /* -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L, + /* -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L, + /* -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L, + /* -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L, + /* -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L, + /* -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL, + /* -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L, + /* -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL, + /* -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL, + /* -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL, + /* -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L, + /* -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL, + /* -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL, + /* -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL, + /* -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL, + /* -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L, + /* -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L, + /* -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L, + /* -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL, + /* -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L, + /* -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL, + /* -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L, + /* -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L, + /* -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL, + /* -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL, + /* -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L, + /* -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L, + /* -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL, + /* -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L, + /* -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L, + /* -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L, + /* -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL, + /* -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL, + /* -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL, + /* -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL, + /* -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L, + /* -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L, + /* -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L, + /* -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L, + /* -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL, + /* -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L, + /* -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL, + /* -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L, + /* -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL, + /* -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL, + /* -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL, + /* -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L, + /* -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL, + /* -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L, + /* -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL, + /* -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL, + /* -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L, + /* -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL, + /* -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L, + /* -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L, + /* -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L, + /* -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L, + /* -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L, + /* -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L, + /* -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L, + /* -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL, + /* -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL, + /* -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L, + /* -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L, + /* -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL, + /* -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L, + /* -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L, + /* -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL, + /* -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L, + /* -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L, + /* -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L, + /* -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L, + /* -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L, + /* -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L, + /* -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL, + /* -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L, + /* -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L, + /* -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL, + /* -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L, + /* -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L, + /* -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL, + /* -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L, + /* -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L, + /* -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL, + /* -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L, + /* -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L, + /* -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L, + /* -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL, + /* -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L, + /* -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L, + /* -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L, + /* -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L, + /* -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL, + /* -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL, + /* -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L, + /* -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L, + /* 0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0001L, + /* 8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0001L, + /* 9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0001L, + /* 10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0001L, + /* 11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0001L, + /* 12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0001L, + /* 13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0001L, + /* 14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0001L, + /* 15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0001L, + /* 16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0001L, + /* 17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0001L, + /* 18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0001L, + /* 19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0001L, + /* 20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0001L, + /* 21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0001L, + /* 22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0001L, + /* 23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0001L, + /* 24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0001L, + /* 25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0001L, + /* 26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0001L, + /* 27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0001L, + /* 28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0001L, + /* 29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0001L, + /* 30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0001L, + /* 31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0001L, + /* 32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0001L, + /* 33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0001L, + /* 34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0001L, + /* 35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0001L, + /* 36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0001L, + /* 37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0001L, + /* 38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0001L, + /* 39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0001L, + /* 40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0001L, + /* 41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0001L, + /* 42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0001L, + /* 43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0001L, + /* 44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0001L, + /* 45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0001L, + /* 46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0001L, + /* 47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0001L, + /* 48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4001L, + /* 49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5001L, + /* 50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B201L, + /* 51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E81L, + /* 52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B621L, + /* 53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D5L, + /* 54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F64AL, + /* 55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL, + /* 56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL, + /* 57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L, + /* 58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L, + /* 59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL, + /* 60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L, + /* 61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL, + /* 62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL, + /* 63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL, + /* 64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL, + /* 65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL, + /* 66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL, + /* 67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L, + /* 68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L, + /* 69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL, + /* 70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L, + /* 71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L, + /* 72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L, + /* 73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L, + /* 74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L, + /* 75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L, + /* 76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L, + /* 77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L, + /* 78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL, + /* 79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L, + /* 80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L, + /* 81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L, + /* 82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L, + /* 83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L, + /* 84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL, + /* 85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL, + /* 86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L, + /* 87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL, + /* 88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L, + /* 89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL, + /* 90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L, + /* 91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL, + /* 92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L, + /* 93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL, + /* 94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L, + /* 95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L, + /* 96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L, + /* 97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L, + /* 98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L, + /* 99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L, + /* 100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L, + /* 101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL, + /* 102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L, + /* 103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL, + /* 104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L, + /* 105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL, + /* 106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL, + /* 107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L, + /* 108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L, + /* 109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L, + /* 110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L, + /* 111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L, + /* 112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL, + /* 113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L, + /* 114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L, + /* 115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L, + /* 116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L, + /* 117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L, + /* 118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL, + /* 119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL, + /* 120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL, + /* 121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL, + /* 122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L, + /* 123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL, + /* 124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L, + /* 125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L, + /* 126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L, + /* 127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L, + /* 128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL, + /* 129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L, + /* 130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL, + /* 131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL, + /* 132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL, + /* 133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL, + /* 134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L, + /* 135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L, + /* 136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL, + /* 137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL, + /* 138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L, + /* 139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL, + /* 140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL, + /* 141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L, + /* 142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL, + /* 143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL, + /* 144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL, + /* 145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L, + /* 146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L, + /* 147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL, + /* 148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L, + /* 149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL, + /* 150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL, + /* 151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL, + /* 152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL, + /* 153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L, + /* 154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL, + /* 155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL, + /* 156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L, + /* 157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL, + /* 158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L, + /* 159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL, + /* 160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L, + /* 161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L, + /* 162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L, + /* 163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L, + /* 164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL, + /* 165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L, + /* 166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL, + /* 167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L, + /* 168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L, + /* 169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L, + /* 170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL, + /* 171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L, + /* 172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L, + /* 173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL, + /* 174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL, + /* 175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL, + /* 176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L, + /* 177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L, + /* 178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL, + /* 179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L, + /* 180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L, + /* 181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L, + /* 182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L, + /* 183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L, + /* 184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL, + /* 185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL, + /* 186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL, + /* 187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL, + /* 188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL, + /* 189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL, + /* 190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L, + /* 191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL, + /* 192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L, + /* 193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L, + /* 194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL, + /* 195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L, + /* 196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L, + /* 197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L, + /* 198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL, + /* 199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L, + /* 200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L, + /* 201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L, + /* 202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL, + /* 203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L, + /* 204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL, + /* 205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL, + /* 206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L, + /* 207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL, + /* 208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L, + /* 209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L, + /* 210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL, + /* 211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L, + /* 212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L, + /* 213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L, + /* 214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL, + /* 215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL, + /* 216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L, + /* 217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL, + /* 218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L, + /* 219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L, + /* 220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L, + /* 221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L, + /* 222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L, + /* 223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L, + /* 224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL, + /* 225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L, + /* 226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L, + /* 227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL, + /* 228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L, + /* 229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L, + /* 230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL, + /* 231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L, + /* 232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L, + /* 233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L, + /* 234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L, + /* 235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL, + /* 236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL, + /* 237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L, + /* 238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L, + /* 239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L, + /* 240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL, + /* 241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL, + /* 242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL, + /* 243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L, + /* 244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL, + /* 245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL, + /* 246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL, + /* 247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L, + /* 248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L, + /* 249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L, + /* 250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L, + /* 251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L, + /* 252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L, + /* 253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL, + /* 254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L, + /* 255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L, + /* 256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL, + /* 257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL, + /* 258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L, + /* 259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL, + /* 260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L, + /* 261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL, + /* 262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L, + /* 263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL, + /* 264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L, + /* 265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL, + /* 266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L, + /* 267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L, + /* 268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL, + /* 269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL, + /* 270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL, + /* 271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L, + /* 272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L, + /* 273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L, + /* 274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L, + /* 275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L, + /* 276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L, + /* 277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L, + /* 278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL, + /* 279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL, + /* 280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL, + /* 281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L, + /* 282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL, + /* 283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L, + /* 284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L, + /* 285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L, + /* 286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L, + /* 287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL, + /* 288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L, + /* 289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL, + /* 290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L, + /* 291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL, + /* 292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL, + /* 293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L, + /* 294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL, + /* 295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L, + /* 296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L, + /* 297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L, + /* 298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL, + /* 299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L, + /* 300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L, + /* 301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL, + /* 302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L, + /* 303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL, + /* 304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL, + /* 305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L, + /* 306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L, + /* 307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL, + /* 308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L, + /* 309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L, + /* 310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L, + /* 311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L, + /* 312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L, + /* 313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L, + /* 314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL, + /* 315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L, + /* 316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL, + /* 317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL, + /* 318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L, + /* 319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L, + /* 320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L, + /* 321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L, + /* 322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L, + /* 323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL, + /* 324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, + }; + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/BasicChecker.java b/test/jdk/jdk/internal/math/ToDecimal/BasicChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/BasicChecker.java @@ -0,0 +1,16 @@ +class BasicChecker { + + static final boolean FAILURE_THROWS_EXCEPTION = true; + + static void assertTrue(boolean ok, String valueName) { + if (ok) { + return; + } + String msg = valueName + " is not correct"; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(msg); + } + System.err.println(msg); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalChecker.java @@ -0,0 +1,385 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import java.math.BigDecimal; +import java.util.Random; + +import static java.lang.Double.*; +import static java.lang.Long.numberOfTrailingZeros; +import static java.lang.Math.scalb; + +/* + * @test + * @bug 8202555 + * @author Raffaello Giulietti + */ +public class DoubleToDecimalChecker extends ToDecimalChecker { + + private static final int RANDOM_COUNT = 1_000_000; + + private static final int MIN_EXP = -323; + private static final int MAX_EXP = 309; + private static final int H = 17; + private static final int P = 53; + + private double v; + private final long originalBits; + + private DoubleToDecimalChecker(double v, String s) { + super(s); + this.v = v; + originalBits = doubleToRawLongBits(v); + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.doubleValue() == v; + } + + @Override + boolean recovers(String s) { + return parseDouble(s) == v; + } + + @Override + String hexBits() { + return String.format("0x%01X__%03X__%01X_%04X_%04X_%04X", + (int) (originalBits >>> 63) & 0x1, + (int) (originalBits >>> 52) & 0x7FF, + (int) (originalBits >>> 48) & 0xF, + (int) (originalBits >>> 32) & 0xFFFF, + (int) (originalBits >>> 16) & 0xFFFF, + (int) originalBits & 0xFFFF); + } + + @Override + int minExp() { + return MIN_EXP; + } + + @Override + int maxExp() { + return MAX_EXP; + } + + @Override + int maxLen10() { + return H; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == POSITIVE_INFINITY; + } + + @Override + void negate() { + v = -v; + } + + @Override + boolean isNegative() { + return originalBits < 0; + } + + @Override + boolean isNaN() { + return Double.isNaN(v); + } + + private static void toDec(double v) { + String s = Double.toString(v); + new DoubleToDecimalChecker(v, s).assertTrue(); + } + + private static void testExtremeValues() { + toDec(NEGATIVE_INFINITY); + toDec(-MAX_VALUE); + toDec(-MIN_NORMAL); + toDec(-MIN_VALUE); + toDec(-0.0); + toDec(0.0); + toDec(MIN_VALUE); + toDec(MIN_NORMAL); + toDec(MAX_VALUE); + toDec(POSITIVE_INFINITY); + toDec(NaN); + + /* + Quiet NaNs have the most significant bit of the mantissa as 1, + while signaling NaNs have it as 0. + Exercise 4 combinations of quiet/signaling NaNs and + "positive/negative" NaNs + */ + toDec(longBitsToDouble(0x7FF8_0000_0000_0001L)); + toDec(longBitsToDouble(0x7FF0_0000_0000_0001L)); + toDec(longBitsToDouble(0xFFF8_0000_0000_0001L)); + toDec(longBitsToDouble(0xFFF0_0000_0000_0001L)); + + /* + All values treated specially by Schubfach + */ + toDec(4.9E-324); + toDec(9.9E-324); + } + + /* + A few "powers of 10" are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf10() { + for (int e = MIN_EXP; e <= MAX_EXP; ++e) { + toDec(parseDouble("1e" + e)); + } + } + + /* + Many powers of 2 are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf2() { + for (double v = MIN_VALUE; v <= MAX_VALUE; v *= 2) { + toDec(v); + } + } + + /* + There are many doubles that are rendered incorrectly by the JDK. + While the renderings correctly round back to the original value, + they are longer than needed or are not the closest decimal to the double. + Here are just a very few examples. + */ + private static final String[] Anomalies = { + // JDK renders these, and others, with 18 digits! + "2.82879384806159E17", "1.387364135037754E18", + "1.45800632428665E17", + + // JDK renders these longer than needed. + "1.6E-322", "6.3E-322", + "7.3879E20", "2.0E23", "7.0E22", "9.2E22", + "9.5E21", "3.1E22", "5.63E21", "8.41E21", + + // JDK does not render these, and many others, as the closest. + "9.9E-324", "9.9E-323", + "1.9400994884341945E25", "3.6131332396758635E25", + "2.5138990223946153E25", + }; + + private static void testSomeAnomalies() { + for (String dec : Anomalies) { + toDec(parseDouble(dec)); + } + } + + /* + Values are from + Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" + tables 3 and 4 + */ + private static final double[] PaxsonSignificands = { + 8_511_030_020_275_656L, + 5_201_988_407_066_741L, + 6_406_892_948_269_899L, + 8_431_154_198_732_492L, + 6_475_049_196_144_587L, + 8_274_307_542_972_842L, + 5_381_065_484_265_332L, + 6_761_728_585_499_734L, + 7_976_538_478_610_756L, + 5_982_403_858_958_067L, + 5_536_995_190_630_837L, + 7_225_450_889_282_194L, + 7_225_450_889_282_194L, + 8_703_372_741_147_379L, + 8_944_262_675_275_217L, + 7_459_803_696_087_692L, + 6_080_469_016_670_379L, + 8_385_515_147_034_757L, + 7_514_216_811_389_786L, + 8_397_297_803_260_511L, + 6_733_459_239_310_543L, + 8_091_450_587_292_794L, + + 6_567_258_882_077_402L, + 6_712_731_423_444_934L, + 6_712_731_423_444_934L, + 5_298_405_411_573_037L, + 5_137_311_167_659_507L, + 6_722_280_709_661_868L, + 5_344_436_398_034_927L, + 8_369_123_604_277_281L, + 8_995_822_108_487_663L, + 8_942_832_835_564_782L, + 8_942_832_835_564_782L, + 8_942_832_835_564_782L, + 6_965_949_469_487_146L, + 6_965_949_469_487_146L, + 6_965_949_469_487_146L, + 7_487_252_720_986_826L, + 5_592_117_679_628_511L, + 8_887_055_249_355_788L, + 6_994_187_472_632_449L, + 8_797_576_579_012_143L, + 7_363_326_733_505_337L, + 8_549_497_411_294_502L, + }; + + private static final int[] PaxsonExponents = { + -342, + -824, + 237, + 72, + 99, + 726, + -456, + -57, + 376, + 377, + 93, + 710, + 709, + 117, + -1, + -707, + -381, + 721, + -828, + -345, + 202, + -473, + + 952, + 535, + 534, + -957, + -144, + 363, + -169, + -853, + -780, + -383, + -384, + -385, + -249, + -250, + -251, + 548, + 164, + 665, + 690, + 588, + 272, + -448, + }; + + private static void testPaxson() { + for (int i = 0; i < PaxsonSignificands.length; ++i) { + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); + } + } + + /* + Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0. + These are all exact doubles. + */ + private static void testLongs() { + for (int i = 10_000; i < 100_000; ++i) { + toDec(i * 1e15); + } + } + + /* + Tests all integers up to 1_000_000. + These are all exact doubles and exercise a fast path. + */ + private static void testInts() { + for (int i = 0; i <= 1_000_000; ++i) { + toDec(i); + } + } + + /* + Random doubles over the whole range + */ + private static void testRandom() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(longBitsToDouble(r.nextLong())); + } + } + + /* + Random doubles over the integer range [0, 2^52). + These are all exact doubles and exercise the fast path (except 0). + */ + private static void testRandomUnit() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(r.nextLong() & (1L << P - 1)); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-3 + */ + private static void testRandomMilli() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(r.nextLong() % 1_000_000_000_000_000_000L / 1e3); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-6 + */ + private static void testRandomMicro() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6); + } + } + + public static void main(String[] args) { + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testLongs(); + testRandom(); + testRandomUnit(); + testRandomMilli(); + testRandomMicro(); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalChecker.java @@ -0,0 +1,328 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import java.math.BigDecimal; +import java.util.Random; + +import static java.lang.Float.*; +import static java.lang.Integer.numberOfTrailingZeros; +import static java.lang.Math.scalb; + +/* + * @test + * @author Raffaello Giulietti + */ +public class FloatToDecimalChecker extends ToDecimalChecker { + + private static final int RANDOM_COUNT = 1_000_000; + + private static final int MIN_EXP = -44; + private static final int MAX_EXP = 39; + private static final int H = 9; + private static final int P = 24; + + private float v; + private final int originalBits; + + private FloatToDecimalChecker(float v, String s) { + super(s); + this.v = v; + originalBits = floatToRawIntBits(v); + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.floatValue() == v; + } + + @Override + String hexBits() { + return String.format("0x%01X__%02X__%02X_%04X", + (originalBits >>> 31) & 0x1, + (originalBits >>> 23) & 0xFF, + (originalBits >>> 16) & 0x7F, + originalBits & 0xFFFF); + } + + @Override + boolean recovers(String s) { + return parseFloat(s) == v; + } + + @Override + int minExp() { + return MIN_EXP; + } + + @Override + int maxExp() { + return MAX_EXP; + } + + @Override + int maxLen10() { + return H; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == POSITIVE_INFINITY; + } + + @Override + void negate() { + v = -v; + } + + @Override + boolean isNegative() { + return originalBits < 0; + } + + @Override + boolean isNaN() { + return Float.isNaN(v); + } + + private static void toDec(float v) { + String s = Float.toString(v); + new FloatToDecimalChecker(v, s).assertTrue(); + } + + private static void testExtremeValues() { + toDec(NEGATIVE_INFINITY); + toDec(-MAX_VALUE); + toDec(-MIN_NORMAL); + toDec(-MIN_VALUE); + toDec(-0.0f); + toDec(0.0f); + toDec(MIN_VALUE); + toDec(MIN_NORMAL); + toDec(MAX_VALUE); + toDec(POSITIVE_INFINITY); + toDec(NaN); + + /* + Quiet NaNs have the most significant bit of the mantissa as 1, + while signaling NaNs have it as 0. + Exercise 4 combinations of quiet/signaling NaNs and + "positive/negative" NaNs. + */ + toDec(intBitsToFloat(0x7FC0_0001)); + toDec(intBitsToFloat(0x7F80_0001)); + toDec(intBitsToFloat(0xFFC0_0001)); + toDec(intBitsToFloat(0xFF80_0001)); + + /* + All values treated specially by Schubfach + */ + toDec(1.4E-45F); + toDec(2.8E-45F); + toDec(4.2E-45F); + toDec(5.6E-45F); + toDec(7.0E-45F); + toDec(8.4E-45F); + toDec(9.8E-45F); + } + + /* + A few "powers of 10" are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf10() { + for (int e = MIN_EXP; e <= MAX_EXP; ++e) { + toDec(parseFloat("1e" + e)); + } + } + + /* + Many powers of 2 are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf2() { + for (float v = MIN_VALUE; v <= MAX_VALUE; v *= 2) { + toDec(v); + } + } + + /* + There are many floats that are rendered incorrectly by the JDK. + While the renderings correctly round back to the original value, + they are longer than needed or are not the closest decimal to the float. + Here are just a very few examples. + */ + private static final String[] Anomalies = { + // JDK renders these longer than needed. + "1.1754944E-38", "2.2E-44", + "1.0E16", "2.0E16", "3.0E16", "5.0E16", "3.0E17", + "3.2E18", "3.7E18", "3.7E16", "3.72E17", + + // JDK does not render this as the closest. + "9.9E-44", + }; + + private static void testSomeAnomalies() { + for (String dec : Anomalies) { + toDec(parseFloat(dec)); + } + } + + /* + Values are from + Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" + tables 16 and 17 + */ + private static final float[] PaxsonSignificands = { + 12_676_506, + 15_445_013, + 13_734_123, + 12_428_269, + 12_676_506, + 15_334_037, + 11_518_287, + 12_584_953, + 15_961_084, + 14_915_817, + 10_845_484, + 16_431_059, + + 16_093_626, + 9_983_778, + 12_745_034, + 12_706_553, + 11_005_028, + 15_059_547, + 16_015_691, + 8_667_859, + 14_855_922, + 14_855_922, + 10_144_164, + 13_248_074, + }; + + private static final int[] PaxsonExponents = { + -102, + -103, + 86, + -138, + -130, + -146, + -41, + -145, + -125, + -146, + -102, + -61, + + 69, + 25, + 104, + 72, + 45, + 71, + -99, + 56, + -82, + -83, + -110, + 95, + }; + + private static void testPaxson() { + for (int i = 0; i < PaxsonSignificands.length; ++i) { + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); + } + } + + /* + Tests all positive integers below 2^23. + These are all exact floats and exercise the fast path. + */ + private static void testInts() { + for (int i = 1; i < 1 << P - 1; ++i) { + toDec(i); + } + } + + /* + Random floats over the whole range. + */ + private static void testRandom() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(intBitsToFloat(r.nextInt())); + } + } + + /* + All, really all, 2^32 possible floats. Takes between 90 and 120 minutes. + */ + private static void testAll() { + // Avoid wrapping around Integer.MAX_VALUE + int bits = Integer.MIN_VALUE; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(intBitsToFloat(bits)); + } + toDec(intBitsToFloat(bits)); + } + + /* + All 2^31 positive floats. + */ + private static void testPositive() { + // Avoid wrapping around Integer.MAX_VALUE + int bits = 0; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(intBitsToFloat(bits)); + } + toDec(intBitsToFloat(bits)); + } + + public static void main(String[] args) { + if (args.length > 0 && args[0].equals("all")) { + testAll(); + return; + } + if (args.length > 0 && args[0].equals("positive")) { + testPositive(); + return; + } + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testRandom(); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/ToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/ToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/ToDecimalChecker.java @@ -0,0 +1,375 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import java.io.IOException; +import java.io.StringReader; +import java.math.BigDecimal; +import java.math.BigInteger; + +/* +A checker for the Javadoc specification. +It just relies on straightforward use of (expensive) BigDecimal arithmetic, +not optimized at all. + */ +abstract class ToDecimalChecker extends BasicChecker { + + // The string to check + private final String s; + + // The decimal parsed from s is c 10^q + private long c; + private int q; + + // The number of digits parsed from s: 10^(len10-1) <= c < 10^len10 + private int len10; + + ToDecimalChecker(String s) { + this.s = s; + } + + void assertTrue() { + if (isOK()) { + return; + } + String msg = "toString applied to the bits " + + hexBits() + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(msg); + } + System.err.println(msg); + } + + /* + Returns whether s syntactically meets the expected output of + toString. It is restricted to finite positive outputs. + It is an unusually long method but rather straightforward, too. + Many conditionals could be merged, but KISS here. + */ + private boolean parse(String t) { + try { + // first determine interesting boundaries in the string + StringReader r = new StringReader(t); + int ch = r.read(); + + int i = 0; + while (ch == '0') { + ++i; + ch = r.read(); + } + // i is just after zeroes starting the integer + + int p = i; + while ('0' <= ch && ch <= '9') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++p; + ch = r.read(); + } + // p is just after digits ending the integer + + int fz = p; + if (ch == '.') { + ++fz; + ch = r.read(); + } + // fz is just after a decimal '.' + + int f = fz; + while (ch == '0') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++f; + ch = r.read(); + } + // f is just after zeroes starting the fraction + + if (c == 0) { + len10 = 0; + } + int x = f; + while ('0' <= ch && ch <= '9') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++x; + ch = r.read(); + } + // x is just after digits ending the fraction + + int g = x; + if (ch == 'E') { + ++g; + ch = r.read(); + } + // g is just after an exponent indicator 'E' + + int ez = g; + if (ch == '-') { + ++ez; + ch = r.read(); + } + // ez is just after a '-' sign in the exponent + + int e = ez; + while (ch == '0') { + ++e; + ch = r.read(); + } + // e is just after zeroes starting the exponent + + int z = e; + while ('0' <= ch && ch <= '9') { + q = 10 * q + (ch - '0'); + if (q < 0) { + return false; + } + ++z; + ch = r.read(); + } + // z is just after digits ending the exponent + + // No other char after the number + if (z != t.length()) { + return false; + } + + // The integer must be present + if (p == 0) { + return false; + } + + // The decimal '.' must be present + if (fz == p) { + return false; + } + + // The fraction must be present + if (x == fz) { + return false; + } + + // The fraction is not 0 or it consists of exactly one 0 + if (f == x && f - fz > 1) { + return false; + } + + // Plain notation, no exponent + if (x == z) { + // At most one 0 starting the integer + if (i > 1) { + return false; + } + + // If the integer is 0, at most 2 zeroes start the fraction + if (i == 1 && f - fz > 2) { + return false; + } + + // The integer cannot have more than 7 digits + if (p > 7) { + return false; + } + + q = fz - x; + + // OK for plain notation + return true; + } + + // Computerized scientific notation + + // The integer has exactly one nonzero digit + if (i != 0 || p != 1) { + return false; + } + + // + // There must be an exponent indicator + if (x == g) { + return false; + } + + // There must be an exponent + if (ez == z) { + return false; + } + + // The exponent must not start with zeroes + if (ez != e) { + return false; + } + + if (g != ez) { + q = -q; + } + + // The exponent must not lie in [-3, 7) + if (-3 <= q && q < 7) { + return false; + } + + q += fz - x; + + // OK for computerized scientific notation + return true; + } catch (IOException ex) { + // An IOException on a StringReader??? Please... + return false; + } + } + + private boolean isOK() { + if (isNaN()) { + return s.equals("NaN"); + } + String t = s; + if (isNegative()) { + if (s.isEmpty() || s.charAt(0) != '-') { + return false; + } + negate(); + t = s.substring(1); + } + if (isInfinity()) { + return t.equals("Infinity"); + } + if (isZero()) { + return t.equals("0.0"); + } + if (!parse(t)) { + return false; + } + if (len10 < 2) { + c *= 10; + q -= 1; + len10 += 1; + } + if (2 > len10 || len10 > maxLen10()) { + return false; + } + + // The exponent is bounded + if (minExp() > q + len10 || q + len10 > maxExp()) { + return false; + } + + // s must recover v + try { + if (!recovers(t)) { + return false; + } + } catch (NumberFormatException e) { + return false; + } + + // Get rid of trailing zeroes, still ensuring at least 2 digits + while (len10 > 2 && c % 10 == 0) { + c /= 10; + q += 1; + len10 -= 1; + } + + if (len10 > 2) { + // Try with a shorter number less than v... + if (recovers(BigDecimal.valueOf(c / 10, -q - 1))) { + return false; + } + + // ... and with a shorter number greater than v + if (recovers(BigDecimal.valueOf(c / 10 + 1, -q - 1))) { + return false; + } + } + + // Try with the decimal predecessor... + BigDecimal dp = c == 10 ? + BigDecimal.valueOf(99, -q + 1) : + BigDecimal.valueOf(c - 1, -q); + if (recovers(dp)) { + BigDecimal bv = toBigDecimal(); + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); + if (deltav.signum() >= 0) { + return true; + } + BigDecimal delta = dp.subtract(bv); + if (delta.signum() >= 0) { + return false; + } + int cmp = deltav.compareTo(delta); + return cmp > 0 || cmp == 0 && (c & 0x1) == 0; + } + + // ... and with the decimal successor + BigDecimal ds = BigDecimal.valueOf(c + 1, -q); + if (recovers(ds)) { + BigDecimal bv = toBigDecimal(); + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); + if (deltav.signum() <= 0) { + return true; + } + BigDecimal delta = ds.subtract(bv); + if (delta.signum() <= 0) { + return false; + } + int cmp = deltav.compareTo(delta); + return cmp < 0 || cmp == 0 && (c & 0x1) == 0; + } + + return true; + } + + abstract BigDecimal toBigDecimal(); + + abstract boolean recovers(BigDecimal b); + + abstract boolean recovers(String s); + + abstract String hexBits(); + + abstract int minExp(); + + abstract int maxExp(); + + abstract int maxLen10(); + + abstract boolean isZero(); + + abstract boolean isInfinity(); + + abstract void negate(); + + abstract boolean isNegative(); + + abstract boolean isNaN(); + +} -------------- next part -------------- # HG changeset patch # Date 1551899836 -3600 # Wed Mar 06 20:17:16 2019 +0100 # Node ID 085dc7813bec375fc77ab7f0adecdce9d4d03c11 # Parent 17fb726e6d8eec4acc3b3a91e63cf6d9d5ba7103 Patch to fix JDK-4511638 4511638: Double.toString(double) sometimes produces incorrect results Reviewed-by: TBD Contributed-by: Raffaello Giulietti diff --git a/src/java.base/share/classes/java/lang/Double.java b/src/java.base/share/classes/java/lang/Double.java old mode 100644 new mode 100755 --- a/src/java.base/share/classes/java/lang/Double.java +++ b/src/java.base/share/classes/java/lang/Double.java @@ -32,6 +32,7 @@ import jdk.internal.math.FloatingDecimal; import jdk.internal.math.DoubleConsts; +import jdk.internal.math.DoubleToDecimal; import jdk.internal.HotSpotIntrinsicCandidate; /** @@ -145,69 +146,120 @@ public static final Class TYPE = (Class) Class.getPrimitiveClass("double"); /** - * Returns a string representation of the {@code double} - * argument. All characters mentioned below are ASCII characters. - *

          - *
        • If the argument is NaN, the result is the string - * "{@code NaN}". - *
        • Otherwise, the result is a string that represents the sign and - * magnitude (absolute value) of the argument. If the sign is negative, - * the first character of the result is '{@code -}' - * ({@code '\u005Cu002D'}); if the sign is positive, no sign character - * appears in the result. As for the magnitude m: - *
            - *
          • If m is infinity, it is represented by the characters - * {@code "Infinity"}; thus, positive infinity produces the result - * {@code "Infinity"} and negative infinity produces the result - * {@code "-Infinity"}. - * - *
          • If m is zero, it is represented by the characters - * {@code "0.0"}; thus, negative zero produces the result - * {@code "-0.0"} and positive zero produces the result - * {@code "0.0"}. + * Returns a string rendering of the {@code double} argument. * - *
          • If m is greater than or equal to 10-3 but less - * than 107, then it is represented as the integer part of - * m, in decimal form with no leading zeroes, followed by - * '{@code .}' ({@code '\u005Cu002E'}), followed by one or - * more decimal digits representing the fractional part of m. - * - *
          • If m is less than 10-3 or greater than or - * equal to 107, then it is represented in so-called - * "computerized scientific notation." Let n be the unique - * integer such that 10n ≤ m {@literal <} - * 10n+1; then let a be the - * mathematically exact quotient of m and - * 10n so that 1 ≤ a {@literal <} 10. The - * magnitude is then represented as the integer part of a, - * as a single decimal digit, followed by '{@code .}' - * ({@code '\u005Cu002E'}), followed by decimal digits - * representing the fractional part of a, followed by the - * letter '{@code E}' ({@code '\u005Cu0045'}), followed - * by a representation of n as a decimal integer, as - * produced by the method {@link Integer#toString(int)}. + *

            The characters of the result are all drawn from the ASCII set. + *

              + *
            • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
            • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
            • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
            • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
            • A finite positive {@code v} is rendered in two stages: + *
                + *
              • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
              • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. *
              *
            - * How many digits must be printed for the fractional part of - * m or a? There must be at least one digit to represent - * the fractional part, and beyond that as many, but only as many, more - * digits as are needed to uniquely distinguish the argument value from - * adjacent values of type {@code double}. That is, suppose that - * x is the exact mathematical value represented by the decimal - * representation produced by this method for a finite nonzero argument - * d. Then d must be the {@code double} value nearest - * to x; or if two {@code double} values are equally close - * to x, then d must be one of them and the least - * significant bit of the significand of d must be {@code 0}. + * + *

            A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

            The decimal dv + * for a finite positive {@code v} is defined as follows: + *

              + *
            • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
            • Let m be the minimal length over all decimals in R. + *
            • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
            • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
            + * + *

            The (uniquely) selected decimal dv + * is then formatted. * - *

            To create localized string representations of a floating-point - * value, use subclasses of {@link java.text.NumberFormat}. + *

            Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

              + *
            • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
            • Case 0 ≤ e < 7: + *
                + *
              • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
              • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
              + *
            • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
                + *
              • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
              • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
              + *
            * - * @param d the {@code double} to be converted. - * @return a string representation of the argument. + * @param v the {@code double} to be rendered. + * @return a string rendering of the argument. */ - public static String toString(double d) { - return FloatingDecimal.toJavaFormatString(d); + public static String toString(double v) { + return DoubleToDecimal.toString(v); } /** diff --git a/src/java.base/share/classes/java/lang/Float.java b/src/java.base/share/classes/java/lang/Float.java old mode 100644 new mode 100755 --- a/src/java.base/share/classes/java/lang/Float.java +++ b/src/java.base/share/classes/java/lang/Float.java @@ -31,6 +31,7 @@ import java.util.Optional; import jdk.internal.math.FloatingDecimal; +import jdk.internal.math.FloatToDecimal; import jdk.internal.HotSpotIntrinsicCandidate; /** @@ -142,73 +143,120 @@ public static final Class TYPE = (Class) Class.getPrimitiveClass("float"); /** - * Returns a string representation of the {@code float} - * argument. All characters mentioned below are ASCII characters. - *
              - *
            • If the argument is NaN, the result is the string - * "{@code NaN}". - *
            • Otherwise, the result is a string that represents the sign and - * magnitude (absolute value) of the argument. If the sign is - * negative, the first character of the result is - * '{@code -}' ({@code '\u005Cu002D'}); if the sign is - * positive, no sign character appears in the result. As for - * the magnitude m: + * Returns a string rendering of the {@code float} argument. + * + *

              The characters of the result are all drawn from the ASCII set. *

                - *
              • If m is infinity, it is represented by the characters - * {@code "Infinity"}; thus, positive infinity produces - * the result {@code "Infinity"} and negative infinity - * produces the result {@code "-Infinity"}. - *
              • If m is zero, it is represented by the characters - * {@code "0.0"}; thus, negative zero produces the result - * {@code "-0.0"} and positive zero produces the result - * {@code "0.0"}. - *
              • If m is greater than or equal to 10-3 but - * less than 107, then it is represented as the - * integer part of m, in decimal form with no leading - * zeroes, followed by '{@code .}' - * ({@code '\u005Cu002E'}), followed by one or more - * decimal digits representing the fractional part of - * m. - *
              • If m is less than 10-3 or greater than or - * equal to 107, then it is represented in - * so-called "computerized scientific notation." Let n - * be the unique integer such that 10n ≤ - * m {@literal <} 10n+1; then let a - * be the mathematically exact quotient of m and - * 10n so that 1 ≤ a {@literal <} 10. - * The magnitude is then represented as the integer part of - * a, as a single decimal digit, followed by - * '{@code .}' ({@code '\u005Cu002E'}), followed by - * decimal digits representing the fractional part of - * a, followed by the letter '{@code E}' - * ({@code '\u005Cu0045'}), followed by a representation - * of n as a decimal integer, as produced by the - * method {@link java.lang.Integer#toString(int)}. - * + *
              • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
              • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
              • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
              • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
              • A finite positive {@code v} is rendered in two stages: + *
                  + *
                • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
                • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. *
                *
              - * How many digits must be printed for the fractional part of - * m or a? There must be at least one digit - * to represent the fractional part, and beyond that as many, but - * only as many, more digits as are needed to uniquely distinguish - * the argument value from adjacent values of type - * {@code float}. That is, suppose that x is the - * exact mathematical value represented by the decimal - * representation produced by this method for a finite nonzero - * argument f. Then f must be the {@code float} - * value nearest to x; or, if two {@code float} values are - * equally close to x, then f must be one of - * them and the least significant bit of the significand of - * f must be {@code 0}. + * + *

              A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

              The decimal dv + * for a finite positive {@code v} is defined as follows: + *

                + *
              • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
              • Let m be the minimal length over all decimals in R. + *
              • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
              • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
              + * + *

              The (uniquely) selected decimal dv + * is then formatted. * - *

              To create localized string representations of a floating-point - * value, use subclasses of {@link java.text.NumberFormat}. + *

              Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

                + *
              • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
              • Case 0 ≤ e < 7: + *
                  + *
                • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
                • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
                + *
              • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
                  + *
                • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
                • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
                + *
              * - * @param f the float to be converted. - * @return a string representation of the argument. + * @param v the {@code float} to be rendered. + * @return a string rendering of the argument. */ - public static String toString(float f) { - return FloatingDecimal.toJavaFormatString(f); + public static String toString(float v) { + return FloatToDecimal.toString(v); } /** diff --git a/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java @@ -0,0 +1,573 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import static java.lang.Double.*; +import static java.lang.Long.*; +import static java.lang.Math.multiplyHigh; +import static jdk.internal.math.MathUtils.*; + +/** + * This class exposes a method to render a {@code double} as a string. + * + * @author Raffaello Giulietti + */ +final public class DoubleToDecimal { + /* + For full details about this code see the following references: + + [1] Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + + Divisions are avoided for the benefit of those architectures that do not + provide specific machine instructions or where they are slow. + This is discussed in section 10 of [1]. + */ + + // The precision in bits. + static final int P = 53; + + // H is as in section 8 of [1]. + static final int H = 17; + + // 10^(MIN_EXP - 1) <= MIN_VALUE < 10^MIN_EXP + static final int MIN_EXP = -323; + + // 10^(MAX_EXP - 1) <= MAX_VALUE < 10^MAX_EXP + static final int MAX_EXP = 309; + + // Exponent width in bits. + private static final int W = (Double.SIZE - 1) - (P - 1); + + // Minimum value of the exponent: -(2^(W-1)) - P + 3. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // Minimum value of the significand of a normal value: 2^(P-1). + private static final long C_MIN = 1L << P - 1; + + // Mask to extract the biased exponent. + private static final int BQ_MASK = (1 << W) - 1; + + // Mask to extract the fraction bits. + private static final long T_MASK = (1L << P - 1) - 1; + + // Used in rop(). + private static final long MASK_63 = (1L << 63) - 1; + + // Used for left-to-tight digit extraction. + private static final int MASK_28 = (1 << 28) - 1; + + // For thread-safety, each thread gets its own instance of this class. + private static final ThreadLocal threadLocal = + ThreadLocal.withInitial(DoubleToDecimal::new); + + /* + Room for the longer of the forms + -ddddd.dddddddddddd H + 2 characters + -0.00ddddddddddddddddd H + 5 characters + -d.ddddddddddddddddE-eee H + 7 characters + where there are H digits d + */ + private final byte[] buf = new byte[H + 7]; + + // Index into buf of rightmost valid character. + private int index; + + private DoubleToDecimal() { + } + + /** + * Returns a string rendering of the {@code double} argument. + * + *

              The characters of the result are all drawn from the ASCII set. + *

                + *
              • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
              • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
              • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
              • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
              • A finite positive {@code v} is rendered in two stages: + *
                  + *
                • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
                • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. + *
                + *
              + * + *

              A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

              The decimal dv + * for a finite positive {@code v} is defined as follows: + *

                + *
              • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
              • Let m be the minimal length over all decimals in R. + *
              • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
              • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
              + * + *

              The (uniquely) selected decimal dv + * is then formatted. + * + *

              Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

                + *
              • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
              • Case 0 ≤ e < 7: + *
                  + *
                • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
                • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
                + *
              • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
                  + *
                • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
                • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
                + *
              + * + * @param v the {@code double} to be rendered. + * @return a string rendering of the argument. + */ + public static String toString(double v) { + return threadLocalInstance().toDecimal(v); + } + + private static DoubleToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(double v) { + /* + For full details see references [2] and [1]. + + Let + Q_MAX = 2^(W-1) - P + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either 2^(P-1) <= c < 2^P (normal) + or 0 < c < 2^(P-1) and q = Q_MIN (subnormal) + */ + long bits = doubleToRawLongBits(v); + long t = bits & T_MASK; + int bq = (int) (bits >>> P - 1) & BQ_MASK; + if (bq < BQ_MASK) { + index = -1; + if (bits < 0) { + append('-'); + } + if (bq != 0) { + // normal value. Here mq = -q + int mq = -Q_MIN + 1 - bq; + long c = C_MIN | t; + // The fast path discussed in section 8.3 of [1]. + if (0 < mq & mq < P) { + long f = c >> mq; + if (f << mq == c) { + return toChars(f, 0); + } + } + return toDecimal(-mq, c); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, long c) { + /* + The skeleton corresponds to figure 4 of [1]. + The efficient computations are those summarized in figure 7. + + Here's a correspondence between Java names and names in [1], + expressed as approximate LaTeX source code and informally. + Other names are identical. + cb: \bar{c} "c-bar" + cbr: \bar{c}_r "c-bar-r" + cbl: \bar{c}_l "c-bar-l" + + vb: \bar{v} "v-bar" + vbr: \bar{v}_r "v-bar-r" + vbl: \bar{v}_l "v-bar-l" + + rop: r_o' "r-o-prime" + */ + int out = (int) c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + /* + flog10pow2(e) = floor(log_10(2^e)) + flog10threeQuartersPow2(e) = floor(log_10(3/4 2^e)) + flog2pow10(e) = floor(log_2(10^e)) + */ + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 3; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 2; + } + cbl = cb - 1; + + // g1 and g0 are as in section 9.8.3, so g = g1 2^63 + g0 + long g1 = g1(-k); + long g0 = g0(-k); + + long vb = rop(g1, g0, cb << h); + long vbl = rop(g1, g0, cbl << h); + long vbr = rop(g1, g0, cbr << h); + + long s = vb >> 2; + if (s >= 100) { + /* + For n = 17, m = 1 the table in section 10 of [1] shows + s' = + floor(s / 10) = floor(s 115'292'150'460'684'698 / 2^60) = + floor(s 115'292'150'460'684'698 2^4 / 2^64) + + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + upin iff u' = sp10 10^k in Rv + wpin iff w' = tp10 10^k in Rv + See section 9.3. + */ + long sp10 = 10 * multiplyHigh(s, 115_292_150_460_684_698L << 4); + long tp10 = sp10 + 10; + boolean upin = vbl + out <= sp10 << 2; + boolean wpin = (tp10 << 2) + out <= vbr; + if (upin != wpin) { + return toChars(upin ? sp10 : tp10, k); + } + } else if (s < 10) { + switch ((int) s) { + case 4: + return toChars(49, -325); // 4.9 10^(-324) + case 9: + return toChars(99, -325); // 9.9 10^(-324) + } + } + + /* + 10 <= s < 100 or s >= 100 and u', w' not in Rv + uin iff u = s 10^k in Rv + win iff w = t 10^k in Rv + See section 9.3. + */ + long t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of u or w lies in Rv. + return toChars(uin ? s : t, k); + } + /* + Both u and w lie in Rv: determine the one closest to v. + See section 9.3. + */ + long cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + /* + Computes rop(cp g 2^(-127)), where g = g1 2^63 + g0 + See section 9.9 and figure 6 of [1]. + */ + private static long rop(long g1, long g0, long cp) { + long x1 = multiplyHigh(g0, cp); + long y0 = g1 * cp; + long y1 = multiplyHigh(g1, cp); + long z = (y0 >>> 1) + x1; + long vbp = y1 + (z >>> 63); + return vbp | (z & MASK_63) + MASK_63 >>> 63; + } + + /* + Formats the decimal f 10^e. + */ + private String toChars(long f, int e) { + /* + For details not discussed here see section 10 of [1]. + + Determine len such that + 10^(len-1) <= f < 10^len + */ + int len = flog10pow2(Long.SIZE - numberOfLeadingZeros(f)); + if (f >= pow10(len)) { + len += 1; + } + + /* + Let fp and ep be the original f and e, respectively. + Transform f and e to ensure + 10^(H-1) <= f < 10^H + fp 10^ep = f 10^(e-H) = 0.f 10^e + */ + f *= pow10(H - len); + e += len; + + /* + The toChars?() methods perform left-to-right digits extraction + using ints, provided that the arguments are limited to 8 digits. + Therefore, split the H = 17 digits of f into: + h = the most significant digit of f + m = the next 8 most significant digits of f + l = the last 8, least significant digits of f + + For n = 17, m = 8 the table in section 10 of [1] shows + floor(f / 10^8) = floor(193'428'131'138'340'668 f / 2^84) = + floor(floor(193'428'131'138'340'668 f / 2^64) / 2^20) + and for n = 9, m = 8 + floor(hm / 10^8) = floor(1'441'151'881 hm / 2^57) + */ + long hm = multiplyHigh(f, 193_428_131_138_340_668L) >>> 20; + int l = (int) (f - 100_000_000L * hm); + int h = (int) (hm * 1_441_151_881L >>> 57); + int m = (int) (hm - 100_000_000 * h); + + if (0 < e && e <= 7) { + return toChars1(h, m, l, e); + } + if (-3 < e && e <= 0) { + return toChars2(h, m, l, e); + } + return toChars3(h, m, l, e); + } + + private String toChars1(int h, int m, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + appendDigit(h); + int y = y(m); + int t; + int i = 1; + for (; i < e; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + append('.'); + for (; i <= 8; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + lowDigits(l); + return charsToString(); + } + + private String toChars2(int h, int m, int l, int e) { + // -3 < e <= 0: plain format with leading zeroes. + appendDigit(0); + append('.'); + for (; e < 0; ++e) { + appendDigit(0); + } + appendDigit(h); + append8Digits(m); + lowDigits(l); + return charsToString(); + } + + private String toChars3(int h, int m, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(m); + lowDigits(l); + exponent(e - 1); + return charsToString(); + } + + private void lowDigits(int l) { + if (l != 0) { + append8Digits(l); + } + removeTrailingZeroes(); + } + + private void append8Digits(int m) { + /* + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + int y = y(m); + for (int i = 0; i < 8; ++i) { + int t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + } + + private void removeTrailingZeroes() { + while (buf[index] == '0') { + --index; + } + // ... but do not remove the one directly to the right of '.' + if (buf[index] == '.') { + ++index; + } + } + + private int y(int a) { + /* + Algorithm 1 in [3] needs computation of + floor((a + 1) 2^n / b^k) - 1 + with a < 10^8, b = 10, k = 8, n = 28. + Noting that + (a + 1) 2^n <= 10^8 2^28 < 10^17 + For n = 17, m = 8 the table in section 10 of [1] leads to: + */ + return (int) (multiplyHigh( + (long) (a + 1) << 28, + 193_428_131_138_340_668L) >>> 20) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + int d; + if (e >= 100) { + /* + For n = 3, m = 2 the table in section 10 of [1] shows + floor(e / 100) = floor(1'311 e / 2^17) + */ + d = e * 1_311 >>> 17; + appendDigit(d); + e -= 100 * d; + } + /* + For n = 2, m = 1 the table in section 10 of [1] shows + floor(e / 10) = floor(103 e / 2^10) + */ + d = e * 103 >>> 10; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated constructor enhances performance. + */ + @SuppressWarnings("deprecation") + private String charsToString() { + return new String(buf, 0, 0, index + 1); + } + +} diff --git a/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java @@ -0,0 +1,549 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import static java.lang.Float.*; +import static java.lang.Integer.*; +import static java.lang.Math.multiplyHigh; +import static jdk.internal.math.MathUtils.*; + +/** + * This class exposes a method to render a {@code float} as a string. + * + * @author Raffaello Giulietti + */ +final public class FloatToDecimal { + /* + For full details about this code see the following references: + + [1] Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + + Divisions are avoided for the benefit of those architectures that do not + provide specific machine instructions or where they are slow. + This is discussed in section 10 of [1]. + */ + + // The precision in bits. + static final int P = 24; + + // H is as in section 8 of [1]. + static final int H = 9; + + // 10^(MIN_EXP - 1) <= MIN_VALUE < 10^MIN_EXP + static final int MIN_EXP = -44; + + // 10^(MAX_EXP - 1) <= MAX_VALUE < 10^MAX_EXP + static final int MAX_EXP = 39; + + // Exponent width in bits. + private static final int W = (Float.SIZE - 1) - (P - 1); + + // Minimum value of the exponent: -(2^(W-1)) - P + 3. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // Minimum value of the significand of a normal value: 2^(P-1). + private static final int C_MIN = 1 << P - 1; + + // Mask to extract the biased exponent. + private static final int BQ_MASK = (1 << W) - 1; + + // Mask to extract the fraction bits. + private static final int T_MASK = (1 << P - 1) - 1; + + // Used in rop(). + private static final long MASK_32 = (1L << 32) - 1; + + // Used for left-to-tight digit extraction. + private static final int MASK_28 = (1 << 28) - 1; + + // For thread-safety, each thread gets its own instance of this class. + private static final ThreadLocal threadLocal = + ThreadLocal.withInitial(FloatToDecimal::new); + + /* + Room for the longer of the forms + -ddddd.dddd H + 2 characters + -0.00ddddddddd H + 5 characters + -d.ddddddddE-ee H + 6 characters + where there are H digits d + */ + private final byte[] buf = new byte[H + 6]; + + // Index into buf of rightmost valid character. + private int index; + + private FloatToDecimal() { + } + + /** + * Returns a string rendering of the {@code float} argument. + * + *

              The characters of the result are all drawn from the ASCII set. + *

                + *
              • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
              • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
              • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
              • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
              • A finite positive {@code v} is rendered in two stages: + *
                  + *
                • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
                • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. + *
                + *
              + * + *

              A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

              The decimal dv + * for a finite positive {@code v} is defined as follows: + *

                + *
              • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
              • Let m be the minimal length over all decimals in R. + *
              • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
              • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
              + * + *

              The (uniquely) selected decimal dv + * is then formatted. + * + *

              Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

                + *
              • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
              • Case 0 ≤ e < 7: + *
                  + *
                • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
                • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
                + *
              • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
                  + *
                • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
                • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
                + *
              + * + * @param v the {@code float} to be rendered. + * @return a string rendering of the argument. + */ + public static String toString(float v) { + return threadLocalInstance().toDecimal(v); + } + + private static FloatToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(float v) { + /* + For full details see references [2] and [1]. + + Let + Q_MAX = 2^(W-1) - P + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either 2^(P-1) <= c < 2^P (normal) + or 0 < c < 2^(P-1) and q = Q_MIN (subnormal) + */ + int bits = floatToRawIntBits(v); + int t = bits & T_MASK; + int bq = (bits >>> P - 1) & BQ_MASK; + if (bq < BQ_MASK) { + index = -1; + if (bits < 0) { + append('-'); + } + if (bq != 0) { + // normal value. Here mq = -q + int mq = -Q_MIN + 1 - bq; + int c = C_MIN | t; + // The fast path discussed in section 8.3 of [1]. + if (0 < mq & mq < P) { + int f = c >> mq; + if (f << mq == c) { + return toChars(f, 0); + } + } + return toDecimal(-mq, c); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, int c) { + /* + The skeleton corresponds to figure 4 of [1]. + The efficient computations are those summarized in figure 7. + Also check the appendix. + + Here's a correspondence between Java names and names in [1], + expressed as approximate LaTeX source code and informally. + Other names are identical. + cb: \bar{c} "c-bar" + cbr: \bar{c}_r "c-bar-r" + cbl: \bar{c}_l "c-bar-l" + + vb: \bar{v} "v-bar" + vbr: \bar{v}_r "v-bar-r" + vbl: \bar{v}_l "v-bar-l" + + rop: r_o' "r-o-prime" + */ + int out = c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + /* + flog10pow2(e) = floor(log_10(2^e)) + flog10threeQuartersPow2(e) = floor(log_10(3/4 2^e)) + flog2pow10(e) = floor(log_2(10^e)) + */ + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 34; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 33; + } + cbl = cb - 1; + + // g is as in the appendix + long g = g1(-k) + 1; + + int vb = rop(g, cb << h); + int vbl = rop(g, cbl << h); + int vbr = rop(g, cbr << h); + + int s = vb >> 2; + if (s >= 100) { + /* + For n = 9, m = 1 the table in section 10 of [1] shows + s' = + floor(s / 10) = floor(s 1'717'986'919 / 2^34) + + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + upin iff u' = sp10 10^k in Rv + wpin iff w' = tp10 10^k in Rv + See section 9.3. + */ + int sp10 = 10 * (int) (s * 1_717_986_919L >>> 34); + int tp10 = sp10 + 10; + boolean upin = vbl + out <= sp10 << 2; + boolean wpin = (tp10 << 2) + out <= vbr; + if (upin != wpin) { + return toChars(upin ? sp10 : tp10, k); + } + } else if (s < 10) { + switch (s) { + case 1: return toChars(14, -46); // 1.4 * 10^-45 + case 2: return toChars(28, -46); // 2.8 * 10^-45 + case 4: return toChars(42, -46); // 4.2 * 10^-45 + case 5: return toChars(56, -46); // 5.6 * 10^-45 + case 7: return toChars(70, -46); // 7.0 * 10^-45 + case 8: return toChars(84, -46); // 8.4 * 10^-45 + case 9: return toChars(98, -46); // 9.8 * 10^-45 + } + } + + /* + 10 <= s < 100 or s >= 100 and u', w' not in Rv + uin iff u = s 10^k in Rv + win iff w = t 10^k in Rv + See section 9.3. + */ + int t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of u or w lies in Rv. + return toChars(uin ? s : t, k); + } + /* + Both u and w lie in Rv: determine the one closest to v. + See section 9.3. + */ + int cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + /* + Computes rop(cp g 2^(-95)) + See appendix and figure 9 of [1]. + */ + private static int rop(long g, long cp) { + long x1 = multiplyHigh(g, cp); + long vbp = x1 >>> 31; + return (int) (vbp | (x1 & MASK_32) + MASK_32 >>> 32); + } + + /* + Formats the decimal f 10^e. + */ + private String toChars(int f, int e) { + /* + For details not discussed here see section 10 of [1]. + + Determine len such that + 10^(len-1) <= f < 10^len + */ + int len = flog10pow2(Integer.SIZE - numberOfLeadingZeros(f)); + if (f >= pow10(len)) { + len += 1; + } + + /* + Let fp and ep be the original f and e, respectively. + Transform f and e to ensure + 10^(H-1) <= f < 10^H + fp 10^ep = f 10^(e-H) = 0.f 10^e + */ + f *= pow10(H - len); + e += len; + + /* + The toChars?() methods perform left-to-right digits extraction + using ints, provided that the arguments are limited to 8 digits. + Therefore, split the H = 9 digits of f into: + h = the most significant digit of f + l = the last 8, least significant digits of f + + For n = 9, m = 8 the table in section 10 of [1] shows + floor(f / 10^8) = floor(1'441'151'881 f / 2^57) + */ + int h = (int) (f * 1_441_151_881L >>> 57); + int l = f - 100_000_000 * h; + + if (0 < e && e <= 7) { + return toChars1(h, l, e); + } + if (-3 < e && e <= 0) { + return toChars2(h, l, e); + } + return toChars3(h, l, e); + } + + private String toChars1(int h, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + appendDigit(h); + int y = y(l); + int t; + int i = 1; + for (; i < e; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + append('.'); + for (; i <= 8; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + removeTrailingZeroes(); + return charsToString(); + } + + private String toChars2(int h, int l, int e) { + // -3 < e <= 0: plain format with leading zeroes. + appendDigit(0); + append('.'); + for (; e < 0; ++e) { + appendDigit(0); + } + appendDigit(h); + append8Digits(l); + removeTrailingZeroes(); + return charsToString(); + } + + private String toChars3(int h, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(l); + removeTrailingZeroes(); + exponent(e - 1); + return charsToString(); + } + + private void append8Digits(int m) { + /* + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + int y = y(m); + for (int i = 0; i < 8; ++i) { + int t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + } + + private void removeTrailingZeroes() { + while (buf[index] == '0') { + --index; + } + // ... but do not remove the one directly to the right of '.' + if (buf[index] == '.') { + ++index; + } + } + + private int y(int a) { + /* + Algorithm 1 in [3] needs computation of + floor((a + 1) 2^n / b^k) - 1 + with a < 10^8, b = 10, k = 8, n = 28. + Noting that + (a + 1) 2^n <= 10^8 2^28 < 10^17 + For n = 17, m = 8 the table in section 10 of [1] leads to: + */ + return (int) (multiplyHigh( + (long) (a + 1) << 28, + 193_428_131_138_340_668L) >>> 20) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + For n = 2, m = 1 the table in section 10 of [1] shows + floor(e / 10) = floor(103 e / 2^10) + */ + int d = e * 103 >>> 10; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated constructor enhances performance. + */ + @SuppressWarnings("deprecation") + private String charsToString() { + return new String(buf, 0, 0, index + 1); + } + +} diff --git a/src/java.base/share/classes/jdk/internal/math/MathUtils.java b/src/java.base/share/classes/jdk/internal/math/MathUtils.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/MathUtils.java @@ -0,0 +1,799 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +/** + * This class exposes package private utilities for other classes. Thus, + * all methods are assumed to be invoked with correct arguments, so they are + * not checked at all. + * + * @author Raffaello Giulietti + */ +final class MathUtils { + /* + For full details about this code see the following reference: + + Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + */ + + // The minimum and maximum k + static final int MIN_K = -324; + static final int MAX_K = 292; + + // C_10 = floor(log10(2) * 2^Q_10), A_10 = floor(log10(3/4) * 2^Q_10) + private static final int Q_10 = 41; + private static final long C_10 = 661_971_961_083L; + private static final long A_10 = -274_743_187_321L; + + // C_2 = floor(log2(10) * 2^Q_2) + private static final int Q_2 = 38; + private static final long C_2 = 913_124_641_741L; + + private MathUtils() { + } + + private static final long[] pow10 = { + 1L, + 10L, + 100L, + 1_000L, + 10_000L, + 100_000L, + 1_000_000L, + 10_000_000L, + 100_000_000L, + 1_000_000_000L, + 10_000_000_000L, + 100_000_000_000L, + 1_000_000_000_000L, + 10_000_000_000_000L, + 100_000_000_000_000L, + 1_000_000_000_000_000L, + 10_000_000_000_000_000L, + 100_000_000_000_000_000L, + }; + + /** + * Returns 10{@code e}. + * + * @param e The exponent which must meet + * 0 ≤ {@code e} ≤ {@link DoubleToDecimal#H}. + * @return 10{@code e}. + */ + static long pow10(int e) { + return pow10[e]; + } + + /** + * Returns the unique integer k such that + * 10k ≤ 2{@code e} + * < 10k+1. + *

              + * The result is correct when |{@code e}| ≤ 5_456_721. + * Otherwise the result is undefined. + * + * @param e The exponent of 2, which should meet + * |{@code e}| ≤ 5_456_721 for safe results. + * @return ⌊log102{@code e}⌋. + */ + static int flog10pow2(int e) { + return (int) (e * C_10 >> Q_10); + } + + /** + * Returns the unique integer k such that + * 10k ≤ 3/4 · 2{@code e} + * < 10k+1. + *

              + * The result is correct when + * -2_956_395 ≤ {@code e} ≤ 2_500_325. + * Otherwise the result is undefined. + * + * @param e The exponent of 2, which should meet + * -2_956_395 ≤ {@code e} ≤ 2_500_325 for safe results. + * @return ⌊log10(3/4 · + * 2{@code e})⌋. + */ + static int flog10threeQuartersPow2(int e) { + return (int) (e * C_10 + A_10 >> Q_10); + } + + /** + * Returns the unique integer k such that + * 2k ≤ 10{@code e} + * < 2k+1. + *

              + * The result is correct when |{@code e}| ≤ 1_838_394. + * Otherwise the result is undefined. + * + * @param e The exponent of 10, which should meet + * |{@code e}| ≤ 1_838_394 for safe results. + * @return ⌊log210{@code e}⌋. + */ + static int flog2pow10(int e) { + return (int) (e * C_2 >> Q_2); + } + + /** + * Let 10{@code e} = β 2r, + * for the unique pair of integer r and real β meeting + * 2125 ≤ β < 2126. + * Further, let g = ⌊β⌋ + 1. + * Split g into the higher 63 bits g1 and + * the lower 63 bits g0. Thus, + * g1 = + * ⌊g 2-63⌋ + * and + * g0 = + * g - g1 263. + *

              + * This method returns g1 while + * {@link #g0(int)} returns g0. + *

              + * If needed, the exponent r can be computed as + * r = {@code flog2pow10(e)} - 125 (see {@link #flog2pow10(int)}). + * + * @param e The exponent of 10. + * @return g1 as described above. + */ + static long g1(int e) { + return g[e + MAX_K << 1]; + } + + /** + * Returns g0 as described in + * {@link #g1(int)}. + * + * @param e The exponent of 10. + * @return g0 as described in + * {@link #g1(int)}. + */ + static long g0(int e) { + return g[e + MAX_K << 1 | 1]; + } + + /** + * The precomputed values for {@link #g1(int)} and {@link #g0(int)}. + */ + private static final long[] g = { + /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL, + /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL, + /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L, + /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L, + /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL, + /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L, + /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L, + /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL, + /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L, + /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL, + /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL, + /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L, + /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL, + /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L, + /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L, + /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL, + /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L, + /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L, + /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L, + /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL, + /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L, + /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L, + /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L, + /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL, + /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L, + /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L, + /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL, + /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L, + /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L, + /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L, + /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L, + /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL, + /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL, + /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L, + /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L, + /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL, + /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L, + /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L, + /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L, + /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L, + /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L, + /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L, + /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL, + /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L, + /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L, + /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L, + /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L, + /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L, + /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L, + /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L, + /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L, + /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L, + /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL, + /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L, + /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L, + /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL, + /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L, + /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL, + /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L, + /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L, + /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL, + /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L, + /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L, + /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L, + /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL, + /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L, + /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L, + /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L, + /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL, + /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L, + /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L, + /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L, + /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L, + /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL, + /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L, + /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L, + /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL, + /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L, + /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L, + /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L, + /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L, + /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L, + /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L, + /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL, + /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL, + /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L, + /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L, + /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL, + /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL, + /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L, + /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L, + /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL, + /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L, + /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L, + /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L, + /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L, + /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL, + /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L, + /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L, + /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L, + /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L, + /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L, + /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L, + /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L, + /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L, + /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L, + /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L, + /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L, + /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L, + /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L, + /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L, + /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L, + /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL, + /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L, + /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL, + /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL, + /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L, + /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L, + /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L, + /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L, + /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L, + /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L, + /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L, + /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L, + /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L, + /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL, + /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL, + /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L, + /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL, + /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L, + /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L, + /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL, + /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L, + /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL, + /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL, + /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL, + /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL, + /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L, + /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL, + /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L, + /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL, + /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L, + /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L, + /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL, + /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL, + /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL, + /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L, + /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL, + /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L, + /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL, + /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L, + /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L, + /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL, + /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L, + /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L, + /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL, + /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L, + /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L, + /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L, + /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL, + /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL, + /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL, + /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L, + /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL, + /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L, + /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL, + /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L, + /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL, + /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL, + /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L, + /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L, + /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL, + /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL, + /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL, + /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L, + /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL, + /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL, + /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L, + /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L, + /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L, + /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L, + /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L, + /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L, + /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L, + /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL, + /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L, + /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL, + /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L, + /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L, + /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L, + /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL, + /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL, + /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL, + /* -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L, + /* -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL, + /* -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL, + /* -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L, + /* -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L, + /* -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L, + /* -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L, + /* -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L, + /* -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL, + /* -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L, + /* -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL, + /* -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL, + /* -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL, + /* -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L, + /* -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL, + /* -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL, + /* -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL, + /* -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL, + /* -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L, + /* -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L, + /* -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L, + /* -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL, + /* -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L, + /* -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL, + /* -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L, + /* -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L, + /* -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL, + /* -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL, + /* -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L, + /* -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L, + /* -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL, + /* -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L, + /* -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L, + /* -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L, + /* -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL, + /* -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL, + /* -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL, + /* -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL, + /* -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L, + /* -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L, + /* -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L, + /* -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L, + /* -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL, + /* -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L, + /* -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL, + /* -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L, + /* -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL, + /* -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL, + /* -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL, + /* -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L, + /* -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL, + /* -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L, + /* -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL, + /* -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL, + /* -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L, + /* -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL, + /* -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L, + /* -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L, + /* -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L, + /* -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L, + /* -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L, + /* -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L, + /* -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L, + /* -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL, + /* -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL, + /* -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L, + /* -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L, + /* -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL, + /* -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L, + /* -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L, + /* -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL, + /* -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L, + /* -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L, + /* -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L, + /* -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L, + /* -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L, + /* -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L, + /* -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL, + /* -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L, + /* -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L, + /* -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL, + /* -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L, + /* -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L, + /* -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL, + /* -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L, + /* -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L, + /* -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL, + /* -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L, + /* -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L, + /* -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L, + /* -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL, + /* -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L, + /* -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L, + /* -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L, + /* -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L, + /* -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL, + /* -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL, + /* -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L, + /* -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L, + /* 0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0001L, + /* 8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0001L, + /* 9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0001L, + /* 10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0001L, + /* 11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0001L, + /* 12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0001L, + /* 13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0001L, + /* 14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0001L, + /* 15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0001L, + /* 16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0001L, + /* 17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0001L, + /* 18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0001L, + /* 19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0001L, + /* 20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0001L, + /* 21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0001L, + /* 22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0001L, + /* 23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0001L, + /* 24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0001L, + /* 25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0001L, + /* 26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0001L, + /* 27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0001L, + /* 28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0001L, + /* 29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0001L, + /* 30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0001L, + /* 31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0001L, + /* 32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0001L, + /* 33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0001L, + /* 34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0001L, + /* 35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0001L, + /* 36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0001L, + /* 37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0001L, + /* 38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0001L, + /* 39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0001L, + /* 40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0001L, + /* 41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0001L, + /* 42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0001L, + /* 43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0001L, + /* 44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0001L, + /* 45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0001L, + /* 46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0001L, + /* 47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0001L, + /* 48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4001L, + /* 49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5001L, + /* 50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B201L, + /* 51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E81L, + /* 52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B621L, + /* 53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D5L, + /* 54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F64AL, + /* 55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL, + /* 56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL, + /* 57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L, + /* 58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L, + /* 59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL, + /* 60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L, + /* 61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL, + /* 62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL, + /* 63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL, + /* 64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL, + /* 65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL, + /* 66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL, + /* 67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L, + /* 68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L, + /* 69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL, + /* 70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L, + /* 71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L, + /* 72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L, + /* 73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L, + /* 74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L, + /* 75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L, + /* 76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L, + /* 77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L, + /* 78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL, + /* 79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L, + /* 80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L, + /* 81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L, + /* 82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L, + /* 83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L, + /* 84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL, + /* 85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL, + /* 86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L, + /* 87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL, + /* 88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L, + /* 89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL, + /* 90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L, + /* 91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL, + /* 92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L, + /* 93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL, + /* 94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L, + /* 95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L, + /* 96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L, + /* 97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L, + /* 98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L, + /* 99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L, + /* 100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L, + /* 101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL, + /* 102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L, + /* 103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL, + /* 104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L, + /* 105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL, + /* 106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL, + /* 107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L, + /* 108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L, + /* 109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L, + /* 110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L, + /* 111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L, + /* 112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL, + /* 113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L, + /* 114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L, + /* 115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L, + /* 116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L, + /* 117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L, + /* 118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL, + /* 119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL, + /* 120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL, + /* 121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL, + /* 122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L, + /* 123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL, + /* 124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L, + /* 125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L, + /* 126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L, + /* 127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L, + /* 128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL, + /* 129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L, + /* 130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL, + /* 131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL, + /* 132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL, + /* 133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL, + /* 134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L, + /* 135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L, + /* 136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL, + /* 137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL, + /* 138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L, + /* 139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL, + /* 140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL, + /* 141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L, + /* 142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL, + /* 143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL, + /* 144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL, + /* 145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L, + /* 146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L, + /* 147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL, + /* 148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L, + /* 149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL, + /* 150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL, + /* 151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL, + /* 152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL, + /* 153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L, + /* 154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL, + /* 155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL, + /* 156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L, + /* 157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL, + /* 158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L, + /* 159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL, + /* 160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L, + /* 161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L, + /* 162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L, + /* 163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L, + /* 164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL, + /* 165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L, + /* 166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL, + /* 167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L, + /* 168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L, + /* 169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L, + /* 170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL, + /* 171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L, + /* 172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L, + /* 173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL, + /* 174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL, + /* 175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL, + /* 176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L, + /* 177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L, + /* 178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL, + /* 179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L, + /* 180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L, + /* 181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L, + /* 182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L, + /* 183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L, + /* 184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL, + /* 185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL, + /* 186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL, + /* 187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL, + /* 188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL, + /* 189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL, + /* 190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L, + /* 191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL, + /* 192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L, + /* 193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L, + /* 194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL, + /* 195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L, + /* 196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L, + /* 197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L, + /* 198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL, + /* 199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L, + /* 200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L, + /* 201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L, + /* 202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL, + /* 203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L, + /* 204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL, + /* 205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL, + /* 206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L, + /* 207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL, + /* 208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L, + /* 209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L, + /* 210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL, + /* 211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L, + /* 212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L, + /* 213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L, + /* 214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL, + /* 215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL, + /* 216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L, + /* 217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL, + /* 218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L, + /* 219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L, + /* 220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L, + /* 221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L, + /* 222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L, + /* 223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L, + /* 224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL, + /* 225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L, + /* 226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L, + /* 227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL, + /* 228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L, + /* 229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L, + /* 230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL, + /* 231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L, + /* 232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L, + /* 233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L, + /* 234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L, + /* 235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL, + /* 236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL, + /* 237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L, + /* 238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L, + /* 239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L, + /* 240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL, + /* 241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL, + /* 242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL, + /* 243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L, + /* 244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL, + /* 245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL, + /* 246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL, + /* 247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L, + /* 248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L, + /* 249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L, + /* 250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L, + /* 251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L, + /* 252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L, + /* 253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL, + /* 254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L, + /* 255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L, + /* 256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL, + /* 257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL, + /* 258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L, + /* 259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL, + /* 260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L, + /* 261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL, + /* 262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L, + /* 263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL, + /* 264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L, + /* 265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL, + /* 266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L, + /* 267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L, + /* 268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL, + /* 269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL, + /* 270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL, + /* 271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L, + /* 272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L, + /* 273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L, + /* 274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L, + /* 275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L, + /* 276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L, + /* 277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L, + /* 278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL, + /* 279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL, + /* 280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL, + /* 281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L, + /* 282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL, + /* 283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L, + /* 284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L, + /* 285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L, + /* 286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L, + /* 287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL, + /* 288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L, + /* 289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL, + /* 290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L, + /* 291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL, + /* 292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL, + /* 293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L, + /* 294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL, + /* 295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L, + /* 296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L, + /* 297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L, + /* 298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL, + /* 299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L, + /* 300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L, + /* 301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL, + /* 302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L, + /* 303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL, + /* 304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL, + /* 305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L, + /* 306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L, + /* 307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL, + /* 308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L, + /* 309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L, + /* 310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L, + /* 311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L, + /* 312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L, + /* 313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L, + /* 314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL, + /* 315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L, + /* 316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL, + /* 317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL, + /* 318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L, + /* 319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L, + /* 320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L, + /* 321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L, + /* 322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L, + /* 323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL, + /* 324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, + }; + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/BasicChecker.java b/test/jdk/jdk/internal/math/ToDecimal/BasicChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/BasicChecker.java @@ -0,0 +1,16 @@ +class BasicChecker { + + static final boolean FAILURE_THROWS_EXCEPTION = true; + + static void assertTrue(boolean ok, String valueName) { + if (ok) { + return; + } + String msg = valueName + " is not correct"; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(msg); + } + System.err.println(msg); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalChecker.java @@ -0,0 +1,385 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import java.math.BigDecimal; +import java.util.Random; + +import static java.lang.Double.*; +import static java.lang.Long.numberOfTrailingZeros; +import static java.lang.Math.scalb; + +/* + * @test + * @bug 8202555 + * @author Raffaello Giulietti + */ +public class DoubleToDecimalChecker extends ToDecimalChecker { + + private static final int RANDOM_COUNT = 1_000_000; + + private static final int MIN_EXP = -323; + private static final int MAX_EXP = 309; + private static final int H = 17; + private static final int P = 53; + + private double v; + private final long originalBits; + + private DoubleToDecimalChecker(double v, String s) { + super(s); + this.v = v; + originalBits = doubleToRawLongBits(v); + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.doubleValue() == v; + } + + @Override + boolean recovers(String s) { + return parseDouble(s) == v; + } + + @Override + String hexBits() { + return String.format("0x%01X__%03X__%01X_%04X_%04X_%04X", + (int) (originalBits >>> 63) & 0x1, + (int) (originalBits >>> 52) & 0x7FF, + (int) (originalBits >>> 48) & 0xF, + (int) (originalBits >>> 32) & 0xFFFF, + (int) (originalBits >>> 16) & 0xFFFF, + (int) originalBits & 0xFFFF); + } + + @Override + int minExp() { + return MIN_EXP; + } + + @Override + int maxExp() { + return MAX_EXP; + } + + @Override + int maxLen10() { + return H; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == POSITIVE_INFINITY; + } + + @Override + void negate() { + v = -v; + } + + @Override + boolean isNegative() { + return originalBits < 0; + } + + @Override + boolean isNaN() { + return Double.isNaN(v); + } + + private static void toDec(double v) { + String s = Double.toString(v); + new DoubleToDecimalChecker(v, s).assertTrue(); + } + + private static void testExtremeValues() { + toDec(NEGATIVE_INFINITY); + toDec(-MAX_VALUE); + toDec(-MIN_NORMAL); + toDec(-MIN_VALUE); + toDec(-0.0); + toDec(0.0); + toDec(MIN_VALUE); + toDec(MIN_NORMAL); + toDec(MAX_VALUE); + toDec(POSITIVE_INFINITY); + toDec(NaN); + + /* + Quiet NaNs have the most significant bit of the mantissa as 1, + while signaling NaNs have it as 0. + Exercise 4 combinations of quiet/signaling NaNs and + "positive/negative" NaNs + */ + toDec(longBitsToDouble(0x7FF8_0000_0000_0001L)); + toDec(longBitsToDouble(0x7FF0_0000_0000_0001L)); + toDec(longBitsToDouble(0xFFF8_0000_0000_0001L)); + toDec(longBitsToDouble(0xFFF0_0000_0000_0001L)); + + /* + All values treated specially by Schubfach + */ + toDec(4.9E-324); + toDec(9.9E-324); + } + + /* + A few "powers of 10" are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf10() { + for (int e = MIN_EXP; e <= MAX_EXP; ++e) { + toDec(parseDouble("1e" + e)); + } + } + + /* + Many powers of 2 are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf2() { + for (double v = MIN_VALUE; v <= MAX_VALUE; v *= 2) { + toDec(v); + } + } + + /* + There are many doubles that are rendered incorrectly by the JDK. + While the renderings correctly round back to the original value, + they are longer than needed or are not the closest decimal to the double. + Here are just a very few examples. + */ + private static final String[] Anomalies = { + // JDK renders these, and others, with 18 digits! + "2.82879384806159E17", "1.387364135037754E18", + "1.45800632428665E17", + + // JDK renders these longer than needed. + "1.6E-322", "6.3E-322", + "7.3879E20", "2.0E23", "7.0E22", "9.2E22", + "9.5E21", "3.1E22", "5.63E21", "8.41E21", + + // JDK does not render these, and many others, as the closest. + "9.9E-324", "9.9E-323", + "1.9400994884341945E25", "3.6131332396758635E25", + "2.5138990223946153E25", + }; + + private static void testSomeAnomalies() { + for (String dec : Anomalies) { + toDec(parseDouble(dec)); + } + } + + /* + Values are from + Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" + tables 3 and 4 + */ + private static final double[] PaxsonSignificands = { + 8_511_030_020_275_656L, + 5_201_988_407_066_741L, + 6_406_892_948_269_899L, + 8_431_154_198_732_492L, + 6_475_049_196_144_587L, + 8_274_307_542_972_842L, + 5_381_065_484_265_332L, + 6_761_728_585_499_734L, + 7_976_538_478_610_756L, + 5_982_403_858_958_067L, + 5_536_995_190_630_837L, + 7_225_450_889_282_194L, + 7_225_450_889_282_194L, + 8_703_372_741_147_379L, + 8_944_262_675_275_217L, + 7_459_803_696_087_692L, + 6_080_469_016_670_379L, + 8_385_515_147_034_757L, + 7_514_216_811_389_786L, + 8_397_297_803_260_511L, + 6_733_459_239_310_543L, + 8_091_450_587_292_794L, + + 6_567_258_882_077_402L, + 6_712_731_423_444_934L, + 6_712_731_423_444_934L, + 5_298_405_411_573_037L, + 5_137_311_167_659_507L, + 6_722_280_709_661_868L, + 5_344_436_398_034_927L, + 8_369_123_604_277_281L, + 8_995_822_108_487_663L, + 8_942_832_835_564_782L, + 8_942_832_835_564_782L, + 8_942_832_835_564_782L, + 6_965_949_469_487_146L, + 6_965_949_469_487_146L, + 6_965_949_469_487_146L, + 7_487_252_720_986_826L, + 5_592_117_679_628_511L, + 8_887_055_249_355_788L, + 6_994_187_472_632_449L, + 8_797_576_579_012_143L, + 7_363_326_733_505_337L, + 8_549_497_411_294_502L, + }; + + private static final int[] PaxsonExponents = { + -342, + -824, + 237, + 72, + 99, + 726, + -456, + -57, + 376, + 377, + 93, + 710, + 709, + 117, + -1, + -707, + -381, + 721, + -828, + -345, + 202, + -473, + + 952, + 535, + 534, + -957, + -144, + 363, + -169, + -853, + -780, + -383, + -384, + -385, + -249, + -250, + -251, + 548, + 164, + 665, + 690, + 588, + 272, + -448, + }; + + private static void testPaxson() { + for (int i = 0; i < PaxsonSignificands.length; ++i) { + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); + } + } + + /* + Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0. + These are all exact doubles. + */ + private static void testLongs() { + for (int i = 10_000; i < 100_000; ++i) { + toDec(i * 1e15); + } + } + + /* + Tests all integers up to 1_000_000. + These are all exact doubles and exercise a fast path. + */ + private static void testInts() { + for (int i = 0; i <= 1_000_000; ++i) { + toDec(i); + } + } + + /* + Random doubles over the whole range + */ + private static void testRandom() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(longBitsToDouble(r.nextLong())); + } + } + + /* + Random doubles over the integer range [0, 2^52). + These are all exact doubles and exercise the fast path (except 0). + */ + private static void testRandomUnit() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(r.nextLong() & (1L << P - 1)); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-3 + */ + private static void testRandomMilli() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(r.nextLong() % 1_000_000_000_000_000_000L / 1e3); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-6 + */ + private static void testRandomMicro() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6); + } + } + + public static void main(String[] args) { + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testLongs(); + testRandom(); + testRandomUnit(); + testRandomMilli(); + testRandomMicro(); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalChecker.java @@ -0,0 +1,328 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import java.math.BigDecimal; +import java.util.Random; + +import static java.lang.Float.*; +import static java.lang.Integer.numberOfTrailingZeros; +import static java.lang.Math.scalb; + +/* + * @test + * @author Raffaello Giulietti + */ +public class FloatToDecimalChecker extends ToDecimalChecker { + + private static final int RANDOM_COUNT = 1_000_000; + + private static final int MIN_EXP = -44; + private static final int MAX_EXP = 39; + private static final int H = 9; + private static final int P = 24; + + private float v; + private final int originalBits; + + private FloatToDecimalChecker(float v, String s) { + super(s); + this.v = v; + originalBits = floatToRawIntBits(v); + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.floatValue() == v; + } + + @Override + String hexBits() { + return String.format("0x%01X__%02X__%02X_%04X", + (originalBits >>> 31) & 0x1, + (originalBits >>> 23) & 0xFF, + (originalBits >>> 16) & 0x7F, + originalBits & 0xFFFF); + } + + @Override + boolean recovers(String s) { + return parseFloat(s) == v; + } + + @Override + int minExp() { + return MIN_EXP; + } + + @Override + int maxExp() { + return MAX_EXP; + } + + @Override + int maxLen10() { + return H; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == POSITIVE_INFINITY; + } + + @Override + void negate() { + v = -v; + } + + @Override + boolean isNegative() { + return originalBits < 0; + } + + @Override + boolean isNaN() { + return Float.isNaN(v); + } + + private static void toDec(float v) { + String s = Float.toString(v); + new FloatToDecimalChecker(v, s).assertTrue(); + } + + private static void testExtremeValues() { + toDec(NEGATIVE_INFINITY); + toDec(-MAX_VALUE); + toDec(-MIN_NORMAL); + toDec(-MIN_VALUE); + toDec(-0.0f); + toDec(0.0f); + toDec(MIN_VALUE); + toDec(MIN_NORMAL); + toDec(MAX_VALUE); + toDec(POSITIVE_INFINITY); + toDec(NaN); + + /* + Quiet NaNs have the most significant bit of the mantissa as 1, + while signaling NaNs have it as 0. + Exercise 4 combinations of quiet/signaling NaNs and + "positive/negative" NaNs. + */ + toDec(intBitsToFloat(0x7FC0_0001)); + toDec(intBitsToFloat(0x7F80_0001)); + toDec(intBitsToFloat(0xFFC0_0001)); + toDec(intBitsToFloat(0xFF80_0001)); + + /* + All values treated specially by Schubfach + */ + toDec(1.4E-45F); + toDec(2.8E-45F); + toDec(4.2E-45F); + toDec(5.6E-45F); + toDec(7.0E-45F); + toDec(8.4E-45F); + toDec(9.8E-45F); + } + + /* + A few "powers of 10" are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf10() { + for (int e = MIN_EXP; e <= MAX_EXP; ++e) { + toDec(parseFloat("1e" + e)); + } + } + + /* + Many powers of 2 are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf2() { + for (float v = MIN_VALUE; v <= MAX_VALUE; v *= 2) { + toDec(v); + } + } + + /* + There are many floats that are rendered incorrectly by the JDK. + While the renderings correctly round back to the original value, + they are longer than needed or are not the closest decimal to the float. + Here are just a very few examples. + */ + private static final String[] Anomalies = { + // JDK renders these longer than needed. + "1.1754944E-38", "2.2E-44", + "1.0E16", "2.0E16", "3.0E16", "5.0E16", "3.0E17", + "3.2E18", "3.7E18", "3.7E16", "3.72E17", + + // JDK does not render this as the closest. + "9.9E-44", + }; + + private static void testSomeAnomalies() { + for (String dec : Anomalies) { + toDec(parseFloat(dec)); + } + } + + /* + Values are from + Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" + tables 16 and 17 + */ + private static final float[] PaxsonSignificands = { + 12_676_506, + 15_445_013, + 13_734_123, + 12_428_269, + 12_676_506, + 15_334_037, + 11_518_287, + 12_584_953, + 15_961_084, + 14_915_817, + 10_845_484, + 16_431_059, + + 16_093_626, + 9_983_778, + 12_745_034, + 12_706_553, + 11_005_028, + 15_059_547, + 16_015_691, + 8_667_859, + 14_855_922, + 14_855_922, + 10_144_164, + 13_248_074, + }; + + private static final int[] PaxsonExponents = { + -102, + -103, + 86, + -138, + -130, + -146, + -41, + -145, + -125, + -146, + -102, + -61, + + 69, + 25, + 104, + 72, + 45, + 71, + -99, + 56, + -82, + -83, + -110, + 95, + }; + + private static void testPaxson() { + for (int i = 0; i < PaxsonSignificands.length; ++i) { + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); + } + } + + /* + Tests all positive integers below 2^23. + These are all exact floats and exercise the fast path. + */ + private static void testInts() { + for (int i = 1; i < 1 << P - 1; ++i) { + toDec(i); + } + } + + /* + Random floats over the whole range. + */ + private static void testRandom() { + Random r = new Random(); + for (int i = 0; i < RANDOM_COUNT; ++i) { + toDec(intBitsToFloat(r.nextInt())); + } + } + + /* + All, really all, 2^32 possible floats. Takes between 90 and 120 minutes. + */ + private static void testAll() { + // Avoid wrapping around Integer.MAX_VALUE + int bits = Integer.MIN_VALUE; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(intBitsToFloat(bits)); + } + toDec(intBitsToFloat(bits)); + } + + /* + All 2^31 positive floats. + */ + private static void testPositive() { + // Avoid wrapping around Integer.MAX_VALUE + int bits = 0; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(intBitsToFloat(bits)); + } + toDec(intBitsToFloat(bits)); + } + + public static void main(String[] args) { + if (args.length > 0 && args[0].equals("all")) { + testAll(); + return; + } + if (args.length > 0 && args[0].equals("positive")) { + testPositive(); + return; + } + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testRandom(); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/ToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/ToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/ToDecimalChecker.java @@ -0,0 +1,375 @@ +/* + * Copyright 2018-2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import java.io.IOException; +import java.io.StringReader; +import java.math.BigDecimal; +import java.math.BigInteger; + +/* +A checker for the Javadoc specification. +It just relies on straightforward use of (expensive) BigDecimal arithmetic, +not optimized at all. + */ +abstract class ToDecimalChecker extends BasicChecker { + + // The string to check + private final String s; + + // The decimal parsed from s is c 10^q + private long c; + private int q; + + // The number of digits parsed from s: 10^(len10-1) <= c < 10^len10 + private int len10; + + ToDecimalChecker(String s) { + this.s = s; + } + + void assertTrue() { + if (isOK()) { + return; + } + String msg = "toString applied to the bits " + + hexBits() + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(msg); + } + System.err.println(msg); + } + + /* + Returns whether s syntactically meets the expected output of + toString. It is restricted to finite positive outputs. + It is an unusually long method but rather straightforward, too. + Many conditionals could be merged, but KISS here. + */ + private boolean parse(String t) { + try { + // first determine interesting boundaries in the string + StringReader r = new StringReader(t); + int ch = r.read(); + + int i = 0; + while (ch == '0') { + ++i; + ch = r.read(); + } + // i is just after zeroes starting the integer + + int p = i; + while ('0' <= ch && ch <= '9') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++p; + ch = r.read(); + } + // p is just after digits ending the integer + + int fz = p; + if (ch == '.') { + ++fz; + ch = r.read(); + } + // fz is just after a decimal '.' + + int f = fz; + while (ch == '0') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++f; + ch = r.read(); + } + // f is just after zeroes starting the fraction + + if (c == 0) { + len10 = 0; + } + int x = f; + while ('0' <= ch && ch <= '9') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++x; + ch = r.read(); + } + // x is just after digits ending the fraction + + int g = x; + if (ch == 'E') { + ++g; + ch = r.read(); + } + // g is just after an exponent indicator 'E' + + int ez = g; + if (ch == '-') { + ++ez; + ch = r.read(); + } + // ez is just after a '-' sign in the exponent + + int e = ez; + while (ch == '0') { + ++e; + ch = r.read(); + } + // e is just after zeroes starting the exponent + + int z = e; + while ('0' <= ch && ch <= '9') { + q = 10 * q + (ch - '0'); + if (q < 0) { + return false; + } + ++z; + ch = r.read(); + } + // z is just after digits ending the exponent + + // No other char after the number + if (z != t.length()) { + return false; + } + + // The integer must be present + if (p == 0) { + return false; + } + + // The decimal '.' must be present + if (fz == p) { + return false; + } + + // The fraction must be present + if (x == fz) { + return false; + } + + // The fraction is not 0 or it consists of exactly one 0 + if (f == x && f - fz > 1) { + return false; + } + + // Plain notation, no exponent + if (x == z) { + // At most one 0 starting the integer + if (i > 1) { + return false; + } + + // If the integer is 0, at most 2 zeroes start the fraction + if (i == 1 && f - fz > 2) { + return false; + } + + // The integer cannot have more than 7 digits + if (p > 7) { + return false; + } + + q = fz - x; + + // OK for plain notation + return true; + } + + // Computerized scientific notation + + // The integer has exactly one nonzero digit + if (i != 0 || p != 1) { + return false; + } + + // + // There must be an exponent indicator + if (x == g) { + return false; + } + + // There must be an exponent + if (ez == z) { + return false; + } + + // The exponent must not start with zeroes + if (ez != e) { + return false; + } + + if (g != ez) { + q = -q; + } + + // The exponent must not lie in [-3, 7) + if (-3 <= q && q < 7) { + return false; + } + + q += fz - x; + + // OK for computerized scientific notation + return true; + } catch (IOException ex) { + // An IOException on a StringReader??? Please... + return false; + } + } + + private boolean isOK() { + if (isNaN()) { + return s.equals("NaN"); + } + String t = s; + if (isNegative()) { + if (s.isEmpty() || s.charAt(0) != '-') { + return false; + } + negate(); + t = s.substring(1); + } + if (isInfinity()) { + return t.equals("Infinity"); + } + if (isZero()) { + return t.equals("0.0"); + } + if (!parse(t)) { + return false; + } + if (len10 < 2) { + c *= 10; + q -= 1; + len10 += 1; + } + if (2 > len10 || len10 > maxLen10()) { + return false; + } + + // The exponent is bounded + if (minExp() > q + len10 || q + len10 > maxExp()) { + return false; + } + + // s must recover v + try { + if (!recovers(t)) { + return false; + } + } catch (NumberFormatException e) { + return false; + } + + // Get rid of trailing zeroes, still ensuring at least 2 digits + while (len10 > 2 && c % 10 == 0) { + c /= 10; + q += 1; + len10 -= 1; + } + + if (len10 > 2) { + // Try with a shorter number less than v... + if (recovers(BigDecimal.valueOf(c / 10, -q - 1))) { + return false; + } + + // ... and with a shorter number greater than v + if (recovers(BigDecimal.valueOf(c / 10 + 1, -q - 1))) { + return false; + } + } + + // Try with the decimal predecessor... + BigDecimal dp = c == 10 ? + BigDecimal.valueOf(99, -q + 1) : + BigDecimal.valueOf(c - 1, -q); + if (recovers(dp)) { + BigDecimal bv = toBigDecimal(); + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); + if (deltav.signum() >= 0) { + return true; + } + BigDecimal delta = dp.subtract(bv); + if (delta.signum() >= 0) { + return false; + } + int cmp = deltav.compareTo(delta); + return cmp > 0 || cmp == 0 && (c & 0x1) == 0; + } + + // ... and with the decimal successor + BigDecimal ds = BigDecimal.valueOf(c + 1, -q); + if (recovers(ds)) { + BigDecimal bv = toBigDecimal(); + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); + if (deltav.signum() <= 0) { + return true; + } + BigDecimal delta = ds.subtract(bv); + if (delta.signum() <= 0) { + return false; + } + int cmp = deltav.compareTo(delta); + return cmp < 0 || cmp == 0 && (c & 0x1) == 0; + } + + return true; + } + + abstract BigDecimal toBigDecimal(); + + abstract boolean recovers(BigDecimal b); + + abstract boolean recovers(String s); + + abstract String hexBits(); + + abstract int minExp(); + + abstract int maxExp(); + + abstract int maxLen10(); + + abstract boolean isZero(); + + abstract boolean isInfinity(); + + abstract void negate(); + + abstract boolean isNegative(); + + abstract boolean isNaN(); + +} From alexander.matveev at oracle.com Thu Mar 7 01:10:55 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 6 Mar 2019 17:10:55 -0800 Subject: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty Message-ID: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Added custom action to check installation folder and display confirmation dialog to ask user to continue installation if destination folder is not empty. This is same behavior and confirmation message as for .exe. [1] https://bugs.openjdk.java.net/browse/JDK-8214566 [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ Thanks, Alexander From henry.jen at oracle.com Thu Mar 7 01:41:35 2019 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 6 Mar 2019 17:41:35 -0800 Subject: RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris) In-Reply-To: <30e94474-4d86-dc2b-d255-2cbb042b7aee@oracle.com> References: <30CF8EDF-A04E-43B3-A45B-1B155752D0C2@oracle.com> <30e94474-4d86-dc2b-d255-2cbb042b7aee@oracle.com> Message-ID: <15E3F88B-D43E-4571-8942-7932774364DA@oracle.com> Thanks, Roger. Cheers, Henry > On Mar 1, 2019, at 10:27 AM, Roger Riggs wrote: > > Hi Henry, > > The change looks ok, Reviewed. > > (I'm not that familiar with Solaris). > > Thanks, Roger > > > > On 3/1/19 10:45 AM, Henry Jen wrote: >> Ping! >> >> Any thought on this webrev restore the way for Solaris LD_LIBRARY_PATH_64 handling? >> >> Cheers, >> Henry >> >> >>> On Feb 13, 2019, at 9:37 AM, Henry Jen wrote: >>> >>> Hi, >>> >>> Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when LD_LIBRARY_PATH_64 is set, we setup LD_LIBRARY_PATH based on that value and unset LD_LIBRARY_PATH_64 in the relaunched process. >>> >>> Same approach was used before JDK-6367077, and the override is expected behavior on Solaris 64-bit as stated in Solaris 64-bit Developer's Guide[2], >>> "The 64-bit dynamic linker's search path can be completely overridden using the LD_LIBRARY_PATH_64 environment variable." >>> >>> Cheers, >>> Henry >>> >>> [1] http://cr.openjdk.java.net/~henryjen/8217216/0/webrev/ >>> [2] https://docs.oracle.com/cd/E19455-01/806-0477/dev-env-7/index.html >>> > From peter.levart at gmail.com Thu Mar 7 08:41:14 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 7 Mar 2019 09:41:14 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: Hi, I see this is already discussed in the "Alternatives" section of the proposal (sorry for not reading this through before asking)... But I don't quite understand the following part that talks about making IterableOnce a supertype of Iterable: "However, doing so would require weakening the contract of IterableOnce. To allow Iterable to be a subtype, the semantics of IterableOnce would need to change to allow iteration once and possibly more, instead of the currently proposed at-most-once semantics. Having IterableOnce be a subtype allows the specification to make a much stronger assertion." Why would that require "weakening the contract of IterableOnce" ? Because if IterableOnce was specified to throw exception on the 2nd and subsequent invocations, some instances (those implementing Iterable) would not respect that? I see this as less evil than doing the other way around. How many situations will rely on IterableOnce to throw exception vs. how many situations will rely on Iterable to allow multiple invocations? But I agree with assessment that changing language to retrofit foreach loop to work with a supertype of Iterable (although it seems a backwards compatible change) would be too costly for this feature. And there are already other similar decisions made in API design of Java. For example Collections framework with immutable vs. mutable collections. This distinction is not even encoded in type(s). But this API was designed from the beginning with that in mind and therefore most code consuming collection types documents how it uses the passed-in collections (whether it only reads from them or also modifies them). Consumers of Iterable(s) did not have that requirement from the beginning. If they had, we would not need a special type to mark the distinction. The specification of Iterable could simply state that: "There are two kinds of Iterable(s) in this world: those that may be iterated only once and those that can be iterated multiple times"... OTOH, having a separate type for only-once iterables would only help identify instances of them, but would not help in documenting the consumers. Consumers would still have to document this via javadoc. I would not recommend consumers to take parameters of type IterableOnce if IterableOnce was a subtype of Iterable, because they would unnecessarily restrict themselves to consume just the less capable instances. In addition, introduction of IterableOnce as a subtype of Iterable does not help in (re)specifying the Iterable type. There will be two kinds of Iterable(s) in the new world regardless of that. There is a benefit in the runtime though. The code can decide what to do with the passed-in Iterable depending on it implementing IterableOnce or not. Much like what RandomAccess interface does to List(s). The code can decide to dump the iterable into a List and iterate the List multiple times if the Iterable implements IterableOnce or do direct multiple iteration on the passed-in Iterable if it doesnt. Regards, Peter On 3/6/19 4:50 PM, Peter Levart wrote: > Hi Stuart, > > According to Liskov substitution principle: > > ??? Subtype Requirement: Let ? ( x ) be a property provable about > objects x of type T. Then ? ( y ) should be true for objects y of type > S where S is a subtype of T. > > > Let ? ( x ) for objects x of type Iterable be: "x.iterator() may be > invoked multiple times, each time starting new iteration". > > This clearly holds. > > Does ? ( y ) hold for objects y of type IterableOnce? Clearly not. > > In this respect Iterable should be a subtype of IterableOnce and > foreach loop should be retrofitted to work with IterableOnce. > > What do you think? > > Regards, Peter > > On 3/1/19 3:43 AM, Stuart Marks wrote: >> Hi all, >> >> Please review and comment on this proposal to allow Stream instances >> to be used in enhanced-for ("for-each") loops. >> >> Abstract >> >> Occasionally it's useful to iterate a Stream using a conventional >> loop. However, the Stream interface doesn't implement Iterable, and >> therefore streams cannot be used with the enhanced-for statement. >> This is a proposal to remedy that situation by introducing a new >> interface IterableOnce that is a subtype of Iterable, and then >> retrofitting the Stream interface to implement it. Other JDK classes >> will also be retrofitted to implement IterableOnce. >> >> Full Proposal: >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html >> >> Bug report: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8148917 >> >> Webrev: >> >> ??? http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ >> >> Note, this changeset isn't ready to push yet. In particular, it has >> no tests yet. However, the implementation is so simple that I figured >> I should include it. Comments on the specification wording are also >> welcome. >> >> Thanks, >> >> s'marks > From peter.levart at gmail.com Thu Mar 7 09:00:30 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 7 Mar 2019 10:00:30 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: On 3/7/19 9:41 AM, Peter Levart wrote: > There is a benefit in the runtime though. The code can decide what to > do with the passed-in Iterable depending on it implementing > IterableOnce or not. Much like what RandomAccess interface does to > List(s). The code can decide to dump the iterable into a List and > iterate the List multiple times if the Iterable implements > IterableOnce or do direct multiple iteration on the passed-in Iterable > if it doesn't. Expanding on this further, there could be help for multi-pass iteration in the Iterable(Once) interfaces. For example: public interface Iterable { ??? Iterator iterator(); ??? default Iterable toMultipassIterable() { ??????? return this; ??? } } and then: public interface IterableOnce extends Iterable { ??? @Override ??? default Iterable toMultipassIterable() { ??????? List list = new ArrayList<>(); ??????? for (T t : this) { ??????????? list.add(t); ??????? } ??????? return list; ??? } } ... so any new code that needs multiple passes can do so easily. Regards, Peter From brian.burkhalter at oracle.com Thu Mar 7 09:33:18 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Mar 2019 09:33:18 +0000 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> Message-ID: <6C095966-0356-44DB-B34E-A696FE637094@oracle.com> The corresponding webrev may be viewed at [1]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/4511638/webrev.01/ > On Mar 6, 2019, at 7:31 PM, raffaello.giulietti at gmail.com wrote: > > the latest version of the patch, replacing the one found at [1]. > In the next days, my sponsor Brian Burkhalter will publish it as a webrev. From brian.burkhalter at oracle.com Thu Mar 7 09:39:51 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Mar 2019 09:39:51 +0000 Subject: 6504660: HPI panic callback is dead code Message-ID: Please review this fix [1] to remove dead code [2]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/6504660/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-6504660 From claes.redestad at oracle.com Thu Mar 7 09:43:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 7 Mar 2019 10:43:45 +0100 Subject: 6504660: HPI panic callback is dead code In-Reply-To: References: Message-ID: <3457f784-4e86-5b31-c947-29fce8687cee@oracle.com> Hi Brian, looks fine! Thanks! /Claes On 2019-03-07 10:39, Brian Burkhalter wrote: > Please review this fix [1] to remove dead code [2]. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/6504660/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-6504660 > From aph at redhat.com Thu Mar 7 10:04:37 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Mar 2019 10:04:37 +0000 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> Message-ID: <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> On 3/6/19 7:31 PM, raffaello.giulietti at gmail.com wrote: > the latest version of the patch, replacing the one found at [1]. > In the next days, my sponsor Brian Burkhalter will publish it as a webrev. I still believe you'd be better off defining an unsigned multiplyHigh than all that messing about with shifts and masks in rop(). -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From brian.burkhalter at oracle.com Thu Mar 7 10:10:33 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Mar 2019 10:10:33 +0000 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> Message-ID: <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> > On Mar 7, 2019, at 10:04 AM, Andrew Haley wrote: > > On 3/6/19 7:31 PM, raffaello.giulietti at gmail.com wrote: >> the latest version of the patch, replacing the one found at [1]. >> In the next days, my sponsor Brian Burkhalter will publish it as a webrev. > > I still believe you'd be better off defining an unsigned multiplyHigh than > all that messing about with shifts and masks in rop(). There is in fact an open issue for unsigned multiplyHigh: https://bugs.openjdk.java.net/browse/JDK-8188044 Brian From amaembo at gmail.com Thu Mar 7 10:33:20 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 7 Mar 2019 17:33:20 +0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Message-ID: Hello, Remi! It actually works thanks to auto-boxing/unboxing. E.g. this implementation works: static Iterable range(int from, int to) { return () -> new PrimitiveIterator.OfInt() { int cur = from; @Override public int nextInt() { if (cur >= to) { throw new NoSuchElementException(); } return cur++; } @Override public boolean hasNext() { return cur < to; } }; } public static void main(String[] args) { for(int i : range(0, 100)) { System.out.println(i); } } It correctly compiles and prints numbers from 0 to 99. As IntStream extends BaseStream and BaseStream> defines Iterator iterator(), it would be no problem with using IntStream.range in such code pattern were BaseStream extends IterableOnce. Of course this produces unnecessary garbage, as I said. With best regards, Tagir Valeev. On Wed, Mar 6, 2019 at 7:37 PM Remi Forax wrote: > > Hi Tagir, > try to do it now and you will see that you can't, because you can not write Iterable yet. > Once we will get generics over value types, it will be a no-brainer. > > R?mi > > ----- Mail original ----- > > De: "Tagir Valeev" > > ?: "Stuart Marks" > > Cc: "core-libs-dev" > > Envoy?: Mercredi 6 Mars 2019 11:10:41 > > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > > > Hello! > > > > By the way one of the painful code patterns in modern Java is `for(int > > i = 0; i > newbies and prone to errors as the variable need to be repeated three > > times. Also the variable is not effectively final, despite it never > > changes within the loop body, so could have been considered as > > redeclared on every loop iteration (like in for-each). With the new > > proposal it's possible to write `for(int i : range(0, bound).boxed())` > > (assuming import static j.u.s.IntStream.range), which looks much > > better, though it has obvious performance drawback. Moving > > IterableOnce to BaseStream would enable to use `for(int i : range(0, > > bound))` which looks even better, though again we have plenty of > > garbage (but considerably less than in previous case!). I wonder > > whether Java could evolve to the point where such kind of code would > > be a recommended way to iterate over subsequent integer values without > > any performance handicap. > > > > With best regards, > > Tagir Valeev. > > > > On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: > >> > >> Hi all, > >> > >> Please review and comment on this proposal to allow Stream instances to be used > >> in enhanced-for ("for-each") loops. > >> > >> Abstract > >> > >> Occasionally it's useful to iterate a Stream using a conventional loop. However, > >> the Stream interface doesn't implement Iterable, and therefore streams cannot be > >> used with the enhanced-for statement. This is a proposal to remedy that > >> situation by introducing a new interface IterableOnce that is a subtype of > >> Iterable, and then retrofitting the Stream interface to implement it. Other JDK > >> classes will also be retrofitted to implement IterableOnce. > >> > >> Full Proposal: > >> > >> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > >> > >> Bug report: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8148917 > >> > >> Webrev: > >> > >> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > >> > >> Note, this changeset isn't ready to push yet. In particular, it has no tests > >> yet. However, the implementation is so simple that I figured I should include > >> it. Comments on the specification wording are also welcome. > >> > >> Thanks, > >> > > > s'marks From nishit.jain at oracle.com Thu Mar 7 11:51:04 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 7 Mar 2019 17:21:04 +0530 Subject: =?UTF-8?Q?Re=3a_=3ci18n_dev=3e_=5b13=5d_RFR_8217254=2c_8217721=3a_C?= =?UTF-8?Q?ompactNumberFormat=e2=80=8b=28=29_constructor_does_not_comply_wit?= =?UTF-8?Q?h_spec_and_format=e2=80=8b=28=29_method_spec_for_IAEx_is_not_comp?= =?UTF-8?Q?laint?= In-Reply-To: <8d2ca26c-fd85-87e7-3600-de36434612ed@oracle.com> References: <8d2ca26c-fd85-87e7-3600-de36434612ed@oracle.com> Message-ID: Thanks Naoto, Updated: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.01/ Regards, Nishit Jain On 06-03-2019 23:24, naoto.sato at oracle.com wrote: > Hi Nishit, > > Just one comment on j.t.CompactNumberFormat.java. At line 425, Null > check can be done at the top of the method, as a parameter check, so > that all the unnecessary "if-elseif" can be avoided. Others look good. > > Naoto > > > On 3/6/19 3:56 AM, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8217254 and JDK-8217721 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217254 >> ????? https://bugs.openjdk.java.net/browse/JDK-8217721 >> >> Webrev: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.00/ >> >> >> Issue: The exception thrown by constructor and format() method was >> not compliant with the specification >> Fix: Updated the constructor and format method to throw exception as >> per the specification >> >> Regards, >> Nishit Jain >> From andy.herrick at oracle.com Thu Mar 7 12:42:50 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 7 Mar 2019 07:42:50 -0500 Subject: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty In-Reply-To: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> References: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> Message-ID: <9f7f5d94-b617-ed65-9d2c-aee0bfd7ee16@oracle.com> Looks good to me: You may want to get approval from build team for makefile changes. /Andy On 3/6/2019 8:10 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Added custom action to check installation folder and display > confirmation dialog to ask user to continue installation if > destination folder is not empty. This is same behavior and > confirmation message as for .exe. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214566 > > [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ > > Thanks, > Alexander From rachna.goel at oracle.com Thu Mar 7 12:50:44 2019 From: rachna.goel at oracle.com (Rachna Goel) Date: Thu, 7 Mar 2019 18:20:44 +0530 Subject: [13] RFR: 8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time In-Reply-To: <42f5f5f7-e8bf-9d12-7bbc-0429c9312ad7@oracle.com> References: <42f5f5f7-e8bf-9d12-7bbc-0429c9312ad7@oracle.com> Message-ID: <49c97d60-e4ee-e8b3-2ef4-936b0420a9df@oracle.com> Hi Naoto, This fix looks good to me. Thanks, Rachna On 3/6/19 4:50 AM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8218948 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8218948/webrev.00/ > > This is a follow on fix to 8217366. There are several root causes > included in this bug, when the runtime supplements missing display > names in non-US locales :- > > - Retrieve the names for the requested id first, before it maps to the > canonical id, and on canonicalizing the id, use unique way > (canonicalTZID()) to canonicalize. > > - Retrieve the names in the same manner, between > DateFormatSymbols.getZoneStrings() and TimeZone.getDisplayName(). > > - Correctly map the Chinese locales between JDK and CLDR, in terms of > Simplified/Traditional scripts. > > Naoto -- Thanks, Rachna From erik.joelsson at oracle.com Thu Mar 7 14:52:40 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Mar 2019 06:52:40 -0800 Subject: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty In-Reply-To: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> References: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> Message-ID: <82961966-139a-96d4-1049-96857f8ff5fd@oracle.com> Hello Alexander, A few notes: $(call SET_SHARED_LIBRARY_ORIGIN) and TOOLCHAIN_LINK_CXX have no effect on Windows, so should be removed to avoid confusion in the future. This new library does not link with libjava so I see no need to add that prerequisite declaration. /Erik On 2019-03-06 17:10, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Added custom action to check installation folder and display > confirmation dialog to ask user to continue installation if > destination folder is not empty. This is same behavior and > confirmation message as for .exe. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214566 > > [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ > > Thanks, > Alexander From sean.mullan at oracle.com Thu Mar 7 15:02:39 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 7 Mar 2019 10:02:39 -0500 Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com> References: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com> Message-ID: On 3/5/19 7:50 PM, Weijun Wang wrote: > The fix looks fine to me. > > However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy? If you specify the UNC policy file as just a file pathname (and not a "file:" URL), ex: -Djava.security.policy=\\host\Users\duke\java.policy In this case, the Policy implementation converts the canonical form of the path into an encoded "file:" URL (see sun.net.www.ParseUtil.fileToEncodedURL) and the URL works when passed to PolicyUtil.getInputStream (which decodes it into a path and opens it with FileInputStream). However, if you specify the UNC policy file as a "file:" URL, it depends on the user getting the proper URL encoding (escaped characters, etc) right. For example: -Djava.security.policy=file:\\host\Users\duke\java.policy will not work because it ignores the hostname and tries to load \Users\duke\java.policy. However: -Djava.security.policy=file:\\\\host\Users\duke\java.policy does work. I'm not entirely sure, but I think it has something to do with escaping the leading backslashes so that it is not considered a host part of the URL. There's possibly some unnecessary overhead encoding the path into a URL and decoding back again, but I don't want to tinker with it unless there is a known issue. --Sean > > I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer. > > Thanks, > Max > >> On Mar 6, 2019, at 3:53 AM, Sean Mullan wrote: >> >> Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError. >> >> The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard). >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/ >> bugid: https://bugs.openjdk.java.net/browse/JDK-8218618 >> >> --Sean > From mandy.chung at oracle.com Thu Mar 7 15:38:48 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Mar 2019 15:38:48 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: Hi Adam, On 3/6/19 8:28 AM, Adam Farley8 wrote: > Hi Mandy, > > The webrev has been updated with the new test: > http://cr.openjdk.java.net/~afarley/8216558/webrev/ Looks okay although I think the test adds isFinal check for the new test case is meant to be say static final field. > Note that I included a handful of small improvements, and that the final > fields are all setAccessible by default, because (a) it seemed cleaner > than adding a new control bit, and (b) nobody is meant to be changing > final fields anyway. I'm not sure what you tried to say about "nobody is meant to be changing final fields". There should be tests covering all cases. In any case, since you chose to modify MethodHandlesGeneralTest, it's okay to add tests for the static final fields which is what this fix is about. I created a JBS issue to add test cases for the instance final fields: https://bugs.openjdk.java.net/browse/JDK-8220282 FYI. I have a patch for it and will send out for review. http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8220282/webrev.00/ Mandy From mandy.chung at oracle.com Thu Mar 7 16:10:41 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Mar 2019 16:10:41 +0000 Subject: Review Request: JDK-8220282 Add MethodHandle tests on accessing final fields Message-ID: <8fb939e4-afbc-6711-1d16-b0c7f34d0a10@oracle.com> This adds the test cases of setter on final fields to ensure no write access to final fields with the exception on unreflectSetter on Field of an instance final field whose accessible flag is set once JDK-8216558 is resolved. Webrev at: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8220282/webrev.00/ Mandy From adam.farley at uk.ibm.com Thu Mar 7 17:44:13 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 7 Mar 2019 17:44:13 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: Hi Mandy, Since you have created a new work item to cover the test work, do let me know if you want the test code removed from the webrev for the original issue. Also, by "nobody is meant to be changing final fields anyway", I was explaining my decision to setAccessible(true) on the final fields by default, rather than setting it via a control bit as you suggested. Seemed to save code while exposing us to minimal risk, because the field is meant to be immutable (final). Lastly, I'm sorry to see you weren't happy with the quality of my test code. Your changes seem much larger in scale, and quite different to my changes. Could you explain the benefits of your approach, vs simply adding non-static final fields to my code? No judgement, just looking to learn here. :) Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 07/03/2019 15:38:48: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 07/03/2019 15:40 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > > On 3/6/19 8:28 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > The webrev has been updated with the new test: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8216558_webrev_&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jQfLigt7_Y_u9yffi19X55OptDevspJHn76z12Z_XZI&s=93WLChJClpzd43Gy4CUKWGrdi5AZcRXLyAn93S1irj8&e= > > Looks okay although I think the test adds isFinal check for the new test > case is meant to be say static final field. > > > Note that I included a handful of small improvements, and that the final > > fields are all setAccessible by default, because (a) it seemed cleaner > > than adding a new control bit, and (b) nobody is meant to be changing > > final fields anyway. > > I'm not sure what you tried to say about "nobody is meant to be changing > final fields". There should be tests covering all cases. > > In any case, since you chose to modify MethodHandlesGeneralTest, it's > okay to add tests for the static final fields which is what this fix > is about. I created a JBS issue to add test cases for the instance > final fields: > https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8220282&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jQfLigt7_Y_u9yffi19X55OptDevspJHn76z12Z_XZI&s=fIIn31odNd2SEKaj2zUF4qc03FJhqnQzROj09QrS0Jw&e= > > FYI. I have a patch for it and will send out for review. > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Emchung_jdk13_webrevs_8220282_webrev. > 00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jQfLigt7_Y_u9yffi19X55OptDevspJHn76z12Z_XZI&s=YhNHbETeM1kVO2frjr6aXSMgZCc69B3kDqVEiOHVSCg&e= > > Mandy > 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 Thu Mar 7 17:47:18 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 7 Mar 2019 09:47:18 -0800 Subject: =?UTF-8?Q?Re=3a_=3ci18n_dev=3e_=5b13=5d_RFR_8217254=2c_8217721=3a_C?= =?UTF-8?Q?ompactNumberFormat=e2=80=8b=28=29_constructor_does_not_comply_wit?= =?UTF-8?Q?h_spec_and_format=e2=80=8b=28=29_method_spec_for_IAEx_is_not_comp?= =?UTF-8?Q?laint?= In-Reply-To: References: <8d2ca26c-fd85-87e7-3600-de36434612ed@oracle.com> Message-ID: <81e4cf9f-404c-51fc-ae3b-c2b2cfdde6fa@oracle.com> Looks good. Naoto On 3/7/19 3:51 AM, Nishit Jain wrote: > Thanks Naoto, > > Updated: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.01/ > > Regards, > Nishit Jain > On 06-03-2019 23:24, naoto.sato at oracle.com wrote: >> Hi Nishit, >> >> Just one comment on j.t.CompactNumberFormat.java. At line 425, Null >> check can be done at the top of the method, as a parameter check, so >> that all the unnecessary "if-elseif" can be avoided. Others look good. >> >> Naoto >> >> >> On 3/6/19 3:56 AM, Nishit Jain wrote: >>> Hi, >>> >>> Please review the fix for JDK-8217254 and JDK-8217721 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217254 >>> ????? https://bugs.openjdk.java.net/browse/JDK-8217721 >>> >>> Webrev: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.00/ >>> >>> >>> Issue: The exception thrown by constructor and format() method was >>> not compliant with the specification >>> Fix: Updated the constructor and format method to throw exception as >>> per the specification >>> >>> Regards, >>> Nishit Jain >>> > From aph at redhat.com Thu Mar 7 18:01:06 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Mar 2019 18:01:06 +0000 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> Message-ID: <6df01f14-dd0a-6319-50ef-7dd9228bd355@redhat.com> On 3/7/19 10:10 AM, Brian Burkhalter wrote: > >> On Mar 7, 2019, at 10:04 AM, Andrew Haley wrote: >> >> I still believe you'd be better off defining an unsigned multiplyHigh than >> all that messing about with shifts and masks in rop(). > > There is in fact an open issue for unsigned multiplyHigh: > > https://bugs.openjdk.java.net/browse/JDK-8188044 Do you want to do it? If not I will. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From lance.andersen at oracle.com Thu Mar 7 18:08:32 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 7 Mar 2019 13:08:32 -0500 Subject: Review Request: JDK-8220282 Add MethodHandle tests on accessing final fields In-Reply-To: <8fb939e4-afbc-6711-1d16-b0c7f34d0a10@oracle.com> References: <8fb939e4-afbc-6711-1d16-b0c7f34d0a10@oracle.com> Message-ID: <17D7C893-9AC1-4B69-80A2-D96E23450C79@oracle.com> Looks ok Mandy > On Mar 7, 2019, at 11:10 AM, Mandy Chung wrote: > > This adds the test cases of setter on final fields to ensure no write > access to final fields with the exception on unreflectSetter on Field > of an instance final field whose accessible flag is set once > JDK-8216558 is resolved. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8220282/webrev.00/ > > > 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 raffaello.giulietti at gmail.com Thu Mar 7 19:16:58 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 7 Mar 2019 20:16:58 +0100 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> Message-ID: <869b3807-bce5-eccd-0efe-9bbf01780c41@gmail.com> On 2019-03-07 11:10, Brian Burkhalter wrote: > >> On Mar 7, 2019, at 10:04 AM, Andrew Haley > > wrote: >> >> On 3/6/19 7:31 PM,raffaello.giulietti at gmail.com >> wrote: >>> the latest version of the patch, replacing the one found at [1]. >>> In the next days, my sponsor Brian Burkhalter will publish it as a >>> webrev. >> >> I still believe you'd be better off defining an unsigned multiplyHigh than >> all that messing about with shifts and masks in rop(). > > There is in fact an open issue for unsigned multiplyHigh: > > https://bugs.openjdk.java.net/browse/JDK-8188044 > > Brian Hi Andrew, a couple of weeks ago I tried to refactor the code assuming the existence of unsignedMultiplyHigh() (either as some future intrinsic or as a Java method) and a wider representations of g with either 127 or 128 bits: g = g1 2^64 + g0 with either 2^63 <= g1 < 2^64 (128 bits) or 2^62 <= g1 < 2^63 (127 bits) Unfortunately, the resulting code of rop() isn't any simpler. That's because then an intermediate sum can overflow the 64 bits of a long. As a consequence, there's need for more elaborate logic to determine the carry and other slightly more complicated computations to assemble the final result. All in all, the resulting code has more operations and looks longer. I tried with four variants. In addition to the mults, which are needed anyway, the current code has 3 shifts, 3 adds, 2 bitwise logicals. As mentioned, I couldn't come up with a solution that would help reducing this count. I would be glad to hear of better solutions and to write down a mathematical proof for the document. In the meantime I got rid of the last division. There's no division at all in the whole algorithm. Greetings Raffaello From lance.andersen at oracle.com Thu Mar 7 19:20:54 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 7 Mar 2019 14:20:54 -0500 Subject: [13] RFR: 8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time In-Reply-To: <42f5f5f7-e8bf-9d12-7bbc-0429c9312ad7@oracle.com> References: <42f5f5f7-e8bf-9d12-7bbc-0429c9312ad7@oracle.com> Message-ID: <718B49AA-9D7B-4A46-98F4-9FB4E8DFCFF1@oracle.com> Hi Naoto, Sorry for the late review, It looks good to me > On Mar 5, 2019, at 6:20 PM, Naoto Sato wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8218948 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8218948/webrev.00/ > > This is a follow on fix to 8217366. There are several root causes included in this bug, when the runtime supplements missing display names in non-US locales :- > > - Retrieve the names for the requested id first, before it maps to the canonical id, and on canonicalizing the id, use unique way (canonicalTZID()) to canonicalize. > > - Retrieve the names in the same manner, between DateFormatSymbols.getZoneStrings() and TimeZone.getDisplayName(). > > - Correctly map the Chinese locales between JDK and CLDR, in terms of Simplified/Traditional scripts. > > 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 alexander.matveev at oracle.com Thu Mar 7 22:52:56 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 7 Mar 2019 14:52:56 -0800 Subject: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty In-Reply-To: <82961966-139a-96d4-1049-96857f8ff5fd@oracle.com> References: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> <82961966-139a-96d4-1049-96857f8ff5fd@oracle.com> Message-ID: Hi Erik, http://cr.openjdk.java.net/~almatvee/8214566/webrev.01/ - Removed $(call SET_SHARED_LIBRARY_ORIGIN), TOOLCHAIN_LINK_CXX and linking with libjava. Thanks, Alexander On 3/7/2019 6:52 AM, Erik Joelsson wrote: > Hello Alexander, > > A few notes: > > $(call SET_SHARED_LIBRARY_ORIGIN) and TOOLCHAIN_LINK_CXX have no > effect on Windows, so should be removed to avoid confusion in the future. > > This new library does not link with libjava so I see no need to add > that prerequisite declaration. > > /Erik > > On 2019-03-06 17:10, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Added custom action to check installation folder and display >> confirmation dialog to ask user to continue installation if >> destination folder is not empty. This is same behavior and >> confirmation message as for .exe. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8214566 >> >> [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ >> >> Thanks, >> Alexander From mandy.chung at oracle.com Thu Mar 7 23:17:15 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Mar 2019 23:17:15 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> On 3/7/19 9:44 AM, Adam Farley8 wrote: > Hi Mandy, > > Since you have created a new work item to cover the test work, do let > me know if you want the test code removed from the webrev for the > original issue. You push what you have. Your fix should come with a regression test. Please make sure you do jdk-submit to verify the test work. > Also, by "nobody is meant to be changing final fields anyway", I was > explaining my decision to setAccessible(true) on the final fields by > default, rather than setting it via a control bit as you suggested. > Seemed to save code while exposing us to minimal risk, because the > field is meant to be immutable (final). > > Lastly, I'm sorry to see you weren't happy with the quality of my test > code. Your changes seem much larger in scale, and quite different to > my changes. Could you explain the benefits of your approach, vs simply > adding non-static final fields to my code? First, I dont see my test update is large scale. Second, it's not about the quality of the test code. The size of the change is not the sole factor to consider but that seems to bother you. Anyway, the test itself isn't easy to work with. You have done the fix to include the regression test which is okay. Your patch made me to look at the test closer which I started from the version in the repo, not based on your version. Once you push your fix, I can generate a new webrev to see the diff that I can revise on top of your version. I change a couple things. The test uses Error in HasFields.CASES to indicate a negative test. For a final field, it has no write access and it is a negative test case except unreflectSetter on an instance final field whose accessible flag is true. That explains why Error.class is in the third element of the new case added for final field that actually reflects if a test case is positive or negative when calling testAccessor. What you added is treating setter on final field is positive test case and then returns when IAE is thrown. It does the work but passing incorrect information. I uncovered some unnecessary test cases for findSetter on static fields and findStaticSetter on non-static fields. It's an existing test issue and I think they should be filtered out and that's why CASES is separated into two separate ArrayLists and the new static cases(int testMode) method. I see that you used a new kind for static final field that may be a good approach. When I pull down your change, I will send out a revision (that's why I wait for your patch to go in first and see any thing I should change). Hope this helps. Mandy From takiguc at linux.vnet.ibm.com Fri Mar 8 00:57:36 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 08 Mar 2019 09:57:36 +0900 Subject: RFR: 8220281 IBM-858 alias name is missing on IBM00858 charset Message-ID: Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8220281 Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.00/ I'd like to obtain a sponsor for this issue. en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2] IBM00858 charset was registered into IANA Character Sets. [3] And Java already has IBM00858. But IBM00858 charset has IBM-858 alias. Because of this situation, JDK13 does not start on AIX en_US.IBM-858 locale. I'd like to request to add some charset aliases against following charsets: ibm00858, ibm01140, ibm01141, ibm01142, ibm01143, ibm01144, ibm01145, ibm01146, ibm01147, ibm01148, ibm01149, x-ibm833 [1] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/support_languages_locales.htm [2] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.nlsgdrf/support_languages_locales.htm [3] https://www.iana.org/assignments/character-sets/character-sets.xhtml Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From TOSHIONA at jp.ibm.com Fri Mar 8 06:25:05 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Fri, 8 Mar 2019 15:25:05 +0900 Subject: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10 Message-ID: Hi, Could you review this fix? I'd like to have a sponsor of it, since I'm an author. Bug: https://bugs.openjdk.java.net/browse/JDK-8220227 Webrev: http://cr.openjdk.java.net/~tnakamura/8220227/webrev.00/ Issue: Under Windows 10 non-English, Locale.getDisplayCountry() shows an error message, if Host Locale Provider is used (-Djava.locale.providers=HOST). Fix proposal: The current code compares "Unknown Region (" with the result, but it could be translated. I believe we can compare it with "("+RegionCode+")", which covers all 38 Language Packs of Windows Server 2016. Thanks, Toshio Nakamura From mandy.chung at oracle.com Fri Mar 8 07:54:53 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Mar 2019 07:54:53 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> Message-ID: <5db1bccb-7aee-61fb-6788-200dbb11c95a@oracle.com> On 3/7/19 3:17 PM, Mandy Chung wrote: > >> Lastly, I'm sorry to see you weren't happy with the quality of my test >> code. Your changes seem much larger in scale, and quite different to >> my changes. Could you explain the benefits of your approach, vs simply >> adding non-static final fields to my code? > > First, I dont see my test update is large scale.? Second, it's not > about the quality of the test code.? The size of the change is not > the sole factor to consider but that seems to bother you.? Anyway, > the test itself isn't easy to work with.? You have done the fix to > include the regression test which is okay. BTW one other main purpose I propose my patch is to show you an example that proposing this change (that you consider larger in scale) does not take months to approve. I should make this explicit. Mandy From brian.burkhalter at oracle.com Fri Mar 8 09:12:51 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Mar 2019 09:12:51 +0000 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <6df01f14-dd0a-6319-50ef-7dd9228bd355@redhat.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> <6df01f14-dd0a-6319-50ef-7dd9228bd355@redhat.com> Message-ID: <8E764307-AFB3-4BD9-B6CA-EF12C78EF8F4@oracle.com> > On Mar 7, 2019, at 6:01 PM, Andrew Haley wrote: > > On 3/7/19 10:10 AM, Brian Burkhalter wrote: >> >>> On Mar 7, 2019, at 10:04 AM, Andrew Haley > wrote: >>> >>> I still believe you'd be better off defining an unsigned multiplyHigh than >>> all that messing about with shifts and masks in rop(). >> >> There is in fact an open issue for unsigned multiplyHigh: >> >> https://bugs.openjdk.java.net/browse/JDK-8188044 > > Do you want to do it? If not I will. Your contribution would be most welcome. Thanks, Brian From joe.darcy at oracle.com Fri Mar 8 11:08:57 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 8 Mar 2019 03:08:57 -0800 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull Message-ID: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Hello, The code in java.lang.Throwable has various explicit null checks that could be rewritten to use Objects.requireNonNull. Please review the patch below which implements this refactoring. Thanks, -Joe diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java --- a/src/java.base/share/classes/java/lang/Throwable.java??? Thu Mar 07 10:22:19 2019 +0100 +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Fri Mar 08 02:06:42 2019 -0800 @@ -874,8 +874,7 @@ ???????? // Validate argument ???????? StackTraceElement[] defensiveCopy = stackTrace.clone(); ???????? for (int i = 0; i < defensiveCopy.length; i++) { -??????????? if (defensiveCopy[i] == null) -??????????????? throw new NullPointerException("stackTrace[" + i + "]"); +??????????? Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i + "]"); ???????? } ???????? synchronized (this) { @@ -914,8 +913,7 @@ ???????????????? for (Throwable t : suppressedExceptions) { ???????????????????? // Enforce constraints on suppressed exceptions in ???????????????????? // case of corrupt or malicious stream. -??????????????????? if (t == null) -??????????????????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); +??????????????????? Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); ???????????????????? if (t == this) ???????????????????????? throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); ???????????????????? suppressed.add(t); @@ -942,8 +940,7 @@ ???????????????? stackTrace = null; ???????????? } else { // Verify stack trace elements are non-null. ???????????????? for(StackTraceElement ste : stackTrace) { -??????????????????? if (ste == null) -??????????????????????? throw new NullPointerException("null StackTraceElement in serial stream. "); +??????????????????? Objects.requireNonNull(ste, "null StackTraceElement in serial stream. "); ???????????????? } ???????????? } ???????? } else { @@ -1034,8 +1031,7 @@ ???????? if (exception == this) ???????????? throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); -??????? if (exception == null) -??????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); +??????? Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); ???????? if (suppressedExceptions == null) // Suppressed exceptions not recorded ???????????? return; From lance.andersen at oracle.com Fri Mar 8 11:23:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 8 Mar 2019 06:23:57 -0500 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: <624A119D-2CB1-40E8-85F6-BED277D36714@oracle.com> +1 > On Mar 8, 2019, at 6:08 AM, Joe Darcy wrote: > > Hello, > > The code in java.lang.Throwable has various explicit null checks that could be rewritten to use Objects.requireNonNull. > > Please review the patch below which implements this refactoring. > > Thanks, > > -Joe > > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 10:22:19 2019 +0100 > +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 02:06:42 2019 -0800 > @@ -874,8 +874,7 @@ > // Validate argument > StackTraceElement[] defensiveCopy = stackTrace.clone(); > for (int i = 0; i < defensiveCopy.length; i++) { > - if (defensiveCopy[i] == null) > - throw new NullPointerException("stackTrace[" + i + "]"); > + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i + "]"); > } > > synchronized (this) { > @@ -914,8 +913,7 @@ > for (Throwable t : suppressedExceptions) { > // Enforce constraints on suppressed exceptions in > // case of corrupt or malicious stream. > - if (t == null) > - throw new NullPointerException(NULL_CAUSE_MESSAGE); > + Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); > if (t == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > suppressed.add(t); > @@ -942,8 +940,7 @@ > stackTrace = null; > } else { // Verify stack trace elements are non-null. > for(StackTraceElement ste : stackTrace) { > - if (ste == null) > - throw new NullPointerException("null StackTraceElement in serial stream. "); > + Objects.requireNonNull(ste, "null StackTraceElement in serial stream. "); > } > } > } else { > @@ -1034,8 +1031,7 @@ > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > - if (exception == null) > - throw new NullPointerException(NULL_CAUSE_MESSAGE); > + Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); > > if (suppressedExceptions == null) // Suppressed exceptions not recorded > return; > 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 amaembo at gmail.com Fri Mar 8 11:56:23 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 8 Mar 2019 18:56:23 +0700 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: Hello! > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 > 10:22:19 2019 +0100 > +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 > 02:06:42 2019 -0800 > @@ -874,8 +874,7 @@ > // Validate argument > StackTraceElement[] defensiveCopy = stackTrace.clone(); > for (int i = 0; i < defensiveCopy.length; i++) { > - if (defensiveCopy[i] == null) > - throw new NullPointerException("stackTrace[" + i + "]"); > + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i > + "]"); Won't it produce unnecessary garbage due to string concatenation on the common case when all frames are non-null? With best regards, Tagir Valeev. From aph at redhat.com Fri Mar 8 13:35:25 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Mar 2019 13:35:25 +0000 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <869b3807-bce5-eccd-0efe-9bbf01780c41@gmail.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> <869b3807-bce5-eccd-0efe-9bbf01780c41@gmail.com> Message-ID: Hi, On 3/7/19 7:16 PM, Raffaello Giulietti wrote: > a couple of weeks ago I tried to refactor the code assuming the > existence of unsignedMultiplyHigh() (either as some future intrinsic or > as a Java method) and a wider representations of g with either 127 or > 128 bits: > g = g1 2^64 + g0 > > with either > 2^63 <= g1 < 2^64 (128 bits) > > or > 2^62 <= g1 < 2^63 (127 bits) > > Unfortunately, the resulting code of rop() isn't any simpler. That's > because then an intermediate sum can overflow the 64 bits of a long. As > a consequence, there's need for more elaborate logic to determine > the carry and other slightly more complicated computations to assemble > the final result. All in all, the resulting code has more operations and > looks longer. Ah, I see. I agree, we still don't quite have the full set of operations that we need in Java, in particular a nice way of doing an add with carry. Thank you for the explanation. > In the meantime I got rid of the last division. There's no division at > all in the whole algorithm. Excellent. This is looking very good indeed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.joelsson at oracle.com Fri Mar 8 14:26:28 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Mar 2019 06:26:28 -0800 Subject: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty In-Reply-To: References: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> <82961966-139a-96d4-1049-96857f8ff5fd@oracle.com> Message-ID: <927ee5f4-8c93-d8eb-0525-687b1d2bd434@oracle.com> Build changes look good. /Erik On 2019-03-07 14:52, Alexander Matveev wrote: > Hi Erik, > > http://cr.openjdk.java.net/~almatvee/8214566/webrev.01/ > > - Removed $(call SET_SHARED_LIBRARY_ORIGIN), TOOLCHAIN_LINK_CXX and > linking with libjava. > > Thanks, > Alexander > > On 3/7/2019 6:52 AM, Erik Joelsson wrote: >> Hello Alexander, >> >> A few notes: >> >> $(call SET_SHARED_LIBRARY_ORIGIN) and TOOLCHAIN_LINK_CXX have no >> effect on Windows, so should be removed to avoid confusion in the >> future. >> >> This new library does not link with libjava so I see no need to add >> that prerequisite declaration. >> >> /Erik >> >> On 2019-03-06 17:10, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Added custom action to check installation folder and display >>> confirmation dialog to ask user to continue installation if >>> destination folder is not empty. This is same behavior and >>> confirmation message as for .exe. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8214566 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ >>> >>> Thanks, >>> Alexander > From christoph.langer at sap.com Fri Mar 8 14:39:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Mar 2019 14:39:45 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux Message-ID: Hi, please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. Thank you and Best regards Christoph From mik3hall at gmail.com Fri Mar 8 14:57:08 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Mar 2019 08:57:08 -0600 Subject: jpackage ALL-SYSTEM Message-ID: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> I have made changes to my application that make it mostly functional with the exception of JMX pid attach as built by jpackage. I thought I had this functionality working when I first got the application to use Java 9 but it no longer appears to work again now, either with my Java 9 app or my 13-internal+0-jdk13-jpackage.17 version app. I understand for this issue serviceability-dev might be a better list for this but there may be one jpackage issue concerned as well. Again, I don?t consider this a jpackage problem, my application now builds as successfully as it currently can with jpackage as-is. What I get attempting a JMX attach is? 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) The application also can?t be connected to from jconsole. Eclipse can be, so can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing ?add-modules ALL-SYSTEM I was going to try this with my application but it did not work. The error persisted on that as a jvm argument. Using it as a jpackage ?add-modules parameter gets... Module ALL-SYSTEM does not exist. The one question I would have for jpackage is should this work as a ?add-modules parameter? However, if anyone has any suggestions on getting JMX attach to work besides adding serviceability-dev to my forums that would be appreciated as well. Thanks. From aph at redhat.com Fri Mar 8 15:20:42 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Mar 2019 15:20:42 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. I don't see any explanation of why this should go into jdk11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From raffaello.giulietti at gmail.com Fri Mar 8 16:56:39 2019 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Fri, 8 Mar 2019 17:56:39 +0100 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> <869b3807-bce5-eccd-0efe-9bbf01780c41@gmail.com> Message-ID: <4ec34854-b6c3-3f7d-19fc-9cfa3a3ff6a9@gmail.com> On 2019-03-08 14:35, Andrew Haley wrote: > Hi, > > On 3/7/19 7:16 PM, Raffaello Giulietti wrote: > >> a couple of weeks ago I tried to refactor the code assuming the >> existence of unsignedMultiplyHigh() (either as some future intrinsic or >> as a Java method) and a wider representations of g with either 127 or >> 128 bits: >> g = g1 2^64 + g0 >> >> with either >> 2^63 <= g1 < 2^64 (128 bits) >> >> or >> 2^62 <= g1 < 2^63 (127 bits) >> >> Unfortunately, the resulting code of rop() isn't any simpler. That's >> because then an intermediate sum can overflow the 64 bits of a long. As >> a consequence, there's need for more elaborate logic to determine >> the carry and other slightly more complicated computations to assemble >> the final result. All in all, the resulting code has more operations and >> looks longer. > > Ah, I see. I agree, we still don't quite have the full set of operations > that we need in Java, in particular a nice way of doing an add with carry. > Yes. > Thank you for the explanation. > You're welcome. >> In the meantime I got rid of the last division. There's no division at >> all in the whole algorithm. > > Excellent. This is looking very good indeed. > From shade at redhat.com Fri Mar 8 17:35:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Mar 2019 18:35:12 +0100 Subject: RFR (S) 8074817: Resolve disabled warnings for libverify Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8074817 Fix: http://cr.openjdk.java.net/~shade/8074817/webrev.03/ This hopefully resolves warnings in libverify. See bug report for warnings list. Testing: jdk-submit, local {Linux, Windows} x86_64 builds Thanks, -Aleksey From naoto.sato at oracle.com Fri Mar 8 17:39:48 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 8 Mar 2019 09:39:48 -0800 Subject: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10 In-Reply-To: References: Message-ID: <052c5c92-2af7-2603-e913-2265e14b3781@oracle.com> Hi Nakamura-san, Thanks for fixing this. Since it is using a heuristic way to detect "unknown", I'd use String.endsWith() instead of String.contains() both in HostLocaleProviderAdapterImpl.java and LocaleProviders.java, which would be more accurate. Naoto On 3/7/19 10:25 PM, Toshio 5 Nakamura wrote: > > Hi, > > Could you review this fix? I'd like to have a sponsor of it, since I'm an > author. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220227 > Webrev: http://cr.openjdk.java.net/~tnakamura/8220227/webrev.00/ > > Issue: > Under Windows 10 non-English, Locale.getDisplayCountry() shows an error > message, > if Host Locale Provider is used (-Djava.locale.providers=HOST). > > Fix proposal: > The current code compares "Unknown Region (" with the result, but it could > be translated. > I believe we can compare it with "("+RegionCode+")", which covers all 38 > Language > Packs of Windows Server 2016. > > Thanks, > Toshio Nakamura > From ecki at zusammenkunft.net Fri Mar 8 17:40:20 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 8 Mar 2019 18:40:20 +0100 Subject: jpackage ALL-SYSTEM In-Reply-To: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> Message-ID: <5c82a904.1c69fb81.10097.bf1b@mx.google.com> Can you confir it works if you start your application with a stand-alone JDK? I suspect you have a custom jlink Image which misses the modules. Can you share your jpackage configuration or at least run ?Java ?list-modules? and ?validate-modules in your installed app? I think you Need at least jdk.attach jdk.attach provides com.sun.tools.attach.spi.AttachProvider used by jdk.attach -- http://bernd.eckenfels.net Von: Michael Hall Gesendet: Freitag, 8. M?rz 2019 18:29 An: core-libs-dev at openjdk.java.net Betreff: jpackage ALL-SYSTEM I have made changes to my application that make it mostly functional with the exception of JMX pid attach as built by jpackage. I thought I had this functionality working when I first got the application to use Java 9 but it no longer appears to work again now, either with my Java 9 app or my 13-internal+0-jdk13-jpackage.17 version app. I understand for this issue serviceability-dev might be a better list for this but there may be one jpackage issue concerned as well. Again, I don?t consider this a jpackage problem, my application now builds as successfully as it currently can with jpackage as-is. What I get attempting a JMX attach is? 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) The application also can?t be connected to from jconsole. Eclipse can be, so can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing ?add-modules ALL-SYSTEM I was going to try this with my application but it did not work. The error persisted on that as a jvm argument. Using it as a jpackage ?add-modules parameter gets... Module ALL-SYSTEM does not exist. The one question I would have for jpackage is should this work as a ?add-modules parameter? However, if anyone has any suggestions on getting JMX attach to work besides adding serviceability-dev to my forums that would be appreciated as well. Thanks. From naoto.sato at oracle.com Fri Mar 8 17:56:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 8 Mar 2019 09:56:15 -0800 Subject: RFR: 8220281 IBM-858 alias name is missing on IBM00858 charset In-Reply-To: References: Message-ID: <97186d40-763d-ed20-569a-ea76c54d802d@oracle.com> Hi Takiguchi-san, Looks good to me. I'd replace Locale.ENGLISH with Locale.ROOT for toLowerCase() method. On 3/7/19 4:57 PM, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8220281 > Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2] > IBM00858 charset was registered into IANA Character Sets. [3] > And Java already has IBM00858. > But IBM00858 charset has IBM-858 alias. Did you mean "does not have"? BTW, have you tested the new test case on other platforms, i.e., Windows/Linux/macOS? Naoto > Because of this situation, JDK13 does not start on AIX en_US.IBM-858 > locale. > > I'd like to request to add some charset aliases against following charsets: > ? ibm00858, ibm01140, ibm01141, ibm01142, ibm01143, ibm01144, > ? ibm01145, ibm01146, ibm01147, ibm01148, ibm01149, x-ibm833 > > [1] > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/support_languages_locales.htm > > [2] > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.nlsgdrf/support_languages_locales.htm > > [3] https://www.iana.org/assignments/character-sets/character-sets.xhtml > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > From andy.herrick at oracle.com Fri Mar 8 18:10:22 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 8 Mar 2019 13:10:22 -0500 Subject: jpackage ALL-SYSTEM In-Reply-To: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> Message-ID: With jpackage EA 3 (build 17) the option --add-modules does not properly recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH. This will be addressed in the next EA release. The default jlink options used (in EA 3) may also not include --bind-services jlink option, which it will moving forward. In many cases the jlink options used by jpackage to construct the runtime for a modular application may not be exactly what the application wants. In that case it is advisable to run jlink first to create the optimal runtime image for a specific application, then to run jpackage with --runtime-image option to use that runtime image when packaging the application. /Andy On 3/8/2019 9:57 AM, Michael Hall wrote: > I have made changes to my application that make it mostly functional with the exception of JMX pid attach as built by jpackage. > I thought I had this functionality working when I first got the application to use Java 9 but it no longer appears to work again now, either with my Java 9 app or my 13-internal+0-jdk13-jpackage.17 version app. > I understand for this issue serviceability-dev might be a better list for this but there may be one jpackage issue concerned as well. > Again, I don?t consider this a jpackage problem, my application now builds as successfully as it currently can with jpackage as-is. > What I get attempting a JMX attach is? > 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) > > The application also can?t be connected to from jconsole. Eclipse can be, so can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing ?add-modules ALL-SYSTEM > I was going to try this with my application but it did not work. The error persisted on that as a jvm argument. > Using it as a jpackage ?add-modules parameter gets... > Module ALL-SYSTEM does not exist. > > The one question I would have for jpackage is should this work as a ?add-modules parameter? > > However, if anyone has any suggestions on getting JMX attach to work besides adding serviceability-dev to my forums that would be appreciated as well. > > Thanks. From erik.joelsson at oracle.com Fri Mar 8 19:11:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Mar 2019 11:11:20 -0800 Subject: RFR (S) 8074817: Resolve disabled warnings for libverify In-Reply-To: References: Message-ID: Looks good to me, but someone from core libs should look at the source changes too. /Erik On 2019-03-08 09:35, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8074817 > > Fix: > http://cr.openjdk.java.net/~shade/8074817/webrev.03/ > > This hopefully resolves warnings in libverify. See bug report for warnings list. > > Testing: jdk-submit, local {Linux, Windows} x86_64 builds > > Thanks, > -Aleksey > From sergei.tsypanov at yandex.ru Fri Mar 8 19:22:10 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 08 Mar 2019 21:22:10 +0200 Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: Message-ID: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> Hello, I have an enhancement proposal for some cases of String concatenation in Java. Currently we concat Strings mostly using java.lang.StringBuilder. The main disadvantage of StringBuilder is underlying char array or rather a need to resize it when the capacity is about to exceed array length and subsequent copying of array content into newly allocated array. One alternative solution existing is StringJoiner. Before JDK 9 it was a kind of decorator over StringBuilder, but later it was reworked in order to store appended Strings into String[] and overall capacity accumulated into int field. This makes it possible to allocate char[] only once and of exact size in toString() method reducing allocation cost. My proposal is to copy-paste the code of StringJoinder into newly created class java.util.StringChain, drop the code responsible for delimiter, prefix and suffix and use it instead of StringBuilder in common StringBuilder::append concatenation pattern. Possible use-cases for proposed code are: - plain String concatenation - String::chain (new methods) - Stream.collect(Collectors.joining()) - StringConcatFactory We can create new methods String.chain(Iterable) and String.chain(CharSequence...) which allow to encapsulate boilerplate code like StringBuilder sb = new StringBuilder(); for (CharSequence cs : charSequences) { ?? sb.append(cs); } String result = sb.toString(): into one line: String result = String.chain(charSequences); As of performance I've done some measurements using JMH on my work machine (Intel i7-7700) for both Latin and non-Latin Strings of different size and count. Here are the results: https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt There is a few corner cases (e.g. 1000 Strings of length 1 appended) when StringBuilder takes over StringChain constructed with default capacity of 8, but StringChain constructed with exact added Strings count almost always wins, especially when dealing with non-Latin chars (Russian in my case). I've also created a separate repo on GitHub with benchmarks: https://github.com/stsypanov/string-chain Key feature here is ability to allocate String array of exact size is cases we know added elements count. Thus I think that if the change will be accepted we can add also an overloaded method String.chain(Collection) as Collection::size allows to contruct StringChain of exact size. Patch is attached. Kind regards, Sergei Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: StringChain.patch Type: text/x-diff Size: 9376 bytes Desc: not available URL: From forax at univ-mlv.fr Fri Mar 8 19:58:11 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 8 Mar 2019 20:58:11 +0100 (CET) Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> Message-ID: <1866665646.997163.1552075091851.JavaMail.zimbra@u-pem.fr> Hi, adding StringChain send the wrong message IMO, we already have StringBuffer, StringBuilder and StringJoiner, let's try not to add another way to concatenate a variable number of Strings in Java. I wonder if you can not achieve what you want by specializing String.join() and StringJoiner if the delimiter is an empty String ? R?mi ----- Mail original ----- > De: "?????? ???????" > ?: "core-libs-dev" > Envoy?: Vendredi 8 Mars 2019 20:22:10 > Objet: [PATCH] enhancement proposal for String concatenation > Hello, > > I have an enhancement proposal for some cases of String concatenation in Java. > > Currently we concat Strings mostly using java.lang.StringBuilder. The main > disadvantage of StringBuilder is underlying char array or rather a need to > resize it when the capacity is about to exceed array length and subsequent > copying of array content into newly allocated array. > > One alternative solution existing is StringJoiner. Before JDK 9 it was a kind of > decorator over StringBuilder, but later it was reworked in order to store > appended Strings into String[] and overall capacity accumulated into int field. > This makes it possible to allocate char[] only once and of exact size in > toString() method reducing allocation cost. > > My proposal is to copy-paste the code of StringJoinder into newly created class > java.util.StringChain, drop the code responsible for delimiter, prefix and > suffix and use it instead of StringBuilder in common StringBuilder::append > concatenation pattern. > > Possible use-cases for proposed code are: > - plain String concatenation > - String::chain (new methods) > - Stream.collect(Collectors.joining()) > - StringConcatFactory > > We can create new methods String.chain(Iterable) and > String.chain(CharSequence...) which allow to encapsulate boilerplate code like > > > StringBuilder sb = new StringBuilder(); > for (CharSequence cs : charSequences) { >?? sb.append(cs); > } > String result = sb.toString(): > > > into one line: > > > String result = String.chain(charSequences); > > > > As of performance I've done some measurements using JMH on my work machine > (Intel i7-7700) for both Latin and non-Latin Strings of different size and > count. > Here are the results: > > https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt > > There is a few corner cases (e.g. 1000 Strings of length 1 appended) when > StringBuilder takes over StringChain constructed with default capacity of 8, > but StringChain constructed with exact added Strings count almost always wins, > especially when dealing with non-Latin chars (Russian in my case). > > I've also created a separate repo on GitHub with benchmarks: > > https://github.com/stsypanov/string-chain > > Key feature here is ability to allocate String array of exact size is cases we > know added elements count. > Thus I think that if the change will be accepted we can add also an overloaded > method String.chain(Collection) as Collection::size allows to > contruct StringChain of exact size. > > Patch is attached. > > Kind regards, > Sergei Tsypanov From ivan.gerasimov at oracle.com Fri Mar 8 20:00:55 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 8 Mar 2019 12:00:55 -0800 Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> Message-ID: Hi Sergei! As you said, this new class is pretty much like StringJoiner with reduced functionality. For appending all elements of an Iterable you could use list.forEach(s -> sj.add(s)). With kind regards, Ivan On 3/8/19 11:22 AM, ?????? ??????? wrote: > Hello, > > I have an enhancement proposal for some cases of String concatenation in Java. > > Currently we concat Strings mostly using java.lang.StringBuilder. The main disadvantage of StringBuilder is underlying char array or rather a need to resize it when the capacity is about to exceed array length and subsequent copying of array content into newly allocated array. > > One alternative solution existing is StringJoiner. Before JDK 9 it was a kind of decorator over StringBuilder, but later it was reworked in order to store appended Strings into String[] and overall capacity accumulated into int field. This makes it possible to allocate char[] only once and of exact size in toString() method reducing allocation cost. > > My proposal is to copy-paste the code of StringJoinder into newly created class java.util.StringChain, drop the code responsible for delimiter, prefix and suffix and use it instead of StringBuilder in common StringBuilder::append concatenation pattern. > > Possible use-cases for proposed code are: > - plain String concatenation > - String::chain (new methods) > - Stream.collect(Collectors.joining()) > - StringConcatFactory > > We can create new methods String.chain(Iterable) and String.chain(CharSequence...) which allow to encapsulate boilerplate code like > > > StringBuilder sb = new StringBuilder(); > for (CharSequence cs : charSequences) { > sb.append(cs); > } > String result = sb.toString(): > > > into one line: > > > String result = String.chain(charSequences); > > > > As of performance I've done some measurements using JMH on my work machine (Intel i7-7700) for both Latin and non-Latin Strings of different size and count. > Here are the results: > > https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt > > There is a few corner cases (e.g. 1000 Strings of length 1 appended) when StringBuilder takes over StringChain constructed with default capacity of 8, but StringChain constructed with exact added Strings count almost always wins, especially when dealing with non-Latin chars (Russian in my case). > > I've also created a separate repo on GitHub with benchmarks: > > https://github.com/stsypanov/string-chain > > Key feature here is ability to allocate String array of exact size is cases we know added elements count. > Thus I think that if the change will be accepted we can add also an overloaded method String.chain(Collection) as Collection::size allows to contruct StringChain of exact size. > > Patch is attached. > > Kind regards, > Sergei Tsypanov -- With kind regards, Ivan Gerasimov From mandy.chung at oracle.com Fri Mar 8 20:17:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Mar 2019 20:17:39 +0000 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: <6280e8f3-a14e-0411-ce57-cc1a0ecc6ee3@oracle.com> Looks good to me. Mandy On 3/8/19 3:08 AM, Joe Darcy wrote: > Hello, > > The code in java.lang.Throwable has various explicit null checks that > could be rewritten to use Objects.requireNonNull. > > Please review the patch below which implements this refactoring. > > Thanks, > > -Joe > > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java??? Thu Mar 07 > 10:22:19 2019 +0100 > +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Fri Mar 08 > 02:06:42 2019 -0800 > @@ -874,8 +874,7 @@ > ???????? // Validate argument > ???????? StackTraceElement[] defensiveCopy = stackTrace.clone(); > ???????? for (int i = 0; i < defensiveCopy.length; i++) { > -??????????? if (defensiveCopy[i] == null) > -??????????????? throw new NullPointerException("stackTrace[" + i + "]"); > +??????????? Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i > + "]"); > ???????? } > > ???????? synchronized (this) { > @@ -914,8 +913,7 @@ > ???????????????? for (Throwable t : suppressedExceptions) { > ???????????????????? // Enforce constraints on suppressed exceptions in > ???????????????????? // case of corrupt or malicious stream. > -??????????????????? if (t == null) > -??????????????????????? throw new > NullPointerException(NULL_CAUSE_MESSAGE); > +??????????????????? Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); > ???????????????????? if (t == this) > ???????????????????????? throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > ???????????????????? suppressed.add(t); > @@ -942,8 +940,7 @@ > ???????????????? stackTrace = null; > ???????????? } else { // Verify stack trace elements are non-null. > ???????????????? for(StackTraceElement ste : stackTrace) { > -??????????????????? if (ste == null) > -??????????????????????? throw new NullPointerException("null > StackTraceElement in serial stream. "); > +??????????????????? Objects.requireNonNull(ste, "null StackTraceElement > in serial stream. "); > ???????????????? } > ???????????? } > ???????? } else { > @@ -1034,8 +1031,7 @@ > ???????? if (exception == this) > ???????????? throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > -??????? if (exception == null) > -??????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); > +??????? Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); > > ???????? if (suppressedExceptions == null) // Suppressed exceptions not > recorded > ???????????? return; > From ecki at zusammenkunft.net Fri Mar 8 20:34:30 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 8 Mar 2019 20:34:30 +0000 Subject: jpackage ALL-SYSTEM In-Reply-To: References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com>, Message-ID: Hm, we really should think about renaming --bind-services into --add-all-junk. Will using the option by default make image creation even less useful (i.e. does not safe much) in jpackage? Will there be a option to turn it off? Otherwise I guess it?s best to only support --runtime-Image method. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Andy Herrick Gesendet: Freitag, M?rz 8, 2019 9:13 PM An: core-libs-dev at openjdk.java.net Betreff: Re: jpackage ALL-SYSTEM With jpackage EA 3 (build 17) the option --add-modules does not properly recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH. This will be addressed in the next EA release. The default jlink options used (in EA 3) may also not include --bind-services jlink option, which it will moving forward. In many cases the jlink options used by jpackage to construct the runtime for a modular application may not be exactly what the application wants. In that case it is advisable to run jlink first to create the optimal runtime image for a specific application, then to run jpackage with --runtime-image option to use that runtime image when packaging the application. /Andy On 3/8/2019 9:57 AM, Michael Hall wrote: > I have made changes to my application that make it mostly functional with the exception of JMX pid attach as built by jpackage. > I thought I had this functionality working when I first got the application to use Java 9 but it no longer appears to work again now, either with my Java 9 app or my 13-internal+0-jdk13-jpackage.17 version app. > I understand for this issue serviceability-dev might be a better list for this but there may be one jpackage issue concerned as well. > Again, I don?t consider this a jpackage problem, my application now builds as successfully as it currently can with jpackage as-is. > What I get attempting a JMX attach is? > 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) > > The application also can?t be connected to from jconsole. Eclipse can be, so can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing ?add-modules ALL-SYSTEM > I was going to try this with my application but it did not work. The error persisted on that as a jvm argument. > Using it as a jpackage ?add-modules parameter gets... > Module ALL-SYSTEM does not exist. > > The one question I would have for jpackage is should this work as a ?add-modules parameter? > > However, if anyone has any suggestions on getting JMX attach to work besides adding serviceability-dev to my forums that would be appreciated as well. > > Thanks. From martinrb at google.com Fri Mar 8 20:35:59 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 Mar 2019 12:35:59 -0800 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev wrote: > Hello! > > > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java > > --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 > > 10:22:19 2019 +0100 > > +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 > > 02:06:42 2019 -0800 > > @@ -874,8 +874,7 @@ > > // Validate argument > > StackTraceElement[] defensiveCopy = stackTrace.clone(); > > for (int i = 0; i < defensiveCopy.length; i++) { > > - if (defensiveCopy[i] == null) > > - throw new NullPointerException("stackTrace[" + i + "]"); > > + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i > > + "]"); > > Won't it produce unnecessary garbage due to string concatenation on > the common case when all frames are non-null? > I share Tagir's doubts. I avoid this construction in performance sensitive code. Java doesn't offer syntactic abstraction (can I haz macros?) so the Java Way is to write the explicit if. Logging frameworks have the same trouble. https://github.com/google/flogger Perhaps hotspot's improved automatic NPE reporting makes the message detail here obsolete? From mik3hall at gmail.com Fri Mar 8 20:39:47 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Mar 2019 14:39:47 -0600 Subject: jpackage ALL-SYSTEM In-Reply-To: References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> Message-ID: > On Mar 8, 2019, at 12:10 PM, Andy Herrick wrote: > > With jpackage EA 3 (build 17) the option --add-modules does not properly recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH. > > This will be addressed in the next EA release. > > The default jlink options used (in EA 3) may also not include --bind-services jlink option, which it will moving forward. > > In many cases the jlink options used by jpackage to construct the runtime for a modular application may not be exactly what the application wants. > > In that case it is advisable to run jlink first to create the optimal runtime image for a specific application, then to run jpackage with --runtime-image option to use that runtime image when packaging the application. > > /Andy Thanks for the suggestion, I?ll give that a try. From mik3hall at gmail.com Fri Mar 8 20:39:06 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Mar 2019 14:39:06 -0600 Subject: jpackage ALL-SYSTEM In-Reply-To: <5c82a904.1c69fb81.10097.bf1b@mx.google.com> References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> <5c82a904.1c69fb81.10097.bf1b@mx.google.com> Message-ID: > On Mar 8, 2019, at 11:40 AM, Bernd Eckenfels wrote: > > Can you confir it works if you start your application with a stand-alone JDK? > > I suspect you have a custom jlink Image which misses the modules. Can you share your jpackage configuration or at least run ?Java ?list-modules? and ?validate-modules in your installed app? I think you Need at least jdk.attach I think jpackage always includes a custom jlink of the runtime? The build normally includes --add-modules java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell \ I remember having issues with this at Java 9 as well. I think the jigsaw forum suggestion of adding java.se was what seemed to get it working then. Output of ?list-modules includes ___________________ outputdir/HalfPipe.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java --list-modules --validate-modules java.base at 13-internal ... java.management at 13-internal java.management.rmi at 13-internal ... java.rmi at 13-internal java.scripting at 13-internal java.se at 13-internal ... jdk.attach at 13-internal > > What I get attempting a JMX attach is? > 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) > I think the exception does show that the jdk.attach module is included? From mik3hall at gmail.com Fri Mar 8 20:50:29 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Mar 2019 14:50:29 -0600 Subject: jpackage ALL-SYSTEM In-Reply-To: <5c82a904.1c69fb81.10097.bf1b@mx.google.com> References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> <5c82a904.1c69fb81.10097.bf1b@mx.google.com> Message-ID: <8AC53FA0-2985-4321-A913-008B16581417@gmail.com> > On Mar 8, 2019, at 11:40 AM, Bernd Eckenfels wrote: > > Can you confir it works if you start your application with a stand-alone JDK? > > I suspect you have a custom jlink Image which misses the modules. Can you share your jpackage configuration or at least run ?Java ?list-modules? and ?validate-modules in your installed app? I think you Need at least jdk.attach > > > jdk.attach provides com.sun.tools.attach.spi.AttachProvider used by jdk.attach > -- > http://bernd.eckenfels.net > Out of curiosity I tried this on a simpler test app. jconsole also can?t connect to this one. I thought it should be possible without the target java application having to do anything at all, that other properly configured applications should be able to attach to them? Maybe I should take this to the other list? From mandy.chung at oracle.com Fri Mar 8 20:57:05 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Mar 2019 20:57:05 +0000 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: On 3/8/19 12:35 PM, Martin Buchholz wrote: > On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev wrote: > >> Hello! >> >>> diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java >>> --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 >>> 10:22:19 2019 +0100 >>> +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 >>> 02:06:42 2019 -0800 >>> @@ -874,8 +874,7 @@ >>> // Validate argument >>> StackTraceElement[] defensiveCopy = stackTrace.clone(); >>> for (int i = 0; i < defensiveCopy.length; i++) { >>> - if (defensiveCopy[i] == null) >>> - throw new NullPointerException("stackTrace[" + i + "]"); >>> + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i >>> + "]"); >> >> Won't it produce unnecessary garbage due to string concatenation on >> the common case when all frames are non-null? >> > > I share Tagir's doubts. I avoid this construction in performance sensitive > code. I see Tagir's comment after I replied. I share Tagir's concern as well and the exception message would be constructed unconditionally with this change. java.base is compiled with -XDstringConcat=inline due to bootstrapping and so the supplier does not help here. Mandy From andy.herrick at oracle.com Fri Mar 8 20:57:19 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 8 Mar 2019 15:57:19 -0500 Subject: RFR: JDK-171959: add-launcher is not working when normal jar is used for first launcher and module is used for second launcher Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8171959 [2] http://cr.openjdk.java.net/~herrick/8171959/ /Andy From alexander.matveev at oracle.com Fri Mar 8 23:23:23 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 8 Mar 2019 15:23:23 -0800 Subject: RFR: JDK-171959: add-launcher is not working when normal jar is used for first launcher and module is used for second launcher In-Reply-To: References: Message-ID: Hi Andy, Looks good. Thanks, Alexander On 3/8/2019 12:57 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] https://bugs.openjdk.java.net/browse/JDK-8171959 > > [2] http://cr.openjdk.java.net/~herrick/8171959/ > > /Andy > From alexander.matveev at oracle.com Fri Mar 8 23:46:18 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 8 Mar 2019 15:46:18 -0800 Subject: RFR: JDK-8215574 : Investigate and document usage of --category, --copyright, --vendor and --description Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Removed unused TITLE which is just APP_NAME. - Fix maintainer for DEB packages "vendor " instead of vendor or just email. - Fixed description for RPM, used to be just app name. - Fixed version and description for .exe installers. - Removed Comments and added Manufacturer attribute to Wix config file. Comments is not needed and Manufacturer is optional based on spec. [1] https://bugs.openjdk.java.net/browse/JDK-8215574 [2] http://cr.openjdk.java.net/~almatvee/8215574/webrev.00/ Thanks, Alexander From roger.riggs at oracle.com Sat Mar 9 07:52:41 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Sat, 9 Mar 2019 07:52:41 +0000 Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> Message-ID: <2ccd8d11-7642-0cf3-8fea-cd6dae03e9e1@oracle.com> Hi, Copy/paste is almost always brings more of a liability than an asset due to long term maintenance, skew, etc. Another possibility for StringJoiner is to look at the approach being investigated for String.format in JEP 348[1]. It leverages the work already done to support String concatenation ("+") in JEP 280[2]. [1] https://openjdk.java.net/jeps/348 [2] https://openjdk.java.net/jeps/280 Regards, Roger On 3/8/19 8:00 PM, Ivan Gerasimov wrote: > Hi Sergei! > > As you said, this new class is pretty much like StringJoiner with > reduced functionality. > > For appending all elements of an Iterable you could use list.forEach(s > -> sj.add(s)). > > With kind regards, > Ivan > > On 3/8/19 11:22 AM, ?????? ??????? wrote: >> Hello, >> >> I have an enhancement proposal for some cases of String concatenation >> in Java. >> >> Currently we concat Strings mostly using java.lang.StringBuilder. The >> main disadvantage of StringBuilder is underlying char array or rather >> a need to resize it when the capacity is about to exceed array length >> and subsequent copying of array content into newly allocated array. >> >> One alternative solution existing is StringJoiner. Before JDK 9 it >> was a kind of decorator over StringBuilder, but later it was reworked >> in order to store appended Strings into String[] and overall capacity >> accumulated into int field. This makes it possible to allocate char[] >> only once and of exact size in toString() method reducing allocation >> cost. >> >> My proposal is to copy-paste the code of StringJoinder into newly >> created class java.util.StringChain, drop the code responsible for >> delimiter, prefix and suffix and use it instead of StringBuilder in >> common StringBuilder::append concatenation pattern. >> >> Possible use-cases for proposed code are: >> - plain String concatenation >> - String::chain (new methods) >> - Stream.collect(Collectors.joining()) >> - StringConcatFactory >> >> We can create new methods String.chain(Iterable) and >> String.chain(CharSequence...) which allow to encapsulate boilerplate >> code like >> >> >> ?? StringBuilder sb = new StringBuilder(); >> ?? for (CharSequence cs : charSequences) { >> ???? sb.append(cs); >> ?? } >> ?? String result = sb.toString(): >> >> >> into one line: >> >> >> ?? String result = String.chain(charSequences); >> >> >> >> As of performance I've done some measurements using JMH on my work >> machine (Intel i7-7700) for both Latin and non-Latin Strings of >> different size and count. >> Here are the results: >> >> https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt >> >> >> There is a few corner cases (e.g. 1000 Strings of length 1 appended) >> when StringBuilder takes over StringChain constructed with default >> capacity of 8, but StringChain constructed with exact added Strings >> count almost always wins, especially when dealing with non-Latin >> chars (Russian in my case). >> >> I've also created a separate repo on GitHub with benchmarks: >> >> https://github.com/stsypanov/string-chain >> >> Key feature here is ability to allocate String array of exact size is >> cases we know added elements count. >> Thus I think that if the change will be accepted we can add also an >> overloaded method String.chain(Collection) as >> Collection::size allows to contruct StringChain of exact size. >> >> Patch is attached. >> >> Kind regards, >> Sergei Tsypanov > From forax at univ-mlv.fr Sat Mar 9 09:57:34 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 9 Mar 2019 10:57:34 +0100 (CET) Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: <2ccd8d11-7642-0cf3-8fea-cd6dae03e9e1@oracle.com> References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> <2ccd8d11-7642-0cf3-8fea-cd6dae03e9e1@oracle.com> Message-ID: <497171205.1021026.1552125454937.JavaMail.zimbra@u-pem.fr> yes, but unlike Strig.format() where the number of objects to concatenate is usually known, with String.join() you can only detect if the delimiter is constant, you don't know how many strings you have to concatenate, so the best you can do is a kind of loop customization, given that JITs also do this optimization, it's not obvious that perf can be better. R?mi ----- Mail original ----- > De: "Roger Riggs" > ?: "core-libs-dev" > Envoy?: Samedi 9 Mars 2019 08:52:41 > Objet: Re: [PATCH] enhancement proposal for String concatenation > Hi, > > Copy/paste is almost always brings more of a liability than an asset > due to long term maintenance, skew, etc. > > Another possibility for StringJoiner is to look at the approach being > investigated > for String.format in JEP 348[1]. > > It leverages the work already done to support String concatenation ("+") > in JEP 280[2]. > > [1] https://openjdk.java.net/jeps/348 > [2] https://openjdk.java.net/jeps/280 > > Regards, Roger > > On 3/8/19 8:00 PM, Ivan Gerasimov wrote: >> Hi Sergei! >> >> As you said, this new class is pretty much like StringJoiner with >> reduced functionality. >> >> For appending all elements of an Iterable you could use list.forEach(s >> -> sj.add(s)). >> >> With kind regards, >> Ivan >> >> On 3/8/19 11:22 AM, ?????? ??????? wrote: >>> Hello, >>> >>> I have an enhancement proposal for some cases of String concatenation >>> in Java. >>> >>> Currently we concat Strings mostly using java.lang.StringBuilder. The >>> main disadvantage of StringBuilder is underlying char array or rather >>> a need to resize it when the capacity is about to exceed array length >>> and subsequent copying of array content into newly allocated array. >>> >>> One alternative solution existing is StringJoiner. Before JDK 9 it >>> was a kind of decorator over StringBuilder, but later it was reworked >>> in order to store appended Strings into String[] and overall capacity >>> accumulated into int field. This makes it possible to allocate char[] >>> only once and of exact size in toString() method reducing allocation >>> cost. >>> >>> My proposal is to copy-paste the code of StringJoinder into newly >>> created class java.util.StringChain, drop the code responsible for >>> delimiter, prefix and suffix and use it instead of StringBuilder in >>> common StringBuilder::append concatenation pattern. >>> >>> Possible use-cases for proposed code are: >>> - plain String concatenation >>> - String::chain (new methods) >>> - Stream.collect(Collectors.joining()) >>> - StringConcatFactory >>> >>> We can create new methods String.chain(Iterable) and >>> String.chain(CharSequence...) which allow to encapsulate boilerplate >>> code like >>> >>> >>> ?? StringBuilder sb = new StringBuilder(); >>> ?? for (CharSequence cs : charSequences) { >>> ???? sb.append(cs); >>> ?? } >>> ?? String result = sb.toString(): >>> >>> >>> into one line: >>> >>> >>> ?? String result = String.chain(charSequences); >>> >>> >>> >>> As of performance I've done some measurements using JMH on my work >>> machine (Intel i7-7700) for both Latin and non-Latin Strings of >>> different size and count. >>> Here are the results: >>> >>> https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt >>> >>> >>> There is a few corner cases (e.g. 1000 Strings of length 1 appended) >>> when StringBuilder takes over StringChain constructed with default >>> capacity of 8, but StringChain constructed with exact added Strings >>> count almost always wins, especially when dealing with non-Latin >>> chars (Russian in my case). >>> >>> I've also created a separate repo on GitHub with benchmarks: >>> >>> https://github.com/stsypanov/string-chain >>> >>> Key feature here is ability to allocate String array of exact size is >>> cases we know added elements count. >>> Thus I think that if the change will be accepted we can add also an >>> overloaded method String.chain(Collection) as >>> Collection::size allows to contruct StringChain of exact size. >>> >>> Patch is attached. >>> >>> Kind regards, >>> Sergei Tsypanov From sergei.tsypanov at yandex.ru Sat Mar 9 19:42:35 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Sat, 09 Mar 2019 21:42:35 +0200 Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: <1866665646.997163.1552075091851.JavaMail.zimbra@u-pem.fr> References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> <1866665646.997163.1552075091851.JavaMail.zimbra@u-pem.fr> Message-ID: <18773011552160555@myt4-c0b480c282c8.qloud-c.yandex.net> Hi Remi, you are right, for a long time I've used String.join("") or new StringJoiner("") to do some cheating for String concatenation as StringJoiner performs better in many cases. It came to mind that we could use existing StringJoiner, but introduce into it a constructor taking expected length of 'elts' array because currently it is initialized at first add call with amount of 8 causing either overallocation or repeating reallocation with data copying. Imagine the case when we have elts of lenght 1000 fully populated and one more element is added. Current implementation creates new array of length 2000 eventually containing only 1001 elements. Making it possible to allocate StringJoiner's elts of exact size prevents from adding new class but allows performance improvements for the cases when we know the amount of elements to be added. 08.03.2019, 21:58, "Remi Forax" : > Hi, > adding StringChain send the wrong message IMO, we already have StringBuffer, StringBuilder and StringJoiner, > let's try not to add another way to concatenate a variable number of Strings in Java. > > I wonder if you can not achieve what you want by specializing String.join() and StringJoiner if the delimiter is an empty String ? > > R?mi > > ----- Mail original ----- >> ?De: "?????? ???????" >> ??: "core-libs-dev" >> ?Envoy?: Vendredi 8 Mars 2019 20:22:10 >> ?Objet: [PATCH] enhancement proposal for String concatenation > >> ?Hello, >> >> ?I have an enhancement proposal for some cases of String concatenation in Java. >> >> ?Currently we concat Strings mostly using java.lang.StringBuilder. The main >> ?disadvantage of StringBuilder is underlying char array or rather a need to >> ?resize it when the capacity is about to exceed array length and subsequent >> ?copying of array content into newly allocated array. >> >> ?One alternative solution existing is StringJoiner. Before JDK 9 it was a kind of >> ?decorator over StringBuilder, but later it was reworked in order to store >> ?appended Strings into String[] and overall capacity accumulated into int field. >> ?This makes it possible to allocate char[] only once and of exact size in >> ?toString() method reducing allocation cost. >> >> ?My proposal is to copy-paste the code of StringJoinder into newly created class >> ?java.util.StringChain, drop the code responsible for delimiter, prefix and >> ?suffix and use it instead of StringBuilder in common StringBuilder::append >> ?concatenation pattern. >> >> ?Possible use-cases for proposed code are: >> ?- plain String concatenation >> ?- String::chain (new methods) >> ?- Stream.collect(Collectors.joining()) >> ?- StringConcatFactory >> >> ?We can create new methods String.chain(Iterable) and >> ?String.chain(CharSequence...) which allow to encapsulate boilerplate code like >> >> ??StringBuilder sb = new StringBuilder(); >> ??for (CharSequence cs : charSequences) { >> ?? sb.append(cs); >> ??} >> ??String result = sb.toString(): >> >> ?into one line: >> >> ??String result = String.chain(charSequences); >> >> ?As of performance I've done some measurements using JMH on my work machine >> ?(Intel i7-7700) for both Latin and non-Latin Strings of different size and >> ?count. >> ?Here are the results: >> >> ?https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt >> >> ?There is a few corner cases (e.g. 1000 Strings of length 1 appended) when >> ?StringBuilder takes over StringChain constructed with default capacity of 8, >> ?but StringChain constructed with exact added Strings count almost always wins, >> ?especially when dealing with non-Latin chars (Russian in my case). >> >> ?I've also created a separate repo on GitHub with benchmarks: >> >> ?https://github.com/stsypanov/string-chain >> >> ?Key feature here is ability to allocate String array of exact size is cases we >> ?know added elements count. >> ?Thus I think that if the change will be accepted we can add also an overloaded >> ?method String.chain(Collection) as Collection::size allows to >> ?contruct StringChain of exact size. >> >> ?Patch is attached. >> >> ?Kind regards, >> ?Sergei Tsypanov From sergei.tsypanov at yandex.ru Sat Mar 9 19:52:53 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Sat, 09 Mar 2019 21:52:53 +0200 Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> Message-ID: <18873051552161173@iva7-4f557d6b60d4.qloud-c.yandex.net> Hello Ivan, indeed your solution for Iterables is more compact than mine (it can be event shorter with method reference), however it doesn't solve the problem of array reallocation. See my response to Remi below 08.03.2019, 22:01, "Ivan Gerasimov" : > Hi Sergei! > > As you said, this new class is pretty much like StringJoiner with > reduced functionality. > > For appending all elements of an Iterable you could use list.forEach(s > -> sj.add(s)). > > With kind regards, > Ivan > > On 3/8/19 11:22 AM, ?????? ??????? wrote: >> ?Hello, >> >> ?I have an enhancement proposal for some cases of String concatenation in Java. >> >> ?Currently we concat Strings mostly using java.lang.StringBuilder. The main disadvantage of StringBuilder is underlying char array or rather a need to resize it when the capacity is about to exceed array length and subsequent copying of array content into newly allocated array. >> >> ?One alternative solution existing is StringJoiner. Before JDK 9 it was a kind of decorator over StringBuilder, but later it was reworked in order to store appended Strings into String[] and overall capacity accumulated into int field. This makes it possible to allocate char[] only once and of exact size in toString() method reducing allocation cost. >> >> ?My proposal is to copy-paste the code of StringJoinder into newly created class java.util.StringChain, drop the code responsible for delimiter, prefix and suffix and use it instead of StringBuilder in common StringBuilder::append concatenation pattern. >> >> ?Possible use-cases for proposed code are: >> ?- plain String concatenation >> ?- String::chain (new methods) >> ?- Stream.collect(Collectors.joining()) >> ?- StringConcatFactory >> >> ?We can create new methods String.chain(Iterable) and String.chain(CharSequence...) which allow to encapsulate boilerplate code like >> >> ????StringBuilder sb = new StringBuilder(); >> ????for (CharSequence cs : charSequences) { >> ??????sb.append(cs); >> ????} >> ????String result = sb.toString(): >> >> ?into one line: >> >> ????String result = String.chain(charSequences); >> >> ?As of performance I've done some measurements using JMH on my work machine (Intel i7-7700) for both Latin and non-Latin Strings of different size and count. >> ?Here are the results: >> >> ?https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt >> >> ?There is a few corner cases (e.g. 1000 Strings of length 1 appended) when StringBuilder takes over StringChain constructed with default capacity of 8, but StringChain constructed with exact added Strings count almost always wins, especially when dealing with non-Latin chars (Russian in my case). >> >> ?I've also created a separate repo on GitHub with benchmarks: >> >> ?https://github.com/stsypanov/string-chain >> >> ?Key feature here is ability to allocate String array of exact size is cases we know added elements count. >> ?Thus I think that if the change will be accepted we can add also an overloaded method String.chain(Collection) as Collection::size allows to contruct StringChain of exact size. >> >> ?Patch is attached. >> >> ?Kind regards, >> ?Sergei Tsypanov > > -- > With kind regards, > Ivan Gerasimov From peter.levart at gmail.com Sun Mar 10 09:50:39 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 10 Mar 2019 10:50:39 +0100 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: (forgot to send to the list also, so this one if for the list...) On 3/9/19 3:12 PM, Martin Buchholz wrote: > As an old lisper, I would personally love to see syntactic > abstraction, but also understand that this is not in the spirit of Java. > > Given the lack of syntactic abstraction, writing all of those slightly > annoying "if" statements *is* in the spirit of Java - so just do it! > > lambdas have so much performance magic!? My brain is still working out > a performance model.? But no amount of lambda perf machinery will ever > beat that "if" statement! I disagree. In this particular case, this is not true. A lambda that captures no local or instance state is lazily constructed just once (when the lambda expression is 1st evaluated) and then it is used as a "local" constant. The performance model of this statement: ??? Objects.requireNonNullElements(defensiveCopy, i-> "stackTrace[" + i + "]"); Is exactly the same as the performance model of this combo: ??? static class Holder { ??? ??? static final IntFunction messageSupplier = i-> "stackTrace[" + i + "]"; ??? } // ...and then in code: ??? Objects.requireNonNullElements(defensiveCopy, Holder.messageSupplier); The code in requireNonNullElements contains the same loop and the same "if" as the original loop and if statement, so the performance is the same as "that "if" statement". There's even a potential to introduce further optimization if such logic is extracted into a method as opposed to writing in-line loops with ifs (for example with some bulk comparison intrinsified logic) so there is even a potential to "beat" that "if" statement... Regards, Peter > > On Sat, Mar 9, 2019 at 1:23 AM Peter Levart > wrote: > > Hi, > > On 3/8/19 9:35 PM, Martin Buchholz wrote: > > On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev > wrote: > > > >> Hello! > >> > >>> diff -r 274361bd6915 > src/java.base/share/classes/java/lang/Throwable.java > >>> --- a/src/java.base/share/classes/java/lang/Throwable.java? ? > Thu Mar 07 > >>> 10:22:19 2019 +0100 > >>> +++ b/src/java.base/share/classes/java/lang/Throwable.java? ? > Fri Mar 08 > >>> 02:06:42 2019 -0800 > >>> @@ -874,8 +874,7 @@ > >>>? ? ? ? ? ? // Validate argument > >>>? ? ? ? ? ? StackTraceElement[] defensiveCopy = stackTrace.clone(); > >>>? ? ? ? ? ? for (int i = 0; i < defensiveCopy.length; i++) { > >>> -? ? ? ? ? ? if (defensiveCopy[i] == null) > >>> -? ? ? ? ? ? ? ? throw new NullPointerException("stackTrace[" > + i + "]"); > >>> + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i > >>> + "]"); > >> Won't it produce unnecessary garbage due to string concatenation on > >> the common case when all frames are non-null? > >> > > I share Tagir's doubts.? I avoid this construction in > performance sensitive > > code. > > Java doesn't offer syntactic abstraction (can I haz macros?) so > the Java > > Way is to write the explicit if. > > > > Logging frameworks have the same trouble. > > https://github.com/google/flogger > > > > Perhaps hotspot's improved automatic NPE reporting makes the > message detail > > here obsolete? > > If you are referring to the RFR 8218628 by Lindenmaier Goetz which is > being proposed on this list, then I believe it will only pertain to > situations when the bytecode instructions perform the de-reference of > the null reference. In above case, the NPE is thrown explicitly by > throw. Well maybe, if the loop was rewritten into: > > for (int i = 0; i < defensiveCopy.length; i++) { > ?? defensiveCopy[i].getClass(); > } > > ...the automatic message could be created, but I doubt that it > would be > as informative as the custom message above. > > If this is a common situation (from my experience it is and I always > write utility methods for it over and over again), then perhaps a new > utility method could be added to Objects, like the following: > > ???? /** > ????? * Checks that the specified array contains only not {@code > null} > elements > ????? * and throws a customized {@link NullPointerException} if it > doesn't. > ????? * > ????? *

              This method allows creation of customized message > depending > on index > ????? * of 1st element found to be null. > ????? * > ????? * @param array?????????? the array to check for nullity of > elements > ????? * @param messageSupplier supplier of the detail message to be > ????? *??????????????????????? used in the event that an element > of the > array is > ????? *??????????????????????? {@code null} > ????? * @param ???????????? the type of the elements > ????? * @return {@code array} if the array and all its elements are > ????? * not {@code null} > ????? * @throws NullPointerException with no message when {@code > array} > is {@code null} > ????? *????????????????????????????? or else with message returned by > {@code messageSupplier} > ????? *????????????????????????????? when an element of {@code > array} is > {@code null}. > ????? * @since 13 > ????? */ > ???? public static T[] requireNonNullElements(T[] array, > IntFunction messageSupplier) { > ???????? for (int i = 0; i < array.length; i++) { > ???????????? if (array[i] == null) { > ???????????????? throw new NullPointerException(messageSupplier == > null > ? null : messageSupplier.apply(i)); > ???????????? } > ???????? } > ???????? return array; > ???? } > > > The above for loop could then be re-written as: > > ???? Objects.requireNonNullElements(defensiveCopy, i-> > "stackTrace[" + > i+ "]"); > > The lambda in that case is a constant singleton since it does not > capture any surrounding state. > > > Regards, Peter > > From forax at univ-mlv.fr Sun Mar 10 11:21:47 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 10 Mar 2019 12:21:47 +0100 (CET) Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Martin Buchholz" > ?: "Tagir Valeev" > Cc: "core-libs-dev" > Envoy?: Vendredi 8 Mars 2019 21:35:59 > Objet: Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull > On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev wrote: > >> Hello! >> >> > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java >> > --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 >> > 10:22:19 2019 +0100 >> > +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 >> > 02:06:42 2019 -0800 >> > @@ -874,8 +874,7 @@ >> > // Validate argument >> > StackTraceElement[] defensiveCopy = stackTrace.clone(); >> > for (int i = 0; i < defensiveCopy.length; i++) { >> > - if (defensiveCopy[i] == null) >> > - throw new NullPointerException("stackTrace[" + i + "]"); >> > + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i >> > + "]"); >> >> Won't it produce unnecessary garbage due to string concatenation on >> the common case when all frames are non-null? >> > > I share Tagir's doubts. I avoid this construction in performance sensitive > code. > Java doesn't offer syntactic abstraction (can I haz macros?) so the Java > Way is to write the explicit if. > > Logging frameworks have the same trouble. > https://github.com/google/flogger No, they don't if the API use the pattern described by Peter https://github.com/forax/beautiful_logger > > Perhaps hotspot's improved automatic NPE reporting makes the message detail > here obsolete? anyway, i agree with what's Martin and Tagir said, requireNonNull() should not be used in this particular case. R?mi From Alan.Bateman at oracle.com Sun Mar 10 12:17:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Mar 2019 12:17:21 +0000 Subject: RFR (S) 8074817: Resolve disabled warnings for libverify In-Reply-To: References: Message-ID: <34226665-e9db-d921-90e8-2c49013e4bc5@oracle.com> On 08/03/2019 17:35, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8074817 > > Fix: > http://cr.openjdk.java.net/~shade/8074817/webrev.03/ > > This hopefully resolves warnings in libverify. See bug report for warnings list. > This looks okay to me (we should probably have fixed this in 2015 when initially found). -Alan From martinrb at google.com Sun Mar 10 20:19:41 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 Mar 2019 13:19:41 -0700 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: We should stop discussing this here, but ... On Sun, Mar 10, 2019 at 1:51 AM Peter Levart wrote: > > In this particular case, this is not true. A lambda that captures no > local or instance state is lazily constructed just once (when the lambda > expression is 1st evaluated) and then it is used as a "local" constant. > > The performance model of this statement: > > Objects.requireNonNullElements(defensiveCopy, i-> "stackTrace[" + i > + "]"); > > Is exactly the same as the performance model of this combo: > > static class Holder { > static final IntFunction messageSupplier = i-> > "stackTrace[" + i + "]"; > } > I think that one is too expensive! Initialization-on-demand holder idiom requires adding an entry to a jar file and classload at runtime, and causes some overhead in every single java program, even those that don't load the class. (one of the things improved by lambdas!) > // ...and then in code: > > Objects.requireNonNullElements(defensiveCopy, Holder.messageSupplier); > > The code in requireNonNullElements contains the same loop and the same > "if" as the original loop and if statement, so the performance is the > same as "that "if" statement". There's even a potential to introduce > further optimization if such logic is extracted into a method as opposed > to writing in-line loops with ifs (for example with some bulk comparison > intrinsified logic) so there is even a potential to "beat" that "if" > statement... > Users shouldn't have to extract code into methods ("outlining") to get the JIT to optimize. 13 years later, the "easy" JIT bug JDK-6445664 Eliminate remaining performance penalty for using assert still isn't fixed. From takiguc at linux.vnet.ibm.com Mon Mar 11 03:35:09 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 11 Mar 2019 12:35:09 +0900 Subject: RFR: 8220281 IBM-858 alias name is missing on IBM00858 charset In-Reply-To: <97186d40-763d-ed20-569a-ea76c54d802d@oracle.com> References: <97186d40-763d-ed20-569a-ea76c54d802d@oracle.com> Message-ID: Hello Naoto. I appreciate your suggestion. I modified IBMBugs.java testcase. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8220281 Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.01/ > Did you mean "does not have"? Thank you for your confirmation, my statement was not correct. It should be: ====== en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2] IBM00858 charset was registered into IANA Character Sets. [3] And Java already has IBM00858. But IBM00858 charset *does not have* IBM-858 alias. ====== > BTW, have you tested the new test case > on other platforms, i.e., Windows/Linux/macOS? Yes, I ran modified TestIBMBugs.java with jtreg on AIX, Linux x64 and Windows Server 2012 R2. It worked fine on these plaforms. Sorry, I don't have macOS build environment... Thanks, Ichiroh Takiguchi On 2019-03-09 02:56, naoto.sato at oracle.com wrote: > Hi Takiguchi-san, > > Looks good to me. I'd replace Locale.ENGLISH with Locale.ROOT for > toLowerCase() method. > > On 3/7/19 4:57 PM, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8220281 >> Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.00/ >> >> I'd like to obtain a sponsor for this issue. >> >> en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2] >> IBM00858 charset was registered into IANA Character Sets. [3] >> And Java already has IBM00858. >> But IBM00858 charset has IBM-858 alias. > > Did you mean "does not have"? BTW, have you tested the new test case > on other platforms, i.e., Windows/Linux/macOS? > > Naoto > >> Because of this situation, JDK13 does not start on AIX en_US.IBM-858 >> locale. >> >> I'd like to request to add some charset aliases against following >> charsets: >> ? ibm00858, ibm01140, ibm01141, ibm01142, ibm01143, ibm01144, >> ? ibm01145, ibm01146, ibm01147, ibm01148, ibm01149, x-ibm833 >> >> [1] >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/support_languages_locales.htm >> [2] >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.nlsgdrf/support_languages_locales.htm >> [3] >> https://www.iana.org/assignments/character-sets/character-sets.xhtml >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From lukas.eder at gmail.com Fri Mar 8 20:47:38 2019 From: lukas.eder at gmail.com (Lukas Eder) Date: Fri, 8 Mar 2019 21:47:38 +0100 Subject: JDK 12's String::transform vs F#'s |> operator Message-ID: Hello, I've recently learned about JDK 12's new String::transform method: https://bugs.openjdk.java.net/browse/JDK-8203703 Obviously, this is useful. And obviously, this would be far more useful as a general pattern than just something for String. E.g. why not also for any Number subtype. For Boolean. For java.time types. Etc. So, I'm wondering if this is a good opportunity to discuss about more generally useful language features that could do the same thing but for all types. I'm guessing that after Java 8's decision against extension methods and in favour of default methods, the extension method approach will probably be dismissed: public "extension" R T.transform( Function f ) { f.apply(self); } F# (and OCaml and some others) has a very useful operator |> [1]. F# also has the inverse <| operator. It can be implemented relatively easily in languages with tools like extension methods or implicit functions, such as Scala [2], and it is being considered for JavaScript [3]. Before we see tons of new SomeFinalJDKType::transform methods being added on an ad-hoc basis, would a pipeline operator be something useful and worth discussing in Java, as well? Thanks, Lukas [1]: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/ [2]: https://hackernoon.com/operator-in-scala-cbca7b939fc0 [3]: https://github.com/tc39/proposal-pipeline-operator From david.holmes at oracle.com Mon Mar 11 07:03:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Mar 2019 17:03:57 +1000 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <923e5bec-0a33-3824-23d5-d8cfbea6157d@oracle.com> On 7/03/2019 12:48 am, Scott Palmer wrote: > I don?t mean any offence, but I have to say, I strongly disagree with nearly everything you?ve written below. To me, the idea of making a stream of integers for a simple loop counter is hackish, confusing, verbose, and basically abusing the stream concept. The only part I agree with is that it is an obvious performance drawback as well. A counter and a stream of integers are completely different concepts and should not be confused in this manner. I totally agree! The stream variant is just obfuscation at its worst - cleverness for cleverness sake. My 2c. David > Scott > >> On Mar 6, 2019, at 5:10 AM, Tagir Valeev wrote: >> >> Hello! >> >> By the way one of the painful code patterns in modern Java is `for(int >> i = 0; i> newbies and prone to errors as the variable need to be repeated three >> times. Also the variable is not effectively final, despite it never >> changes within the loop body, so could have been considered as >> redeclared on every loop iteration (like in for-each). With the new >> proposal it's possible to write `for(int i : range(0, bound).boxed())` >> (assuming import static j.u.s.IntStream.range), which looks much >> better, though it has obvious performance drawback. Moving >> IterableOnce to BaseStream would enable to use `for(int i : range(0, >> bound))` which looks even better, though again we have plenty of >> garbage (but considerably less than in previous case!). I wonder >> whether Java could evolve to the point where such kind of code would >> be a recommended way to iterate over subsequent integer values without >> any performance handicap. >> >> With best regards, >> Tagir Valeev. >> >> On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: >>> >>> Hi all, >>> >>> Please review and comment on this proposal to allow Stream instances to be used >>> in enhanced-for ("for-each") loops. >>> >>> Abstract >>> >>> Occasionally it's useful to iterate a Stream using a conventional loop. However, >>> the Stream interface doesn't implement Iterable, and therefore streams cannot be >>> used with the enhanced-for statement. This is a proposal to remedy that >>> situation by introducing a new interface IterableOnce that is a subtype of >>> Iterable, and then retrofitting the Stream interface to implement it. Other JDK >>> classes will also be retrofitted to implement IterableOnce. >>> >>> Full Proposal: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html >>> >>> Bug report: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148917 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ >>> >>> Note, this changeset isn't ready to push yet. In particular, it has no tests >>> yet. However, the implementation is so simple that I figured I should include >>> it. Comments on the specification wording are also welcome. >>> >>> Thanks, >>> >>> s'marks > From lenborje at gmail.com Mon Mar 11 08:40:08 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Mon, 11 Mar 2019 09:40:08 +0100 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified Message-ID: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> I'm experimenting with jpackage from the current EA available at https://jdk.java.net/jpackage/ , for the moment on Mac only. I have an existing application which I have previously deployed on multiple platforms using the then bundled javafxpackager. With the current EA (build 17), I find I must specify the --installer-type parameter, otherwise I get the following error: $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage create-installer --overwrite --output /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui --app-image /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app --icon BMF.icns --identifier com.cinnober.bmf.gui.Main --app-version 1.6.10 --verbose jdk.jpackage.internal.PackagerException: Bundler Mac App Store Ready Bundler skipped because of a configuration problem: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. Advice to fix: Either unset 'signBundle' or set 'signBundle' to true. at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:642) at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) Caused by: jdk.jpackage.internal.ConfigException: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. at jdk.jpackage/jdk.jpackage.internal.MacAppStoreBundler.validate(MacAppStoreBundler.java:332) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:705) ... 3 more With the previous javafxpackager this wasn't needed. Javafxpackager always tried to create all installer types and ignored all errors from any specific bundler, e.g. on linux it always tried to create both a Debian package and an rpm and just ignored if any of the requisite builder tools was unavailable. The obvious workaround in my case is to run jpackage twice, once with "--installer-type pkg" and once with "--installer-type dmg", but since I'm furthered hampered by limitations of my toolchain (gradle + badass-jlink-plugin) it would really simplify matters it jpackage could be restored to the javafxpackager behaviour when "--installer-type" is unspecified, e.g. ignore errors and create whatever installers it can. Best regards, /Lennart B?rjeson From peter.levart at gmail.com Mon Mar 11 08:41:49 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 11 Mar 2019 09:41:49 +0100 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> Message-ID: On 3/10/19 9:19 PM, Martin Buchholz wrote: > We should stop discussing this here, but ... ... I think that we really should, but ... > > On Sun, Mar 10, 2019 at 1:51 AM Peter Levart > wrote: > > > In this particular case, this is not true. A lambda that captures no > local or instance state is lazily constructed just once (when the > lambda > expression is 1st evaluated) and then it is used as a "local" > constant. > > The performance model of this statement: > > ???? Objects.requireNonNullElements(defensiveCopy, i-> > "stackTrace[" + i > + "]"); > > Is exactly the same as the performance model of this combo: > > ???? static class Holder { > ???? ??? static final IntFunction messageSupplier = i-> > "stackTrace[" + i + "]"; > ???? } > > > I think that one is too expensive! > Initialization-on-demand holder idiom requires adding an entry to a > jar file and classload at runtime, > and causes some overhead in every single java program, even those that > don't load the class. > (one of the things improved by lambdas!) Yes, I was trying to present the equivalence of performance models of warmed-up code. Inline lambda doesn't require any new entries in jar files, but it has some "initialization" overhead, that's true. > // ...and then in code: > > ???? Objects.requireNonNullElements(defensiveCopy, > Holder.messageSupplier); > > The code in requireNonNullElements contains the same loop and the > same > "if" as the original loop and if statement, so the performance is the > same as "that "if" statement". There's even a potential to introduce > further optimization if such logic is extracted into a method as > opposed > to writing in-line loops with ifs (for example with some bulk > comparison > intrinsified logic) so there is even a potential to "beat" that "if" > statement... > > > Users shouldn't have to extract code into methods ("outlining") to get > the JIT to optimize. No, and this is not the goal here. The original? intent of Joe's patch is to reduce boilerplate while not worsening the (warmed-up?) performance at the same time. I think that the deciding factor about introducing such method should be the frequency of occurrence of such programming pattern in real code. Would introduction and use of such method be worth it on the global scale in the short run? As it turns out, inspecting the code of java.base module, for example, shows that there are some places where such method could be of use, but not enough to warrant its introduction. There are quite a few places where an array or an Iterable is iterated and elements checked for non-nullness, but those loops usually contain other logic too, so It seems that this concrete "if" will stay where it is. Regards, Peter > 13 years later, the "easy" JIT bug > JDK-6445664 > Eliminate remaining performance penalty for using assert > still isn't fixed. From christoph.langer at sap.com Mon Mar 11 08:50:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Mar 2019 08:50:56 +0000 Subject: RFR (XS): 8220409: [TESTBUG] jdk jtreg test jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java - testOverlapWithBaseModule tests the wrong thing Message-ID: Hi, please review this small test fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8220409 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220409.0/ The test uses a wrong option "-add-modules" instead of "--add-modules" in one place. Thanks Christoph From TOSHIONA at jp.ibm.com Mon Mar 11 08:57:11 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 11 Mar 2019 17:57:11 +0900 Subject: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10 In-Reply-To: <052c5c92-2af7-2603-e913-2265e14b3781@oracle.com> References: <052c5c92-2af7-2603-e913-2265e14b3781@oracle.com> Message-ID: Hi Naoto-san, Thank you for reviewing the fix. Could you re-review the updated webrev? http://cr.openjdk.java.net/~tnakamura/8220227/webrev.01/ Thanks, Toshio Nakamura naoto.sato at oracle.com wrote on 2019/03/09 02:39:48: > From: naoto.sato at oracle.com > To: Toshio 5 Nakamura , 18n-dev dev at openjdk.java.net>, core-libs-dev > Date: 2019/03/09 02:39 > Subject: Re: [13] RFR: 8220227: Host Locale Provider > getDisplayCountry returns error message under non-English Win10 > > Hi Nakamura-san, > > Thanks for fixing this. Since it is using a heuristic way to detect > "unknown", I'd use String.endsWith() instead of String.contains() both > in HostLocaleProviderAdapterImpl.java and LocaleProviders.java, which > would be more accurate. > > Naoto > > On 3/7/19 10:25 PM, Toshio 5 Nakamura wrote: > > > > Hi, > > > > Could you review this fix? I'd like to have a sponsor of it, since I'm an > > author. > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8220227&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=cWI02BT4Ii-- > XvWPkl7JnE5M_ShlPLTERbtkTMMn1mU&s=8UA5DKmhd3SIIZmsX8JNOvaQ5wxcIq5bwdtHAnZLsPU&e= > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8220227_webrev. > 00_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=cWI02BT4Ii-- > XvWPkl7JnE5M_ShlPLTERbtkTMMn1mU&s=kLSymGjxW5MrGtWY3zs7VEdg1BN6nYGQjue1w- > nPs7c&e= > > > > Issue: > > Under Windows 10 non-English, Locale.getDisplayCountry() shows an error > > message, > > if Host Locale Provider is used (-Djava.locale.providers=HOST). > > > > Fix proposal: > > The current code compares "Unknown Region (" with the result, but it could > > be translated. > > I believe we can compare it with "("+RegionCode+")", which covers all 38 > > Language > > Packs of Windows Server 2016. > > > > Thanks, > > Toshio Nakamura > > > From peter.levart at gmail.com Mon Mar 11 09:04:40 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 11 Mar 2019 10:04:40 +0100 Subject: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s) Message-ID: <84b2fb20-2e6e-6307-afd8-8eafcfb311a5@gmail.com> Hello, I stumbled on the specification of a static utility method CharSequence#compare introduced in Java 11 which says: ???? * Compares two {@code CharSequence} instances lexicographically. Returns a ???? * negative value, zero, or a positive value if the first sequence is lexicographically ???? * less than, equal to, or greater than the second, respectively. The implementation of this method does the following: ??? public static int compare(CharSequence cs1, CharSequence cs2) { ??????? if (Objects.requireNonNull(cs1) == Objects.requireNonNull(cs2)) { ??????????? return 0; ??????? } ??????? if (cs1.getClass() == cs2.getClass() && cs1 instanceof Comparable) { ??????????? return ((Comparable) cs1).compareTo(cs2); ??????? } ??? ??? ... lexical comparison char-by-char ... This means that if the method is called with two instances of the same class that also implements Comparable, the comparison is delegated to the .compareTo() method of that class. But CharSequence interface neither extends Comparable nor does it specify? what such CharSequence implementations should conform to when they also implement Comparable. There could be a perfectly valid custom CharSequence implementation that implemented Comparable which doesn't order instances lexicographically. The guarantee this method gives is not respected in this case. So, what shall be done? - nothing - CharSequence interface specification should be extended to require Comparable CharSeqeunces to implement lexicographical ordering - CharSequence#compare method specification should be extended to inform the users about that delegation to Comparable CharSequence(s) - CharSequence#compare method implementation should be changed to not delegate to .compareTo() (at all or just for "unknown" Comparable CharSequence(s)) Regards, Peter From Alan.Bateman at oracle.com Mon Mar 11 09:03:52 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2019 09:03:52 +0000 Subject: RFR (XS): 8220409: [TESTBUG] jdk jtreg test jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java - testOverlapWithBaseModule tests the wrong thing In-Reply-To: References: Message-ID: On 11/03/2019 08:50, Langer, Christoph wrote: > Hi, > > please review this small test fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220409 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220409.0/ > > The test uses a wrong option "-add-modules" instead of "--add-modules" in one place. > The change to testOverlapWithBaseModule looks okay, the changes to the imports are not needed but okay too. -Alan From shade at redhat.com Mon Mar 11 11:52:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Mar 2019 12:52:38 +0100 Subject: RFR (S) 8074817: Resolve disabled warnings for libverify In-Reply-To: <34226665-e9db-d921-90e8-2c49013e4bc5@oracle.com> References: <34226665-e9db-d921-90e8-2c49013e4bc5@oracle.com> Message-ID: On 3/10/19 1:17 PM, Alan Bateman wrote: > On 08/03/2019 17:35, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8074817 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8074817/webrev.03/ >> >> This hopefully resolves warnings in libverify. See bug report for warnings list. >> > This looks okay to me (we should probably have fixed this in 2015 when initially found). Thanks! Pushed. -Aleksey From lenborje at gmail.com Mon Mar 11 11:55:22 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Mon, 11 Mar 2019 12:55:22 +0100 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> Message-ID: Looking into the code of Arguments.generateBundle(Map params), I believe it's a bug to immediately throw an error when a bundler has configuration problems. Instead, that bundler should be removed from the platformBundlers List. Quick-and-dirty solution: diff -r e11f3bf34083 src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java --- a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java Fri Mar 01 08:27:51 2019 -0500 +++ b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java Mon Mar 11 12:37:43 2019 +0100 @@ -37,6 +37,7 @@ import java.util.HashMap; import java.util.HashSet; import java.util.List; +import java.util.ListIterator; import java.util.Map; import java.util.Set; import java.util.Properties; @@ -655,7 +656,10 @@ // clean these extra (and unneeded) temp directories. StandardBundlerParam.BUILD_ROOT.fetchFrom(params); - for (jdk.jpackage.internal.Bundler bundler : getPlatformBundlers()) { + List platformBundlers = getPlatformBundlers(); + ListIterator platformBundleIterator = platformBundlers.listIterator(); + while (platformBundleIterator.hasNext()) { + jdk.jpackage.internal.Bundler bundler = platformBundleIterator.next(); Map localParams = new HashMap<>(params); try { if (bundler.validate(localParams)) { @@ -677,18 +681,20 @@ } catch (ConfigException e) { Log.debug(e); if (e.getAdvice() != null) { - throw new PackagerException(e, + Log.info(new PackagerException(e, "MSG_BundlerConfigException", - bundler.getName(), e.getMessage(), e.getAdvice()); + bundler.getName(), e.getMessage(), e.getAdvice()).getMessage()); } else { - throw new PackagerException(e, + Log.info(new PackagerException(e, "MSG_BundlerConfigExceptionNoAdvice", - bundler.getName(), e.getMessage()); + bundler.getName(), e.getMessage()).getMessage()); } + platformBundleIterator.remove(); } catch (RuntimeException re) { Log.debug(re); - throw new PackagerException(re, "MSG_BundlerRuntimeException", - bundler.getName(), re.toString()); + Log.info(new PackagerException(re, "MSG_BundlerRuntimeException", + bundler.getName(), re.toString()).getMessage()); + platformBundleIterator.remove(); } finally { if (userProvidedBuildRoot) { Log.verbose(MessageFormat.format( Best regards, /Lennart B?rjeson > 11 mars 2019 kl. 09:40 skrev Lennart B?rjeson : > > I'm experimenting with jpackage from the current EA available at https://jdk.java.net/jpackage/ , for the moment on Mac only. > > I have an existing application which I have previously deployed on multiple platforms using the then bundled javafxpackager. > > With the current EA (build 17), I find I must specify the --installer-type parameter, otherwise I get the following error: > > $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage create-installer --overwrite --output /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui --app-image /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app --icon BMF.icns --identifier com.cinnober.bmf.gui.Main --app-version 1.6.10 --verbose > jdk.jpackage.internal.PackagerException: Bundler Mac App Store Ready Bundler skipped because of a configuration problem: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. > Advice to fix: Either unset 'signBundle' or set 'signBundle' to true. > at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726) > at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:642) > at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) > at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) > Caused by: jdk.jpackage.internal.ConfigException: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. > at jdk.jpackage/jdk.jpackage.internal.MacAppStoreBundler.validate(MacAppStoreBundler.java:332) > at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:705) > ... 3 more > > With the previous javafxpackager this wasn't needed. Javafxpackager always tried to create all installer types and ignored all errors from any specific bundler, e.g. on linux it always tried to create both a Debian package and an rpm and just ignored if any of the requisite builder tools was unavailable. > > The obvious workaround in my case is to run jpackage twice, once with "--installer-type pkg" and once with "--installer-type dmg", but since I'm furthered hampered by limitations of my toolchain (gradle + badass-jlink-plugin) it would really simplify matters it jpackage could be restored to the javafxpackager behaviour when "--installer-type" is unspecified, e.g. ignore errors and create whatever installers it can. > > > Best regards, > > /Lennart B?rjeson > > From david.lloyd at redhat.com Mon Mar 11 13:09:45 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 11 Mar 2019 08:09:45 -0500 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: Is vfork still guaranteed to be functional by the end of the Java 11 support frame, from the perspective of any organization which supports JDKs of this version? On Fri, Mar 8, 2019 at 9:22 AM Andrew Haley wrote: > > On 3/8/19 2:39 PM, Langer, Christoph wrote: > > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. > > I don't see any explanation of why this should go into jdk11. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- - DML From christoph.langer at sap.com Mon Mar 11 14:36:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Mar 2019 14:36:54 +0000 Subject: RFR (XS): 8220409: [TESTBUG] jdk jtreg test jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java - testOverlapWithBaseModule tests the wrong thing In-Reply-To: References: Message-ID: Thanks for the review, Alan. I pushed it. > -----Original Message----- > From: Alan Bateman > Sent: Montag, 11. M?rz 2019 10:04 > To: Langer, Christoph ; Java Core Libs dev at openjdk.java.net>; jigsaw-dev > Subject: Re: RFR (XS): 8220409: [TESTBUG] jdk jtreg test > jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java > - testOverlapWithBaseModule tests the wrong thing > > On 11/03/2019 08:50, Langer, Christoph wrote: > > Hi, > > > > please review this small test fix. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220409 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220409.0/ > > > > The test uses a wrong option "-add-modules" instead of "--add-modules" > in one place. > > > The change to testOverlapWithBaseModule looks okay, the changes to the > imports are not needed but okay too. > > -Alan > From bob.vandette at oracle.com Mon Mar 11 15:13:16 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 11 Mar 2019 11:13:16 -0400 Subject: RFR: Container Fixes (8219652, 8217766, 8212528) Message-ID: Please review these three fixes for Linux Docker/cgroup container support. https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in osContainer_linux.cpp#L102 appears unreachable This change corrects a rarely used hotspot code path to be compatible with the Java based Metrics. https://bugs.openjdk.java.net/browse/JDK-8212528 - Wrong cgroup subsystem being used for some CPU Container Metrics Most Linux distros provide symbolic links for cpuacct and cpu controller directories. Docker on the Mac does not. This causes some of the cpu statistics to be unreported. https://bugs.openjdk.java.net/browse/JDK-8217766 - Container Support doesn't work for some Join Controllers combinations The cgroup identification -implemented by parsing /proc/self/mountinfo and /proc/self/cgroup- assumed each cgroup controller was mounted disjoint from the others (except for "cpu" and "cpuacct" controllers). Which means, we expected one single controller per mountinfo line. This matches the way most Linux distributions currently configure cgroupsv1 by default. Yet controllers can be grouped arbitrarily. For instance, using the JoinControllers systemd directive. One use case for that is to let Kubernetes' kubelet discover his own dedicated and reserved cgroup hierarchy. In that situation, the JVM fails to discover the expected cgroup controllers set, and, when running containerized, default to a suboptimal understanding of available resources. Supporting arbitrarily controllers groups per mountpoint actually allows for simpler and easier to follow code, as we don't need nested if/else for every controller. This fix also updates the Containers Metrics, to support joint controllers. Bob. From bob.vandette at oracle.com Mon Mar 11 15:15:40 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 11 Mar 2019 11:15:40 -0400 Subject: RFR: Container Fixes (8219652, 8217766, 8212528) In-Reply-To: References: Message-ID: <4DECB008-08C6-444C-9BC5-E0D4C6D4D76F@oracle.com> Sorry, missed a link: http://cr.openjdk.java.net/~bobv/8217766/webrev.0/ Bob. > On Mar 11, 2019, at 11:13 AM, Bob Vandette wrote: > > Please review these three fixes for Linux Docker/cgroup container support. > > https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in osContainer_linux.cpp#L102 appears unreachable > > This change corrects a rarely used hotspot code path to be compatible with the Java based Metrics. > > https://bugs.openjdk.java.net/browse/JDK-8212528 - Wrong cgroup subsystem being used for some CPU Container Metrics > > Most Linux distros provide symbolic links for cpuacct and cpu controller directories. Docker on the Mac does not. > This causes some of the cpu statistics to be unreported. > > https://bugs.openjdk.java.net/browse/JDK-8217766 - Container Support doesn't work for some Join Controllers combinations > > The cgroup identification -implemented by parsing /proc/self/mountinfo > and /proc/self/cgroup- assumed each cgroup controller was mounted > disjoint from the others (except for "cpu" and "cpuacct" controllers). > Which means, we expected one single controller per mountinfo line. > > This matches the way most Linux distributions currently configure > cgroupsv1 by default. Yet controllers can be grouped arbitrarily. > For instance, using the JoinControllers systemd directive. > One use case for that is to let Kubernetes' kubelet discover his own > dedicated and reserved cgroup hierarchy. In that situation, the JVM > fails to discover the expected cgroup controllers set, and, when running > containerized, default to a suboptimal understanding of available resources. > > Supporting arbitrarily controllers groups per mountpoint actually > allows for simpler and easier to follow code, as we don't need nested > if/else for every controller. > > This fix also updates the Containers Metrics, to support joint controllers. > > Bob. > > > From adam.farley at uk.ibm.com Mon Mar 11 15:48:02 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 11 Mar 2019 15:48:02 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> Message-ID: Hi Mandy, Thank you for explaining. :) Unfortunately I'm only a mere Author, and I cannot submit test runs on the shared test server. I have run the test locally, and it passes against a patched build and fails correctly agaionst an unpatched build, so I think we're good to go. Can you tell me if there's something I can do to help move the CSR forward? Also, can you tell me if an additional CSR would need to be created for other releases if this fix gets backported? Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 07/03/2019 23:17:15: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 07/03/2019 23:19 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > > > On 3/7/19 9:44 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > Since you have created a new work item to cover the test work, do let > > me know if you want the test code removed from the webrev for the > > original issue. > > You push what you have. Your fix should come with a regression test. > Please make sure you do jdk-submit to verify the test work. > > > Also, by "nobody is meant to be changing final fields anyway", I was > > explaining my decision to setAccessible(true) on the final fields by > > default, rather than setting it via a control bit as you suggested. > > Seemed to save code while exposing us to minimal risk, because the > > field is meant to be immutable (final). > > > > Lastly, I'm sorry to see you weren't happy with the quality of my test > > code. Your changes seem much larger in scale, and quite different to > > my changes. Could you explain the benefits of your approach, vs simply > > adding non-static final fields to my code? > > First, I dont see my test update is large scale. Second, it's not > about the quality of the test code. The size of the change is not > the sole factor to consider but that seems to bother you. Anyway, > the test itself isn't easy to work with. You have done the fix to > include the regression test which is okay. > > Your patch made me to look at the test closer which I started from > the version in the repo, not based on your version. Once you push > your fix, I can generate a new webrev to see the diff that I can > revise on top of your version. > > I change a couple things. The test uses Error in HasFields.CASES to > indicate a negative test. For a final field, it has no write access > and it is a negative test case except unreflectSetter on an instance > final field whose accessible flag is true. That explains why > Error.class is in the third element of the new case added for final > field that actually reflects if a test case is positive or negative > when calling testAccessor. What you added is treating setter on > final field is positive test case and then returns when IAE is thrown. > It does the work but passing incorrect information. > > I uncovered some unnecessary test cases for findSetter on > static fields and findStaticSetter on non-static fields. It's an > existing test issue and I think they should be filtered out and > that's why CASES is separated into two separate ArrayLists and the new > static cases(int testMode) method. I see that you used a new kind for > static final field that may be a good approach. When I pull down your > change, I will send out a revision (that's why I wait for your patch > to go in first and see any thing I should change). > > Hope this helps. > > Mandy > 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 at hotmail.com Mon Mar 11 16:24:33 2019 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 11 Mar 2019 16:24:33 +0000 Subject: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s) In-Reply-To: <84b2fb20-2e6e-6307-afd8-8eafcfb311a5@gmail.com> References: <84b2fb20-2e6e-6307-afd8-8eafcfb311a5@gmail.com> Message-ID: Hi Peter, The initial implementation was only optimized to call into String.compare if the arguments were string [1]. I proposed the current code a general form to catch java.nio.CharBuffer and any new JDK implementations of CharSequence + Comparable. Naively, I lean towards "- CharSequence interface specification should be extended to require Comparable CharSeqeunces to implement lexicographical ordering". Jason 1: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/051124.html ________________________________________ From: core-libs-dev on behalf of Peter Levart Sent: Monday, March 11, 2019 4:04 AM To: core-libs-dev Subject: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s) Hello, I stumbled on the specification of a static utility method CharSequence#compare introduced in Java 11 which says: * Compares two {@code CharSequence} instances lexicographically. Returns a * negative value, zero, or a positive value if the first sequence is lexicographically * less than, equal to, or greater than the second, respectively. The implementation of this method does the following: public static int compare(CharSequence cs1, CharSequence cs2) { if (Objects.requireNonNull(cs1) == Objects.requireNonNull(cs2)) { return 0; } if (cs1.getClass() == cs2.getClass() && cs1 instanceof Comparable) { return ((Comparable) cs1).compareTo(cs2); } ... lexical comparison char-by-char ... This means that if the method is called with two instances of the same class that also implements Comparable, the comparison is delegated to the .compareTo() method of that class. But CharSequence interface neither extends Comparable nor does it specify what such CharSequence implementations should conform to when they also implement Comparable. There could be a perfectly valid custom CharSequence implementation that implemented Comparable which doesn't order instances lexicographically. The guarantee this method gives is not respected in this case. So, what shall be done? - nothing - CharSequence interface specification should be extended to require Comparable CharSeqeunces to implement lexicographical ordering - CharSequence#compare method specification should be extended to inform the users about that delegation to Comparable CharSequence(s) - CharSequence#compare method implementation should be changed to not delegate to .compareTo() (at all or just for "unknown" Comparable CharSequence(s)) Regards, Peter From naoto.sato at oracle.com Mon Mar 11 16:28:08 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 11 Mar 2019 09:28:08 -0700 Subject: RFR: 8220281 IBM-858 alias name is missing on IBM00858 charset In-Reply-To: References: <97186d40-763d-ed20-569a-ea76c54d802d@oracle.com> Message-ID: <527ece36-517f-7ffc-6cb2-d13e1b0d4a41@oracle.com> Looks good to me, thanks. I can sponsor your fix. Naoto On 3/10/19 8:35 PM, Ichiroh Takiguchi wrote: > Hello Naoto. > > I appreciate your suggestion. > I modified IBMBugs.java testcase. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8220281 > Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.01/ > >> Did you mean "does not have"? > > Thank you for your confirmation, my statement was not correct. > It should be: > ====== > en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2] > IBM00858 charset was registered into IANA Character Sets. [3] > And Java already has IBM00858. > But IBM00858 charset *does not have* IBM-858 alias. > ====== > >> BTW, have you tested the new test case >> on other platforms, i.e., Windows/Linux/macOS? > Yes, I ran modified TestIBMBugs.java with jtreg on AIX, Linux x64 and > Windows Server 2012 R2. > It worked fine on these plaforms. > Sorry, I don't have macOS build environment... > > Thanks, > Ichiroh Takiguchi > > On 2019-03-09 02:56, naoto.sato at oracle.com wrote: >> Hi Takiguchi-san, >> >> Looks good to me. I'd replace Locale.ENGLISH with Locale.ROOT for >> toLowerCase() method. >> >> On 3/7/19 4:57 PM, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8220281 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.00/ >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2] >>> IBM00858 charset was registered into IANA Character Sets. [3] >>> And Java already has IBM00858. >>> But IBM00858 charset has IBM-858 alias. >> >> Did you mean "does not have"? BTW, have you tested the new test case >> on other platforms, i.e., Windows/Linux/macOS? >> >> Naoto >> >>> Because of this situation, JDK13 does not start on AIX en_US.IBM-858 >>> locale. >>> >>> I'd like to request to add some charset aliases against following >>> charsets: >>> ?? ibm00858, ibm01140, ibm01141, ibm01142, ibm01143, ibm01144, >>> ?? ibm01145, ibm01146, ibm01147, ibm01148, ibm01149, x-ibm833 >>> >>> [1] >>> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/support_languages_locales.htm >>> [2] >>> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.nlsgdrf/support_languages_locales.htm >>> [3] https://www.iana.org/assignments/character-sets/character-sets.xhtml >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> > From joe.darcy at oracle.com Mon Mar 11 16:29:46 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 11 Mar 2019 09:29:46 -0700 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> Message-ID: Hello, Always surprising how much discussion an (apparently) simple refactoring can generate! Thanks to Tagir for spotting this issue. For completeness, the two-argument forms of requireNonNull which takes a Supplier is not applicable to preserve the message behavior since the loop counter i is not final or effectively final: ??? Objects.requireNonNull(defensiveCopy[i],? () -> "stackTrace[" + i + "]"); Therefore, I'll revert this use of requireNonNull in Throwable but keep the other three: diff -r 289fd6cb7480 src/java.base/share/classes/java/lang/Throwable.java --- a/src/java.base/share/classes/java/lang/Throwable.java??? Mon Mar 11 15:34:16 2019 +0100 +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Mon Mar 11 09:28:51 2019 -0700 @@ -914,8 +914,7 @@ ???????????????? for (Throwable t : suppressedExceptions) { ???????????????????? // Enforce constraints on suppressed exceptions in ???????????????????? // case of corrupt or malicious stream. -??????????????????? if (t == null) -??????????????????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); +??????????????????? Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); ???????????????????? if (t == this) ???????????????????????? throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); ???????????????????? suppressed.add(t); @@ -942,8 +941,7 @@ ???????????????? stackTrace = null; ???????????? } else { // Verify stack trace elements are non-null. ???????????????? for(StackTraceElement ste : stackTrace) { -??????????????????? if (ste == null) -??????????????????????? throw new NullPointerException("null StackTraceElement in serial stream. "); +??????????????????? Objects.requireNonNull(ste, "null StackTraceElement in serial stream."); ???????????????? } ???????????? } ???????? } else { @@ -1034,8 +1032,7 @@ ???????? if (exception == this) ???????????? throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); -??????? if (exception == null) -??????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); +??????? Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); ???????? if (suppressedExceptions == null) // Suppressed exceptions not recorded ???????????? return; Thanks, -Joe On 3/10/2019 4:21 AM, Remi Forax wrote: > ----- Mail original ----- >> De: "Martin Buchholz" >> ?: "Tagir Valeev" >> Cc: "core-libs-dev" >> Envoy?: Vendredi 8 Mars 2019 21:35:59 >> Objet: Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull >> On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev wrote: >> >>> Hello! >>> >>>> diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java >>>> --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 >>>> 10:22:19 2019 +0100 >>>> +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 >>>> 02:06:42 2019 -0800 >>>> @@ -874,8 +874,7 @@ >>>> // Validate argument >>>> StackTraceElement[] defensiveCopy = stackTrace.clone(); >>>> for (int i = 0; i < defensiveCopy.length; i++) { >>>> - if (defensiveCopy[i] == null) >>>> - throw new NullPointerException("stackTrace[" + i + "]"); >>>> + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i >>>> + "]"); >>> Won't it produce unnecessary garbage due to string concatenation on >>> the common case when all frames are non-null? >>> >> I share Tagir's doubts. I avoid this construction in performance sensitive >> code. >> Java doesn't offer syntactic abstraction (can I haz macros?) so the Java >> Way is to write the explicit if. >> >> Logging frameworks have the same trouble. >> https://github.com/google/flogger > > No, they don't if the API use the pattern described by Peter > https://github.com/forax/beautiful_logger > >> Perhaps hotspot's improved automatic NPE reporting makes the message detail >> here obsolete? > anyway, i agree with what's Martin and Tagir said, requireNonNull() should not be used in this particular case. > > R?mi From naoto.sato at oracle.com Mon Mar 11 16:29:02 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 11 Mar 2019 09:29:02 -0700 Subject: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10 In-Reply-To: References: <052c5c92-2af7-2603-e913-2265e14b3781@oracle.com> Message-ID: <8373556b-982d-b7e6-aa29-3344d9d563c7@oracle.com> Looks good to me. I can sponsor your fix. Naoto On 3/11/19 1:57 AM, Toshio 5 Nakamura wrote: > Hi Naoto-san, > > Thank you for reviewing the fix. > Could you re-review the updated webrev? > > http://cr.openjdk.java.net/~tnakamura/8220227/webrev.01/ > > Thanks, > Toshio Nakamura > > naoto.sato at oracle.com wrote on 2019/03/09 02:39:48: > > > From: naoto.sato at oracle.com > > To: Toshio 5 Nakamura , 18n-dev > dev at openjdk.java.net>, core-libs-dev > > Date: 2019/03/09 02:39 > > Subject: Re: [13] RFR: 8220227: Host Locale Provider > > getDisplayCountry returns error message under non-English Win10 > > > > Hi Nakamura-san, > > > > Thanks for fixing this. Since it is using a heuristic way to detect > > "unknown", I'd use String.endsWith() instead of String.contains() both > > in HostLocaleProviderAdapterImpl.java and LocaleProviders.java, which > > would be more accurate. > > > > Naoto > > > > On 3/7/19 10:25 PM, Toshio 5 Nakamura wrote: > > > > > > Hi, > > > > > > Could you review this fix? I'd like to have a sponsor of it, since > I'm an > > > author. > > > > > > Bug: INVALID URI REMOVED > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8220227&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=cWI02BT4Ii-- > > > XvWPkl7JnE5M_ShlPLTERbtkTMMn1mU&s=8UA5DKmhd3SIIZmsX8JNOvaQ5wxcIq5bwdtHAnZLsPU&e= > > > Webrev: INVALID URI REMOVED > > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8220227_webrev. > > 00_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=cWI02BT4Ii-- > > XvWPkl7JnE5M_ShlPLTERbtkTMMn1mU&s=kLSymGjxW5MrGtWY3zs7VEdg1BN6nYGQjue1w- > > nPs7c&e= > > > > > > Issue: > > > Under Windows 10 non-English, Locale.getDisplayCountry() shows an error > > > message, > > > if Host Locale Provider is used (-Djava.locale.providers=HOST). > > > > > > Fix proposal: > > > The current code compares "Unknown Region (" with the result, but > it could > > > be translated. > > > I believe we can compare it with "("+RegionCode+")", which covers > all 38 > > > Language > > > Packs of Windows Server 2016. > > > > > > Thanks, > > > Toshio Nakamura > > > > > > From andy.herrick at oracle.com Mon Mar 11 17:04:27 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 11 Mar 2019 13:04:27 -0400 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> Message-ID: <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> Although we plan to remove the mac-app-store intaller type for the first release (which will fix this instance the problem for now) I agree this is not right for an exception in one install type to prevent the other types (if there are any) from running. I think instead though we should try to run them all, then log what succeeded and then throw the exception if any failed. /Andy On 3/11/2019 7:55 AM, Lennart B?rjeson wrote: > Looking into the code of Arguments.generateBundle(Map params), I believe it's a bug to immediately throw an error when a bundler has configuration problems. > > Instead, that bundler should be removed from the platformBundlers List. Quick-and-dirty solution: > > > diff -r e11f3bf34083 src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java > --- a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java Fri Mar 01 08:27:51 2019 -0500 > +++ b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java Mon Mar 11 12:37:43 2019 +0100 > @@ -37,6 +37,7 @@ > import java.util.HashMap; > import java.util.HashSet; > import java.util.List; > +import java.util.ListIterator; > import java.util.Map; > import java.util.Set; > import java.util.Properties; > @@ -655,7 +656,10 @@ > // clean these extra (and unneeded) temp directories. > StandardBundlerParam.BUILD_ROOT.fetchFrom(params); > > - for (jdk.jpackage.internal.Bundler bundler : getPlatformBundlers()) { > + List platformBundlers = getPlatformBundlers(); > + ListIterator platformBundleIterator = platformBundlers.listIterator(); > + while (platformBundleIterator.hasNext()) { > + jdk.jpackage.internal.Bundler bundler = platformBundleIterator.next(); > Map localParams = new HashMap<>(params); > try { > if (bundler.validate(localParams)) { > @@ -677,18 +681,20 @@ > } catch (ConfigException e) { > Log.debug(e); > if (e.getAdvice() != null) { > - throw new PackagerException(e, > + Log.info(new PackagerException(e, > "MSG_BundlerConfigException", > - bundler.getName(), e.getMessage(), e.getAdvice()); > + bundler.getName(), e.getMessage(), e.getAdvice()).getMessage()); > } else { > - throw new PackagerException(e, > + Log.info(new PackagerException(e, > "MSG_BundlerConfigExceptionNoAdvice", > - bundler.getName(), e.getMessage()); > + bundler.getName(), e.getMessage()).getMessage()); > } > + platformBundleIterator.remove(); > } catch (RuntimeException re) { > Log.debug(re); > - throw new PackagerException(re, "MSG_BundlerRuntimeException", > - bundler.getName(), re.toString()); > + Log.info(new PackagerException(re, "MSG_BundlerRuntimeException", > + bundler.getName(), re.toString()).getMessage()); > + platformBundleIterator.remove(); > } finally { > if (userProvidedBuildRoot) { > Log.verbose(MessageFormat.format( > > > Best regards, > > /Lennart B?rjeson > >> 11 mars 2019 kl. 09:40 skrev Lennart B?rjeson : >> >> I'm experimenting with jpackage from the current EA available at https://jdk.java.net/jpackage/ , for the moment on Mac only. >> >> I have an existing application which I have previously deployed on multiple platforms using the then bundled javafxpackager. >> >> With the current EA (build 17), I find I must specify the --installer-type parameter, otherwise I get the following error: >> >> $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage create-installer --overwrite --output /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui --app-image /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app --icon BMF.icns --identifier com.cinnober.bmf.gui.Main --app-version 1.6.10 --verbose >> jdk.jpackage.internal.PackagerException: Bundler Mac App Store Ready Bundler skipped because of a configuration problem: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. >> Advice to fix: Either unset 'signBundle' or set 'signBundle' to true. >> at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726) >> at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:642) >> at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) >> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) >> Caused by: jdk.jpackage.internal.ConfigException: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. >> at jdk.jpackage/jdk.jpackage.internal.MacAppStoreBundler.validate(MacAppStoreBundler.java:332) >> at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:705) >> ... 3 more >> >> With the previous javafxpackager this wasn't needed. Javafxpackager always tried to create all installer types and ignored all errors from any specific bundler, e.g. on linux it always tried to create both a Debian package and an rpm and just ignored if any of the requisite builder tools was unavailable. >> >> The obvious workaround in my case is to run jpackage twice, once with "--installer-type pkg" and once with "--installer-type dmg", but since I'm furthered hampered by limitations of my toolchain (gradle + badass-jlink-plugin) it would really simplify matters it jpackage could be restored to the javafxpackager behaviour when "--installer-type" is unspecified, e.g. ignore errors and create whatever installers it can. >> >> >> Best regards, >> >> /Lennart B?rjeson >> >> From andy.herrick at oracle.com Mon Mar 11 17:07:39 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 11 Mar 2019 13:07:39 -0400 Subject: RFR: JDK-8215574 : Investigate and document usage of --category, --copyright, --vendor and --description In-Reply-To: References: Message-ID: <85ba1dc7-83dc-54be-8266-51033444d969@oracle.com> Looks good. /Andy On 3/8/2019 6:46 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Removed unused TITLE which is just APP_NAME. > - Fix maintainer for DEB packages "vendor " instead of vendor > or just email. > - Fixed description for RPM, used to be just app name. > - Fixed version and description for .exe installers. > - Removed Comments and added Manufacturer attribute to Wix config > file. Comments is not needed and Manufacturer is optional based on spec. > > [1] https://bugs.openjdk.java.net/browse/JDK-8215574 > > [2] http://cr.openjdk.java.net/~almatvee/8215574/webrev.00/ > > Thanks, > Alexander From andy.herrick at oracle.com Mon Mar 11 17:08:16 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 11 Mar 2019 13:08:16 -0400 Subject: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty In-Reply-To: References: <2c51cff8-1b17-4b73-a15d-ff6ce08ca68e@oracle.com> <82961966-139a-96d4-1049-96857f8ff5fd@oracle.com> Message-ID: looks good. /Andy On 3/7/2019 5:52 PM, Alexander Matveev wrote: > Hi Erik, > > http://cr.openjdk.java.net/~almatvee/8214566/webrev.01/ > > - Removed $(call SET_SHARED_LIBRARY_ORIGIN), TOOLCHAIN_LINK_CXX and > linking with libjava. > > Thanks, > Alexander > > On 3/7/2019 6:52 AM, Erik Joelsson wrote: >> Hello Alexander, >> >> A few notes: >> >> $(call SET_SHARED_LIBRARY_ORIGIN) and TOOLCHAIN_LINK_CXX have no >> effect on Windows, so should be removed to avoid confusion in the >> future. >> >> This new library does not link with libjava so I see no need to add >> that prerequisite declaration. >> >> /Erik >> >> On 2019-03-06 17:10, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Added custom action to check installation folder and display >>> confirmation dialog to ask user to continue installation if >>> destination folder is not empty. This is same behavior and >>> confirmation message as for .exe. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8214566 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ >>> >>> Thanks, >>> Alexander > From mandy.chung at oracle.com Mon Mar 11 17:59:36 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 Mar 2019 10:59:36 -0700 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> Message-ID: The updated patch looks good. Mandy On 3/11/19 9:29 AM, Joe Darcy wrote: > Hello, > > Always surprising how much discussion an (apparently) simple refactoring > can generate! > > Thanks to Tagir for spotting this issue. > > For completeness, the two-argument forms of requireNonNull which takes a > Supplier is not applicable to preserve the message behavior > since the loop counter i is not final or effectively final: > > ??? Objects.requireNonNull(defensiveCopy[i],? () -> "stackTrace[" + i + > "]"); > > Therefore, I'll revert this use of requireNonNull in Throwable but keep > the other three: > > diff -r 289fd6cb7480 src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java??? Mon Mar 11 > 15:34:16 2019 +0100 > +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Mon Mar 11 > 09:28:51 2019 -0700 > @@ -914,8 +914,7 @@ > ???????????????? for (Throwable t : suppressedExceptions) { > ???????????????????? // Enforce constraints on suppressed exceptions in > ???????????????????? // case of corrupt or malicious stream. > -??????????????????? if (t == null) > -??????????????????????? throw new > NullPointerException(NULL_CAUSE_MESSAGE); > +??????????????????? Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); > ???????????????????? if (t == this) > ???????????????????????? throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > ???????????????????? suppressed.add(t); > @@ -942,8 +941,7 @@ > ???????????????? stackTrace = null; > ???????????? } else { // Verify stack trace elements are non-null. > ???????????????? for(StackTraceElement ste : stackTrace) { > -??????????????????? if (ste == null) > -??????????????????????? throw new NullPointerException("null > StackTraceElement in serial stream. "); > +??????????????????? Objects.requireNonNull(ste, "null StackTraceElement > in serial stream."); > ???????????????? } > ???????????? } > ???????? } else { > @@ -1034,8 +1032,7 @@ > ???????? if (exception == this) > ???????????? throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > -??????? if (exception == null) > -??????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); > +??????? Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); > > ???????? if (suppressedExceptions == null) // Suppressed exceptions not > recorded > ???????????? return; > > Thanks, > > -Joe From huizhe.wang at oracle.com Mon Mar 11 18:22:12 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 Mar 2019 11:22:12 -0700 Subject: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method Message-ID: <5C86A754.7050308@oracle.com> Please review a fix for a JCK failure. All XML-related JCK and SQE tests passed after the patch. JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ Thanks, Joe From lance.andersen at oracle.com Mon Mar 11 18:31:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 Mar 2019 14:31:57 -0400 Subject: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method In-Reply-To: <5C86A754.7050308@oracle.com> References: <5C86A754.7050308@oracle.com> Message-ID: Hi Joe I think this is fine. I might consider beefing up the test assertEquals message it is just the name Assert.assertEquals(value, prValues[i], prNames[i]); HTH Best Lance > On Mar 11, 2019, at 2:22 PM, Joe Wang wrote: > > Please review a fix for a JCK failure. All XML-related JCK and SQE tests passed after the patch. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ > > Thanks, > Joe > 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 huizhe.wang at oracle.com Mon Mar 11 18:41:01 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 Mar 2019 11:41:01 -0700 Subject: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method In-Reply-To: References: <5C86A754.7050308@oracle.com> Message-ID: <5C86ABBD.2010306@oracle.com> Thanks Lance! The assertEquals message adds the name (prNames[i]) of the property (e.g. media-type) so that it shows "java.lang.AssertionError: media-type expected [text/html] but found [text/xml]" when fail. There's also a debug message that displays all of the properties when the test passes: method: actual: html, expected: html version: actual: 4.0, expected: 4.0 indent: actual: yes, expected: yes media-type: actual: text/html, expected: text/html Best, Joe On 3/11/19, 11:31 AM, Lance Andersen wrote: > Hi Joe > > I think this is fine. I might consider beefing up the test > assertEquals message it is just the name > > Assert.assertEquals(value, prValues[i], prNames[i]); > > > HTH > > Best > Lance >> On Mar 11, 2019, at 2:22 PM, Joe Wang > > wrote: >> >> Please review a fix for a JCK failure. All XML-related JCK and SQE >> tests passed after the patch. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ >> >> >> Thanks, >> Joe >> > > > > 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 lance.andersen at oracle.com Mon Mar 11 18:54:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 Mar 2019 14:54:38 -0400 Subject: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method In-Reply-To: <5C86ABBD.2010306@oracle.com> References: <5C86A754.7050308@oracle.com> <5C86ABBD.2010306@oracle.com> Message-ID: <61F64149-D61D-4463-B0CC-CD225F3279FF@oracle.com> Hi Joe, > On Mar 11, 2019, at 2:41 PM, Joe Wang wrote: > > Thanks Lance! > > The assertEquals message adds the name (prNames[i]) of the property (e.g. media-type) so that it shows "java.lang.AssertionError: media-type expected [text/html] but found [text/xml]" when fail. Yep, I saw that, just my personal taste I sometimes like a bit more that is why I just mentioned it, it is all good either way :-) > There's also a debug message that displays all of the properties when the test passes: > method: actual: html, expected: html > version: actual: 4.0, expected: 4.0 > indent: actual: yes, expected: yes > media-type: actual: text/html, expected: text/html > > Best, > Joe > > On 3/11/19, 11:31 AM, Lance Andersen wrote: >> >> Hi Joe >> >> I think this is fine. I might consider beefing up the test assertEquals message it is just the name >> >> Assert.assertEquals(value, prValues[i], prNames[i]); >> >> >> HTH >> >> Best >> Lance >>> On Mar 11, 2019, at 2:22 PM, Joe Wang > wrote: >>> >>> Please review a fix for a JCK failure. All XML-related JCK and SQE tests passed after the patch. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ >>> >>> Thanks, >>> Joe >>> >> >> >> >> 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 huizhe.wang at oracle.com Mon Mar 11 19:15:26 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 Mar 2019 12:15:26 -0700 Subject: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method In-Reply-To: <61F64149-D61D-4463-B0CC-CD225F3279FF@oracle.com> References: <5C86A754.7050308@oracle.com> <5C86ABBD.2010306@oracle.com> <61F64149-D61D-4463-B0CC-CD225F3279FF@oracle.com> Message-ID: <5C86B3CE.8070908@oracle.com> On 3/11/19, 11:54 AM, Lance Andersen wrote: > Hi Joe, > >> On Mar 11, 2019, at 2:41 PM, Joe Wang > > wrote: >> >> Thanks Lance! >> >> The assertEquals message adds the name (prNames[i]) of the property >> (e.g. media-type) so that it shows "java.lang.AssertionError: >> media-type expected [text/html] but found [text/xml]" when fail. > > Yep, I saw that, just my personal taste I sometimes like a bit more > that is why I just mentioned it, it is all good either way :-) I added a msg so that it displays in a bit detail in case of a failure, e.g.: java.lang.AssertionError: The value of the property 'media-type' should be 'text/html' when the method is 'html'. expected [text/html] but found [text/xml] How does that sound? -Joe > >> There's also a debug message that displays all of the properties when >> the test passes: >> method: actual: html, expected: html >> version: actual: 4.0, expected: 4.0 >> indent: actual: yes, expected: yes >> media-type: actual: text/html, expected: text/html >> >> Best, >> Joe >> >> On 3/11/19, 11:31 AM, Lance Andersen wrote: >>> Hi Joe >>> >>> I think this is fine. I might consider beefing up the test >>> assertEquals message it is just the name >>> >>> Assert.assertEquals(value, prValues[i], prNames[i]); >>> >>> >>> HTH >>> >>> Best >>> Lance >>>> On Mar 11, 2019, at 2:22 PM, Joe Wang >>> > wrote: >>>> >>>> Please review a fix for a JCK failure. All XML-related JCK and SQE >>>> tests passed after the patch. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ >>>> >>>> >>>> Thanks, >>>> Joe >>>> >>> >>> >>> >>> >>> 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 brent.christian at oracle.com Mon Mar 11 19:19:35 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 11 Mar 2019 12:19:35 -0700 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: <26dd51b8-35cf-e1db-7b9f-bb3bd9f5b0a7@oracle.com> Hi, Jon On 2/28/19 1:38 PM, Jonathan Gibbons wrote: > >> On 28/02/2019 20:58, Jonathan Gibbons wrote: >>> Looking at the revised JAR specification, approved in [1], it is >>> disappointing that the spec contains text which is specific to >>> a JAR file being used in a classloader: >>> >>> |The resulting URLs are inserted into the search path of the class >>> loader opening the context JAR immediately following the path of the >>> context JAR. Any duplicated URLs are omitted.| >>> >>> That text would seem not to apply to javac and other tools that may wish >>> to process the class files in a JAR file. > > |Agreed it might be good to fix it if possible. All the preceding text > is good, and can be handled by javac. The only questionable bit is the > text "Any duplicated URLs are omitted" which could be moved up a bit in > the spec to a new paragraph, and maybe rephrased to use "ignored" > instead of "omitted". If that were done, all the stuff about class > loaders could be taken as non-normative text. I've updated the spec changes in the CSR[1] to address your concerns. For reference, the new relevant passages are: "Invalid entries are ignored. Valid entries are resolved against the context JAR. If the resulting URL is invalid or refers to a resource that cannot be found, then it is ignored. Duplicate URLs are ignored. The resulting URLs are inserted into the class path, immediately following the URL of the context JAR. For example, given the following class path:" Let me know if this will work for javac, and I will proceed. Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8217215 From lance.andersen at oracle.com Mon Mar 11 20:11:50 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 Mar 2019 16:11:50 -0400 Subject: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method In-Reply-To: <5C86B3CE.8070908@oracle.com> References: <5C86A754.7050308@oracle.com> <5C86ABBD.2010306@oracle.com> <61F64149-D61D-4463-B0CC-CD225F3279FF@oracle.com> <5C86B3CE.8070908@oracle.com> Message-ID: > On Mar 11, 2019, at 3:15 PM, Joe Wang wrote: > > > > On 3/11/19, 11:54 AM, Lance Andersen wrote: >> >> Hi Joe, >> >>> On Mar 11, 2019, at 2:41 PM, Joe Wang > wrote: >>> >>> Thanks Lance! >>> >>> The assertEquals message adds the name (prNames[i]) of the property (e.g. media-type) so that it shows "java.lang.AssertionError: media-type expected [text/html] but found [text/xml]" when fail. >> >> Yep, I saw that, just my personal taste I sometimes like a bit more that is why I just mentioned it, it is all good either way :-) > > I added a msg so that it displays in a bit detail in case of a failure, e.g.: > java.lang.AssertionError: The value of the property 'media-type' should be 'text/html' when the method is 'html'. > expected [text/html] but found [text/xml] > > How does that sound? works for me > > -Joe > >> >>> There's also a debug message that displays all of the properties when the test passes: >>> method: actual: html, expected: html >>> version: actual: 4.0, expected: 4.0 >>> indent: actual: yes, expected: yes >>> media-type: actual: text/html, expected: text/html >>> >>> Best, >>> Joe >>> >>> On 3/11/19, 11:31 AM, Lance Andersen wrote: >>>> >>>> Hi Joe >>>> >>>> I think this is fine. I might consider beefing up the test assertEquals message it is just the name >>>> >>>> Assert.assertEquals(value, prValues[i], prNames[i]); >>>> >>>> >>>> HTH >>>> >>>> Best >>>> Lance >>>>> On Mar 11, 2019, at 2:22 PM, Joe Wang > wrote: >>>>> >>>>> Please review a fix for a JCK failure. All XML-related JCK and SQE tests passed after the patch. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 >>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>> >>>> >>>> >>>> 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 >> >> >> > 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 claes.redestad at oracle.com Mon Mar 11 21:01:04 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 Mar 2019 22:01:04 +0100 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> Message-ID: <956ce98a-ac56-52e8-ea48-b34e4a59300a@oracle.com> On 2019-03-11 18:59, Mandy Chung wrote: > The updated patch looks good. > > Mandy > +1 /Claes From ivan.gerasimov at oracle.com Mon Mar 11 21:26:52 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 11 Mar 2019 14:26:52 -0700 Subject: [PATCH] enhancement proposal for String concatenation In-Reply-To: <18873051552161173@iva7-4f557d6b60d4.qloud-c.yandex.net> References: <4736391552072930@iva1-5148b5385b62.qloud-c.yandex.net> <18873051552161173@iva7-4f557d6b60d4.qloud-c.yandex.net> Message-ID: <80c9eb43-0063-fb29-f624-b7ad10cadf33@oracle.com> Yes, I agree that StringJoiner could benefit from a hint about the expected number of elements to join. On the other hand, with the current allocation scheme, each reference stored in the elts[] will only be copied at most twice on average, so the total performance improvement might not be that significant to justify the API change. With kind regards, Ivan On 3/9/19 11:52 AM, ?????? ??????? wrote: > Hello Ivan, > > indeed your solution for Iterables is more compact than mine (it can be event shorter with method reference), however it doesn't solve the problem of array reallocation. > > See my response to Remi below > > 08.03.2019, 22:01, "Ivan Gerasimov" : >> Hi Sergei! >> >> As you said, this new class is pretty much like StringJoiner with >> reduced functionality. >> >> For appending all elements of an Iterable you could use list.forEach(s >> -> sj.add(s)). >> >> With kind regards, >> Ivan >> >> On 3/8/19 11:22 AM, ?????? ??????? wrote: >>> Hello, >>> >>> I have an enhancement proposal for some cases of String concatenation in Java. >>> >>> Currently we concat Strings mostly using java.lang.StringBuilder. The main disadvantage of StringBuilder is underlying char array or rather a need to resize it when the capacity is about to exceed array length and subsequent copying of array content into newly allocated array. >>> >>> One alternative solution existing is StringJoiner. Before JDK 9 it was a kind of decorator over StringBuilder, but later it was reworked in order to store appended Strings into String[] and overall capacity accumulated into int field. This makes it possible to allocate char[] only once and of exact size in toString() method reducing allocation cost. >>> >>> My proposal is to copy-paste the code of StringJoinder into newly created class java.util.StringChain, drop the code responsible for delimiter, prefix and suffix and use it instead of StringBuilder in common StringBuilder::append concatenation pattern. >>> >>> Possible use-cases for proposed code are: >>> - plain String concatenation >>> - String::chain (new methods) >>> - Stream.collect(Collectors.joining()) >>> - StringConcatFactory >>> >>> We can create new methods String.chain(Iterable) and String.chain(CharSequence...) which allow to encapsulate boilerplate code like >>> >>> StringBuilder sb = new StringBuilder(); >>> for (CharSequence cs : charSequences) { >>> sb.append(cs); >>> } >>> String result = sb.toString(): >>> >>> into one line: >>> >>> String result = String.chain(charSequences); >>> >>> As of performance I've done some measurements using JMH on my work machine (Intel i7-7700) for both Latin and non-Latin Strings of different size and count. >>> Here are the results: >>> >>> https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt >>> >>> There is a few corner cases (e.g. 1000 Strings of length 1 appended) when StringBuilder takes over StringChain constructed with default capacity of 8, but StringChain constructed with exact added Strings count almost always wins, especially when dealing with non-Latin chars (Russian in my case). >>> >>> I've also created a separate repo on GitHub with benchmarks: >>> >>> https://github.com/stsypanov/string-chain >>> >>> Key feature here is ability to allocate String array of exact size is cases we know added elements count. >>> Thus I think that if the change will be accepted we can add also an overloaded method String.chain(Collection) as Collection::size allows to contruct StringChain of exact size. >>> >>> Patch is attached. >>> >>> Kind regards, >>> Sergei Tsypanov >> -- >> With kind regards, >> Ivan Gerasimov -- With kind regards, Ivan Gerasimov From mandy.chung at oracle.com Mon Mar 11 22:49:27 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 Mar 2019 15:49:27 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> Message-ID: On 3/11/19 8:48 AM, Adam Farley8 wrote: > Hi Mandy, > > Thank you for explaining. :) > > Unfortunately I'm only a mere Author, and I cannot submit test runs on > the shared test server. > > I have run the test locally, and it passes against a patched build and > fails correctly agaionst an unpatched build, so I think we're good to go. I will sponsor this patch for you when CSR is approved. > Can you tell me if there's something I can do to help move the CSR forward? No additional action from your end. It's already in finalized state. > Also, can you tell me if an additional CSR would need to be created for > other releases if this fix gets backported? Which release are you thinking to backport to? IMO I don't think this fix is critical for existing releases and this fix has behavioral change. Mandy > Best Regards > > Adam Farley > IBM Runtimes > > > Mandy Chung wrote on 07/03/2019 23:17:15: > >> From: Mandy Chung >> To: Adam Farley8 >> Cc: core-libs-dev >> Date: 07/03/2019 23:19 >> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails >> to throw IllegalAccessException for final fields >> >> >> >> On 3/7/19 9:44 AM, Adam Farley8 wrote: >> > Hi Mandy, >> > >> > Since you have created a new work item to cover the test work, do let >> > me know if you want the test code removed from the webrev for the >> > original issue. >> >> You push what you have. ?Your fix should come with a regression test. >> Please make sure you do jdk-submit to verify the test work. >> >> > Also, by "nobody is meant to be changing final fields anyway", I was >> > explaining my decision to setAccessible(true) on the final fields by >> > default, rather than setting it via a control bit as you suggested. >> > Seemed to save code while exposing us to minimal risk, because the >> > field is meant to be immutable (final). >> > >> > Lastly, I'm sorry to see you weren't happy with the quality of my test >> > code. Your changes seem much larger in scale, and quite different to >> > my changes. Could you explain the benefits of your approach, vs simply >> > adding non-static final fields to my code? >> >> First, I dont see my test update is large scale. ?Second, it's not >> about the quality of the test code. ?The size of the change is not >> the sole factor to consider but that seems to bother you. ?Anyway, >> the test itself isn't easy to work with. ?You have done the fix to >> include the regression test which is okay. >> >> Your patch made me to look at the test closer which I started from >> the version in the repo, not based on your version. ?Once you push >> your fix, I can generate a new webrev to see the diff that I can >> revise on top of your version. >> >> I change a couple things. ?The test uses Error in HasFields.CASES to >> indicate a negative test. ?For a final field, it has no write access >> and it is a negative test case except unreflectSetter on an instance >> final field whose accessible flag is true. ?That explains why >> Error.class is in the third element of the new case added for final >> field that actually reflects if a test case is positive or negative >> when calling testAccessor. ? What you added is treating setter on >> final field is positive test case and then returns when IAE is thrown. >> It does the work but passing incorrect information. >> >> I uncovered some unnecessary test cases for findSetter on >> static fields and findStaticSetter on non-static fields. ?It's an >> existing test issue and I think they ?should be filtered out and >> that's why CASES is separated into two separate ArrayLists and the new >> static cases(int testMode) method. ?I see that you used a new kind for >> static final field that may be a good approach. ?When I pull down your >> change, I will send out a revision (that's why I wait for your patch >> to go in first and see any thing I should change). >> >> Hope this helps. >> >> Mandy >> > > 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 john.r.rose at oracle.com Mon Mar 11 23:07:47 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Mar 2019 18:07:47 -0500 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Message-ID: On Mar 7, 2019, at 4:33 AM, Tagir Valeev wrote: > > Hello, Remi! > > It actually works thanks to auto-boxing/unboxing. E.g. this > implementation works: > > static Iterable range(int from, int to) { > return () -> new PrimitiveIterator.OfInt() { > int cur = from; > > @Override > public int nextInt() { > if (cur >= to) { > throw new NoSuchElementException(); > } > return cur++; > } > > @Override > public boolean hasNext() { > return cur < to; > } > }; > } > > public static void main(String[] args) { > for(int i : range(0, 100)) { > System.out.println(i); > } > } > > It correctly compiles and prints numbers from 0 to 99. As IntStream > extends BaseStream and BaseStream BaseStream> defines Iterator iterator(), it would be no > problem with using IntStream.range in such code pattern were > BaseStream extends IterableOnce. > > Of course this produces unnecessary garbage, as I said. This is a relatively simple kind of garbage to remove, because it is made (by calls to Integer.valueOf) at the adapted boundaries of the iterator, which are readily inlined into the loop. The deeper internal logic of the range function is box-free, as is the loop itself, so the garbage is relatively easy to remove. That said, "out of the box" there is lots of garbage created unless -XX:+AggressiveUnboxing is turned on. I assume Graal does a good job on it, even without this switch. If we ever succeed in suppressing the identity of java.lang.Integer, and/or after making functions like range into reified generics, the boxing will go away even more directly and simply. So, from the JIT engineering point of view, I would classify this particular boxing problem as relatively short-lived. ? John P.S. I also saw the fiery objections to the range() idiom, and I have to disagree with those disagreers! I prefer the range idiom to the multi-part for-init-test-step idiom, because counters are semantically *more complex* than ranges, from the viewpoints I typically use to reason about programs. (There are times when a separate counter state *is* preferable to me, but usually when there is some sort of extra "i += skip" side effect in the loop.) That's got to be a matter of taste. I suppose some people habitually reason about programs in lower-level terms, like x86 instructions, and there a counter is no more complex than a range; for those people there's no reason to learn a different concept than a for-loop. And surely there are other points of view that favor the good old for-loop-with-int-counter. I'm more tolerant of new-fangled range-based notations because they let me avoid having to reason about side-effect-laden entities like counters, and that feels like a good thing to me. Tastes vary. > > With best regards, > Tagir Valeev. > > On Wed, Mar 6, 2019 at 7:37 PM Remi Forax wrote: >> >> Hi Tagir, >> try to do it now and you will see that you can't, because you can not write Iterable yet. >> Once we will get generics over value types, it will be a no-brainer. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Tagir Valeev" >>> ?: "Stuart Marks" >>> Cc: "core-libs-dev" >>> Envoy?: Mercredi 6 Mars 2019 11:10:41 >>> Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams >> >>> Hello! >>> >>> By the way one of the painful code patterns in modern Java is `for(int >>> i = 0; i>> newbies and prone to errors as the variable need to be repeated three >>> times. Also the variable is not effectively final, despite it never >>> changes within the loop body, so could have been considered as >>> redeclared on every loop iteration (like in for-each). With the new >>> proposal it's possible to write `for(int i : range(0, bound).boxed())` >>> (assuming import static j.u.s.IntStream.range), which looks much >>> better, though it has obvious performance drawback. Moving >>> IterableOnce to BaseStream would enable to use `for(int i : range(0, >>> bound))` which looks even better, though again we have plenty of >>> garbage (but considerably less than in previous case!). I wonder >>> whether Java could evolve to the point where such kind of code would >>> be a recommended way to iterate over subsequent integer values without >>> any performance handicap. >>> >>> With best regards, >>> Tagir Valeev. >>> >>> On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: >>>> >>>> Hi all, >>>> >>>> Please review and comment on this proposal to allow Stream instances to be used >>>> in enhanced-for ("for-each") loops. >>>> >>>> Abstract >>>> >>>> Occasionally it's useful to iterate a Stream using a conventional loop. However, >>>> the Stream interface doesn't implement Iterable, and therefore streams cannot be >>>> used with the enhanced-for statement. This is a proposal to remedy that >>>> situation by introducing a new interface IterableOnce that is a subtype of >>>> Iterable, and then retrofitting the Stream interface to implement it. Other JDK >>>> classes will also be retrofitted to implement IterableOnce. >>>> >>>> Full Proposal: >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html >>>> >>>> Bug report: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148917 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ >>>> >>>> Note, this changeset isn't ready to push yet. In particular, it has no tests >>>> yet. However, the implementation is so simple that I figured I should include >>>> it. Comments on the specification wording are also welcome. >>>> >>>> Thanks, >>>> >>>> s'marks From javalists at cbfiddle.com Mon Mar 11 23:36:51 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 11 Mar 2019 16:36:51 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Message-ID: <1BA00B01-A5AC-4BB2-9C24-698C52904D34@cbfiddle.com> Also, if the upper bound is an expression, the range() approach makes it clear that the upper bound expression is intended to be evaluated once. > On Mar 11, 2019, at 4:07 PM, John Rose > wrote: > > P.S. I also saw the fiery objections to the range() idiom, and I have > to disagree with those disagreers! I prefer the range idiom to the > multi-part for-init-test-step idiom, because counters are semantically > *more complex* than ranges, from the viewpoints I typically use to > reason about programs. (There are times when a separate counter > state *is* preferable to me, but usually when there is some sort of > extra "i += skip" side effect in the loop.) That's got to be a matter of > taste. I suppose some people habitually reason about programs > in lower-level terms, like x86 instructions, and there a counter is no > more complex than a range; for those people there's no reason to > learn a different concept than a for-loop. And surely there are other > points of view that favor the good old for-loop-with-int-counter. > > I'm more tolerant of new-fangled range-based notations because they > let me avoid having to reason about side-effect-laden entities > like counters, and that feels like a good thing to me. Tastes vary. From amaembo at gmail.com Tue Mar 12 02:28:35 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 12 Mar 2019 09:28:35 +0700 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> Message-ID: Looks good now, thanks! With best regards, Tagir Valeev On Mon, Mar 11, 2019 at 11:29 PM Joe Darcy wrote: > > Hello, > > Always surprising how much discussion an (apparently) simple refactoring > can generate! > > Thanks to Tagir for spotting this issue. > > For completeness, the two-argument forms of requireNonNull which takes a > Supplier is not applicable to preserve the message behavior > since the loop counter i is not final or effectively final: > > Objects.requireNonNull(defensiveCopy[i], () -> "stackTrace[" + i + > "]"); > > Therefore, I'll revert this use of requireNonNull in Throwable but keep > the other three: > > diff -r 289fd6cb7480 src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java Mon Mar 11 > 15:34:16 2019 +0100 > +++ b/src/java.base/share/classes/java/lang/Throwable.java Mon Mar 11 > 09:28:51 2019 -0700 > @@ -914,8 +914,7 @@ > for (Throwable t : suppressedExceptions) { > // Enforce constraints on suppressed exceptions in > // case of corrupt or malicious stream. > - if (t == null) > - throw new NullPointerException(NULL_CAUSE_MESSAGE); > + Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); > if (t == this) > throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > suppressed.add(t); > @@ -942,8 +941,7 @@ > stackTrace = null; > } else { // Verify stack trace elements are non-null. > for(StackTraceElement ste : stackTrace) { > - if (ste == null) > - throw new NullPointerException("null > StackTraceElement in serial stream. "); > + Objects.requireNonNull(ste, "null StackTraceElement > in serial stream."); > } > } > } else { > @@ -1034,8 +1032,7 @@ > if (exception == this) > throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > - if (exception == null) > - throw new NullPointerException(NULL_CAUSE_MESSAGE); > + Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); > > if (suppressedExceptions == null) // Suppressed exceptions not > recorded > return; > > Thanks, > > -Joe > > On 3/10/2019 4:21 AM, Remi Forax wrote: > > ----- Mail original ----- > >> De: "Martin Buchholz" > >> ?: "Tagir Valeev" > >> Cc: "core-libs-dev" > >> Envoy?: Vendredi 8 Mars 2019 21:35:59 > >> Objet: Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull > >> On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev wrote: > >> > >>> Hello! > >>> > >>>> diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java > >>>> --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 > >>>> 10:22:19 2019 +0100 > >>>> +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 > >>>> 02:06:42 2019 -0800 > >>>> @@ -874,8 +874,7 @@ > >>>> // Validate argument > >>>> StackTraceElement[] defensiveCopy = stackTrace.clone(); > >>>> for (int i = 0; i < defensiveCopy.length; i++) { > >>>> - if (defensiveCopy[i] == null) > >>>> - throw new NullPointerException("stackTrace[" + i + "]"); > >>>> + Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i > >>>> + "]"); > >>> Won't it produce unnecessary garbage due to string concatenation on > >>> the common case when all frames are non-null? > >>> > >> I share Tagir's doubts. I avoid this construction in performance sensitive > >> code. > >> Java doesn't offer syntactic abstraction (can I haz macros?) so the Java > >> Way is to write the explicit if. > >> > >> Logging frameworks have the same trouble. > >> https://github.com/google/flogger > > > > No, they don't if the API use the pattern described by Peter > > https://github.com/forax/beautiful_logger > > > >> Perhaps hotspot's improved automatic NPE reporting makes the message detail > >> here obsolete? > > anyway, i agree with what's Martin and Tagir said, requireNonNull() should not be used in this particular case. > > > > R?mi From joe.darcy at oracle.com Tue Mar 12 03:32:43 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 11 Mar 2019 20:32:43 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> Message-ID: On 3/11/2019 3:49 PM, Mandy Chung wrote: > > > On 3/11/19 8:48 AM, Adam Farley8 wrote: >> Hi Mandy, >> >> Thank you for explaining. :) >> >> Unfortunately I'm only a mere Author, and I cannot submit test runs >> on the shared test server. >> >> I have run the test locally, and it passes against a patched build >> and fails correctly agaionst an unpatched build, so I think we're >> good to go. > > I will sponsor this patch for you when CSR is approved. > >> Can you tell me if there's something I can do to help move the CSR >> forward? > > No additional action from your end.? It's already in finalized state. > >> Also, can you tell me if an additional CSR would need to be created >> for other releases if this fix gets backported? > > Which release are you thinking to backport to? > > IMO I don't think this fix is critical for existing releases > and this fix has behavioral change. As a procedural matter, to do a CSR for multiple releases, first create the backport issue for the release or release train in question (e.g. some particular update release like "12.0.1" or "12-pool") and then create a CSR of the backport. This is the procedure if an update release train is using the CSR review process. However, note that as this proposed changes alters a spec in the Java SE API, it would require a maintenance review of the Java SE spec, which is very unlikely to occur in an update release. HTH, -Joe From lenborje at gmail.com Tue Mar 12 07:40:23 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 12 Mar 2019 08:40:23 +0100 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> Message-ID: <8FD446A3-EBB3-4B9B-962E-758315584645@gmail.com> OK. May I hope that a fix for this will make its way to the early-access build soon? (While I can build from source myself, it is much more convenient to use an EA in our CI cluster.) /Lennart > 11 mars 2019 kl. 18:04 skrev Andy Herrick : > > Although we plan to remove the mac-app-store intaller type for the first release (which will fix this instance the problem for now) I agree this is not right for an exception in one install type to prevent the other types (if there are any) from running. > > I think instead though we should try to run them all, then log what succeeded and then throw the exception if any failed. > > /Andy > > > > On 3/11/2019 7:55 AM, Lennart B?rjeson wrote: >> Looking into the code of Arguments.generateBundle(Map params), I believe it's a bug to immediately throw an error when a bundler has configuration problems. >> >> Instead, that bundler should be removed from the platformBundlers List. Quick-and-dirty solution: >> >> >> diff -r e11f3bf34083 src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java >> --- a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java Fri Mar 01 08:27:51 2019 -0500 >> +++ b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java Mon Mar 11 12:37:43 2019 +0100 >> @@ -37,6 +37,7 @@ >> import java.util.HashMap; >> import java.util.HashSet; >> import java.util.List; >> +import java.util.ListIterator; >> import java.util.Map; >> import java.util.Set; >> import java.util.Properties; >> @@ -655,7 +656,10 @@ >> // clean these extra (and unneeded) temp directories. >> StandardBundlerParam.BUILD_ROOT.fetchFrom(params); >> - for (jdk.jpackage.internal.Bundler bundler : getPlatformBundlers()) { >> + List platformBundlers = getPlatformBundlers(); >> + ListIterator platformBundleIterator = platformBundlers.listIterator(); >> + while (platformBundleIterator.hasNext()) { >> + jdk.jpackage.internal.Bundler bundler = platformBundleIterator.next(); >> Map localParams = new HashMap<>(params); >> try { >> if (bundler.validate(localParams)) { >> @@ -677,18 +681,20 @@ >> } catch (ConfigException e) { >> Log.debug(e); >> if (e.getAdvice() != null) { >> - throw new PackagerException(e, >> + Log.info(new PackagerException(e, >> "MSG_BundlerConfigException", >> - bundler.getName(), e.getMessage(), e.getAdvice()); >> + bundler.getName(), e.getMessage(), e.getAdvice()).getMessage()); >> } else { >> - throw new PackagerException(e, >> + Log.info(new PackagerException(e, >> "MSG_BundlerConfigExceptionNoAdvice", >> - bundler.getName(), e.getMessage()); >> + bundler.getName(), e.getMessage()).getMessage()); >> } >> + platformBundleIterator.remove(); >> } catch (RuntimeException re) { >> Log.debug(re); >> - throw new PackagerException(re, "MSG_BundlerRuntimeException", >> - bundler.getName(), re.toString()); >> + Log.info(new PackagerException(re, "MSG_BundlerRuntimeException", >> + bundler.getName(), re.toString()).getMessage()); >> + platformBundleIterator.remove(); >> } finally { >> if (userProvidedBuildRoot) { >> Log.verbose(MessageFormat.format( >> >> >> Best regards, >> >> /Lennart B?rjeson >> >>> 11 mars 2019 kl. 09:40 skrev Lennart B?rjeson : >>> >>> I'm experimenting with jpackage from the current EA available at https://jdk.java.net/jpackage/ >, for the moment on Mac only. >>> >>> I have an existing application which I have previously deployed on multiple platforms using the then bundled javafxpackager. >>> >>> With the current EA (build 17), I find I must specify the --installer-type parameter, otherwise I get the following error: >>> >>> $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage create-installer --overwrite --output /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui --app-image /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app --icon BMF.icns --identifier com.cinnober.bmf.gui.Main --app-version 1.6.10 --verbose >>> jdk.jpackage.internal.PackagerException: Bundler Mac App Store Ready Bundler skipped because of a configuration problem: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. >>> Advice to fix: Either unset 'signBundle' or set 'signBundle' to true. >>> at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726) >>> at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:642) >>> at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) >>> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) >>> Caused by: jdk.jpackage.internal.ConfigException: Mac App Store apps must be signed, and signing has been disabled by bundler configuration. >>> at jdk.jpackage/jdk.jpackage.internal.MacAppStoreBundler.validate(MacAppStoreBundler.java:332) >>> at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:705) >>> ... 3 more >>> >>> With the previous javafxpackager this wasn't needed. Javafxpackager always tried to create all installer types and ignored all errors from any specific bundler, e.g. on linux it always tried to create both a Debian package and an rpm and just ignored if any of the requisite builder tools was unavailable. >>> >>> The obvious workaround in my case is to run jpackage twice, once with "--installer-type pkg" and once with "--installer-type dmg", but since I'm furthered hampered by limitations of my toolchain (gradle + badass-jlink-plugin) it would really simplify matters it jpackage could be restored to the javafxpackager behaviour when "--installer-type" is unspecified, e.g. ignore errors and create whatever installers it can. >>> >>> >>> Best regards, >>> >>> /Lennart B?rjeson From peter.levart at gmail.com Tue Mar 12 08:04:52 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 12 Mar 2019 09:04:52 +0100 Subject: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull In-Reply-To: References: <0756e969-36b1-1c73-6a5c-db948d48ec2f@oracle.com> <34958309.1067053.1552216906996.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, On 3/11/19 5:29 PM, Joe Darcy wrote: > Hello, > > Always surprising how much discussion an (apparently) simple > refactoring can generate! > > Thanks to Tagir for spotting this issue. > > For completeness, the two-argument forms of requireNonNull which takes > a Supplier is not applicable to preserve the message behavior > since the loop counter i is not final or effectively final: > > ??? Objects.requireNonNull(defensiveCopy[i],? () -> "stackTrace[" + i > + "]"); ...and even if it were effectively final, the use of that method would not help in preventing the construction of garbage. It would just replace one type of garbage (StringBuilder(s) and concatenated String(s)) with another type (capturing lambda instances). So this is best left as is. +1 Peter > > Therefore, I'll revert this use of requireNonNull in Throwable but > keep the other three: > > diff -r 289fd6cb7480 src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java??? Mon Mar > 11 15:34:16 2019 +0100 > +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Mon Mar > 11 09:28:51 2019 -0700 > @@ -914,8 +914,7 @@ > ???????????????? for (Throwable t : suppressedExceptions) { > ???????????????????? // Enforce constraints on suppressed exceptions in > ???????????????????? // case of corrupt or malicious stream. > -??????????????????? if (t == null) > -??????????????????????? throw new > NullPointerException(NULL_CAUSE_MESSAGE); > +??????????????????? Objects.requireNonNull(t, NULL_CAUSE_MESSAGE); > ???????????????????? if (t == this) > ???????????????????????? throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > ???????????????????? suppressed.add(t); > @@ -942,8 +941,7 @@ > ???????????????? stackTrace = null; > ???????????? } else { // Verify stack trace elements are non-null. > ???????????????? for(StackTraceElement ste : stackTrace) { > -??????????????????? if (ste == null) > -??????????????????????? throw new NullPointerException("null > StackTraceElement in serial stream. "); > +??????????????????? Objects.requireNonNull(ste, "null > StackTraceElement in serial stream."); > ???????????????? } > ???????????? } > ???????? } else { > @@ -1034,8 +1032,7 @@ > ???????? if (exception == this) > ???????????? throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > -??????? if (exception == null) > -??????????? throw new NullPointerException(NULL_CAUSE_MESSAGE); > +??????? Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE); > > ???????? if (suppressedExceptions == null) // Suppressed exceptions > not recorded > ???????????? return; > > Thanks, > > -Joe > > On 3/10/2019 4:21 AM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Martin Buchholz" >>> ?: "Tagir Valeev" >>> Cc: "core-libs-dev" >>> Envoy?: Vendredi 8 Mars 2019 21:35:59 >>> Objet: Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable >>> to use Objects.requireNonNull >>> On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev wrote: >>> >>>> Hello! >>>> >>>>> diff -r 274361bd6915 >>>>> src/java.base/share/classes/java/lang/Throwable.java >>>>> --- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07 >>>>> 10:22:19 2019 +0100 >>>>> +++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08 >>>>> 02:06:42 2019 -0800 >>>>> @@ -874,8 +874,7 @@ >>>>> ?????????? // Validate argument >>>>> ?????????? StackTraceElement[] defensiveCopy = stackTrace.clone(); >>>>> ?????????? for (int i = 0; i < defensiveCopy.length; i++) { >>>>> -??????????? if (defensiveCopy[i] == null) >>>>> -??????????????? throw new NullPointerException("stackTrace[" + i >>>>> + "]"); >>>>> +??????????? Objects.requireNonNull(defensiveCopy[i], >>>>> "stackTrace[" + i >>>>> + "]"); >>>> Won't it produce unnecessary garbage due to string concatenation on >>>> the common case when all frames are non-null? >>>> >>> I share Tagir's doubts.? I avoid this construction in performance >>> sensitive >>> code. >>> Java doesn't offer syntactic abstraction (can I haz macros?) so the >>> Java >>> Way is to write the explicit if. >>> >>> Logging frameworks have the same trouble. >>> https://github.com/google/flogger >> >> No, they don't if the API use the pattern described by Peter >> https://github.com/forax/beautiful_logger >> >>> Perhaps hotspot's improved automatic NPE reporting makes the message >>> detail >>> here obsolete? >> anyway, i agree with what's Martin and Tagir said, requireNonNull() >> should not be used in this particular case. >> >> R?mi From peter.levart at gmail.com Tue Mar 12 10:29:22 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 12 Mar 2019 11:29:22 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Message-ID: Hi John, On 3/12/19 12:07 AM, John Rose wrote: >> public static void main(String[] args) { >> for(int i : range(0, 100)) { >> System.out.println(i); >> } >> } >> >> It correctly compiles and prints numbers from 0 to 99. As IntStream >> extends BaseStream and BaseStream> BaseStream> defines Iterator iterator(), it would be no >> problem with using IntStream.range in such code pattern were >> BaseStream extends IterableOnce. >> >> Of course this produces unnecessary garbage, as I said. > This is a relatively simple kind of garbage to remove, because > it is made (by calls to Integer.valueOf) at the adapted boundaries > of the iterator, which are readily inlined into the loop. The deeper > internal logic of the range function is box-free, as is the loop itself, > so the garbage is relatively easy to remove. > > That said, "out of the box" there is lots of garbage created unless > -XX:+AggressiveUnboxing is turned on. I assume Graal does a good > job on it, even without this switch. > > If we ever succeed in suppressing the identity of java.lang.Integer, > and/or after making functions like range into reified generics, the > boxing will go away even more directly and simply. > > So, from the JIT engineering point of view, I would classify this > particular boxing problem as relatively short-lived. > > ? John What I have observed (some time ago) is that Integer instances obtained by Integer.valueOf() are never found to "not escape" the JIT compilation unit and are therefore never scalarized by JIT because of the "feature" that was designed to actually prevent the continuous allocation of some "values" of Integer(s) - namely the caching of Integer instances in the Integer.IntegerCache.cache array for values in range [-128, 127]. So the feature designed to prevent continuous allocation is actually working against the desired goal. The code of Integer.valueOf is: ??? public static Integer valueOf(int i) { ??????? if (i >= IntegerCache.low && i <= IntegerCache.high) ??????????? return IntegerCache.cache[i + (-IntegerCache.low)]; ??????? return new Integer(i); ??? } ...so JIT would have to create two specializations of code: one for cached Integer instances which are always real objects and the other for scalarized Integer(s) created by constructor. Last time I experimented with this was in JDK 8. Is HotSpot in JDK 12+ smarter now and can do this? Perhaps the @HotSpotIntrinsicCandidate annotation on this method is a clue that it is treated in a special way by the JIT? Regards, Peter From daniel.fuchs at oracle.com Tue Mar 12 12:06:29 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Mar 2019 05:06:29 -0700 (PDT) Subject: (trivial doc fix) RFR: 8220262: fix headings in java.logging Message-ID: <7eca32cb-d3a5-3e58-96c1-ef98e07ca92c@oracle.com> Hi, Please find below a trivial doc fix for: 8220262: fix headings in java.logging https://bugs.openjdk.java.net/browse/JDK-8220262 The change is just: - *

              LogManager Configuration

              + *

              LogManager Configuration

              full patch below. best regards, -- daniel ========================================================================= diff --git a/src/java.logging/share/classes/java/util/logging/LogManager.java b/src/java.logging/share/classes/java/util/logging/LogManager.java --- a/src/java.logging/share/classes/java/util/logging/LogManager.java +++ b/src/java.logging/share/classes/java/util/logging/LogManager.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2019, 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 @@ -64,7 +64,7 @@ * At startup the LogManager class is located using the * java.util.logging.manager system property. * - *

              LogManager Configuration

              + *

              LogManager Configuration

              * * A LogManager initializes the logging configuration via * the {@link #readConfiguration()} method during LogManager initialization. ========================================================================= From Lance.Andersen at oracle.com Tue Mar 12 12:16:04 2019 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 12 Mar 2019 08:16:04 -0400 Subject: (trivial doc fix) RFR: 8220262: fix headings in java.logging In-Reply-To: <7eca32cb-d3a5-3e58-96c1-ef98e07ca92c@oracle.com> References: <7eca32cb-d3a5-3e58-96c1-ef98e07ca92c@oracle.com> Message-ID: <47302E92-4290-4D2B-A774-B01514818E28@oracle.com> +1 -- 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 Sent from my iPhone > On Mar 12, 2019, at 8:06 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a trivial doc fix for: > > 8220262: fix headings in java.logging > https://bugs.openjdk.java.net/browse/JDK-8220262 > > The change is just: > - *

              LogManager Configuration

              > + *

              LogManager Configuration

              > > full patch below. > > best regards, > > -- daniel > > ========================================================================= > diff --git a/src/java.logging/share/classes/java/util/logging/LogManager.java b/src/java.logging/share/classes/java/util/logging/LogManager.java > --- a/src/java.logging/share/classes/java/util/logging/LogManager.java > +++ b/src/java.logging/share/classes/java/util/logging/LogManager.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2019, 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 > @@ -64,7 +64,7 @@ > * At startup the LogManager class is located using the > * java.util.logging.manager system property. > * > - *

              LogManager Configuration

              > + *

              LogManager Configuration

              > * > * A LogManager initializes the logging configuration via > * the {@link #readConfiguration()} method during LogManager initialization. > ========================================================================= From gary.adams at oracle.com Tue Mar 12 12:16:44 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Mar 2019 08:16:44 -0400 Subject: (trivial doc fix) RFR: 8220262: fix headings in java.logging In-Reply-To: <7eca32cb-d3a5-3e58-96c1-ef98e07ca92c@oracle.com> References: <7eca32cb-d3a5-3e58-96c1-ef98e07ca92c@oracle.com> Message-ID: <5C87A32C.1000202@oracle.com> Doesn't the generated javadoc include an h2 for Class LogManager? That would make the h3 for LogManager Configuration the correct nesting level, even though it does not appear in the individual source file. On 3/12/19, 8:06 AM, Daniel Fuchs wrote: > Hi, > > Please find below a trivial doc fix for: > > 8220262: fix headings in java.logging > https://bugs.openjdk.java.net/browse/JDK-8220262 > > The change is just: > - *

              LogManager Configuration

              > + *

              LogManager Configuration

              > > full patch below. > > best regards, > > -- daniel > > ========================================================================= > diff --git > a/src/java.logging/share/classes/java/util/logging/LogManager.java > b/src/java.logging/share/classes/java/util/logging/LogManager.java > --- a/src/java.logging/share/classes/java/util/logging/LogManager.java > +++ b/src/java.logging/share/classes/java/util/logging/LogManager.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2019, 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 > @@ -64,7 +64,7 @@ > * At startup the LogManager class is located using the > * java.util.logging.manager system property. > * > - *

              LogManager Configuration

              > + *

              LogManager Configuration

              > * > * A LogManager initializes the logging configuration via > * the {@link #readConfiguration()} method during LogManager > initialization. > ========================================================================= From daniel.fuchs at oracle.com Tue Mar 12 12:24:10 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Mar 2019 12:24:10 +0000 Subject: (trivial doc fix) RFR: 8220262: fix headings in java.logging In-Reply-To: <5C87A32C.1000202@oracle.com> References: <7eca32cb-d3a5-3e58-96c1-ef98e07ca92c@oracle.com> <5C87A32C.1000202@oracle.com> Message-ID: Hi Gary, On 12/03/2019 12:16, Gary Adams wrote: > Doesn't the generated javadoc include an h2 for Class LogManager? > > That would make the h3 for LogManager Configuration the correct nesting > level, > even though it does not appear in the individual source file. No, it used to, but now it doesn't. See https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html The previous header tag is now an

              for the class declaration. best regards, -- daniel From forax at univ-mlv.fr Tue Mar 12 12:30:39 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Mar 2019 13:30:39 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Message-ID: <1215402703.499794.1552393839691.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "John Rose" , "Tagir Valeev" > Cc: "core-libs-dev" > Envoy?: Mardi 12 Mars 2019 11:29:22 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hi John, > > On 3/12/19 12:07 AM, John Rose wrote: >>> public static void main(String[] args) { >>> for(int i : range(0, 100)) { >>> System.out.println(i); >>> } >>> } >>> >>> It correctly compiles and prints numbers from 0 to 99. As IntStream >>> extends BaseStream and BaseStream>> BaseStream> defines Iterator iterator(), it would be no >>> problem with using IntStream.range in such code pattern were >>> BaseStream extends IterableOnce. >>> >>> Of course this produces unnecessary garbage, as I said. >> This is a relatively simple kind of garbage to remove, because >> it is made (by calls to Integer.valueOf) at the adapted boundaries >> of the iterator, which are readily inlined into the loop. The deeper >> internal logic of the range function is box-free, as is the loop itself, >> so the garbage is relatively easy to remove. >> >> That said, "out of the box" there is lots of garbage created unless >> -XX:+AggressiveUnboxing is turned on. I assume Graal does a good >> job on it, even without this switch. >> >> If we ever succeed in suppressing the identity of java.lang.Integer, >> and/or after making functions like range into reified generics, the >> boxing will go away even more directly and simply. >> >> So, from the JIT engineering point of view, I would classify this >> particular boxing problem as relatively short-lived. >> >> ? John > > What I have observed (some time ago) is that Integer instances obtained > by Integer.valueOf() are never found to "not escape" the JIT compilation > unit and are therefore never scalarized by JIT because of the "feature" > that was designed to actually prevent the continuous allocation of some > "values" of Integer(s) - namely the caching of Integer instances in the > Integer.IntegerCache.cache array for values in range [-128, 127]. So the > feature designed to prevent continuous allocation is actually working > against the desired goal. The code of Integer.valueOf is: > > ??? public static Integer valueOf(int i) { > ??????? if (i >= IntegerCache.low && i <= IntegerCache.high) > ??????????? return IntegerCache.cache[i + (-IntegerCache.low)]; > ??????? return new Integer(i); > ??? } > > ...so JIT would have to create two specializations of code: one for > cached Integer instances which are always real objects and the other for > scalarized Integer(s) created by constructor. Last time I experimented > with this was in JDK 8. Is HotSpot in JDK 12+ smarter now and can do > this? Perhaps the @HotSpotIntrinsicCandidate annotation on this method > is a clue that it is treated in a special way by the JIT? this has been fixed very recently https://bugs.openjdk.java.net/browse/JDK-8075052 > > > Regards, Peter regards, R?mi From andy.herrick at oracle.com Tue Mar 12 14:22:44 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 12 Mar 2019 10:22:44 -0400 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: <8FD446A3-EBB3-4B9B-962E-758315584645@gmail.com> References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> <8FD446A3-EBB3-4B9B-962E-758315584645@gmail.com> Message-ID: Yes? expect the next EA by next week. /Andy On 3/12/2019 3:40 AM, Lennart B?rjeson wrote: > OK. > > May I hope that a fix for this will make its way to the early-access > build soon? > > (While I can build from source myself, it is much more convenient to > use an EA in our CI cluster.) > > /Lennart > >> 11 mars 2019 kl. 18:04 skrev Andy Herrick > >: >> >> Although we plan to remove the mac-app-store intaller type for the >> first release (which will fix this instance the problem for now) I >> agree this is not right for an exception in one install type to >> prevent the other types (if there are any) from running. >> >> I think instead though we should try to run them all, then log what >> succeeded and then throw the exception if any failed. >> >> /Andy >> >> >> >> On 3/11/2019 7:55 AM, Lennart B?rjeson wrote: >>> Looking into the code of Arguments.generateBundle(Map params), I >>> believe it's a bug to immediately throw an error when a bundler has >>> configuration problems. >>> >>> Instead, that bundler should be removed from the platformBundlers >>> List. Quick-and-dirty solution: >>> >>> >>> diff -r e11f3bf34083 >>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java >>> --- >>> a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java >>> ??????Fri Mar 01 08:27:51 2019 -0500 >>> +++ >>> b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java >>> ??????Mon Mar 11 12:37:43 2019 +0100 >>> @@ -37,6 +37,7 @@ >>> ?import java.util.HashMap; >>> ?import java.util.HashSet; >>> ?import java.util.List; >>> +import java.util.ListIterator; >>> ?import java.util.Map; >>> ?import java.util.Set; >>> ?import java.util.Properties; >>> @@ -655,7 +656,10 @@ >>> ?????????// clean these extra (and unneeded) temp directories. >>> ?????????StandardBundlerParam.BUILD_ROOT.fetchFrom(params); >>> ?- ???????for (jdk.jpackage.internal.Bundler bundler : >>> getPlatformBundlers()) { >>> + ???????List platformBundlers = >>> getPlatformBundlers(); >>> + ???????ListIterator >>> platformBundleIterator = platformBundlers.listIterator(); >>> + ???????while (platformBundleIterator.hasNext()) { >>> + ???????????jdk.jpackage.internal.Bundler bundler = >>> platformBundleIterator.next(); >>> ?????????????Map localParams = new >>> HashMap<>(params); >>> ?????????????try { >>> ?????????????????if (bundler.validate(localParams)) { >>> @@ -677,18 +681,20 @@ >>> ?????????????} catch (ConfigException e) { >>> ?????????????????Log.debug(e); >>> ?????????????????if (e.getAdvice() != null) { >>> - ???????????????????throw new PackagerException(e, >>> + Log.info (new PackagerException(e, >>> ?????????????????????????????"MSG_BundlerConfigException", >>> - ???????????????????????????bundler.getName(), e.getMessage(), >>> e.getAdvice()); >>> + ???????????????????????????bundler.getName(), e.getMessage(), >>> e.getAdvice()).getMessage()); >>> ?????????????????} else { >>> - ???????????????????throw new PackagerException(e, >>> + Log.info (new PackagerException(e, >>> ????????????????????????????"MSG_BundlerConfigExceptionNoAdvice", >>> - ???????????????????????????bundler.getName(), e.getMessage()); >>> + ???????????????????????????bundler.getName(), >>> e.getMessage()).getMessage()); >>> ?????????????????} >>> + ???????????????platformBundleIterator.remove(); >>> ?????????????} catch (RuntimeException re) { >>> ?????????????????Log.debug(re); >>> - ???????????????throw new PackagerException(re, >>> "MSG_BundlerRuntimeException", >>> - ???????????????????????bundler.getName(), re.toString()); >>> + Log.info (new PackagerException(re, >>> "MSG_BundlerRuntimeException", >>> + ???????????????????????bundler.getName(), >>> re.toString()).getMessage()); >>> + ???????????????platformBundleIterator.remove(); >>> ?????????????} finally { >>> ?????????????????if (userProvidedBuildRoot) { >>> ?????????????????????Log.verbose(MessageFormat.format( >>> >>> >>> Best regards, >>> >>> /Lennart B?rjeson >>> >>>> 11 mars 2019 kl. 09:40 skrev Lennart B?rjeson >>> >: >>>> >>>> I'm experimenting with jpackage from the current EA available >>>> athttps://jdk.java.net/jpackage/, >>>> for the moment on Mac only. >>>> >>>> I have an existing application which I have previously deployed on >>>> multiple platforms using the then bundled javafxpackager. >>>> >>>> With the current EA (build 17), I find I must specify the >>>> --installer-type parameter, otherwise I get the following error: >>>> >>>> $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage >>>> create-installer --overwrite --output >>>> /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui >>>> --app-image >>>> /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app >>>> --icon BMF.icns --identifier com.cinnober.bmf.gui.Main >>>> --app-version 1.6.10 --verbose >>>> jdk.jpackage.internal.PackagerException: Bundler Mac App Store >>>> Ready Bundler skipped because of a configuration problem: Mac App >>>> Store apps must be signed, and signing has been disabled by bundler >>>> configuration. >>>> Advice to fix: Either unset 'signBundle' or set 'signBundle' to true. >>>> at >>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726) >>>> at >>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:642) >>>> at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90) >>>> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) >>>> Caused by: jdk.jpackage.internal.ConfigException: Mac App Store >>>> apps must be signed, and signing has been disabled by bundler >>>> configuration. >>>> at >>>> jdk.jpackage/jdk.jpackage.internal.MacAppStoreBundler.validate(MacAppStoreBundler.java:332) >>>> at >>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:705) >>>> ... 3 more >>>> >>>> With the previous javafxpackager this wasn't needed. Javafxpackager >>>> always tried to create all installer types and ignored all errors >>>> from any specific bundler, e.g. on linux it always tried to create >>>> both a Debian package and an rpm and just ignored if any of the >>>> requisite builder tools was unavailable. >>>> >>>> The obvious workaround in my case is to run jpackage twice, once >>>> with "--installer-type pkg" and once with "--installer-type dmg", >>>> but since I'm furthered hampered by limitations of my toolchain >>>> (gradle + badass-jlink-plugin) it would really simplify matters it >>>> jpackage could be restored to the javafxpackager behaviour when >>>> "--installer-type" is unspecified, e.g. ignore errors and create >>>> whatever installers it can. >>>> >>>> >>>> Best regards, >>>> >>>> /Lennart B?rjeson > From brian.goetz at oracle.com Tue Mar 12 15:12:29 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 12 Mar 2019 11:12:29 -0400 Subject: JDK 12's String::transform vs F#'s |> operator In-Reply-To: References: Message-ID: On 3/8/2019 3:47 PM, Lukas Eder wrote: > Hello, > > I've recently learned about JDK 12's new String::transform method: > https://bugs.openjdk.java.net/browse/JDK-8203703 > > Obviously, this is useful. And obviously, this would be far more useful as > a general pattern than just something for String. E.g. why not also for any > Number subtype. For Boolean. For java.time types. Etc. Yes, that's the plan -- to add this method more widely. Yes, we could go bigger, and add the |> operator, but that's not in the current plan. From Roger.Riggs at oracle.com Tue Mar 12 15:32:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 12 Mar 2019 11:32:38 -0400 Subject: RFR [doc] 8220237: ProcessBuilder API documentation typo Message-ID: <24abd8ce-fb21-3334-e582-fd8eccda4521@oracle.com> Please review a doc fix to refer to the correct method reading from the process. diff --git a/src/java.base/share/classes/java/lang/ProcessBuilder.java b/src/java.base/share/classes/java/lang/ProcessBuilder.java --- a/src/java.base/share/classes/java/lang/ProcessBuilder.java +++ b/src/java.base/share/classes/java/lang/ProcessBuilder.java @@ -89,7 +89,7 @@ import sun.security.action.GetPropertyAc ? *
            • a destination for standard output ? * and standard error.? By default, the subprocess writes standard ? * output and standard error to pipes.? Java code can access these pipes - * via the input streams returned by {@link Process#getOutputStream()} and + * via the input streams returned by {@link Process#getInputStream()} and ? * {@link Process#getErrorStream()}.? However, standard output and ? * standard error may be redirected to other destinations using ? * {@link #redirectOutput(Redirect) redirectOutput} and Issue: https://bugs.openjdk.java.net/browse/JDK-8220237 Thanks, Roger From goetz.lindenmaier at sap.com Tue Mar 12 15:04:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Mar 2019 15:04:07 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Message-ID: Hi Peter, > ? 56???? private static final String MESSAGE_PLACEHOLDER = > "NPE_MESSAGE_PLACEHOLDER"; > Here, the initializer of that constant should create a private instance > of String: ... > ??? private static final String MESSAGE_PLACEHOLDER = new String(); Ok, I understand. > ? 81???? public String getMessage() { > ? 82???????? String message = super.getMessage(); > ? 83???????? if (message == MESSAGE_PLACEHOLDER) { > ? 84???????????? message = getExtendedNPEMessage(); > ? 85???????????? setMessage(message); > ? 86???????? } > ? 87???????? return super.getMessage(); > ? 88???? } > > Why not simply returning 'message' local variable here? As I removed the synchronization, this would reduce the chance to get different objects in case of a race. Highly unlikely though. I changed the webrev with this solution to include these your remarks: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03-PeterLevart/ (updated in-place). Nevertheless, I think I will follow Roger's demand to not modify the defaultMessage field. Best regards, Goetz. > > > Regards, Peter > > On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > >> Maybe 10 years ago, when native was the only solution. > >> Now there are tools to analyze bytecode in java. > > I'm working on a Java implementation. > > > >>> Peter Levart proposed to initialize the message with a sentinel instead. > >>> I'll implement this as a proposal. > >> That's an extra overhead too, any assignment is. > > Yes, any code requires some run time. But I think this really is negligible > > in comparison to generating the backtrace, which happens on every > > exception. But I'm fine with the 'always recompute, no serialization' > > solution. If it turns out to be limited, it still can be changed easily. > > > >>> I guess we can go without. > >>> It would be possible to construct a case where two threads > >>> do getMessage() on the same NPE Object but the string is not > >>> the same. > >> Really!, if the bci is the same, the bytecode is the same, what could be > different > >> that would change the data used to create the exception? > > e.getMessage().equals(e.getMessage()) will hold, but > > e.getMessage() != e.getMessage(). > > > > I just implemented the two variants of computing the message, they > > basically differ in NullPointerException.java: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03- > PeterLevart/ > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04- > RogerRiggs/ > > > > I also cleaned up the parameters passed as proposed. > > > >>> We uses this code since 2006, it needed only few changes. I would like to > >>> contribute a follow up for hidden frames of lambdas. > >> Valhalla and evolution of the byte code needs to be considered. > >> Just because its worked for years does not mean it's the best approach > >> today. Dropping it in now means maintaining it in its current form > >> or needing to re-write it later. > > Well, yes, that is true. For any change. For any project. We have heard > > this argument for many of our changes. I don't really think it's a good > > argument. As I understand Valhalla is not targeted for jdk13, and > > holding up changes for some future projects not really is the process > > of OpenJDK, is it? > > > >>>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > >>>> question > >>>> about how useful the information is, developers should not need to know > >>>> about "slot 1". > >>> Developers should work with class files with debug information and then > >>> they would get the name printed. If exceptions are thrown in production > >>> code, any information is helpful. Should I just write "a local"? > >> Go back to who you think is going to benefit from it, it seems targeted > >> at a fairly novice developer, so exposing low level details may be more > >> confusing that just giving a line number and NPE. > > Especially on our improved NPE messages we always got good feedback > > from the developers within SAP. And there are quite some experienced > > people. Any message requires some background to be helpful. And I > > like to get any information I can have in first place. Attaching the > > debugger often is a big overhead. E.g., I look at about 50 failing jtreg > > tests every day, I don't want to get each into the debugger every time > > in the setup where it was running to see what is wrong ... > > > > E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java > > is failing in a headless environment with an NPE on this line: > > SwingUtilities.invokeAndWait(() -> frame.dispose()); > > With this change it said "while trying to invoke the method > javax.swing.JFrame.dispose(()V) of a null object loaded from static field > AltFocusIssueTest.frame" and I figured it's the fact we run headless that > > makes the test fail without even looking at the code. > > > > Best regards, > > Goetz > > > > > > > > > > > > > > > > > > From: Roger Riggs > > Sent: Dienstag, 12. Februar 2019 17:03 > > To: Lindenmaier, Goetz ; Java Core Libs libs-dev at openjdk.java.net> > > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > > > Hi, > > On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > > thanks for looking at my change! > > > > A few higher level issues should be considered, though the details of > > the webrev captured my immediate attention. > > > > Is this the right feature > > Yes!! > > Maybe, that's what debuggers are for. > > > > > > > > and is this the right level of implementation (C++/native)? > > See below. > > Maybe 10 years ago, when native was the only solution. > > Now there are tools to analyze bytecode in java. > > > > > > > > From a security perspective, adding field names to exceptions exposes > > information to callers that they could not otherwise get and that breaks > > encapsulation. > > That needs to be evaluated. > > I can not comment on that. How can I trigger an evaluation of this? > > Who needs to evaluate this? > > > > I think there are ways to make this easier to implement and be easier to > > maintain and perform better. > > > > NullPointerException: > > 28: unused import of Field > > Removed > > > > 64: The lazyComputeMessage boolean should be inverted so it does not > > require > > ?? initialization, false is the default, anything else adds overhead. > > ?? And it may not be needed. > > Peter Levart proposed to initialize the message with a sentinel instead. > > I'll implement this as a proposal. > > That's an extra overhead too, any assignment is. > > > > > > > > 91: Why do you think synchonization is necessary?? It is a performance hit. > > ?? It is highly unlikely to be called from multiple threads and the > > value will > > ?? be the same whether it is computed once or multiple times by > > different threads. > > I guess we can go without. > > It would be possible to construct a case where two threads > > do getMessage() on the same NPE Object but the string is not > > the same. > > Really!, if the bci is the same, the bytecode is the same, what could be > different > > that would change the data used to create the exception? > > > > > > > > 99: extendedMessage will never be null (so says the javadoc of > > getExtendedNPEMessage) > > ? Bug: If it does return null, then null is returned from getMessage > > ? regardless of the value of super.getMessage(). > > Fixed. > > > > 121: Simplify getExtendedNPEMessage by making it only responsible for > > the detail > > ? and not concatenation with an existing message.? Put that in > > getMessage(). > > Fixed. You are right, I only call this when the message is NULL. > > > > ? Its not strictly necessary to change the updated message with > > setMessage(). > > ? Avoiding that will avoid complexity and a performance hit. > > ? The message will be computed each time it is needed, and that happens > > infrequently. > > ? (Even in the serialization case, it will be re-computed from the > > attached stack frames). > > No, you can not recompute it from the stacktrace because that > > does not contain the BCI. Also, after deserialization, the bytecode > > might look different or not available at all. It depends on the actual > > bytecode that has been running when the exception was thrown. > > Right, I realized this too when thinking about it over the weekend. > > > > If a suitable low impact mechanism can't be found, then just > > go back to not exposing the extended message and use only the original. > > Its a bad idea to twist and contort the local design and accessibility > > just for serialization. What remote or delayed client needs to know this? > > > > > > > > > > ? And it avoids adding setMessage() to Throwable, that's significant > > change since > > ? the current implementation only allows the message to be initialized > > not updated. > > ? Immutable is an important characteristic to maintain. > > Yes, I don't like I have to set this. But it follows the same pattern > > as with the stack trace which is only computed on demand. Thus, > > Throwable is not immutable anyways. Before, I implemented this by a > > JNI call hiding this in the Java code. > > I proposed implementing setting the field by reflection, Christoph > > proposed a shared secret. David favored the package private setter. > > Please advice what is best. > > All of them are bad. Private needs to mean private. > > > > And making it mutable, also means that synchronization or volatile > > is needed to ensure a consistent value for getMessage(). > > That turns into a performance issue for all throwables. > > None of the above. > > > > > > > > That makes the writeReplace() unnecessary too. > > No. I need this, see above. > > See above, but is not essential to the core feature. > > > > > > > > Additional command line arguments are an unnecessary complexity, > > documentation, and maintenance overhead.? If the feature is as valuable as > > you suggest, it should be enabled all the time. > > Removed. > > > > I'm assuming there are no tests broken by the modification of the message. > > It is likely that somewhere an application or test looks at the message > > itself. > > Has that been verified? > > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests > and some > > other applications. They are all unaffected by this change after adapting the > > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, > mac) > > Also, I modified quite some messages before which didn't cause any follow- > up > > breakages to my knowledge. > > It does seem unlikely. > > > > > > > > I can't speak for the hotspot code, but that seems to add a lot of code > > to support > > only this convenience feature.? That's a maintenance overhead and burden. > > We uses this code since 2006, it needed only few changes. I would like to > > contribute a follow up for hidden frames of lambdas. > > Valhalla and evolution of the byte code needs to be considered. > > Just because its worked for years does not mean its the best approach > > today.? Dropping it in now means maintaining it in its current form > > or needing to re-write it later. > > > > > > > > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > > question > > about how useful the information is,? developers should not need to know > > about "slot 1". > > Developers should work with class files with debug information and then > > they would get the name printed. If exceptions are thrown in production > > code, any information is helpful. Should I just write "a local"? > > Go back to who you think is going to benefit from it, it seems targeted > > at a fairly novice developer, so exposing low level details may be more > > confusing that just giving a line number and NPE. > > > > > > > > The test output of NullPointerExceptionTest shows > > "java.lang.Object.hashCode(()I)". > > Why is the argument type for Integer shown as "()I";? that's not the > > conventional > > representation of a primitive int. > > I already discussed this with David Holmes: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > February/058464.html > > Other exceptions use the same format. I don't know of an utility in > > hotspot to translate the format to Java source code syntax. We > > implemented such an utility in our internal VM, though, and I would > > like to contribute this, too, adapting all the exceptions. I would do this > > in a follow-up. > > There may be better tools for formatting if it was done in java at a > > more appropriate level of abstraction. > > > > > > > > Generally, the explanations are too verbose. > > Method names and field names would be easier to recognize if they were > > quoted, as is done with 'this'. > > Fixed, although this is not common in exception messages. See the > > messages in > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt > ime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > > line 57ff. Only the String of the name field is quoted, not any entities > > declared in the code. > > Similar > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt > ime/LoaderConstraints/vtableAME/Test.java > > line 60, also showing the internal signature, see above. > > > > Argument numbers should be digits, > > not English words (first, second, etc) to make them easier to pick out. > > Fixed. > > And has it limits that do not read easily, e.g. "nr. 9". > > Sorry, I don't understand > > src/hotspot/share/classfile/bytecodeUtils.cpp:566 > > > test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerE > xceptionTest.java:612 > > > > I would not describe 'this' as a local variable. > > Fixed. > > > > Tests, especially new tests should compile without warnings. > > NullPointerExceptionTest.java:125 newInstance has been deprecated. > > Fixed. > > > > The messages can be easier to understand, e.g. > > 'field a1 is null, trying to invoke a1.hashCode...' instead of: > > "while trying to invoke the method java.lang.Object.hashCode(()I) on a > > null reference loaded from local variable 'a1'" > > The message is built along the structure of the bytecode. > > I'll try to change this and then will come up with a new webrev . > > > > It will easier to understand if it looks more like the code. > > BTW, what does this look like for fully optimized code? > > You mean whether the bytecode is jitted? It's independent > > of how the code is executed, interpreted or compiled. > > > > Does it bear any resemblance to the source code at all? > > Or does it have to be deoptimized to come up with a sensible source > > reference. > > No, jitted methods must not be deoptimized. > > > > How much of this can be done in Java code with StackWalker and other > > java APIs? > > It would be a shame to add this much native code if there was a more robust > > way to implement it using APIs with more leverage. > > StackWalker operates on the Java stack tracke, which does not contain the > BCI > > to my knowledge. Also, I need to read the bytecodes. Are there APIs to > access > > the bytecode as it resides in the metaspace, rewritten, constants resolved > etc? > > The code relies on this. > > > > From the other thread, beware adding overhead to the constructor. > > The lazy computation is essential. > > There are a *lot* of NPEs whose messages will never be needed. > > > > Regards, Roger > > > > > > > > > > Best regards, > > Goetz. > > > > > > > > Regards, Roger > > > > > > On 02/08/2019 09:13 AM, Langer, Christoph wrote: > > Hi Goetz, > > > > ok, so here a new webrev just adding a setter for the field: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > > > > ... and incorporating the other comments. > > Looks better ?? > > > > I have a few additions to > > src/java.base/share/classes/java/lang/NullPointerException.java: > > > > 28 import java.lang.reflect.Field; > > 29 > > -> can be removed now. > > > > 91 synchronized (this) { > > -> I think this is not needed here. The transient modifier for > > lazyComputeMessage already implies the lock on the Object, I think. > > > > 108 return extendedMessage; > > -> I guess it would be more correct if you returned super.getMessage() here. > > > > Thanks > > Christoph > > > > From daniel.fuchs at oracle.com Tue Mar 12 15:44:04 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Mar 2019 15:44:04 +0000 Subject: RFR [doc] 8220237: ProcessBuilder API documentation typo In-Reply-To: <24abd8ce-fb21-3334-e582-fd8eccda4521@oracle.com> References: <24abd8ce-fb21-3334-e582-fd8eccda4521@oracle.com> Message-ID: Looks good to me Roger. It's kind of unfortunate that the process output is returned by a method named getInputStream(), even though I understand that's a mirror effect... best regards, -- daniel On 12/03/2019 15:32, Roger Riggs wrote: > Please review a doc fix to refer to the correct method reading from the > process. > > diff --git a/src/java.base/share/classes/java/lang/ProcessBuilder.java > b/src/java.base/share/classes/java/lang/ProcessBuilder.java > --- a/src/java.base/share/classes/java/lang/ProcessBuilder.java > +++ b/src/java.base/share/classes/java/lang/ProcessBuilder.java > @@ -89,7 +89,7 @@ import sun.security.action.GetPropertyAc > ? *
            • a destination for standard output > ? * and standard error.? By default, the subprocess writes > standard > ? * output and standard error to pipes.? Java code can access these pipes > - * via the input streams returned by {@link Process#getOutputStream()} and > + * via the input streams returned by {@link Process#getInputStream()} and > ? * {@link Process#getErrorStream()}.? However, standard output and > ? * standard error may be redirected to other destinations using > ? * {@link #redirectOutput(Redirect) redirectOutput} and > > Issue: https://bugs.openjdk.java.net/browse/JDK-8220237 > > Thanks, Roger From daniel.fuchs at oracle.com Tue Mar 12 15:59:29 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Mar 2019 15:59:29 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value Message-ID: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> Hi, Please find below a simple fix for 8219197: ThreadGroup.enumerate() may return wrong value http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.00/ This is a bug in the implementation of the recursion, as enumerate(list, n, recurse) should never have returned a value < n. The test passes with the fix and fails 'often enough' without it (~ 1 times out of 2 or 3). best regards, -- daniel From brian.goetz at oracle.com Tue Mar 12 16:04:16 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 12 Mar 2019 12:04:16 -0400 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> No.? You have the LSP backwards (though this is easy to do.) IterableOnce means "*must throw* on subsequent use"; under this spec, an arbitrary Iterable is most certainly *not* an IterableOnce, and therefore an LSP violation. It sounds like you are suggesting that we instead spec IterableAtLeastOnce, of which Iterable *would* be a credible subtype -- but due to how Iterable is specified now, the problem is that Iterable *already is* really "iterable at least once."? So there would be no point in introducing this type; we already have it. If we were doing this from scratch, we might choose a different path, but that option is not open to us.? As several have already noted, this proposal is not ideal, but due to the corner we're painted into by Iterable's current spec, there is not going to be an ideal outcome -- and the current strategy (do nothing) is also not ideal and makes many people unhappy.? So the game here is finding the least-bad solution that is compatible with the constraints we have, which I think Stuart has done exactly. (Also, he did a very nice job of writing up all the alternatives, to avoid (or at least reduce) the torrent of "have you thought about ".) On 3/6/2019 10:50 AM, Peter Levart wrote: > > In this respect Iterable should be a subtype of IterableOnce and > foreach loop should be retrofitted to work with IterableOnce. From andy.herrick at oracle.com Tue Mar 12 16:46:25 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 12 Mar 2019 12:46:25 -0400 Subject: RFR: 8220505: Allow building available installers when --installer-type not specified Message-ID: <7afd070f-25f8-96db-0fa2-c285b4b7931b@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8220505 [2] http://cr.openjdk.java.net/~herrick/8220505/ /Andy From Roger.Riggs at oracle.com Tue Mar 12 16:51:40 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 12 Mar 2019 12:51:40 -0400 Subject: RFR [doc] 8220237: ProcessBuilder API documentation typo In-Reply-To: References: <24abd8ce-fb21-3334-e582-fd8eccda4521@oracle.com> Message-ID: <74023069-32ec-c88e-cd3e-07d1fb722fc4@oracle.com> Thanks Daniel, yes, the method naming ship has sailed. On 03/12/2019 11:44 AM, Daniel Fuchs wrote: > Looks good to me Roger. > > It's kind of unfortunate that the process output > is returned by a method named getInputStream(), > even though I understand that's a mirror effect... > > best regards, > > -- daniel > > On 12/03/2019 15:32, Roger Riggs wrote: >> Please review a doc fix to refer to the correct method reading from >> the process. >> >> diff --git >> a/src/java.base/share/classes/java/lang/ProcessBuilder.java >> b/src/java.base/share/classes/java/lang/ProcessBuilder.java >> --- a/src/java.base/share/classes/java/lang/ProcessBuilder.java >> +++ b/src/java.base/share/classes/java/lang/ProcessBuilder.java >> @@ -89,7 +89,7 @@ import sun.security.action.GetPropertyAc >> ?? *
            • a destination for standard >> output >> ?? * and standard error.? By default, the subprocess >> writes standard >> ?? * output and standard error to pipes.? Java code can access these >> pipes >> - * via the input streams returned by {@link >> Process#getOutputStream()} and >> + * via the input streams returned by {@link >> Process#getInputStream()} and >> ?? * {@link Process#getErrorStream()}.? However, standard output and >> ?? * standard error may be redirected to other destinations using >> ?? * {@link #redirectOutput(Redirect) redirectOutput} and >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8220237 >> >> Thanks, Roger > From lance.andersen at oracle.com Tue Mar 12 17:30:17 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 12 Mar 2019 13:30:17 -0400 Subject: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out Message-ID: Hi all, Please review this addition to the ProblemList.txt as this tests times out from time to time $ hg diff test/jdk/ProblemList.txt diff -r 687e10fefa11 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Mon Mar 11 13:37:56 2019 -0400 +++ b/test/jdk/ProblemList.txt Tue Mar 12 13:27:35 2019 -0400 @@ -840,6 +840,8 @@ # jdk_util +java/util/Arrays/TimSortStackSize2.java 8220005 generic-all + ############################################################################ # jdk_instrument $ 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 peter.levart at gmail.com Tue Mar 12 17:34:58 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 12 Mar 2019 18:34:58 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> Message-ID: On 3/12/19 5:04 PM, Brian Goetz wrote: > No. You have the LSP backwards (though this is easy to do.) > > IterableOnce means "*must throw* on subsequent use"; under this spec, > an arbitrary Iterable is most certainly *not* an IterableOnce, and > therefore an LSP violation. > > It sounds like you are suggesting that we instead spec > IterableAtLeastOnce, of which Iterable *would* be a credible subtype > -- but due to how Iterable is specified now, the problem is that > Iterable *already is* really "iterable at least once."? So there would > be no point in introducing this type; we already have it. Due to how Iterable is specified now it does not promise multiple iterations, but due to how most (all that I know of except DirectoryStream or some 3rd party) Iterables are implemented now, the common expectation is that it does. By implementing more Iterable(s) that don't support multiple iteration (regardless of whether they implement this new sub-type or not), this expectation will be less and less honored. Perhaps this is not so bad. At various occasions the specification has been changed to accommodate the long-standing behavior or expectation of behavior, but this seems not to be one of them. Let's pretend for a moment that Iterable specification was changed to guarantee multi-pass iteration. In that case the IterableAtLeastOnce as a supertype of multi-pass Iterable would make much more sense, wouldn't it? But as there could be Iterables out there that by current spec are perfectly valid and don't support multi-pass iteration, such spec change would make them non-conformant and is therefore not allowed. So I'm convinced now that this is the least-bad solution. Regards, Peter > > If we were doing this from scratch, we might choose a different path, > but that option is not open to us.? As several have already noted, > this proposal is not ideal, but due to the corner we're painted into > by Iterable's current spec, there is not going to be an ideal outcome > -- and the current strategy (do nothing) is also not ideal and makes > many people unhappy.? So the game here is finding the least-bad > solution that is compatible with the constraints we have, which I > think Stuart has done exactly. (Also, he did a very nice job of > writing up all the alternatives, to avoid (or at least reduce) the > torrent of "have you thought about extensively>".) > > On 3/6/2019 10:50 AM, Peter Levart wrote: >> >> In this respect Iterable should be a subtype of IterableOnce and >> foreach loop should be retrofitted to work with IterableOnce. > From brian.goetz at oracle.com Tue Mar 12 17:38:24 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 12 Mar 2019 13:38:24 -0400 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> Message-ID: > Due to how Iterable is specified now it does not promise multiple > iterations, but due to how most (all that I know of except > DirectoryStream or some 3rd party) Iterables are implemented now, the > common expectation is that it does. By implementing more Iterable(s) > that don't support multiple iteration (regardless of whether they > implement this new sub-type or not), this expectation will be less and > less honored. Perhaps this is not so bad. At various occasions the > specification has been changed to accommodate the long-standing > behavior or expectation of behavior, but this seems not to be one of > them. Correct.? But, with separate Iterable and IterableOnce, the spec for Iterable can say "If you don't support multiple iteration, you should implement IO."? Which is OK, because at least those classes are being explicit. > Let's pretend for a moment that Iterable specification was changed to > guarantee multi-pass iteration. In that case the IterableAtLeastOnce > as a supertype of multi-pass Iterable would make much more sense, > wouldn't it? Then we couldn't use Stream in foreach without a language change, which is the whole point of this exercise. From brent.christian at oracle.com Tue Mar 12 17:37:12 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 12 Mar 2019 10:37:12 -0700 Subject: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out In-Reply-To: References: Message-ID: +1 -Brent On 3/12/19 10:30 AM, Lance Andersen wrote: > Hi all, > > Please review this addition to the ProblemList.txt as this tests times out from time to time > > > $ hg diff test/jdk/ProblemList.txt > diff -r 687e10fefa11 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Mar 11 13:37:56 2019 -0400 > +++ b/test/jdk/ProblemList.txt Tue Mar 12 13:27:35 2019 -0400 > @@ -840,6 +840,8 @@ > > # jdk_util > > +java/util/Arrays/TimSortStackSize2.java 8220005 generic-all > + > ############################################################################ > > # jdk_instrument > $ > > > > > > 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 Tue Mar 12 21:45:12 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Mar 2019 14:45:12 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> Message-ID: <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> Hi Remi, > Stream.iterator() can be really really slow, it uses a pull semantics while > the whole Stream push values. When designing it, the lambda EG saw it as an > "escape hatch" in order to interropt with a legacy code than require an > Iterator and not more. If Stream.iterator() is slow, then perhaps it needs to be optimized. Tagir had some ideas for how to do that. Of course, I don't know if that's exactly the right way; some additional investigation should be done. But poor performance relative to Spliterator.tryAdvance() or forEachRemaining() shouldn't be an argument against doing this. People repeatedly bump into the gap in the programming model between streams and the enhanced-for loop, and it's time to fill it in. > This proposal has the side effect of making Stream more different from its > primitive counterpart IntStream, LongStream and DoubleStream which may be > problematic because we are trying to introduce reified generics as part of > Valhalla (there is a recent mail of Brian about not adding methods to > OptionalInt for the same reason). Well, yes, I think that it means that Stream evolves somewhat independently of Int/Long/DoubleStream, but I don't see that this imposes an impediment on generic specialization in Valhalla. In that world, Stream should (mostly) just work. It may also be possible in a specialized world to add the specific things from IntStream (such as sum() and max()) to Stream. > And, the real issue is how to deal with checked exceptions inside the Stream > API, i would prefer to fix that issue instead of trying to find a way to > workaround it. Well I'd like to have a solution for checked exceptions as well, but there doesn't appear to be one on the horizon. I mean, there are some ideas floating around, but nobody is working on them as far as I know. But checked exceptions aren't the only reason to prefer iteration in some cases; loops offer more flexible control flow (break/continue) and easier handling of side effects. The Streams+IterableOnce feature benefits these cases as well as exception handling. s'marks From alexander.matveev at oracle.com Tue Mar 12 21:52:35 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 12 Mar 2019 14:52:35 -0700 Subject: RFR: 8220505: Allow building available installers when --installer-type not specified In-Reply-To: <7afd070f-25f8-96db-0fa2-c285b4b7931b@oracle.com> References: <7afd070f-25f8-96db-0fa2-c285b4b7931b@oracle.com> Message-ID: <185ec8ad-002c-c697-7bd4-2800fec5dba2@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 3/12/2019 9:46 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] https://bugs.openjdk.java.net/browse/JDK-8220505 > > [2] http://cr.openjdk.java.net/~herrick/8220505/ > > /Andy > From stuart.marks at oracle.com Tue Mar 12 21:59:03 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Mar 2019 14:59:03 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> Hi Stephen, > My slight concern is that the terminal operation is hidden and not > immediately visible, which could be surprising. I do note that streams > throw a clear exception if a terminal operation is called a second > time which mitigates this to some degree. Yes, this is certainly a possibility. I'll note that even though my example does it, I think that storing a stream in a local variable is a bit of a code smell. It has to be done for try-with-resources, but storing the head of a pipeline in a local variable so that it can be iterated over does introduce the possibility of accidental reuse. I suspect that most cases (aside from try-with-resources) will call a method returning a fresh Stream that's then iterated over. For example, for (var x : getSomeStream()) { // ... } In this case there's no possibility of accidental reuse. > The IterableOnce class-level Javadoc contradicts the method-level > Javadoc. The class-level say "It is recommended that" whereas the > method-level Javadoc mandates. Oh yes, thanks. I'll fix this to make the behavior mandatory. s'marks From stuart.marks at oracle.com Tue Mar 12 22:05:18 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Mar 2019 15:05:18 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> Message-ID: <51e987ff-49ea-f417-805f-dfd2616f0546@oracle.com> >> Due to how Iterable is specified now it does not promise multiple iterations, >> but due to how most (all that I know of except DirectoryStream or some 3rd >> party) Iterables are implemented now, the common expectation is that it does. >> By implementing more Iterable(s) that don't support multiple iteration >> (regardless of whether they implement this new sub-type or not), this >> expectation will be less and less honored. Perhaps this is not so bad. At >> various occasions the specification has been changed to accommodate the >> long-standing behavior or expectation of behavior, but this seems not to be >> one of them. > > Correct.? But, with separate Iterable and IterableOnce, the spec for Iterable > can say "If you don't support multiple iteration, you should implement IO." > Which is OK, because at least those classes are being explicit. Right. This sort of clarification should be done as part of JDK-8186220. s'marks From ivan.gerasimov at oracle.com Tue Mar 12 23:32:01 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 12 Mar 2019 16:32:01 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> Message-ID: <9b010e5e-80c7-1276-d90f-d2d10aaad864@oracle.com> Hello! Just an observation. If there were two new subtypes of Iterable introduced: IterableOnce and IterableMultipleTimes, then all existing Iterables could be retrofitted to implement one of these. It wouldn't *automatically* solve the problem of 3rd party API, which accepts an Iterable and iterates it multiple times, but would provide a means to change that API in a straightforward way. Also, the static analysis tools could issue a suggestion for code that iterates Iterable more than once to switch to IterableMultipleTimes, so that it won't be possible to pass in an IterableOnce. It would also allow to strengthen the specification for IterableMultipleTimes and state that all classes implementing it must make it possible to obtain multiple iterators. With kind regards, Ivan On 2/28/19 6:43 PM, Stuart Marks wrote: > Hi all, > > Please review and comment on this proposal to allow Stream instances > to be used in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream using a conventional > loop. However, the Stream interface doesn't implement Iterable, and > therefore streams cannot be used with the enhanced-for statement. This > is a proposal to remedy that situation by introducing a new interface > IterableOnce that is a subtype of Iterable, and then retrofitting the > Stream interface to implement it. Other JDK classes will also be > retrofitted to implement IterableOnce. > > Full Proposal: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8148917 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ > > Note, this changeset isn't ready to push yet. In particular, it has no > tests yet. However, the implementation is so simple that I figured I > should include it. Comments on the specification wording are also > welcome. > > Thanks, > > s'marks > -- With kind regards, Ivan Gerasimov From lance.andersen at oracle.com Wed Mar 13 00:01:35 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 12 Mar 2019 20:01:35 -0400 Subject: RFR 8220253: Fix Headings in java.sql.rowset Message-ID: <3AC46E61-BB68-4141-9674-E440C563574F@oracle.com> Hi all Please review the fix for 8220253, to address the javadoc header issues [1] in java.sql.rowset The webrev can be found at: http://cr.openjdk.java.net/~lancea/8220253/webrev.00/ Best Lance [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html 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 joe.darcy at oracle.com Wed Mar 13 00:39:19 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Mar 2019 17:39:19 -0700 Subject: RFR 8220253: Fix Headings in java.sql.rowset In-Reply-To: <3AC46E61-BB68-4141-9674-E440C563574F@oracle.com> References: <3AC46E61-BB68-4141-9674-E440C563574F@oracle.com> Message-ID: +1 Cheers, -Joe On 3/12/2019 5:01 PM, Lance Andersen wrote: > Hi all > > Please review the fix for 8220253, to address the javadoc header issues [1] in java.sql.rowset > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8220253/webrev.00/ > > Best > Lance > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html > > > 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 david.holmes at oracle.com Wed Mar 13 01:55:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2019 11:55:02 +1000 Subject: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out In-Reply-To: References: Message-ID: <00e40321-d2f5-7b34-849b-82ec7d209af4@oracle.com> Hi Lance, On 13/03/2019 3:30 am, Lance Andersen wrote: > Hi all, > > Please review this addition to the ProblemList.txt as this tests times out from time to time > > > $ hg diff test/jdk/ProblemList.txt > diff -r 687e10fefa11 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Mar 11 13:37:56 2019 -0400 > +++ b/test/jdk/ProblemList.txt Tue Mar 12 13:27:35 2019 -0400 > @@ -840,6 +840,8 @@ > > # jdk_util > > +java/util/Arrays/TimSortStackSize2.java 8220005 generic-all The bug number here is the bug that will be used to fix the test, not the bug used to add it to the ProblemList. Thanks, David ----- > + > ############################################################################ > > # jdk_instrument > $ > > > > > > 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.farley at uk.ibm.com Wed Mar 13 10:21:36 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 13 Mar 2019 10:21:36 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <458b8b41-42cf-d846-f5d8-003b9e5236ee@oracle.com> Message-ID: Hi Joe, Mandy, Thanks for getting back to me. Based on these responses, I'm forgoing the backport. Will put this one on the backburner while we wait for the CSR to be approved. Best Regards Adam Farley IBM Runtimes Joe Darcy wrote on 12/03/2019 03:32:43: > From: Joe Darcy > To: Mandy Chung , Adam Farley8 > > Cc: core-libs-dev > Date: 12/03/2019 03:34 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > > On 3/11/2019 3:49 PM, Mandy Chung wrote: > > > > > > On 3/11/19 8:48 AM, Adam Farley8 wrote: > >> Hi Mandy, > >> > >> Thank you for explaining. :) > >> > >> Unfortunately I'm only a mere Author, and I cannot submit test runs > >> on the shared test server. > >> > >> I have run the test locally, and it passes against a patched build > >> and fails correctly agaionst an unpatched build, so I think we're > >> good to go. > > > > I will sponsor this patch for you when CSR is approved. > > > >> Can you tell me if there's something I can do to help move the CSR > >> forward? > > > > No additional action from your end. It's already in finalized state. > > > >> Also, can you tell me if an additional CSR would need to be created > >> for other releases if this fix gets backported? > > > > Which release are you thinking to backport to? > > > > IMO I don't think this fix is critical for existing releases > > and this fix has behavioral change. > > > As a procedural matter, to do a CSR for multiple releases, first create > the backport issue for the release or release train in question (e.g. > some particular update release like "12.0.1" or "12-pool") and then > create a CSR of the backport. This is the procedure if an update release > train is using the CSR review process. > > However, note that as this proposed changes alters a spec in the Java SE > API, it would require a maintenance review of the Java SE spec, which is > very unlikely to occur in an update release. > > HTH, > > -Joe > 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 christoph.langer at sap.com Wed Mar 13 12:44:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Mar 2019 12:44:47 +0000 Subject: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> Message-ID: Hi Daniel, the fix looks good to me. In the test, you could remove the import java.util.Set; in line 36 and List groups of line 74 is not needed as well. BTW, as you are touching it, src/java.base/share/classes/java/lang/ThreadGroup.java does not need the import jdk.internal.misc.VM; in line 30 neither. Maybe you want to clean that up, too? Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Daniel Fuchs > Sent: Dienstag, 12. M?rz 2019 16:59 > To: core-libs-dev > Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value > > Hi, > > Please find below a simple fix for > 8219197: ThreadGroup.enumerate() may return wrong value > > http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.00/ > > This is a bug in the implementation of the recursion, > as enumerate(list, n, recurse) should never have returned > a value < n. > > The test passes with the fix and fails 'often enough' without > it (~ 1 times out of 2 or 3). > > best regards, > > -- daniel From daniel.fuchs at oracle.com Wed Mar 13 12:59:45 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 12:59:45 +0000 Subject: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> Message-ID: <98aec086-f055-078e-bb10-d52860905bed@oracle.com> Hi Christoph, On 13/03/2019 12:44, Langer, Christoph wrote: > In the test, you could remove the import java.util.Set; in line 36 and List groups of line 74 is not needed as well. > > BTW, as you are touching it, src/java.base/share/classes/java/lang/ThreadGroup.java does not need the import jdk.internal.misc.VM; in line 30 neither. Maybe you want to clean that up, too? Good points! Done. http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.01/ best regards and thanks for the feedback, -- daniel > > Best regards > Christoph > From chris.hegarty at oracle.com Wed Mar 13 13:59:53 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Mar 2019 13:59:53 +0000 Subject: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: <98aec086-f055-078e-bb10-d52860905bed@oracle.com> References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> <98aec086-f055-078e-bb10-d52860905bed@oracle.com> Message-ID: <387B5E52-71A7-4779-964F-5920B14AD792@oracle.com> Daniel, > On 13 Mar 2019, at 12:59, Daniel Fuchs wrote: > > Hi Christoph, > > On 13/03/2019 12:44, Langer, Christoph wrote: >> In the test, you could remove the import java.util.Set; in line 36 and List groups of line 74 is not needed as well. >> BTW, as you are touching it, src/java.base/share/classes/java/lang/ThreadGroup.java does not need the import jdk.internal.misc.VM; in line 30 neither. Maybe you want to clean that up, too? > > Good points! Done. > http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.01/ This change looks good to me. -Chris. From pavel.rappo at oracle.com Wed Mar 13 14:02:38 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 13 Mar 2019 14:02:38 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> Message-ID: <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> Hi Daniel, First of all, the change looks good to me. The broken if (destroyed) { return n; } part looks like a "copy and paste" from some other method in the ThreadGroup class. They use recursion a lot. Might it be the case that not only the returned value is wrong, but also the populated list is corrupted? After all the returned value is used as an index for the next insertion. -Pavel > On 12 Mar 2019, at 15:59, Daniel Fuchs wrote: > > Hi, > > Please find below a simple fix for > 8219197: ThreadGroup.enumerate() may return wrong value > > http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.00/ > > This is a bug in the implementation of the recursion, > as enumerate(list, n, recurse) should never have returned > a value < n. > > The test passes with the fix and fails 'often enough' without > it (~ 1 times out of 2 or 3). > > best regards, > > -- daniel From daniel.fuchs at oracle.com Wed Mar 13 14:22:14 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 14:22:14 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> Message-ID: Hi Pavel, On 13/03/2019 14:02, Pavel Rappo wrote: > Might it be the case that not only the returned value is wrong, but also the > populated list is corrupted? After all the returned value is used as an index > for the next insertion. I'm not sure what you mean by that. I don't think there is another bug in the 3-args enumerate methods. But if some node in the tree-like hierarchy returns a wrong value then the next node in the tree-like hierarchy will start writing at the wrong index, and the final value returned by the top-most call will be wrong. Without the fix, and given an original list containing only null, then if you are unlucky enough the final list might look like: n = 2 [t23, t24, t12, t13, t5, t6, null, null, ...] when in reality there are 24 ([t1..t24]) active threads... best regards, -- daniel From jason_mehrens at hotmail.com Wed Mar 13 14:24:10 2019 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 13 Mar 2019 14:24:10 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> , Message-ID: Hi Goetz, For NullPointerException, I don't think you want writeReplace() to call a public method that can be overridden. You probably should create a private helper method that both getMessage and writeReplace() call into. Jason ________________________________________ From: core-libs-dev on behalf of Lindenmaier, Goetz Sent: Tuesday, March 12, 2019 10:04 AM To: Peter Levart; Roger Riggs; Java Core Libs Cc: hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. Hi Peter, > 56 private static final String MESSAGE_PLACEHOLDER = > "NPE_MESSAGE_PLACEHOLDER"; > Here, the initializer of that constant should create a private instance > of String: ... > private static final String MESSAGE_PLACEHOLDER = new String(); Ok, I understand. > 81 public String getMessage() { > 82 String message = super.getMessage(); > 83 if (message == MESSAGE_PLACEHOLDER) { > 84 message = getExtendedNPEMessage(); > 85 setMessage(message); > 86 } > 87 return super.getMessage(); > 88 } > > Why not simply returning 'message' local variable here? As I removed the synchronization, this would reduce the chance to get different objects in case of a race. Highly unlikely though. I changed the webrev with this solution to include these your remarks: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03-PeterLevart/ (updated in-place). Nevertheless, I think I will follow Roger's demand to not modify the defaultMessage field. Best regards, Goetz. > > > Regards, Peter > > On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > >> Maybe 10 years ago, when native was the only solution. > >> Now there are tools to analyze bytecode in java. > > I'm working on a Java implementation. > > > >>> Peter Levart proposed to initialize the message with a sentinel instead. > >>> I'll implement this as a proposal. > >> That's an extra overhead too, any assignment is. > > Yes, any code requires some run time. But I think this really is negligible > > in comparison to generating the backtrace, which happens on every > > exception. But I'm fine with the 'always recompute, no serialization' > > solution. If it turns out to be limited, it still can be changed easily. > > > >>> I guess we can go without. > >>> It would be possible to construct a case where two threads > >>> do getMessage() on the same NPE Object but the string is not > >>> the same. > >> Really!, if the bci is the same, the bytecode is the same, what could be > different > >> that would change the data used to create the exception? > > e.getMessage().equals(e.getMessage()) will hold, but > > e.getMessage() != e.getMessage(). > > > > I just implemented the two variants of computing the message, they > > basically differ in NullPointerException.java: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03- > PeterLevart/ > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04- > RogerRiggs/ > > > > I also cleaned up the parameters passed as proposed. > > > >>> We uses this code since 2006, it needed only few changes. I would like to > >>> contribute a follow up for hidden frames of lambdas. > >> Valhalla and evolution of the byte code needs to be considered. > >> Just because its worked for years does not mean it's the best approach > >> today. Dropping it in now means maintaining it in its current form > >> or needing to re-write it later. > > Well, yes, that is true. For any change. For any project. We have heard > > this argument for many of our changes. I don't really think it's a good > > argument. As I understand Valhalla is not targeted for jdk13, and > > holding up changes for some future projects not really is the process > > of OpenJDK, is it? > > > >>>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > >>>> question > >>>> about how useful the information is, developers should not need to know > >>>> about "slot 1". > >>> Developers should work with class files with debug information and then > >>> they would get the name printed. If exceptions are thrown in production > >>> code, any information is helpful. Should I just write "a local"? > >> Go back to who you think is going to benefit from it, it seems targeted > >> at a fairly novice developer, so exposing low level details may be more > >> confusing that just giving a line number and NPE. > > Especially on our improved NPE messages we always got good feedback > > from the developers within SAP. And there are quite some experienced > > people. Any message requires some background to be helpful. And I > > like to get any information I can have in first place. Attaching the > > debugger often is a big overhead. E.g., I look at about 50 failing jtreg > > tests every day, I don't want to get each into the debugger every time > > in the setup where it was running to see what is wrong ... > > > > E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java > > is failing in a headless environment with an NPE on this line: > > SwingUtilities.invokeAndWait(() -> frame.dispose()); > > With this change it said "while trying to invoke the method > javax.swing.JFrame.dispose(()V) of a null object loaded from static field > AltFocusIssueTest.frame" and I figured it's the fact we run headless that > > makes the test fail without even looking at the code. > > > > Best regards, > > Goetz > > > > > > > > > > > > > > > > > > From: Roger Riggs > > Sent: Dienstag, 12. Februar 2019 17:03 > > To: Lindenmaier, Goetz ; Java Core Libs libs-dev at openjdk.java.net> > > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > > > Hi, > > On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > > thanks for looking at my change! > > > > A few higher level issues should be considered, though the details of > > the webrev captured my immediate attention. > > > > Is this the right feature > > Yes!! > > Maybe, that's what debuggers are for. > > > > > > > > and is this the right level of implementation (C++/native)? > > See below. > > Maybe 10 years ago, when native was the only solution. > > Now there are tools to analyze bytecode in java. > > > > > > > > From a security perspective, adding field names to exceptions exposes > > information to callers that they could not otherwise get and that breaks > > encapsulation. > > That needs to be evaluated. > > I can not comment on that. How can I trigger an evaluation of this? > > Who needs to evaluate this? > > > > I think there are ways to make this easier to implement and be easier to > > maintain and perform better. > > > > NullPointerException: > > 28: unused import of Field > > Removed > > > > 64: The lazyComputeMessage boolean should be inverted so it does not > > require > > initialization, false is the default, anything else adds overhead. > > And it may not be needed. > > Peter Levart proposed to initialize the message with a sentinel instead. > > I'll implement this as a proposal. > > That's an extra overhead too, any assignment is. > > > > > > > > 91: Why do you think synchonization is necessary? It is a performance hit. > > It is highly unlikely to be called from multiple threads and the > > value will > > be the same whether it is computed once or multiple times by > > different threads. > > I guess we can go without. > > It would be possible to construct a case where two threads > > do getMessage() on the same NPE Object but the string is not > > the same. > > Really!, if the bci is the same, the bytecode is the same, what could be > different > > that would change the data used to create the exception? > > > > > > > > 99: extendedMessage will never be null (so says the javadoc of > > getExtendedNPEMessage) > > Bug: If it does return null, then null is returned from getMessage > > regardless of the value of super.getMessage(). > > Fixed. > > > > 121: Simplify getExtendedNPEMessage by making it only responsible for > > the detail > > and not concatenation with an existing message. Put that in > > getMessage(). > > Fixed. You are right, I only call this when the message is NULL. > > > > Its not strictly necessary to change the updated message with > > setMessage(). > > Avoiding that will avoid complexity and a performance hit. > > The message will be computed each time it is needed, and that happens > > infrequently. > > (Even in the serialization case, it will be re-computed from the > > attached stack frames). > > No, you can not recompute it from the stacktrace because that > > does not contain the BCI. Also, after deserialization, the bytecode > > might look different or not available at all. It depends on the actual > > bytecode that has been running when the exception was thrown. > > Right, I realized this too when thinking about it over the weekend. > > > > If a suitable low impact mechanism can't be found, then just > > go back to not exposing the extended message and use only the original. > > Its a bad idea to twist and contort the local design and accessibility > > just for serialization. What remote or delayed client needs to know this? > > > > > > > > > > And it avoids adding setMessage() to Throwable, that's significant > > change since > > the current implementation only allows the message to be initialized > > not updated. > > Immutable is an important characteristic to maintain. > > Yes, I don't like I have to set this. But it follows the same pattern > > as with the stack trace which is only computed on demand. Thus, > > Throwable is not immutable anyways. Before, I implemented this by a > > JNI call hiding this in the Java code. > > I proposed implementing setting the field by reflection, Christoph > > proposed a shared secret. David favored the package private setter. > > Please advice what is best. > > All of them are bad. Private needs to mean private. > > > > And making it mutable, also means that synchronization or volatile > > is needed to ensure a consistent value for getMessage(). > > That turns into a performance issue for all throwables. > > None of the above. > > > > > > > > That makes the writeReplace() unnecessary too. > > No. I need this, see above. > > See above, but is not essential to the core feature. > > > > > > > > Additional command line arguments are an unnecessary complexity, > > documentation, and maintenance overhead. If the feature is as valuable as > > you suggest, it should be enabled all the time. > > Removed. > > > > I'm assuming there are no tests broken by the modification of the message. > > It is likely that somewhere an application or test looks at the message > > itself. > > Has that been verified? > > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests > and some > > other applications. They are all unaffected by this change after adapting the > > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, > mac) > > Also, I modified quite some messages before which didn't cause any follow- > up > > breakages to my knowledge. > > It does seem unlikely. > > > > > > > > I can't speak for the hotspot code, but that seems to add a lot of code > > to support > > only this convenience feature. That's a maintenance overhead and burden. > > We uses this code since 2006, it needed only few changes. I would like to > > contribute a follow up for hidden frames of lambdas. > > Valhalla and evolution of the byte code needs to be considered. > > Just because its worked for years does not mean its the best approach > > today. Dropping it in now means maintaining it in its current form > > or needing to re-write it later. > > > > > > > > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > > question > > about how useful the information is, developers should not need to know > > about "slot 1". > > Developers should work with class files with debug information and then > > they would get the name printed. If exceptions are thrown in production > > code, any information is helpful. Should I just write "a local"? > > Go back to who you think is going to benefit from it, it seems targeted > > at a fairly novice developer, so exposing low level details may be more > > confusing that just giving a line number and NPE. > > > > > > > > The test output of NullPointerExceptionTest shows > > "java.lang.Object.hashCode(()I)". > > Why is the argument type for Integer shown as "()I"; that's not the > > conventional > > representation of a primitive int. > > I already discussed this with David Holmes: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > February/058464.html > > Other exceptions use the same format. I don't know of an utility in > > hotspot to translate the format to Java source code syntax. We > > implemented such an utility in our internal VM, though, and I would > > like to contribute this, too, adapting all the exceptions. I would do this > > in a follow-up. > > There may be better tools for formatting if it was done in java at a > > more appropriate level of abstraction. > > > > > > > > Generally, the explanations are too verbose. > > Method names and field names would be easier to recognize if they were > > quoted, as is done with 'this'. > > Fixed, although this is not common in exception messages. See the > > messages in > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt > ime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > > line 57ff. Only the String of the name field is quoted, not any entities > > declared in the code. > > Similar > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt > ime/LoaderConstraints/vtableAME/Test.java > > line 60, also showing the internal signature, see above. > > > > Argument numbers should be digits, > > not English words (first, second, etc) to make them easier to pick out. > > Fixed. > > And has it limits that do not read easily, e.g. "nr. 9". > > Sorry, I don't understand > > src/hotspot/share/classfile/bytecodeUtils.cpp:566 > > > test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerE > xceptionTest.java:612 > > > > I would not describe 'this' as a local variable. > > Fixed. > > > > Tests, especially new tests should compile without warnings. > > NullPointerExceptionTest.java:125 newInstance has been deprecated. > > Fixed. > > > > The messages can be easier to understand, e.g. > > 'field a1 is null, trying to invoke a1.hashCode...' instead of: > > "while trying to invoke the method java.lang.Object.hashCode(()I) on a > > null reference loaded from local variable 'a1'" > > The message is built along the structure of the bytecode. > > I'll try to change this and then will come up with a new webrev . > > > > It will easier to understand if it looks more like the code. > > BTW, what does this look like for fully optimized code? > > You mean whether the bytecode is jitted? It's independent > > of how the code is executed, interpreted or compiled. > > > > Does it bear any resemblance to the source code at all? > > Or does it have to be deoptimized to come up with a sensible source > > reference. > > No, jitted methods must not be deoptimized. > > > > How much of this can be done in Java code with StackWalker and other > > java APIs? > > It would be a shame to add this much native code if there was a more robust > > way to implement it using APIs with more leverage. > > StackWalker operates on the Java stack tracke, which does not contain the > BCI > > to my knowledge. Also, I need to read the bytecodes. Are there APIs to > access > > the bytecode as it resides in the metaspace, rewritten, constants resolved > etc? > > The code relies on this. > > > > From the other thread, beware adding overhead to the constructor. > > The lazy computation is essential. > > There are a *lot* of NPEs whose messages will never be needed. > > > > Regards, Roger > > > > > > > > > > Best regards, > > Goetz. > > > > > > > > Regards, Roger > > > > > > On 02/08/2019 09:13 AM, Langer, Christoph wrote: > > Hi Goetz, > > > > ok, so here a new webrev just adding a setter for the field: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > > > > ... and incorporating the other comments. > > Looks better ?? > > > > I have a few additions to > > src/java.base/share/classes/java/lang/NullPointerException.java: > > > > 28 import java.lang.reflect.Field; > > 29 > > -> can be removed now. > > > > 91 synchronized (this) { > > -> I think this is not needed here. The transient modifier for > > lazyComputeMessage already implies the lock on the Object, I think. > > > > 108 return extendedMessage; > > -> I guess it would be more correct if you returned super.getMessage() here. > > > > Thanks > > Christoph > > > > From pavel.rappo at oracle.com Wed Mar 13 14:41:19 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 13 Mar 2019 14:41:19 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> Message-ID: > On 13 Mar 2019, at 14:22, Daniel Fuchs wrote: > > I don't think there is another bug in the 3-args enumerate > methods. I might not have expressed myself clearly. I'm not saying there is an extra bug with the fix applied. What I'm saying is that without the fix, not only was the value wrong but the array was also corrupted. The mechanics exactly as you described: later groups overwrote the beginning of the array. I'm reading the test. Still trying to figure out how it works in detail. Give me some more time to get comfortable with it and I will reply to the list. At the very least I would (suggestion) change the @summary. After all if this group is being destroyed, and this is the only call, then 0 would be a correct value, wouldn't it? -Pavel From Alan.Bateman at oracle.com Wed Mar 13 14:45:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Mar 2019 14:45:15 +0000 Subject: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out In-Reply-To: References: Message-ID: On 12/03/2019 17:30, Lance Andersen wrote: > Hi all, > > Please review this addition to the ProblemList.txt as this tests times out from time to time > > I can't tell from the bug what analysis has been done but are these timeouts always debug builds? If so then maybe you could use `@requires vm.debug == false` to have it be skipped on debug builds until it clear whether it's just that the timeout is too small or there is another issue. -Alan From daniel.fuchs at oracle.com Wed Mar 13 16:31:49 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 16:31:49 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> Message-ID: <03d4ef07-8023-04a5-2b48-44e853cc9d52@oracle.com> Hi Pavel, On 13/03/2019 14:41, Pavel Rappo wrote: > After all if this group is > being destroyed, and this is the only call, then 0 would be a correct value, > wouldn't it? It may only be the correct value if the input argument value n == 0. As the @summary section says: the 3-args enumerate method should never return a value lesser (<) than n. cheers, -- daniel From pavel.rappo at oracle.com Wed Mar 13 16:35:55 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 13 Mar 2019 16:35:55 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> Message-ID: <1F36ABE1-C811-49DB-AD83-44C6E3B4374F@oracle.com> Using a bunch of Semaphores here seems a bit surprising. One more CountDownLatch or CyclicBarrier *might* have been better. But I guess it's not of concern. For the diagnostic purposes I would add a newline between t4.join(); t3.join(); since they throw exceptions. Otherwise looks good. Thanks for doing this. -Pavel > On 13 Mar 2019, at 14:41, Pavel Rappo wrote: > > I'm reading the test. Still trying to figure out how it works in detail. Give me > some more time to get comfortable with it and I will reply to the list. At the > very least I would (suggestion) change the @summary. After all if this group is > being destroyed, and this is the only call, then 0 would be a correct value, > wouldn't it? > > -Pavel From daniel.fuchs at oracle.com Wed Mar 13 16:47:50 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 16:47:50 +0000 Subject: RFR: 8219197: ThreadGroup.enumerate() may return wrong value In-Reply-To: <1F36ABE1-C811-49DB-AD83-44C6E3B4374F@oracle.com> References: <9280e82b-61b6-b02e-5caa-bee6785502c7@oracle.com> <80C1F138-0C7E-49D7-8566-6061E4E67546@oracle.com> <1F36ABE1-C811-49DB-AD83-44C6E3B4374F@oracle.com> Message-ID: <0fda85cb-1f05-de61-26d1-96a65723ba8d@oracle.com> Hi Pavel, On 13/03/2019 16:35, Pavel Rappo wrote: > Using a bunch of Semaphores here seems a bit surprising. One more CountDownLatch > or CyclicBarrier *might* have been better. But I guess it's not of concern. Agreed, but I won't change it. The reason is that I had a more extensive version of the test with which I tested a prototype fix for another related ThreadGroup issue - and the semaphore as opposed to latches were useful for that ;-) That other issue is still in my TODO list - but I might take more time to get to it as its fix is a bit more controversial. > For the diagnostic purposes I would add a newline between > > t4.join(); t3.join(); > > since they throw exceptions. Otherwise looks good. Thanks for doing this. OK, will do. Thanks for the feedback! -- daniel From chris.hegarty at oracle.com Wed Mar 13 17:04:57 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Mar 2019 17:04:57 +0000 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base Message-ID: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Trivially, there should be a comma after the year. Just add it. $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, 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 diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 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 diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java --- a/src/java.base/share/classes/sun/security/util/IOUtils.java +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2017, 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 -Chris. From daniel.fuchs at oracle.com Wed Mar 13 17:09:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 17:09:55 +0000 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Message-ID: Looks good to me Chris! cheers, -- daniel On 13/03/2019 17:04, Chris Hegarty wrote: > Trivially, there should be a comma after the year. Just add it. From Roger.Riggs at oracle.com Wed Mar 13 17:09:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 13 Mar 2019 13:09:14 -0400 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Message-ID: <4a8b69e1-c9fd-6a46-a3b4-7e823c3a69ea@oracle.com> Hi Chris, Looks good. Roger On 03/13/2019 01:04 PM, Chris Hegarty wrote: > Trivially, there should be a comma after the year. Just add it. > > > $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun > diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 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 > diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java > --- a/src/java.base/share/classes/sun/security/util/IOUtils.java > +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2017, 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 > > -Chris. From lance.andersen at oracle.com Wed Mar 13 17:10:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Mar 2019 13:10:57 -0400 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Message-ID: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com> +1 > On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote: > > Trivially, there should be a comma after the year. Just add it. > > > $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun > diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 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 > diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java > --- a/src/java.base/share/classes/sun/security/util/IOUtils.java > +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2017, 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 > > -Chris. 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 Wed Mar 13 17:44:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 13 Mar 2019 13:44:14 -0400 Subject: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out In-Reply-To: References: Message-ID: <8202b2d1-22db-9f0f-62cb-6fe720ffbed9@oracle.com> Hi, The test runs significantly slower on the fast debug build. Release images build:? 4 seconds Fastdebug images build: 2.5 minutes $.02, Roger On 03/13/2019 10:45 AM, Alan Bateman wrote: > On 12/03/2019 17:30, Lance Andersen wrote: >> Hi all, >> >> Please review this addition to the ProblemList.txt? as this tests >> times out from time to time >> >> > I can't tell from the bug what analysis has been done but are these > timeouts always debug builds? If so then maybe you could use > `@requires vm.debug == false` to have it be skipped on debug builds > until it clear whether it's just that the timeout is too small or > there is another issue. > > -Alan From lance.andersen at oracle.com Wed Mar 13 18:55:04 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Mar 2019 14:55:04 -0400 Subject: RFR 8220252: Fix Headings in java.naming Message-ID: Hi all Please review the fix for 8220252, to address the javadoc header issues [1] in java.naming The webrev can be found at: http://cr.openjdk.java.net/~lancea/8220252/webrev.00/index.html Best Lance [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html From daniel.fuchs at oracle.com Wed Mar 13 19:05:04 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 19:05:04 +0000 Subject: RFR 8220252: Fix Headings in java.naming In-Reply-To: References: Message-ID: Hi Lance, http://cr.openjdk.java.net/~lancea/8220252/webrev.00/src/java.naming/share/classes/javax/naming/ldap/LdapContext.java.frames.html It looks like 78 *

              Context Request Controls

              100 *

              Connection Request Controls

              136 *

              Service Provider Requirements

              should be

              - it seems they are all logical subsections of 53 *

              Request Controls

              Otherwise looks good! best regards, -- daniel On 13/03/2019 18:55, Lance Andersen wrote: > Hi all > > Please review the fix for 8220252, to address the javadoc header issues [1] in java.naming > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8220252/webrev.00/index.html > > > Best > Lance > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html > > From lance.andersen at oracle.com Wed Mar 13 19:13:14 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Mar 2019 15:13:14 -0400 Subject: RFR 8220252: Fix Headings in java.naming In-Reply-To: References: Message-ID: <2AA96A0F-5624-42E9-AEC3-353B29E9B284@oracle.com> Hi Daniel, > On Mar 13, 2019, at 3:05 PM, Daniel Fuchs wrote: > > Hi Lance, > > http://cr.openjdk.java.net/~lancea/8220252/webrev.00/src/java.naming/share/classes/javax/naming/ldap/LdapContext.java.frames.html > > It looks like > 78 *

              Context Request Controls

              > 100 *

              Connection Request Controls

              > 136 *

              Service Provider Requirements

              > > should be

              - it seems they are all logical subsections > of > 53 *

              Request Controls

              Yes you are right, I missed that but it is updated at http://cr.openjdk.java.net/~lancea/8220252/webrev.01/index.html > > Otherwise looks good! Thank you and have a nice evening Best Lance > > best regards, > > -- daniel > > On 13/03/2019 18:55, Lance Andersen wrote: >> Hi all >> Please review the fix for 8220252, to address the javadoc header issues [1] in java.naming >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8220252/webrev.00/index.html >> Best >> Lance >> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html > 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 kim.barrett at oracle.com Wed Mar 13 20:07:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Mar 2019 16:07:56 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs Message-ID: Please review this change to the JNI specification. The specified behavior of Weak Global References, and in particular their relationship to Java PhantomReference, is being updated to account for a change to PhantomReference by JDK-8071507. CR: https://bugs.openjdk.java.net/browse/JDK-8188066 CSR: https://bugs.openjdk.java.net/browse/JDK-8220617 Changes: http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html specdiff for the changes. In addition to updating the section describing Weak Global References, the description of NewGlobalRef is updated, as well as the copyright footer. http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md Copies of the before and after text for the JNI Weak Global References section; easier to read than diffs or specdiff. From kim.barrett at oracle.com Wed Mar 13 20:29:43 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Mar 2019 16:29:43 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: References: Message-ID: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> > On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: > > Please review this change to the JNI specification. The specified > behavior of Weak Global References, and in particular their > relationship to Java PhantomReference, is being updated to account > for a change to PhantomReference by JDK-8071507. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8188066 > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8220617 > > Changes: > http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html > specdiff for the changes. In addition to updating the section > describing Weak Global References, the description of NewGlobalRef > is updated, as well as the copyright footer. > > http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md > Copies of the before and after text for the JNI Weak Global > References section; easier to read than diffs or specdiff. I botched the upload of the changes to cr.openjdk.java.net. The corrected URLS are: http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1/diff.html http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.html From mandy.chung at oracle.com Wed Mar 13 21:00:06 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Mar 2019 14:00:06 -0700 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> Message-ID: <7a6f0e8a-801f-8976-1d65-986b36a3af7d@oracle.com> On 3/13/19 1:29 PM, Kim Barrett wrote: >> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: >> >> Please review this change to the JNI specification. The specified >> behavior of Weak Global References, and in particular their >> relationship to Java PhantomReference, is being updated to account >> for a change to PhantomReference by JDK-8071507. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8188066 >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8220617 Reviewed. Please either attach the spec diff or inline the spec in the CSR for archiving purpose. This spec update aligning the weak global refs with phantom reference is great and thanks for rewriting spec. Reads well. Mandy From per.liden at oracle.com Wed Mar 13 21:32:09 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 13 Mar 2019 22:32:09 +0100 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> Message-ID: On 03/13/2019 09:29 PM, Kim Barrett wrote: >> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: >> >> Please review this change to the JNI specification. The specified >> behavior of Weak Global References, and in particular their >> relationship to Java PhantomReference, is being updated to account >> for a change to PhantomReference by JDK-8071507. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8188066 >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8220617 >> >> Changes: >> http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html >> specdiff for the changes. In addition to updating the section >> describing Weak Global References, the description of NewGlobalRef >> is updated, as well as the copyright footer. >> >> http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md >> Copies of the before and after text for the JNI Weak Global >> References section; easier to read than diffs or specdiff. Clear and unambiguous, nice! Reviewed. /Per From dkwakkel at gmail.com Wed Mar 13 21:38:03 2019 From: dkwakkel at gmail.com (Donald Kwakkel) Date: Wed, 13 Mar 2019 22:38:03 +0100 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: Attached patch with tests so first the bug for java11 can be fixed and backported. Would be nice if someone can guide me how to continue with this and/or can reply on my previous questions. Op di 5 mrt. 2019 om 07:11 schreef Donald Kwakkel : > > > On 02/28/2019 01:06 PM, Alan Bateman wrote: > > > On 28/02/2019 20:58, Jonathan Gibbons wrote: > > >> Looking at the revised JAR specification, approved in [1], it is > > >> disappointing that the spec contains text which is specific to > > >> a JAR file being used in a classloader: > > >> > > >> |The resulting URLs are inserted into the search path of the class > > >> loader opening the context JAR immediately following the path of the > > >> context JAR. Any duplicated URLs are omitted.| > > >> > > >> That text would seem not to apply to javac and other tools that may wish > > >> to process the class files in a JAR file. > > > That should be fixed as it should apply at compile-time too. > > > > > > -Alan > > > > |Agreed it might be good to fix it if possible. All the preceding text > > is good, and can be handled by javac. The only questionable bit is the > > text "Any duplicated URLs are omitted" which could be moved up a bit in > > the spec to a new paragraph, and maybe rephrased to use "ignored" > > instead of "omitted". If that were done, all the stuff about class > > loaders could be taken as non-normative text. > > So if I am correct the answer to Question 2 is: Yes, behavior must be the same. > > What are the next steps to take for this? And can someone also answer my > other questions?: > > Question 1: Where can I find the tests for these changes? > Question 2: Where should the common code for this be located? > Question 3: Is it an idea to first implement below patch and backport > that, and in addition as new ticket implement the new behaviour also > for javac? > Question 4:Is this they way to do it, or is there a better way to > provide debug information to users running javac? -------------- next part -------------- A non-text attachment was scrubbed... Name: 8218268.patch Type: text/x-patch Size: 8407 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Wed Mar 13 21:58:17 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Mar 2019 14:58:17 -0700 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: <6ef55038-cafe-e823-e124-a32ca4644237@oracle.com> Donald, While it was reasonable to raise the spec issues on core-libs-dev, any/all questions about javac code should be addressed to compiler-dev at openjdk.java.net. That being said, * any comment labelled "// TODO" in new code seems questionable * the copyright date on the test is wrong and should probably be 2019 * the test uses tabs instead of spaces * direct writes to System.err are probably wrong -- Jon On 03/13/2019 02:38 PM, Donald Kwakkel wrote: > Attached patch with tests so first the bug for java11 can be fixed and > backported. > Would be nice if someone can guide me how to continue with this and/or > can reply on my previous questions. > > Op di 5 mrt. 2019 om 07:11 schreef Donald Kwakkel : >>> On 02/28/2019 01:06 PM, Alan Bateman wrote: >>>> On 28/02/2019 20:58, Jonathan Gibbons wrote: >>>>> Looking at the revised JAR specification, approved in [1], it is >>>>> disappointing that the spec contains text which is specific to >>>>> a JAR file being used in a classloader: >>>>> >>>>> |The resulting URLs are inserted into the search path of the class >>>>> loader opening the context JAR immediately following the path of the >>>>> context JAR. Any duplicated URLs are omitted.| >>>>> >>>>> That text would seem not to apply to javac and other tools that may wish >>>>> to process the class files in a JAR file. >>>> That should be fixed as it should apply at compile-time too. >>>> >>>> -Alan >>> |Agreed it might be good to fix it if possible. All the preceding text >>> is good, and can be handled by javac. The only questionable bit is the >>> text "Any duplicated URLs are omitted" which could be moved up a bit in >>> the spec to a new paragraph, and maybe rephrased to use "ignored" >>> instead of "omitted". If that were done, all the stuff about class >>> loaders could be taken as non-normative text. >> So if I am correct the answer to Question 2 is: Yes, behavior must be the same. >> >> What are the next steps to take for this? And can someone also answer my >> other questions?: >> >> Question 1: Where can I find the tests for these changes? >> Question 2: Where should the common code for this be located? >> Question 3: Is it an idea to first implement below patch and backport >> that, and in addition as new ticket implement the new behaviour also >> for javac? >> Question 4:Is this they way to do it, or is there a better way to >> provide debug information to users running javac? From hboehm at google.com Wed Mar 13 22:19:42 2019 From: hboehm at google.com (Hans Boehm) Date: Wed, 13 Mar 2019 15:19:42 -0700 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: References: Message-ID: Looks great to me! Just to be clear, this is intended to guarantee that it's not possible to promote a weak global reference that indirectly points to A after a PhantomReference or a WeakGlobalReference to A has been cleared? Thus this reference clearing must happen more or less atomically. I think this property has always been needed for the intended use of PhantomReferences, since otherwise the referent of a cleared PhantomReference could be resurrected. It's great to get it in the spec. On Wed, Mar 13, 2019 at 1:08 PM Kim Barrett wrote: > Please review this change to the JNI specification. The specified > behavior of Weak Global References, and in particular their > relationship to Java PhantomReference, is being updated to account > for a change to PhantomReference by JDK-8071507. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8188066 > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8220617 > > Changes: > http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html > specdiff for the changes. In addition to updating the section > describing Weak Global References, the description of NewGlobalRef > is updated, as well as the copyright footer. > > http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md > Copies of the before and after text for the JNI Weak Global > References section; easier to read than diffs or specdiff. > > > From brent.christian at oracle.com Wed Mar 13 22:44:15 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 13 Mar 2019 15:44:15 -0700 Subject: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp Message-ID: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> Hi, Please review my test-only fix for 8220088[1]. Along with fixing the issue, I've also converted this .sh test to .java. Webrev is here: http://cr.openjdk.java.net/~bchristi/8220088/webrev.00/ The test does the following: 1. sets up a classloader and loads class "C" into a WeakReference 2. runs a few GCs and ensures that the C class is still live 3. clears the reference to the classloader and runs a few more GCs 4. ensures that the C class has been collected (now that its classloader can also be collected) When run with -Xcomp, the test fails with: Exception in thread "main" java.lang.AssertionError at Main.doTest(Main.java:56) at Main.main(Main.java:41) This comes from the code for step 2: System.gc(); System.gc(); if (c.get() == null) throw new AssertionError(); The C class is being collected before expected. From my testing, I believe that when the test is pre-compiled with -Xcomp, the VM sees that 'loader' gets null'ed out, and doesn't keep it alive. My change to fix this issue is adding this check: + if (loader != null) { // Under -Xcomp, ensure loader is still alive loader = null; + } There are probably other ways to accomplish this, though this worked well for local as well as automated testing. The rest of the changes are for the .sh -> .java conversion. Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8220088 From kim.barrett at oracle.com Wed Mar 13 23:02:13 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Mar 2019 19:02:13 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> Message-ID: <6F6648D3-2536-4047-B73B-0A0411960F49@oracle.com> > On Mar 13, 2019, at 4:29 PM, Kim Barrett wrote: > >> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: >> >> Please review this change to the JNI specification. The specified >> behavior of Weak Global References, and in particular their >> relationship to Java PhantomReference, is being updated to account >> for a change to PhantomReference by JDK-8071507. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8188066 >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8220617 >> >> Changes: >> http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html >> specdiff for the changes. In addition to updating the section >> describing Weak Global References, the description of NewGlobalRef >> is updated, as well as the copyright footer. >> >> http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md >> Copies of the before and after text for the JNI Weak Global >> References section; easier to read than diffs or specdiff. > > I botched the upload of the changes to cr.openjdk.java.net. The corrected URLS are: > > http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1/diff.html > http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.html Stefan Karlsson suggested (offline) a couple of wording changes in the description of Weak Global References. (1) Replace "destroyed" with "deleted" in two places, to align with the names of DeleteGlobalRef and the like. (2) Reword the second sentence of the fourth paragraph, as there is some potential for ambiguity around "If the references are the same". Here's the diff between rev1 and those changes. I'll post an updated specdiff later, once the dust settles. diff -r 76b82c006509 -r 6a2181c4fee2 closed/src/java.se/share/specs/jni/functions.md --- a/closed/src/java.se/share/specs/jni/functions.md Wed Mar 13 15:40:33 2019 -0400 +++ b/closed/src/java.se/share/specs/jni/functions.md Wed Mar 13 17:06:23 2019 -0400 @@ -1177,9 +1177,9 @@ to `NULL` without notice. `IsSameObject` can be used to compare a weak global reference to a non-`NULL` -local or global reference. If the references are the same, the weak global -reference's underlying object will not be freed so long as the other reference -has not been destroyed. +local or global reference. If the objects are the same, the weak global +reference won't become functionally equivalent to `NULL` so long as the other +reference has not been deleted. `IsSameObject` can also be used to compare a weak global reference to `NULL` to determine whether the underlying object has been freed. @@ -1193,7 +1193,7 @@ `NewGlobalRef`. These functions will return `NULL` if the object has been freed. Otherwise, the new reference will prevent the underlying object from being freed. The new reference, if non-`NULL`, can then be used to access the -underlying object, and destroyed when such access is no longer needed. +underlying object, and deleted when such access is no longer needed. ------------------------------------------------------------------------------- From kim.barrett at oracle.com Wed Mar 13 23:03:00 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Mar 2019 19:03:00 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: <7a6f0e8a-801f-8976-1d65-986b36a3af7d@oracle.com> References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> <7a6f0e8a-801f-8976-1d65-986b36a3af7d@oracle.com> Message-ID: > On Mar 13, 2019, at 5:00 PM, Mandy Chung wrote: > > > > On 3/13/19 1:29 PM, Kim Barrett wrote: >>> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: >>> >>> Please review this change to the JNI specification. The specified >>> behavior of Weak Global References, and in particular their >>> relationship to Java PhantomReference, is being updated to account >>> for a change to PhantomReference by JDK-8071507. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8188066 >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8220617 > > Reviewed. Please either attach the spec diff or inline the spec > in the CSR for archiving purpose. > > This spec update aligning the weak global refs with phantom reference > is great and thanks for rewriting spec. Reads well. > > Mandy Thanks. I?ll attach the final specdiff to the CSR once the review is complete. From kim.barrett at oracle.com Wed Mar 13 23:03:14 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Mar 2019 19:03:14 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> Message-ID: > On Mar 13, 2019, at 5:32 PM, Per Liden wrote: > > > On 03/13/2019 09:29 PM, Kim Barrett wrote: >>> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: >>> >>> Please review this change to the JNI specification. The specified >>> behavior of Weak Global References, and in particular their >>> relationship to Java PhantomReference, is being updated to account >>> for a change to PhantomReference by JDK-8071507. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8188066 >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8220617 >>> >>> Changes: >>> http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html >>> specdiff for the changes. In addition to updating the section >>> describing Weak Global References, the description of NewGlobalRef >>> is updated, as well as the copyright footer. >>> >>> http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md >>> Copies of the before and after text for the JNI Weak Global >>> References section; easier to read than diffs or specdiff. > > Clear and unambiguous, nice! > > Reviewed. > > /Per Thanks. From kim.barrett at oracle.com Wed Mar 13 23:07:32 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Mar 2019 19:07:32 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: References: Message-ID: > On Mar 13, 2019, at 6:19 PM, Hans Boehm wrote: > > Looks great to me! Thanks. > Just to be clear, this is intended to guarantee that it's not possible to promote a weak global reference that indirectly points to A after a PhantomReference or a WeakGlobalReference to A has been cleared? Thus this reference clearing must happen more or less atomically. Yes. That?s the point of saying the jweak becomes functionally equivalent to NULL at the same time as a PhantomReference for the same object would be cleared. > I think this property has always been needed for the intended use of PhantomReferences, since otherwise the referent of a cleared PhantomReference could be resurrected. It's great to get it in the spec. Exactly. That?s the ?important safety invariant? mentioned in the CSR. From mandy.chung at oracle.com Thu Mar 14 00:42:15 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Mar 2019 17:42:15 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Message-ID: <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> Hi Goetz, Roger, Coleen, Maurizio and I talked about this proposed feature. We all think that improving NPE message is a useful enhancement for the platform and helps developers to tell what causes NPE. This is not a small enhancement. Diving into a large code review would not be the best way to move this forward as you can see the discussion so far. It would help if you can start with writing down the problem and the proposal like what improvements are proposed and under what circumstances may be acceptable that NPE message won't be improved. This would get the discussion on the proposal feature and then the discussion of the best way to to implement it in the VM, library, or combination. You can consider using the JEP template that gives you a good structure to follow for the write up. What do you think? Mandy From stuart.marks at oracle.com Thu Mar 14 00:45:46 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Mar 2019 17:45:46 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <9b010e5e-80c7-1276-d90f-d2d10aaad864@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <9b010e5e-80c7-1276-d90f-d2d10aaad864@oracle.com> Message-ID: <9d54e171-e066-45a8-119b-9d454481d7a2@oracle.com> On 3/12/19 4:32 PM, Ivan Gerasimov wrote: > If there were two new subtypes of Iterable introduced:? IterableOnce and > IterableMultipleTimes, then all existing Iterables could be retrofitted to > implement one of these. > > It wouldn't *automatically* solve the problem of 3rd party API, which accepts an > Iterable and iterates it multiple times, but would provide a means to change > that API in a straightforward way. > > Also, the static analysis tools could issue a suggestion for code that iterates > Iterable more than once to switch to IterableMultipleTimes, so that it won't be > possible to pass in an IterableOnce. > > It would also allow to strengthen the specification for IterableMultipleTimes > and state that all classes implementing it must make it possible to obtain > multiple iterators. Hi Ivan, This would be a cleaner type hierarchy, in the sense that it would avoid the subtype-or-supertype issue that's being discussed in a parallel segment of this thread. But practically speaking I don't think it adds much value. Most Iterables can be iterated multiple times; it seems to be the exceptional case that an Iterable is once-only. (In the JDK, the examples of Scanner and Stream show that things with once-only behavior avoided implementing Iterable at all.) While we could migrate the JDK classes to IterableMany (or whatever it would be called), I think it's unrealistic to expect that all the Iterable implementations out there in the wild would migrate. We'd thus be left with Iterable and IterableMany meaning more-or-less the same thing in perpetuity. By introducing IterableOnce, we can attract retrofits by once-off things (like Scanner and Streams) and the uncommon occurrences of once-off things like DirectoryStream that currently implement Iterable can be migrated to IterableOnce. Everybody else can then just stay on Iterable. s'marks From stuart.marks at oracle.com Thu Mar 14 01:01:14 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Mar 2019 18:01:14 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <1ed0f069f30c240a629a09b0c4afc69c@duigou.org> References: <1ed0f069f30c240a629a09b0c4afc69c@duigou.org> Message-ID: <56cbf3d8-903a-4fbf-112f-3fbcef6d3f39@oracle.com> On 3/5/19 12:43 PM, Mike Duigou wrote: > I don't believe that I would use the proposed enhancement to the for statement. > For me there is cognitive load reduction in using a symmetrical method for all > iterations even if they end up being a little more complicated for individual > cases. Usually, for me, I use streams. Even the more complicated patterns such > as the presented example will hopefully be familiar because they are repeated in > many places throughout the code. Truly unusual or unique usages are hopefully > very rare. > > To choose between old style for, enhanced for, or streams based on which warts > are to be avoided is just frustrating. Mixing idioms or required mixing of > idioms produces the least satisfying result. Was the use of a particular idiom a > necessity? A choice? Of no consequence? This gets harder to decode with a larger > number of available idioms. I suspect the cases for having mixed-idiom code, as in my example showing a stream head and a for-loop "tail", are somewhat rare. Maybe less than 5% of cases. But it least it's there when you need it, without requiring any subtle workarounds. I think a more likely benefit is that this can reduce the pressure on the question of whether an API should return a Collection or a Stream. One consideration in making such a decision is whether the caller is more likely to iterate or stream the result. If it's likely the caller will want to iterate, this tips the decision toward returning a collection. But returning a collection usually requires creating and storing all the elements, losing laziness, so this is an uncomfortable tradeoff. With the ability to iterate a Stream, it's possible for an API to return a Stream, while letting the caller choose between adding stream operations or iterating it, without losing laziness. s'marks From martinrb at google.com Thu Mar 14 01:08:41 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Mar 2019 18:08:41 -0700 Subject: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp In-Reply-To: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> References: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> Message-ID: Why not Reference.reachabilityFence ? From weijun.wang at oracle.com Thu Mar 14 01:14:55 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Mar 2019 09:14:55 +0800 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com> Message-ID: +1 (on the security class). Thanks, Max > On Mar 14, 2019, at 1:10 AM, Lance Andersen wrote: > > +1 >> On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote: >> >> Trivially, there should be a comma after the year. Just add it. >> >> >> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun >> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java >> --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java >> +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2015, 2017, 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 >> diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 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 >> diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java >> --- a/src/java.base/share/classes/sun/security/util/IOUtils.java >> +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2009, 2017, 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 >> >> -Chris. > > > > 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 ivan.gerasimov at oracle.com Thu Mar 14 02:01:52 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 13 Mar 2019 19:01:52 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <9d54e171-e066-45a8-119b-9d454481d7a2@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <9b010e5e-80c7-1276-d90f-d2d10aaad864@oracle.com> <9d54e171-e066-45a8-119b-9d454481d7a2@oracle.com> Message-ID: Hi Stuart! On 3/13/19 5:45 PM, Stuart Marks wrote: > > On 3/12/19 4:32 PM, Ivan Gerasimov wrote: >> If there were two new subtypes of Iterable introduced: IterableOnce >> and IterableMultipleTimes, then all existing Iterables could be >> retrofitted to implement one of these. >> >> It wouldn't *automatically* solve the problem of 3rd party API, which >> accepts an Iterable and iterates it multiple times, but would provide >> a means to change that API in a straightforward way. >> >> Also, the static analysis tools could issue a suggestion for code >> that iterates Iterable more than once to switch to >> IterableMultipleTimes, so that it won't be possible to pass in an >> IterableOnce. >> >> It would also allow to strengthen the specification for >> IterableMultipleTimes and state that all classes implementing it must >> make it possible to obtain multiple iterators. > > Hi Ivan, > > This would be a cleaner type hierarchy, in the sense that it would > avoid the subtype-or-supertype issue that's being discussed in a > parallel segment of this thread. But practically speaking I don't > think it adds much value. Most Iterables can be iterated multiple > times; it seems to be the exceptional case that an Iterable is > once-only. (In the JDK, the examples of Scanner and Stream show that > things with once-only behavior avoided implementing Iterable at all.) > Yes, I agree that IterableOnce will likely be rare, comparing to IterableMany. > While we could migrate the JDK classes to IterableMany (or whatever it > would be called), I think it's unrealistic to expect that all the > Iterable implementations out there in the wild would migrate. We'd > thus be left with Iterable and IterableMany meaning more-or-less the > same thing in perpetuity. > I'm thinking about a use case with a method that accepts Iterable and *needs* to traverse it multiple times. (You actually gave such example in the proposal: assertThat(Iterable) from AssertJ). With IterableMany it could be handled like this: void foo(Iterable it) { if (!(it instanceof IterableMany)) { var list = new ArrayList(); it.forEach(list::add); it = list; } for (Object x : it) { ... } for (Object x : it) { ... } } On the other hand, checking if the argument is instanceof IterableOnce wouldn't help because the base class Iterable doesn't provide guaranties w.r.t number of traversals. With kind regards, Ivan > > By introducing IterableOnce, we can attract retrofits by once-off > things (like Scanner and Streams) and the uncommon occurrences of > once-off things like DirectoryStream that currently implement Iterable > can be migrated to IterableOnce. Everybody else can then just stay on > Iterable. > > s'marks > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Thu Mar 14 04:40:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2019 14:40:21 +1000 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: <6F6648D3-2536-4047-B73B-0A0411960F49@oracle.com> References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> <6F6648D3-2536-4047-B73B-0A0411960F49@oracle.com> Message-ID: <4a589284-4e4d-5d4c-7441-6d00a9725fe3@oracle.com> Looks good. Thanks Kim! David ----- On 14/03/2019 9:02 am, Kim Barrett wrote: >> On Mar 13, 2019, at 4:29 PM, Kim Barrett wrote: >> >>> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote: >>> >>> Please review this change to the JNI specification. The specified >>> behavior of Weak Global References, and in particular their >>> relationship to Java PhantomReference, is being updated to account >>> for a change to PhantomReference by JDK-8071507. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8188066 >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8220617 >>> >>> Changes: >>> http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1.html >>> specdiff for the changes. In addition to updating the section >>> describing Weak Global References, the description of NewGlobalRef >>> is updated, as well as the copyright footer. >>> >>> http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.md >>> Copies of the before and after text for the JNI Weak Global >>> References section; easier to read than diffs or specdiff. >> >> I botched the upload of the changes to cr.openjdk.java.net. The corrected URLS are: >> >> http://cr.openjdk.java.net/~kbarrett/8188066/jni_specdiff_rev1/diff.html >> http://cr.openjdk.java.net/~kbarrett/8188066/weak_global_refs_rev1.html > > Stefan Karlsson suggested (offline) a couple of wording changes in the > description of Weak Global References. > > (1) Replace "destroyed" with "deleted" in two places, to align with the > names of DeleteGlobalRef and the like. > > (2) Reword the second sentence of the fourth paragraph, as there is some > potential for ambiguity around "If the references are the same". > > Here's the diff between rev1 and those changes. I'll post an updated > specdiff later, once the dust settles. > > diff -r 76b82c006509 -r 6a2181c4fee2 closed/src/java.se/share/specs/jni/functions.md > --- a/closed/src/java.se/share/specs/jni/functions.md Wed Mar 13 15:40:33 2019 -0400 > +++ b/closed/src/java.se/share/specs/jni/functions.md Wed Mar 13 17:06:23 2019 -0400 > @@ -1177,9 +1177,9 @@ > to `NULL` without notice. > > `IsSameObject` can be used to compare a weak global reference to a non-`NULL` > -local or global reference. If the references are the same, the weak global > -reference's underlying object will not be freed so long as the other reference > -has not been destroyed. > +local or global reference. If the objects are the same, the weak global > +reference won't become functionally equivalent to `NULL` so long as the other > +reference has not been deleted. > > `IsSameObject` can also be used to compare a weak global reference to `NULL` > to determine whether the underlying object has been freed. > @@ -1193,7 +1193,7 @@ > `NewGlobalRef`. These functions will return `NULL` if the object has been > freed. Otherwise, the new reference will prevent the underlying object from > being freed. The new reference, if non-`NULL`, can then be used to access the > -underlying object, and destroyed when such access is no longer needed. > +underlying object, and deleted when such access is no longer needed. > > ------------------------------------------------------------------------------- > > From forax at univ-mlv.fr Thu Mar 14 08:07:22 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 14 Mar 2019 09:07:22 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> Message-ID: <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Mardi 12 Mars 2019 22:45:12 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hi Remi, > >> Stream.iterator() can be really really slow, it uses a pull semantics while >> the whole Stream push values. When designing it, the lambda EG saw it as an >> "escape hatch" in order to interropt with a legacy code than require an >> Iterator and not more. > > If Stream.iterator() is slow, then perhaps it needs to be optimized. Tagir had > some ideas for how to do that. Of course, I don't know if that's exactly the > right way; some additional investigation should be done. But poor performance > relative to Spliterator.tryAdvance() or forEachRemaining() shouldn't be an > argument against doing this. People repeatedly bump into the gap in the > programming model between streams and the enhanced-for loop, and it's time to > fill it in. I'm talking about the perf difference between stream.forEach and for(var element: stream), forEachRemaining may be slower because for the VM the ideal case is to see the creation of the Stream and the call to the terminal operation inside the same inlining horizon so the creation of the Stream itself can be elided. A bit of history: they have been several prototypes of how to implement the stream API before the current one, one of them (i think it's the first one) was based on iterators and iterators of iterators, one for each step of the Stream. The perf of that implementation was good until there was too many intermediary ops calls on the Stream and at that point perf were really bad. It's because the VM has two way to find the type of something in a generic code, it can build a profile by remembering what class was used for a method call or it can propagate the type of an argument to the type of the corresponding parameter. Because an iterator stores the element to return in a field, you are loosing the later way to optimize and the former only work if you have no more than 2 different classes in the profile. So while Stream.iterator() may be optimized, it's not that simple. > >> This proposal has the side effect of making Stream more different from its >> primitive counterpart IntStream, LongStream and DoubleStream which may be >> problematic because we are trying to introduce reified generics as part of >> Valhalla (there is a recent mail of Brian about not adding methods to >> OptionalInt for the same reason). > > Well, yes, I think that it means that Stream evolves somewhat independently of > Int/Long/DoubleStream, but I don't see that this imposes an impediment on > generic specialization in Valhalla. In that world, Stream should (mostly) > just work. It may also be possible in a specialized world to add the specific > things from IntStream (such as sum() and max()) to Stream. We may want more here, like having Stream being a subtype of IntStream so there is only one implementation for IntStream and Stream. Thus adding a method that make IntStream and Stream different just make this kind of retrofitting more unlikely. > >> And, the real issue is how to deal with checked exceptions inside the Stream >> API, i would prefer to fix that issue instead of trying to find a way to >> workaround it. > > Well I'd like to have a solution for checked exceptions as well, but there > doesn't appear to be one on the horizon. I mean, there are some ideas floating > around, but nobody is working on them as far as I know. as far as i know, there are two of them, - one is to get ride of checked exception, even Kotlin which tout itself as a language that is more safe that Java doesn't have checked exception, basically Java is the only language that run of the JVM and have checked exception. - the other is to automatically wrap checked exceptions into a corresponding unchecked exception by letting the compiler generate the code that users currently write when the checked exception appear some context by example with the keyword autowrap, - you have the autowrap block (syntactically like a synchronized block) autowrap { return Files.newInputStream(path); // IOException is transformed to UncheckedIOException by calling IOException.wrap() } - you can use autowrap on a method declaration void foo(Path path) autowrap { return Files.newInputStream(path); // IOException is transformed to UncheckedIOException by calling IOException.wrap() } - you can use autowrap with a functional interface void runBlock(autoWrap Consumer consumer) { ... } ... runblock(() -> { Files.newInputStream(path); // IOException is transformed to UncheckedIOException by calling IOException.wrap() }); > > But checked exceptions aren't the only reason to prefer iteration in some cases; > loops offer more flexible control flow (break/continue) and easier handling of > side effects. The Streams+IterableOnce feature benefits these cases as well as > exception handling. the break/continue equivalent on Stream are skip/limit/findFirst/takeWhile/dropWhile i.e. any short-circuit terminal operations. > > s'marks R?mi From aph at redhat.com Thu Mar 14 09:25:40 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2019 09:25:40 +0000 Subject: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp In-Reply-To: References: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> Message-ID: On 3/14/19 1:08 AM, Martin Buchholz wrote: > Why not Reference.reachabilityFence ? Certainly, yes. Apart from anything else, it's much clearer and robust against changes to HotSpot. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.fuchs at oracle.com Thu Mar 14 09:35:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Mar 2019 09:35:55 +0000 Subject: RFR 8220252: Fix Headings in java.naming In-Reply-To: <2AA96A0F-5624-42E9-AEC3-353B29E9B284@oracle.com> References: <2AA96A0F-5624-42E9-AEC3-353B29E9B284@oracle.com> Message-ID: <00a6e4ac-790a-e0ee-d2dc-d4add9603f09@oracle.com> On 13/03/2019 19:13, Lance Andersen wrote: > Yes you are right, I missed that but it is updated at > http://cr.openjdk.java.net/~lancea/8220252/webrev.01/index.html >> Thanks Lance! The new version looks good. best regards, -- daniel From peter.levart at gmail.com Thu Mar 14 10:20:40 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 14 Mar 2019 11:20:40 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> Message-ID: <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> Hi Stuart, The Alternatives section of the proposal is very thorough and it mentions the following alternative: " ??? An alternative adapter is to add a default method to Stream: ??? default Iterable asIterable() { return this::iterator; } ??? for (T t : asIterable(stream)) { ??? ??? ... ??? } ??? This is slightly better at the call site, and it?s restricted to streams. But it?s still not as nice as IterableOnce and it facilitates creation of poorly-behaved Iterable instances. " It think this alternative is not given fair comparison. 1st this is an instance method, so the foreach loop should read: for (T t : stream.asIterable()) { ??? ... } ...which is better in particular when creation of Stream and consumption is performed in single expression (not a good example, since it doesn't close the stream): for (String line : Files.lines(path).asIterable()) { ??? ... } In addition, why should this be restricted to streams? This could be combined with IterableOnce. The method could be called differently and specified as BaseStream's terminal operation, returning IterableOnce instead of Iterable: ??? /** ???? * Returns an {@link IterableOnce} for elements of this stream. ???? * ???? *

              This is a terminal ???? * operation. ???? * ???? * @return iterable for elements of this stream that may be iterated only once ???? */ ??? default IterableOnce iterate() { ??????? Iterator iterator = iterator(); ??????? return () -> iterator; // this should be a proper IterableOnce with exception thrown etc. ??? } So IntStream and friends would get this too, although with necessary boxing, which should be easy for JIT to eliminate and without conflicts between IntStream.forEach and Iterable.forEach. What do you think? Is this additional method invocation too much of a drawback? And now for something more controversial... Is changing the language really out of the picture here? The Iterator interface has got a new default method called forEachRemaining in JDK 8. This method could be seen roughly equivalent to one-shot iteration directly from IterableOnce: IterableOnce.forEach() vs. IterableOnce.iterator().forEachReamining() Both of above can only be performed once. And once is enough for foreach loop. So if foreach loop was retrofitted to also act on Iterator(s) as a possible right hand side (arrays, Iterable(s), Iterator(s)), then we might not need this IterableOnce at all. You could then just write: for (T t : stream.iterator()) ... But that's probably not going to happen right? Regards, Peter On 3/12/19 10:59 PM, Stuart Marks wrote: > Hi Stephen, > >> My slight concern is that the terminal operation is hidden and not >> immediately visible, which could be surprising. I do note that streams >> throw a clear exception if a terminal operation is called a second >> time which mitigates this to some degree. > > Yes, this is certainly a possibility. > > I'll note that even though my example does it, I think that storing a > stream in a local variable is a bit of a code smell. It has to be done > for try-with-resources, but storing the head of a pipeline in a local > variable so that it can be iterated over does introduce the > possibility of accidental reuse. > > I suspect that most cases (aside from try-with-resources) will call a > method returning a fresh Stream that's then iterated over. For example, > > ??? for (var x : getSomeStream()) { > ?????? // ... > ??? } > > In this case there's no possibility of accidental reuse. > >> The IterableOnce class-level Javadoc contradicts the method-level >> Javadoc. The class-level say "It is recommended that" whereas the >> method-level Javadoc mandates. > > Oh yes, thanks. I'll fix this to make the behavior mandatory. > > s'marks > From bob.vandette at oracle.com Thu Mar 14 14:15:55 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 14 Mar 2019 10:15:55 -0400 Subject: RFR: Container Fixes (8219652, 8217766, 8212528) Message-ID: Ping ... Please review these three fixes for Linux Docker/cgroup container support. WEBREV: http://cr.openjdk.java.net/~bobv/8217766/webrev.0 ISSUE1: https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in osContainer_linux.cpp#L102 appears unreachable This change corrects a rarely used hotspot code path making it compatible with the Java based Metrics. ISSUE2: https://bugs.openjdk.java.net/browse/JDK-8212528 - Wrong cgroup subsystem being used for some CPU Container Metrics Most Linux distros provide symbolic links for cpuacct and cpu controller directories. Docker on the Mac does not. This causes some of the cpu statistics to be unreported since the directory name was incorrect. ISSUE3: https://bugs.openjdk.java.net/browse/JDK-8217766 - Container Support doesn't work for some Join Controllers combinations The cgroup identification -implemented by parsing /proc/self/mountinfo and /proc/self/cgroup- assumed each cgroup controller was mounted disjoint from the others (except for "cpu" and "cpuacct" controllers). Which means, we expected one single controller per mountinfo line. This matches the way most Linux distributions currently configure cgroupsv1 by default. Yet controllers can be grouped arbitrarily. For instance, using the JoinControllers systemd directive. One use case for that is to let Kubernetes' kubelet discover his own dedicated and reserved cgroup hierarchy. In that situation, the JVM fails to discover the expected cgroup controllers set, and, when running containerized, default to a suboptimal understanding of available resources. Supporting arbitrarily controllers groups per mountpoint actually allows for simpler and easier to follow code, as we don't need nested if/else for every controller. This fix also updates the Containers Metrics, to support joint controllers. Bob. From brian.goetz at oracle.com Thu Mar 14 14:21:04 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 14 Mar 2019 10:21:04 -0400 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> Message-ID: <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> > It think this alternative is not given fair comparison. 1st this is an > instance method, so the foreach loop should read: > > for (T t : stream.asIterable()) { > ??? ... > } Let's keep sight of the goal here, which is: people find it a gap that Stream does not play cleanly with foreach.? And the main knock against this approach (besides the chorus of "that's not what we wanted" we are sure to get) is that it is not really much more discoverable than some of the other workarounds (such as casting stream::iterator to Iterable.) > > > And now for something more controversial... > > Is changing the language really out of the picture here? Yes.? This issue was extensively litigated during JSR-335, and it was decided that one language-to-library tunnel (Iterable) here was all we wanted.? And there's been no new evidence since then that we want to change the language for this. There's a reason it took as long as it did for Stuart to come up with this proposal; all the options were known for years, they all have problems, and the net benefit is still relatively narrow, which means we don't have a lot of budget before the cost-benefit becomes negative.? I think the option proposed is the least-worst, and people still seem to really want to be able to foreach over streams. From Roger.Riggs at oracle.com Thu Mar 14 14:37:36 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 14 Mar 2019 10:37:36 -0400 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build Message-ID: Please review a test configure change to skip running TimSortStackSize2 on the fast debug build. The running time of the test is excessive. This particular test has been timing out intermittently for a long time. Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-timsort-timeout-8220613/ Issue: ? https://bugs.openjdk.java.net/browse/JDK-8220613 Thanks, Roger From lance.andersen at oracle.com Thu Mar 14 14:41:18 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 14 Mar 2019 10:41:18 -0400 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: References: Message-ID: <3F21F5F1-6033-482F-AEFB-88C4FA5B32AA@oracle.com> Thank you Roger for addressing this Looks good > On Mar 14, 2019, at 10:37 AM, Roger Riggs wrote: > > Please review a test configure change to skip running TimSortStackSize2 > on the fast debug build. The running time of the test is excessive. > This particular test has been timing out intermittently for a long time. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-timsort-timeout-8220613/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8220613 > > 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 scolebourne at joda.org Thu Mar 14 14:50:54 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 14 Mar 2019 14:50:54 +0000 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> Message-ID: On Thu, 14 Mar 2019 at 14:21, Brian Goetz wrote: > There's a reason it took as long as it did for Stuart to come up with > this proposal; all the options were known for years, they all have > problems, and the net benefit is still relatively narrow, which means we > don't have a lot of budget before the cost-benefit becomes negative. I > think the option proposed is the least-worst, and people still seem to > really want to be able to foreach over streams. The cost-benefit is definitely tight, but I think it is positive. As I said here [1] there is still a case for control abstractions in Java even when you have lambdas A new concern from me is that this change would allow Iterable and Stream to be used in foreach, but not Iterator. This seems like an odd/sharp conceptual edge. Why not make `Iterator` implement `IterableOnce`? The default method would obviously just return `this`. It seems to me that if we are willing to countenance foreach over a one-shot Stream, it is inappropriate to deny foreach to a one-shot Iterator. thanks Stephen [1] https://mail.openjdk.java.net/pipermail/amber-dev/2019-March/004127.html From goetz.lindenmaier at sap.com Thu Mar 14 14:58:35 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Mar 2019 14:58:35 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> Message-ID: Hi, > Roger, Coleen, Maurizio and I talked about this proposed feature. > We all think that improving NPE message is a useful enhancement for > the platform and helps developers to tell what causes NPE. Thanks for this positive feedback :)! > This is not a small enhancement. Diving into a large code review > would not be the best way to move this forward as you can see the > discussion so far. > > It would help if you can start with writing down the problem and > the proposal like what improvements are proposed and under what > circumstances may be acceptable that NPE message won't be improved. > This would get the discussion on the proposal feature and then > the discussion of the best way to to implement it in the VM, library, > or combination. You can consider using the JEP template that gives > you a good structure to follow for the write up. Yes, I can write down the overall design of this. This probably is a good idea. I already started editing, but please give me a day or two. The past days I have been working on the C-code. I incorporated Coleens comments, but mostly changed the messages to print different text as it was proposed in several reviews. I'm about to publish a webrev with this new coding. This could be a new, better basis for discussing the wording of the message. Best regards, Goetz. > > What do you think? > > Mandy From maurizio.cimadamore at oracle.com Thu Mar 14 15:00:20 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Mar 2019 15:00:20 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> Message-ID: <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> I second what Mandy says. First let me start by saying that this enhancement will be a great addition to our platform; back in the days when I was teaching some Java classes at the university, I was very aware of how hard it is to diagnose a NPE for someone novel to Java programming. A trained eye of course can quickly scan the line where an exception occurs, and quickly isolate the couple of problematic spots which could have caused an exception. But it takes time to get to that point, and having some helpful messages to help you to get to that point is, IMHO a valuable goal in itself. I also think that the design space for such an enhancement is non trivial, and would best be explored (and captured!) in a medium that is something other than a patch. What kind of improvements should we add to the NPE exception? What happens if the NPE already has an user-provided details message? Should the enhancement make use of optional debugging classfile attributes (you touch this in your nice RFE). And again, what are the performance considerations we deem important for this work to be declared successful? And, maintenance-wise, what is the right way to implement the enhancement? Should we implement that as a pure VM feature, should we implement it on top of the existing VM, using some classfile manipulation (**) ? Or a combination of those? As you can see, there are so many question this enhancement raises that I think going straight for a code review can be a premature move; people will be coming at the review table with different answers to the above set of questions (and maybe additional questions too :-)), and that could make the review process hard and frustrating for all the parties involved. So I warmly suggest we take a step back from the code, and formulate a proposal for enhancing NPE messages in Java; in this sense, a JEP seems to me the most natural way to move forward. (**) I have a quick and dirty prototype of that built using ASM which I'm happy to share, in case you are interested taking a look when evaluating alternatives. Cheers Maurizio On 14/03/2019 00:42, Mandy Chung wrote: > Hi Goetz, > > Roger, Coleen, Maurizio and I talked about this proposed feature. > We all think that improving NPE message is a useful enhancement for > the platform and helps developers to tell what causes NPE. > > This is not a small enhancement.? Diving into a large code review > would not be the best way to move this forward as you can see the > discussion so far. > > It would help if you can start with writing down the problem and > the proposal like what improvements are proposed and under what > circumstances may be acceptable that NPE message won't be improved. > This would get the discussion on the proposal feature and then > the discussion of the best way to to implement it in the VM, library, > or combination.? You can consider using the JEP template that gives > you a good structure to follow for the write up. > > What do you think? > > Mandy From Alan.Bateman at oracle.com Thu Mar 14 15:09:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2019 15:09:41 +0000 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: References: Message-ID: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> On 14/03/2019 14:37, Roger Riggs wrote: > Please review a test configure change to skip running TimSortStackSize2 > on the fast debug build. The running time of the test is excessive. > This particular test has been timing out intermittently for a long time. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-timsort-timeout-8220613/ > > Issue: > ? https://bugs.openjdk.java.net/browse/JDK-8220613 Looks okay but the fastdebug times looks very long compared to other tests - do you know if there a specific assertion that is the issue here? -Alan From Roger.Riggs at oracle.com Thu Mar 14 15:23:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 14 Mar 2019 11:23:34 -0400 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> References: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> Message-ID: <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> Hi Alan, I didn't have a good idea where to look, the times do seem excessive. Suggestions? Thanks, Roger On 03/14/2019 11:09 AM, Alan Bateman wrote: > On 14/03/2019 14:37, Roger Riggs wrote: > Looks okay but the fastdebug times looks very long compared to other > tests - do you know if there a specific assertion that is the issue here? > From peter.levart at gmail.com Thu Mar 14 15:26:05 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 14 Mar 2019 16:26:05 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> Message-ID: <0d795628-5f33-262b-bceb-94a4615cbf0f@gmail.com> Now that Brian put it so nicely, I'm convinced and I'd like to draw back and support this proposal as is... On 3/14/19 3:50 PM, Stephen Colebourne wrote: > On Thu, 14 Mar 2019 at 14:21, Brian Goetz wrote: >> There's a reason it took as long as it did for Stuart to come up with >> this proposal; all the options were known for years, they all have >> problems, and the net benefit is still relatively narrow, which means we >> don't have a lot of budget before the cost-benefit becomes negative. I >> think the option proposed is the least-worst, and people still seem to >> really want to be able to foreach over streams. > The cost-benefit is definitely tight, but I think it is positive. As I > said here [1] there is still a case for control abstractions in Java > even when you have lambdas > > > A new concern from me is that this change would allow Iterable and > Stream to be used in foreach, but not Iterator. This seems like an > odd/sharp conceptual edge. To be precise: this change would not allow Iterable and Stream to be used in foreach. foreach does not change. It would still alow only Iterable (and arrays). The Stream would become an Iterable with this change. > > Why not make `Iterator` implement `IterableOnce`? The default method > would obviously just return `this`. This would conflate concepts to much. Iterator *is* an external iteration state while Iterable[Once] is a (one-shot) factory for Iterator. The specification for IterableOnce could not say that the second and subsequent invocations of iterator() method are to throw exception if Iterator interface extended IterableOnce (interfaces have no state to model this in the default method). > > It seems to me that if we are willing to countenance foreach over a > one-shot Stream, it is inappropriate to deny foreach to a one-shot > Iterator. Again, this proposal does not do anything to foreach specification. It just makes Stream be Iterable. The concepts here are more to the point: Iterable: factory for Iterator Stream: one-shot factory for Spliterator Stream extends IterableOnce: one-shot factory for Spliterator and one-shot factory for Iterator I think this makes perfect sense. Regards, Peter From goetz.lindenmaier at sap.com Thu Mar 14 16:04:48 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Mar 2019 16:04:48 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <9ba9460e-94ba-7175-6a3a-6fd53533e0cf@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> <776b45816d3646b485effb69ec9a134a@sap.com> <9ba9460e-94ba-7175-6a3a-6fd53533e0cf@oracle.com> Message-ID: Hi Coleen, thanks for looking at my change.. > For the record, I think the C++ implementation is more straightforward > than trying to use the Stackwalker and ASM because there's other code > just like it right here. You have all the information you need directly > in the Throwable.backtrace field. Walking it makes sense to me.? Also > the StackWalker has a cost because it creates ResolvedMethodNames that > must be interned in the native code in case of redefinition. Yes, I also think that a Java implementation has more costs at runtime. But as this is only encountered if the message is actually accessed, it's not that much of a concern. > I didn't make it through the code for bytecodeUtils but I think it > should be in the interpreter directory where all the other bytecode > iterating methods are.? I moved it to the interpreter directory. http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/ > It does seem expensive when printing an NPE > message.? I wonder if there's some easily helpful variable names that > you could pick out and not have to do all this work for every sort of > bytecode.? I'll describe the algorithm in some detail in the paper requested. This might answer this point. > Also the file uses non hotspot names also like > 'createInvalidSource' that should be fixed. I still need to fix these. I?ll leave this to a final review. The code still might be discarded in favour of another implementation. > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > NPE/02/src/hotspot/share/classfile/javaClasses.cpp.udiff.html > > There's a 'version' in the backtrace.? If the method->version() doesn't > match the one in the backtrace, this should return false, because the > method was redefined and the bci probably won't match. There's a bunch > of code in javaClasses that does the similar thing. Starting with the back trace, I will always get the right bytecodes. The backtrace keeps the method alive as I understand. The problem I mentioned in other mails is to get that accessible in Java code ... for the C-implementation I have all the proper information just per design of the metaspace/backtrace etc. at hand. Best regards, Goetz. > > This isn't a full review. > > Thanks, > Coleen > > > > > Thanks! > > Goetz > > > >> Also, it was not strictly correct when I said all that is retained is > >> the method bytecodes. Exception tables, line number tables and local var > >> name & type tables are also retained. > >> > >> 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 claes.redestad at oracle.com Thu Mar 14 16:26:05 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Mar 2019 17:26:05 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: Hi, this RFE was stalled due an interaction with SA that has since been resolved. As it still applies cleanly I'll consider it reviewed. I'm just going to do some sanity testing (tier1) before push. Thanks! /Claes On 2018-12-03 17: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 > > Thanks! > > /Claes From jianglizhou at google.com Thu Mar 14 17:08:11 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 14 Mar 2019 10:08:11 -0700 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: Looks good! Thanks, Jiangli On Thu, Mar 14, 2019 at 9:26 AM Claes Redestad wrote: > Hi, > > this RFE was stalled due an interaction with SA that has since been > resolved. As it still applies cleanly I'll consider it reviewed. I'm > just going to do some sanity testing (tier1) before push. > > Thanks! > > /Claes > > On 2018-12-03 17: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 > > > > Thanks! > > > > /Claes > From Alan.Bateman at oracle.com Thu Mar 14 17:13:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2019 17:13:47 +0000 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: On 14/03/2019 16:26, Claes Redestad wrote: > Hi, > > this RFE was stalled due an interaction with SA that has since been > resolved. As it still applies cleanly I'll consider it reviewed. I'm > just going to do some sanity testing (tier1) before push. I think we need to rollback some of the changes that we done in JDK-6805750 so that we don't have non-standard attributes in the map. We shouldn't be hard coding names such as Ant-Version or Bnd-LastModified for example. For the current webrev then I'm concerned it is brings back legacy attributes. The concept of "installed optional packages" was removed in Java SE 9, as was the ability for JAR packaged applets to trigger downloading of optional packages. I don't think the later was ever implemented in the JDK so surprising that we are finding JAR files with those attributes now. If we can prune that down then I think the changes will be okay. -Alan. From claes.redestad at oracle.com Thu Mar 14 17:20:30 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Mar 2019 18:20:30 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: Message-ID: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> On 2019-03-14 18:13, Alan Bateman wrote: > On 14/03/2019 16:26, Claes Redestad wrote: >> Hi, >> >> this RFE was stalled due an interaction with SA that has since been >> resolved. As it still applies cleanly I'll consider it reviewed. I'm >> just going to do some sanity testing (tier1) before push. > I think we need to rollback some of the changes that we done in > JDK-6805750 so that we don't have non-standard attributes in the map. We > shouldn't be hard coding names such as Ant-Version or Bnd-LastModified > for example. > > For the current webrev then I'm concerned it is brings back legacy > attributes. The concept of "installed optional packages" was removed in > Java SE 9, as was the ability for JAR packaged applets to trigger > downloading of optional packages. I don't think the later was ever > implemented in the JDK so surprising that we are finding JAR files with > those attributes now. If we can prune that down then I think the changes > will be okay. Ok. I stumbled on some new test issues in SA with this patch, so I'll need to pause this one for a while anyhow. /Claes From ivan.gerasimov at oracle.com Thu Mar 14 17:29:05 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Mar 2019 10:29:05 -0700 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) Message-ID: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> Hello! Not all the man pages agree that chmod, access and statvfs64 can be interrupted, but at least on some platforms they are allowed to fail with EINTR: chmod(2) on MacOS, access(2) on Solaris and statvfs(3) on Linux. So, it would be more accurate to wrap these up into a RESTARTABLE loop. Also, java_io_UnixFileSystem_list was tiny-optimized to avoid unnecessary reallocation. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456 WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From brent.christian at oracle.com Thu Mar 14 17:41:33 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 14 Mar 2019 10:41:33 -0700 Subject: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp In-Reply-To: References: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> Message-ID: <3f558d46-9c37-334c-dfbc-5afba133a3a2@oracle.com> On 3/13/19 6:08 PM, Martin Buchholz wrote: > Why not?Reference.reachabilityFence ? You mean the mechanism for this precise situation. Yeah, OK. http://cr.openjdk.java.net/~bchristi/8220088/webrev.01/ Thanks, -Brent From bob.vandette at oracle.com Thu Mar 14 17:58:54 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 14 Mar 2019 13:58:54 -0400 Subject: RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: The change looks good. Thanks for fixing this. I?d send this to core-libs (cc?d). Bob. > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf wrote: > > Hi, > > I'm not sure what the right list for Metrics.java[1] is. Assuming it's > serviceability-dev: > > Please review this one-liner for for SubSystem.java which currently > behaves differently from the native implementation in > osContainer_linux.cpp. Please see the details in the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ > > Testing: > Manual testing of JDK-8217338 with Metrics.java support with/without > this fix on Linux x86_64. Metrics tests and Docker tests continue to > pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, which > was fun). > > Thoughts? > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > From brian.burkhalter at oracle.com Thu Mar 14 18:16:10 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Mar 2019 11:16:10 -0700 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) In-Reply-To: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> References: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> Message-ID: Hello Ivan, This looks all right to me. Thanks, Brian > On Mar 14, 2019, at 10:29 AM, Ivan Gerasimov wrote: > > Not all the man pages agree that chmod, access and statvfs64 can be interrupted, but at least on some platforms they are allowed to fail with EINTR: chmod(2) on MacOS, access(2) on Solaris and statvfs(3) on Linux. > > So, it would be more accurate to wrap these up into a RESTARTABLE loop. > > Also, java_io_UnixFileSystem_list was tiny-optimized to avoid unnecessary reallocation. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456 > WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/ From sgehwolf at redhat.com Thu Mar 14 18:24:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Mar 2019 19:24:58 +0100 Subject: RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: On Thu, 2019-03-14 at 13:58 -0400, Bob Vandette wrote: > The change looks good. Thanks for fixing this. Thanks for the review, Bob! Cheers, Severin > I?d send this to core-libs (cc?d). > > Bob. > > > > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf > > wrote: > > > > Hi, > > > > I'm not sure what the right list for Metrics.java[1] is. Assuming > > it's > > serviceability-dev: > > > > Please review this one-liner for for SubSystem.java which currently > > behaves differently from the native implementation in > > osContainer_linux.cpp. Please see the details in the bug. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ > > > > Testing: > > Manual testing of JDK-8217338 with Metrics.java support > > with/without > > this fix on Linux x86_64. Metrics tests and Docker tests continue > > to > > pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, > > which > > was fun). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] > > http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > > From brian.goetz at oracle.com Thu Mar 14 19:45:41 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 14 Mar 2019 15:45:41 -0400 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> Message-ID: <73C33352-5499-4AD3-81D6-83C15CAD74AF@oracle.com> > A new concern from me is that this change would allow Iterable and > Stream to be used in foreach, but not Iterator. This seems like an > odd/sharp conceptual edge. Not actually a new concern ? this was discussed back in JSR 335 as well. > Why not make `Iterator` implement `IterableOnce`? The default method > would obviously just return `this`. Such a default would not conform to the contract, as IO requires that subsequent calls throw. From ivan.gerasimov at oracle.com Thu Mar 14 19:49:55 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Mar 2019 12:49:55 -0700 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout Message-ID: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> Hello! The default implementation of Process.waitFor(long, TimeUnit) does not check if the process has exited after the last portion of the timeout has expired. JDK has two implementations of Process (for Unix and Windows) and they both override waitFor(), so it's not an issue for them. Still, it is better to provide a more accurate default implementation. I'm not quite certain the regression test needs to be included in the fix. The test does demonstrate the issue with the unfixed JDK and passed Okay on all tested platforms in Mach5. Yet, I suspect the test can still show false negative results, as there are no guaranties that even such simple application as `true` will finish in 100 ms. I can tag the test as @ignored with a comment, or simply remove it from the fix. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ Thanks in advance for reviewing! -- With kind regards, Ivan Gerasimov From forax at univ-mlv.fr Thu Mar 14 19:52:36 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 14 Mar 2019 20:52:36 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <1862652716.528071.1551875857364.JavaMail.zimbra@u-pem.fr> Message-ID: <495364679.1132191.1552593156546.JavaMail.zimbra@u-pem.fr> yes,i should have been more specific, you can not *without* having some boxing in the middle. R?mi ----- Mail original ----- > De: "Tagir Valeev" > ?: "Remi Forax" > Cc: "Stuart Marks" , "core-libs-dev" > Envoy?: Jeudi 7 Mars 2019 11:33:20 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hello, Remi! > > It actually works thanks to auto-boxing/unboxing. E.g. this > implementation works: > > static Iterable range(int from, int to) { > return () -> new PrimitiveIterator.OfInt() { > int cur = from; > > @Override > public int nextInt() { > if (cur >= to) { > throw new NoSuchElementException(); > } > return cur++; > } > > @Override > public boolean hasNext() { > return cur < to; > } > }; > } > > public static void main(String[] args) { > for(int i : range(0, 100)) { > System.out.println(i); > } > } > > It correctly compiles and prints numbers from 0 to 99. As IntStream > extends BaseStream and BaseStream BaseStream> defines Iterator iterator(), it would be no > problem with using IntStream.range in such code pattern were > BaseStream extends IterableOnce. > > Of course this produces unnecessary garbage, as I said. > > With best regards, > Tagir Valeev. > > On Wed, Mar 6, 2019 at 7:37 PM Remi Forax wrote: >> >> Hi Tagir, >> try to do it now and you will see that you can't, because you can not write >> Iterable yet. >> Once we will get generics over value types, it will be a no-brainer. >> >> R?mi >> >> ----- Mail original ----- >> > De: "Tagir Valeev" >> > ?: "Stuart Marks" >> > Cc: "core-libs-dev" >> > Envoy?: Mercredi 6 Mars 2019 11:10:41 >> > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams >> >> > Hello! >> > >> > By the way one of the painful code patterns in modern Java is `for(int >> > i = 0; i> > newbies and prone to errors as the variable need to be repeated three >> > times. Also the variable is not effectively final, despite it never >> > changes within the loop body, so could have been considered as >> > redeclared on every loop iteration (like in for-each). With the new >> > proposal it's possible to write `for(int i : range(0, bound).boxed())` >> > (assuming import static j.u.s.IntStream.range), which looks much >> > better, though it has obvious performance drawback. Moving >> > IterableOnce to BaseStream would enable to use `for(int i : range(0, >> > bound))` which looks even better, though again we have plenty of >> > garbage (but considerably less than in previous case!). I wonder >> > whether Java could evolve to the point where such kind of code would >> > be a recommended way to iterate over subsequent integer values without >> > any performance handicap. >> > >> > With best regards, >> > Tagir Valeev. >> > >> > On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks wrote: >> >> >> >> Hi all, >> >> >> >> Please review and comment on this proposal to allow Stream instances to be used >> >> in enhanced-for ("for-each") loops. >> >> >> >> Abstract >> >> >> >> Occasionally it's useful to iterate a Stream using a conventional loop. However, >> >> the Stream interface doesn't implement Iterable, and therefore streams cannot be >> >> used with the enhanced-for statement. This is a proposal to remedy that >> >> situation by introducing a new interface IterableOnce that is a subtype of >> >> Iterable, and then retrofitting the Stream interface to implement it. Other JDK >> >> classes will also be retrofitted to implement IterableOnce. >> >> >> >> Full Proposal: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html >> >> >> >> Bug report: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8148917 >> >> >> >> Webrev: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/ >> >> >> >> Note, this changeset isn't ready to push yet. In particular, it has no tests >> >> yet. However, the implementation is so simple that I figured I should include >> >> it. Comments on the specification wording are also welcome. >> >> >> >> Thanks, >> >> > > > > s'marks From brian.burkhalter at oracle.com Thu Mar 14 20:50:38 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Mar 2019 13:50:38 -0700 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <4ec34854-b6c3-3f7d-19fc-9cfa3a3ff6a9@gmail.com> References: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> <3e8152b3-28ca-a8f3-4e1a-5c6fa9fc9174@gmail.com> <197b5d86-02aa-c940-6b6a-c930400914df@redhat.com> <5E262D56-79DE-4A4B-9F57-569B732A5DDE@oracle.com> <869b3807-bce5-eccd-0efe-9bbf01780c41@gmail.com> <4ec34854-b6c3-3f7d-19fc-9cfa3a3ff6a9@gmail.com> Message-ID: <4DFF6332-3376-4DE7-A6E2-703284D72C60@oracle.com> The CSR for this issue is available for review at https://bugs.openjdk.java.net/browse/JDK-8202555 . If you have a JBS user name you can add yourself as reviewer by editing the issue directly, assuming you concur with the content. Brian > On Mar 8, 2019, at 8:56 AM, raffaello.giulietti at gmail.com wrote: > > On 2019-03-08 14:35, Andrew Haley wrote: >> Hi, >> >> On 3/7/19 7:16 PM, Raffaello Giulietti wrote: >> >>> a couple of weeks ago I tried to refactor the code assuming the >>> existence of unsignedMultiplyHigh() (either as some future intrinsic or >>> as a Java method) and a wider representations of g with either 127 or >>> 128 bits: >>> g = g1 2^64 + g0 >>> >>> with either >>> 2^63 <= g1 < 2^64 (128 bits) >>> >>> or >>> 2^62 <= g1 < 2^63 (127 bits) >>> >>> Unfortunately, the resulting code of rop() isn't any simpler. That's >>> because then an intermediate sum can overflow the 64 bits of a long. As >>> a consequence, there's need for more elaborate logic to determine >>> the carry and other slightly more complicated computations to assemble >>> the final result. All in all, the resulting code has more operations and >>> looks longer. >> >> Ah, I see. I agree, we still don't quite have the full set of operations >> that we need in Java, in particular a nice way of doing an add with carry. >> > > Yes. > > >> Thank you for the explanation. >> > > You're welcome. > > >>> In the meantime I got rid of the last division. There's no division at >>> all in the whole algorithm. >> >> Excellent. This is looking very good indeed. >> > From forax at univ-mlv.fr Thu Mar 14 20:51:02 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 14 Mar 2019 21:51:02 +0100 (CET) Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> Message-ID: <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "Brian Goetz" , "Stuart Marks" , "core-libs-dev" > > Envoy?: Mardi 12 Mars 2019 18:34:58 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > On 3/12/19 5:04 PM, Brian Goetz wrote: >> No. You have the LSP backwards (though this is easy to do.) >> >> IterableOnce means "*must throw* on subsequent use"; under this spec, >> an arbitrary Iterable is most certainly *not* an IterableOnce, and >> therefore an LSP violation. >> >> It sounds like you are suggesting that we instead spec >> IterableAtLeastOnce, of which Iterable *would* be a credible subtype >> -- but due to how Iterable is specified now, the problem is that >> Iterable *already is* really "iterable at least once."? So there would >> be no point in introducing this type; we already have it. > > Due to how Iterable is specified now it does not promise multiple > iterations, but due to how most (all that I know of except > DirectoryStream or some 3rd party) Iterables are implemented now, the > common expectation is that it does. By implementing more Iterable(s) > that don't support multiple iteration (regardless of whether they > implement this new sub-type or not), this expectation will be less and > less honored. Perhaps this is not so bad. At various occasions the > specification has been changed to accommodate the long-standing behavior > or expectation of behavior, but this seems not to be one of them. > > Let's pretend for a moment that Iterable specification was changed to > guarantee multi-pass iteration. In that case the IterableAtLeastOnce as > a supertype of multi-pass Iterable would make much more sense, wouldn't it? > > But as there could be Iterables out there that by current spec are > perfectly valid and don't support multi-pass iteration, such spec change > would make them non-conformant and is therefore not allowed. So I'm > convinced now that this is the least-bad solution. > > Regards, Peter yes, i think i prefer this solution, one Iterable to rule them all. First, it's not in the spirit of the Collection API to multiply the interfaces, by example, we have only one kind of Iterator and not an Iterator and a ReadOnlyIterator even if a lot of iterators doesn't implement remove. It's a central design of the Collection API, reduce the number of interfaces to ease the use even if it means that each interface may have a broader definition. The Collection API design has chosen his side between users and library writers (people that provides implementations) because from the library writer point of view you can not specify exactly the semantics you want. Then from the user POV, what is point of IterableOnce ? I will not using it as parameter because using Iterable is a super-type (like i will use a List instead of an ArrayList as parameter) and if i using it as return type, codes that call that method can put it in an Iterable, this is exactly what the for-each-loop will do BTW, so it's seems useless. Also as Peter said, there are already codes in the wild that create an Iterable that can only be iterated once, ASM has such class, if IterableOnce is added to the JDK, i will have people ask me to retrofit the ASM class to use IterableOnce just for the sake of having the right semantics ? So basically by introducing IterableOnce, all codes that were perfectly fine in term of semantics before introducing IterableOnce are now not quite right because they are not implementing the right interface ? Hum, i think i still not get why we need such interface. R?mi From goetz.lindenmaier at sap.com Thu Mar 14 20:55:47 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Mar 2019 20:55:47 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <3245ec3cefe2471e8382048164c0ba6b@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <3245ec3cefe2471e8382048164c0ba6b@sap.com> Message-ID: Hi, I had promised to work on a better wording of the messages. This I deliver with this webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/ The test in the webrev is modified to just print messages along with the code that raised the messages. Please have a look at these files with test output contained in the webrev: Messages with debug information: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/output_with_debug_info.txt Messages without debug information: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/output_no_debug_info.txt Especially look at the first few messages, they point out the usefulness of this change. They precisely say what was null in a chain of dereferences. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Wednesday, February 13, 2019 10:09 AM > To: 'Mandy Chung' ; Roger Riggs > > Cc: Java Core Libs ; hotspot-runtime- > dev at openjdk.java.net > Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Mandy, > > Thanks for supporting my intend of adding the message as such! > I'll start implementing this in Java and come back with a webrev > in a while. > > In parallel, I would like to continue discussing the other > topics, e.g., the wording of the message. I will probably come up > with a separate webrev for that. > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Mandy Chung > > Sent: Tuesday, February 12, 2019 7:32 PM > > To: Roger Riggs > > Cc: Java Core Libs ; hotspot-runtime- > > dev at openjdk.java.net > > Subject: Re: RFR(L): 8218628: Add detailed message to > NullPointerException > > describing what is null. > > > > On 2/8/19 11:46 AM, Roger Riggs wrote: > > > Hi, > > > > > > A few higher level issues should be considered, though the details > > > of the webrev captured my immediate attention. > > > > > > Is this the right feature and is this the right level of implementation > > > (C++/native)? > > > : > > > How much of this can be done in Java code with StackWalker and other > > > java APIs? > > > It would be a shame to add this much native code if there was a more > > robust > > > way to implement it using APIs with more leverage. > > > > Improving the NPE message for better diagnosability is helpful while > > I share the same concern Roger raised. > > > > Implementing this feature in Java and the library would be a better > > choice as this isn't absolutely required to be done in VM in native. > > > > NPE keeps a backtrace capturing the method id and bci of each stack > > frame. One option to explore is to have StackWalker to accept a > > Throwable object that returns a stream of StackFrame which allows > > you to get the method and BCI and also code source (I started a > > prototype for JDK-8189752 some time ago). It can use the bytecode > > library e.g. ASM to read the bytecode. For NPE message, you can > > implement a specialized StackFrameTraverser just for building > > an exception message purpose. > > > > Mandy From pavel.rappo at oracle.com Thu Mar 14 21:02:03 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 14 Mar 2019 21:02:03 +0000 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> Message-ID: I have to look at this patch in more detail, however here's what jumped out at me straight away: long deadline = System.nanoTime() + remainingNanos; It seems like a possibility for an overflow. Documentation for System.nanoTime has a special section on this: For example, to measure how long some code takes to execute: long startTime = System.nanoTime(); // ... the code being measured ... long elapsedNanos = System.nanoTime() - startTime; To compare elapsed time against a timeout, use if (System.nanoTime() - startTime >= timeoutNanos) ... instead of if (System.nanoTime() >= startTime + timeoutNanos) ... because of the possibility of numerical overflow. Is that of concern in this case? > On 14 Mar 2019, at 19:49, Ivan Gerasimov wrote: > > Hello! > > The default implementation of Process.waitFor(long, TimeUnit) does not check if the process has exited after the last portion of the timeout has expired. > > JDK has two implementations of Process (for Unix and Windows) and they both override waitFor(), so it's not an issue for them. > > Still, it is better to provide a more accurate default implementation. > > I'm not quite certain the regression test needs to be included in the fix. The test does demonstrate the issue with the unfixed JDK and passed Okay on all tested platforms in Mach5. Yet, I suspect the test can still show false negative results, as there are no guaranties that even such simple application as `true` will finish in 100 ms. > I can tag the test as @ignored with a comment, or simply remove it from the fix. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 > WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ > > Thanks in advance for reviewing! > > -- > With kind regards, > Ivan Gerasimov > From ivan.gerasimov at oracle.com Thu Mar 14 21:32:54 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Mar 2019 14:32:54 -0700 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> Message-ID: Thank you Pavel! On 3/14/19 2:02 PM, Pavel Rappo wrote: > I have to look at this patch in more detail, however here's what jumped out at > me straight away: > > long deadline = System.nanoTime() + remainingNanos; > > It seems like a possibility for an overflow. > Not quite. The deadline can surely become negative, which is alright. Later we only check the difference (deadline - System.nanoTime()). Actually, the new code mimics what we have in PocessImpl for Unix and Windows. With kind regards, Ivan > Documentation for System.nanoTime > has a special section on this: > > For example, to measure how long some code takes to execute: > > long startTime = System.nanoTime(); > // ... the code being measured ... > long elapsedNanos = System.nanoTime() - startTime; > > To compare elapsed time against a timeout, use > > if (System.nanoTime() - startTime >= timeoutNanos) ... > > instead of > > if (System.nanoTime() >= startTime + timeoutNanos) ... > > because of the possibility of numerical overflow. > > Is that of concern in this case? > >> On 14 Mar 2019, at 19:49, Ivan Gerasimov wrote: >> >> Hello! >> >> The default implementation of Process.waitFor(long, TimeUnit) does not check if the process has exited after the last portion of the timeout has expired. >> >> JDK has two implementations of Process (for Unix and Windows) and they both override waitFor(), so it's not an issue for them. >> >> Still, it is better to provide a more accurate default implementation. >> >> I'm not quite certain the regression test needs to be included in the fix. The test does demonstrate the issue with the unfixed JDK and passed Okay on all tested platforms in Mach5. Yet, I suspect the test can still show false negative results, as there are no guaranties that even such simple application as `true` will finish in 100 ms. >> I can tag the test as @ignored with a comment, or simply remove it from the fix. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >> >> Thanks in advance for reviewing! >> >> -- >> With kind regards, >> Ivan Gerasimov >> > -- With kind regards, Ivan Gerasimov From igor.ignatyev at oracle.com Thu Mar 14 21:33:20 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 14 Mar 2019 14:33:20 -0700 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <0c282875-2f0b-ed17-4a05-621bd5e0d862@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <0c282875-2f0b-ed17-4a05-621bd5e0d862@oracle.com> Message-ID: Hi Alan, I double checked, the test is linked w/ -ljli, and calls JNI_CreateJavaVM from libjli.so. hence I'll leave JniInvocationTest in jdk/tools/launcher. -- Igor > On Feb 21, 2019, at 12:17 PM, Alan Bateman wrote: > > On 21/02/2019 19:55, Igor Ignatyev wrote: >> : >> Alan, you are right, this test is a JNI test and should be moved to hotspot/runtime/jni. more details in my answer to the same comment in David's email. in two words, I accidentally looked at another test. >> > Can you double check that it is actually using the JNI invocation interface directly? I don't think we were able to find anyone in Eclipse to explain what their launcher on macOS is doing. I suspect it may be directly (or indirectly) reading the CFBundleExecutable property from Info.plist and calling the JNI_CreateJavaVM function in libjli (not libjvm). We probably need more tests in this area and also a bit more archaeology to see whether this was a supported interface in Apple's JDK. > > -Alan From mark.reinhold at oracle.com Thu Mar 14 21:38:04 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 14 Mar 2019 14:38:04 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> Message-ID: <20190314143804.400279193@eggemoggin.niobe.net> 2019/3/14 8:00:20 -0700, maurizio.cimadamore at oracle.com: > I second what Mandy says. > > First let me start by saying that this enhancement will be a great > addition to our platform; back in the days when I was teaching some Java > classes at the university, I was very aware of how hard it is to > diagnose a NPE for someone novel to Java programming. Agreed! > ... > > I also think that the design space for such an enhancement is non > trivial, and would best be explored (and captured!) in a medium that is > something other than a patch. ... Agreed, also. Goetz -- if, per Mandy?s suggestion, you?re going to write something up using the JEP template, might I suggest that you then submit it as an actual JEP? Giving visibility to, and recording, such design-space explorations is one of the primary goals of the JEP process. - Mark From igor.ignatyev at oracle.com Thu Mar 14 21:38:08 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 14 Mar 2019 14:38:08 -0700 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <511d81a3-847c-49d0-76ff-fdc836211f37@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> <511d81a3-847c-49d0-76ff-fdc836211f37@oracle.com> Message-ID: <726FFE91-7F8C-46F6-9DE9-A112F5C5C17B@oracle.com> Hi Misha, thanks for your suggestions, I have moved all runtime tests into subdirectories. here is the updated webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.01/index.html Thanks, -- Igor > On Mar 4, 2019, at 1:57 PM, mikhailo.seledtsov at oracle.com wrote: > > Hi Igor, > > Sorry it took a while to get back to you on this one. See my comment below > > > On 2/22/19 10:35 AM, mikhailo.seledtsov at oracle.com wrote: >> Overall the change looks good; thank you Igor for doing this. I have couple of comments: >> >> - I am in favor of the approach where we move tests first under corresponding sub-component directories in >> test/hotspot sub-tree, and then figure out whether to keep them. Even though in general I am in favor >> of removing tests that are obsolete or of questionable value, this requires time, consideration and discussions. >> Hence, I recommend filing an RFE for that, which can be addressed after the migration. >> >> - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime >> The tests should go into underlying sub-directories which best match functional area or topic of that test. >> In most cases you did it in your change, but there are several tests that your change places directly under >> test/hotspot/jtreg/runtime/: >> >> ExplicitArithmeticCheck.java >> MonitorCacheMaybeExpand_DeadLock.java >> ReflectStackOverflow.java >> ShiftTest.java - David commented this can go under compiler (a jit test) >> WideStrictInline.java > I have looked at the tests in more detail, and here are my recommendation of placements: > ExplicitArithmeticCheck > This test checks that ArithmeticException is thrown when appropriate > I would recommend placing it under runtime/ErrorHandling > MonitorCacheMaybeExpand_DeadLock > Existing folder: runtime/Thread (it does have a locking test) > Or, alternatively, create a new folder: 'locking' or 'monitors' > ReflectStackOverflow > Uses recursive reflection attempting to provoke stack overflow > Can go under: runtime/reflect > WideStrictInline: > checks for correct FP inlining by the interpreter > I could not find existing sections; perhaps create 'interpreter' > folder under 'runtime' > > Thank you, > Misha >> >> Since we plan (as discussed) to follow up this work with an RFE to review and consider removal of old and >> not-that-useful tests, you could place them under 'misc' for now. Alternatively, find the best match >> or create new sub-directories under runtime/ if necessary. >> >> >> Thank you, >> Misha >> >> >> On 2/21/19 11:53 AM, Igor Ignatyev wrote: >>> >>>> On Feb 21, 2019, at 12:11 AM, David Holmes wrote: >>>> >>>> Hi Igor, >>>> >>>> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>>>> Hi all, >>>>> could you please review this small patch which moves tests from test/jdk/vm? >>>> I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! >>> as I wrote in another related email: "one of the reason I'm proposing this move is exactly questionable value of these tests, I want to believe that having these tests in hotspot/ test directories will bring more attention to them from corresponding component teams and hence they will be removed/reworked/re-whatever faster and better. and I also believe that one of the reason we got duplications exactly because these tests were located in jdk test suite." >>> >>>> BTW: >>>> >>>> test/hotspot/jtreg/runtime/ShiftTest.java >>>> >>>> is actually a jit test according to the test comment. >>> sure, I will move it to hotspot/compiler. >>>>> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test >>>> No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. >>> this is actually was my first reaction, and I even have the webrev which moves it to runtime/jni, but then I looked at the associated bug and it is filed against tools/launcher. and I even got a false (as I know by now) memory that I saw JLI_ method being called from the test. there is actually another test (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. >>> >>>> I really think the value of these tests needs to be examined before they are brought over. >>> I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep jdk/vm directory the more tests can end up there and the more rotten these tests become. >>> >>> Thanks, >>> -- Igor >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>>>> testing: tier[1-2] (in progress), all the touched tests locally >>>>> Thanks, >>>>> -- Igor From mikhailo.seledtsov at oracle.com Thu Mar 14 22:53:07 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Thu, 14 Mar 2019 15:53:07 -0700 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <726FFE91-7F8C-46F6-9DE9-A112F5C5C17B@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> <511d81a3-847c-49d0-76ff-fdc836211f37@oracle.com> <726FFE91-7F8C-46F6-9DE9-A112F5C5C17B@oracle.com> Message-ID: <3bd885b4-1e50-dbb4-10f2-31e4b274354b@oracle.com> Looks good to me, Thank you, Misha On 3/14/19 2:38 PM, Igor Ignatyev wrote: > Hi Misha, > > thanks for your suggestions, I have moved all runtime tests into > subdirectories. here is the updated webrev: > http://cr.openjdk.java.net/~iignatyev//8219139/webrev.01/index.html > > > Thanks, > -- Igor > >> On Mar 4, 2019, at 1:57 PM, mikhailo.seledtsov at oracle.com >> wrote: >> >> Hi Igor, >> >> ? Sorry it took a while to get back to you on this one. See my >> comment below >> >> >> On 2/22/19 10:35 AM,mikhailo.seledtsov at oracle.com >> wrote: >>> Overall the change looks good; thank you Igor for doing this. I have >>> couple of comments: >>> >>> - I am in favor of the approach where we move tests first under >>> corresponding sub-component directories in >>> test/hotspot sub-tree, and then figure out whether to keep them. >>> Even though in general I am in favor >>> of removing tests that are obsolete or of questionable value, this >>> requires time, consideration and discussions. >>> Hence, I recommend filing an RFE for that, which can be addressed >>> after the migration. >>> >>> - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime >>> The tests should go into underlying sub-directories which best match >>> functional area or topic of that test. >>> In most cases you did it in your change, but there are several tests >>> that your change places directly under >>> test/hotspot/jtreg/runtime/: >>> >>> ExplicitArithmeticCheck.java >>> MonitorCacheMaybeExpand_DeadLock.java >>> ReflectStackOverflow.java >>> ShiftTest.java - David commented this can go under compiler (a jit test) >>> WideStrictInline.java >> I have looked at the tests in more detail, and here are my >> recommendation of placements: >> ??? ExplicitArithmeticCheck >> ??????? This test checks that ArithmeticException is thrown when >> appropriate >> ??????? I would recommend placing it under runtime/ErrorHandling >> MonitorCacheMaybeExpand_DeadLock >> ??????? Existing folder: runtime/Thread (it does have a locking test) >> ??????? Or, alternatively, create a new folder: 'locking' or 'monitors' >> ??? ReflectStackOverflow >> ??????? Uses recursive reflection attempting to provoke stack overflow >> ??????? Can go under: runtime/reflect >> ??? WideStrictInline: >> ??????? checks for correct FP inlining by the interpreter >> ??????? I could not find existing sections; perhaps create 'interpreter' >> ??????? folder under 'runtime' >> >> Thank you, >> Misha >>> >>> Since we plan (as discussed) to follow up this work with an RFE to >>> review and consider removal of old and >>> not-that-useful tests, you could place them under 'misc' for now. >>> Alternatively, find the best match >>> or create new sub-directories under runtime/ if necessary. >>> >>> >>> Thank you, >>> Misha >>> >>> >>> On 2/21/19 11:53 AM, Igor Ignatyev wrote: >>>> >>>>> On Feb 21, 2019, at 12:11 AM, David Holmes >>>>> > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>> >>>>>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>>>>> Hi all, >>>>>> could you please review this small patch which moves tests from >>>>>> test/jdk/vm? >>>>> I find some of these tests - the runtime ones at least - of >>>>> extremely dubious value. They either cover basic functionality >>>>> that is already well covered, or are regression tests for bugs in >>>>> code that hasn't existed for many many years! >>>> as I wrote in another related email: "one of the reason I'm >>>> proposing this move is exactly questionable value of these tests, I >>>> want to believe that having these tests in hotspot/ test >>>> directories will bring more attention to them from corresponding >>>> component teams and hence they will be removed/reworked/re-whatever >>>> faster and better. and I also believe that one of the reason we got >>>> duplications exactly because these tests were located in jdk test >>>> suite." >>>> >>>>> BTW: >>>>> >>>>> test/hotspot/jtreg/runtime/ShiftTest.java >>>>> >>>>> is actually a jit test according to the test comment. >>>> sure, I will move it to hotspot/compiler. >>>>>> there are 16 tests in test/jdk/vm directory. all but >>>>>> JniInvocationTest are hotspot tests, so they are moved to >>>>>> test/hotspot test suite; JniInvocationTest is a launcher test >>>>> No its a JNI invocation API test - nothing to do with our >>>>> launcher. It belongs in runtime/jni. But we already have tests in >>>>> runtime that use the JNI invocation API so this test adds no new >>>>> coverage. >>>> this is actually was my first reaction, and I even have the webrev >>>> which moves it to runtime/jni, but then I looked at the associated >>>> bug and it is filed against tools/launcher. and I even got a false >>>> (as I know by now) memory that I saw JLI_ method being called from >>>> the test. there is actually another test >>>> (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which >>>> calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. >>>> >>>>> I really think the value of these tests needs to be examined >>>>> before they are brought over. >>>> I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep >>>> jdk/vm directory the more tests can end up there and the more >>>> rotten these tests become. >>>> >>>> Thanks, >>>> -- Igor >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> and hence it's moved to test/jdk/tools/launcher. as >>>>>> hotspot/compiler and hotspot/gc tests use packages, the tests >>>>>> moved there have been updated to have a package statement. >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>>>>> testing: tier[1-2] (in progress), all the touched tests locally >>>>>> Thanks, >>>>>> -- Igor > From scolebourne at joda.org Thu Mar 14 23:16:47 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 14 Mar 2019 23:16:47 +0000 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <73C33352-5499-4AD3-81D6-83C15CAD74AF@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> <73C33352-5499-4AD3-81D6-83C15CAD74AF@oracle.com> Message-ID: On Thu, 14 Mar 2019 at 19:45, Brian Goetz wrote: > Why not make `Iterator` implement `IterableOnce`? The default method > would obviously just return `this`. > > Such a default would not conform to the contract, as IO requires that subsequent calls throw. IterableOnce.wrap(iterator) ? Not providing some kind of connection between these types will look pretty silly I think. Stephen From igor.ignatyev at oracle.com Thu Mar 14 23:49:47 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 14 Mar 2019 16:49:47 -0700 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <3bd885b4-1e50-dbb4-10f2-31e4b274354b@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> <511d81a3-847c-49d0-76ff-fdc836211f37@oracle.com> <726FFE91-7F8C-46F6-9DE9-A112F5C5C17B@oracle.com> <3bd885b4-1e50-dbb4-10f2-31e4b274354b@oracle.com> Message-ID: Thanks for the review Misha. can I get a LGTM from a Reviewer? -- Igor > On Mar 14, 2019, at 3:53 PM, mikhailo.seledtsov at oracle.com wrote: > > Looks good to me, > > Thank you, > > Misha > > > On 3/14/19 2:38 PM, Igor Ignatyev wrote: >> Hi Misha, >> >> thanks for your suggestions, I have moved all runtime tests into subdirectories. here is the updated webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.01/index.html >> >> Thanks, >> -- Igor >> >>> On Mar 4, 2019, at 1:57 PM, mikhailo.seledtsov at oracle.com wrote: >>> >>> Hi Igor, >>> >>> Sorry it took a while to get back to you on this one. See my comment below >>> >>> >>> On 2/22/19 10:35 AM, mikhailo.seledtsov at oracle.com wrote: >>>> Overall the change looks good; thank you Igor for doing this. I have couple of comments: >>>> >>>> - I am in favor of the approach where we move tests first under corresponding sub-component directories in >>>> test/hotspot sub-tree, and then figure out whether to keep them. Even though in general I am in favor >>>> of removing tests that are obsolete or of questionable value, this requires time, consideration and discussions. >>>> Hence, I recommend filing an RFE for that, which can be addressed after the migration. >>>> >>>> - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime >>>> The tests should go into underlying sub-directories which best match functional area or topic of that test. >>>> In most cases you did it in your change, but there are several tests that your change places directly under >>>> test/hotspot/jtreg/runtime/: >>>> >>>> ExplicitArithmeticCheck.java >>>> MonitorCacheMaybeExpand_DeadLock.java >>>> ReflectStackOverflow.java >>>> ShiftTest.java - David commented this can go under compiler (a jit test) >>>> WideStrictInline.java >>> I have looked at the tests in more detail, and here are my recommendation of placements: >>> ExplicitArithmeticCheck >>> This test checks that ArithmeticException is thrown when appropriate >>> I would recommend placing it under runtime/ErrorHandling >>> MonitorCacheMaybeExpand_DeadLock >>> Existing folder: runtime/Thread (it does have a locking test) >>> Or, alternatively, create a new folder: 'locking' or 'monitors' >>> ReflectStackOverflow >>> Uses recursive reflection attempting to provoke stack overflow >>> Can go under: runtime/reflect >>> WideStrictInline: >>> checks for correct FP inlining by the interpreter >>> I could not find existing sections; perhaps create 'interpreter' >>> folder under 'runtime' >>> >>> Thank you, >>> Misha >>>> >>>> Since we plan (as discussed) to follow up this work with an RFE to review and consider removal of old and >>>> not-that-useful tests, you could place them under 'misc' for now. Alternatively, find the best match >>>> or create new sub-directories under runtime/ if necessary. >>>> >>>> >>>> Thank you, >>>> Misha >>>> >>>> >>>> On 2/21/19 11:53 AM, Igor Ignatyev wrote: >>>>> >>>>>> On Feb 21, 2019, at 12:11 AM, David Holmes > wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>>>>>> Hi all, >>>>>>> could you please review this small patch which moves tests from test/jdk/vm? >>>>>> I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! >>>>> as I wrote in another related email: "one of the reason I'm proposing this move is exactly questionable value of these tests, I want to believe that having these tests in hotspot/ test directories will bring more attention to them from corresponding component teams and hence they will be removed/reworked/re-whatever faster and better. and I also believe that one of the reason we got duplications exactly because these tests were located in jdk test suite." >>>>> >>>>>> BTW: >>>>>> >>>>>> test/hotspot/jtreg/runtime/ShiftTest.java >>>>>> >>>>>> is actually a jit test according to the test comment. >>>>> sure, I will move it to hotspot/compiler. >>>>>>> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test >>>>>> No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. >>>>> this is actually was my first reaction, and I even have the webrev which moves it to runtime/jni, but then I looked at the associated bug and it is filed against tools/launcher. and I even got a false (as I know by now) memory that I saw JLI_ method being called from the test. there is actually another test (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. >>>>> >>>>>> I really think the value of these tests needs to be examined before they are brought over. >>>>> I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep jdk/vm directory the more tests can end up there and the more rotten these tests become. >>>>> >>>>> Thanks, >>>>> -- Igor >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>>>>>> testing: tier[1-2] (in progress), all the touched tests locally >>>>>>> Thanks, >>>>>>> -- Igor >> > From david.holmes at oracle.com Thu Mar 14 23:48:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 09:48:03 +1000 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) In-Reply-To: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> References: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> Message-ID: <3db67b6a-a125-60a6-9b95-ba3ae096dac4@oracle.com> Hi Ivan, This is an "ancient" bug that you are fixing. I don't think it is valid. On 15/03/2019 3:29 am, Ivan Gerasimov wrote: > Hello! > > Not all the man pages agree that chmod, access and statvfs64 can be > interrupted, but at least on some platforms they are allowed to fail > with EINTR:? chmod(2) on MacOS, access(2) on Solaris and statvfs(3) on > Linux. > > So, it would be more accurate to wrap these up into a RESTARTABLE loop. When Java threads are created, or native threads attach to the VM to become Java threads, they all get a very specific signal-mask to block most (non synchronous) signals. The signals that we install handlers for in the VM are also configured with SA_RESTART. So unless specifically specified as not honouring SA_RESTART we should not need the RESTARTABLE loop. So I'm not clear exactly what signals we need to be guarding against here, or whether this indicates some kind of (historic) mismatch between the library and VM code? Thanks, David ----- > Also, java_io_UnixFileSystem_list was tiny-optimized to avoid > unnecessary reallocation. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456 > WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/ > > Thanks in advance! > From david.holmes at oracle.com Fri Mar 15 00:28:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 10:28:51 +1000 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> Message-ID: <8aeed742-f71a-d727-8558-517694e73827@oracle.com> Hi Ivan, On 15/03/2019 5:49 am, Ivan Gerasimov wrote: > Hello! > > The default implementation of Process.waitFor(long, TimeUnit) does not > check if the process has exited after the last portion of the timeout > has expired. Please clarify. There is always a race between detecting a timeout and the process actually terminating. If the process actually terminates while you're deciding to report a timeout that seems just an acceptable possibility. No matter what you do the process could terminate just after you decided to report the timeout. David ----- > JDK has two implementations of Process (for Unix and Windows) and they > both override waitFor(), so it's not an issue for them. > > Still, it is better to provide a more accurate default implementation. > > I'm not quite certain the regression test needs to be included in the > fix.? The test does demonstrate the issue with the unfixed JDK and > passed Okay on all tested platforms in Mach5.? Yet, I suspect the test > can still show false negative results, as there are no guaranties that > even such simple application as `true` will finish in 100 ms. > I can tag the test as @ignored with a comment, or simply remove it from > the fix. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 > WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ > > Thanks in advance for reviewing! > From david.holmes at oracle.com Fri Mar 15 00:44:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 10:44:17 +1000 Subject: RFR: Container Fixes (8219652, 8217766, 8212528) In-Reply-To: References: Message-ID: <6374f859-cd79-764b-7331-072ff5595340@oracle.com> Hi Bob, Sorry I took a look but can't really review it in detail as I don't know any of the cgroup details. Not sure who may ... perhaps Misha (cc'd). On 15/03/2019 12:15 am, Bob Vandette wrote: > Ping ... > > > Please review these three fixes for Linux Docker/cgroup container support. > > WEBREV: > > http://cr.openjdk.java.net/~bobv/8217766/webrev.0 src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java The copyright update should have been from: * Copyright (c) 2018, Oracle to * Copyright (c) 2018, 2019, Oracle David ----- > ISSUE1: > > https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in osContainer_linux.cpp#L102 appears unreachable > > This change corrects a rarely used hotspot code path making it compatible with the Java based Metrics. > > ISSUE2: > > https://bugs.openjdk.java.net/browse/JDK-8212528 - Wrong cgroup subsystem being used for some CPU Container Metrics > > Most Linux distros provide symbolic links for cpuacct and cpu controller directories. Docker on the Mac does not. > This causes some of the cpu statistics to be unreported since the directory name was incorrect. > > ISSUE3: > > https://bugs.openjdk.java.net/browse/JDK-8217766 - Container Support doesn't work for some Join Controllers combinations > > The cgroup identification -implemented by parsing /proc/self/mountinfo > and /proc/self/cgroup- assumed each cgroup controller was mounted > disjoint from the others (except for "cpu" and "cpuacct" controllers). > Which means, we expected one single controller per mountinfo line. > > This matches the way most Linux distributions currently configure > cgroupsv1 by default. Yet controllers can be grouped arbitrarily. > For instance, using the JoinControllers systemd directive. > One use case for that is to let Kubernetes' kubelet discover his own > dedicated and reserved cgroup hierarchy. In that situation, the JVM > fails to discover the expected cgroup controllers set, and, when running > containerized, default to a suboptimal understanding of available resources. > > Supporting arbitrarily controllers groups per mountpoint actually > allows for simpler and easier to follow code, as we don't need nested > if/else for every controller. > > This fix also updates the Containers Metrics, to support joint controllers. > > > Bob. > From david.holmes at oracle.com Fri Mar 15 01:18:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 11:18:12 +1000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <726FFE91-7F8C-46F6-9DE9-A112F5C5C17B@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> <511d81a3-847c-49d0-76ff-fdc836211f37@oracle.com> <726FFE91-7F8C-46F6-9DE9-A112F5C5C17B@oracle.com> Message-ID: <96d6b416-f9cb-9c44-922a-dda93fd50cce@oracle.com> Hi Igor, This all seems fine to me. Thanks, David On 15/03/2019 7:38 am, Igor Ignatyev wrote: > Hi Misha, > > thanks for your suggestions, I have moved all runtime tests into > subdirectories. here is the updated webrev: > http://cr.openjdk.java.net/~iignatyev//8219139/webrev.01/index.html > > Thanks, > -- Igor > >> On Mar 4, 2019, at 1:57 PM, mikhailo.seledtsov at oracle.com >> wrote: >> >> Hi Igor, >> >> ? Sorry it took a while to get back to you on this one. See my comment >> below >> >> >> On 2/22/19 10:35 AM,mikhailo.seledtsov at oracle.com >> wrote: >>> Overall the change looks good; thank you Igor for doing this. I have >>> couple of comments: >>> >>> - I am in favor of the approach where we move tests first under >>> corresponding sub-component directories in >>> test/hotspot sub-tree, and then figure out whether to keep them. Even >>> though in general I am in favor >>> of removing tests that are obsolete or of questionable value, this >>> requires time, consideration and discussions. >>> Hence, I recommend filing an RFE for that, which can be addressed >>> after the migration. >>> >>> - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime >>> The tests should go into underlying sub-directories which best match >>> functional area or topic of that test. >>> In most cases you did it in your change, but there are several tests >>> that your change places directly under >>> test/hotspot/jtreg/runtime/: >>> >>> ExplicitArithmeticCheck.java >>> MonitorCacheMaybeExpand_DeadLock.java >>> ReflectStackOverflow.java >>> ShiftTest.java - David commented this can go under compiler (a jit test) >>> WideStrictInline.java >> I have looked at the tests in more detail, and here are my >> recommendation of placements: >> ??? ExplicitArithmeticCheck >> ??????? This test checks that ArithmeticException is thrown when >> appropriate >> ??????? I would recommend placing it under runtime/ErrorHandling >> ??? MonitorCacheMaybeExpand_DeadLock >> ??????? Existing folder: runtime/Thread (it does have a locking test) >> ??????? Or, alternatively, create a new folder: 'locking' or 'monitors' >> ??? ReflectStackOverflow >> ??????? Uses recursive reflection attempting to provoke stack overflow >> ??????? Can go under: runtime/reflect >> ??? WideStrictInline: >> ??????? checks for correct FP inlining by the interpreter >> ??????? I could not find existing sections; perhaps create 'interpreter' >> ??????? folder under 'runtime' >> >> Thank you, >> Misha >>> >>> Since we plan (as discussed) to follow up this work with an RFE to >>> review and consider removal of old and >>> not-that-useful tests, you could place them under 'misc' for now. >>> Alternatively, find the best match >>> or create new sub-directories under runtime/ if necessary. >>> >>> >>> Thank you, >>> Misha >>> >>> >>> On 2/21/19 11:53 AM, Igor Ignatyev wrote: >>>> >>>>> On Feb 21, 2019, at 12:11 AM, David Holmes >>>> > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>>>>> Hi all, >>>>>> could you please review this small patch which moves tests from >>>>>> test/jdk/vm? >>>>> I find some of these tests - the runtime ones at least - of >>>>> extremely dubious value. They either cover basic functionality that >>>>> is already well covered, or are regression tests for bugs in code >>>>> that hasn't existed for many many years! >>>> as I wrote in another related email: "one of the reason I'm >>>> proposing this move is exactly questionable value of these tests, I >>>> want to believe that having these tests in hotspot/ test directories >>>> will bring more attention to them from corresponding component teams >>>> and hence they will be removed/reworked/re-whatever faster and >>>> better. and I also believe that one of the reason we got >>>> duplications exactly because these tests were located in jdk test >>>> suite." >>>> >>>>> BTW: >>>>> >>>>> test/hotspot/jtreg/runtime/ShiftTest.java >>>>> >>>>> is actually a jit test according to the test comment. >>>> sure, I will move it to hotspot/compiler. >>>>>> there are 16 tests in test/jdk/vm directory. all but >>>>>> JniInvocationTest are hotspot tests, so they are moved to >>>>>> test/hotspot test suite; JniInvocationTest is a launcher test >>>>> No its a JNI invocation API test - nothing to do with our launcher. >>>>> It belongs in runtime/jni. But we already have tests in runtime >>>>> that use the JNI invocation API so this test adds no new coverage. >>>> this is actually was my first reaction, and I even have the webrev >>>> which moves it to runtime/jni, but then I looked at the associated >>>> bug and it is filed against tools/launcher. and I even got a false >>>> (as I know by now) memory that I saw JLI_ method being called from >>>> the test. there is actually another test >>>> (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which >>>> calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. >>>> >>>>> I really think the value of these tests needs to be examined before >>>>> they are brought over. >>>> I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep >>>> jdk/vm directory the more tests can end up there and the more rotten >>>> these tests become. >>>> >>>> Thanks, >>>> -- Igor >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> and hence it's moved to test/jdk/tools/launcher. as >>>>>> hotspot/compiler and hotspot/gc tests use packages, the tests >>>>>> moved there have been updated to have a package statement. >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>>>>> testing: tier[1-2] (in progress), all the touched tests locally >>>>>> Thanks, >>>>>> -- Igor > From ivan.gerasimov at oracle.com Fri Mar 15 01:42:33 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Mar 2019 18:42:33 -0700 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) In-Reply-To: <3db67b6a-a125-60a6-9b95-ba3ae096dac4@oracle.com> References: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> <3db67b6a-a125-60a6-9b95-ba3ae096dac4@oracle.com> Message-ID: <33d2cb26-3a3d-4268-f1b0-4396cbfe3923@oracle.com> Thank you David! On 3/14/19 4:48 PM, David Holmes wrote: > Hi Ivan, > > This is an "ancient" bug that you are fixing. I don't think it is valid. > > On 15/03/2019 3:29 am, Ivan Gerasimov wrote: >> Hello! >> >> Not all the man pages agree that chmod, access and statvfs64 can be >> interrupted, but at least on some platforms they are allowed to fail >> with EINTR: chmod(2) on MacOS, access(2) on Solaris and statvfs(3) >> on Linux. >> >> So, it would be more accurate to wrap these up into a RESTARTABLE loop. > > When Java threads are created, or native threads attach to the VM to > become Java threads, they all get a very specific signal-mask to block > most (non synchronous) signals. The signals that we install handlers > for in the VM are also configured with SA_RESTART. So unless > specifically specified as not honouring SA_RESTART we should not need > the RESTARTABLE loop. > > But isn't it possible to install a custom signal handler through JNI, omitting SA_RESTART flag? > > So I'm not clear exactly what signals we need to be guarding against > here, or whether this indicates some kind of (historic) mismatch > between the library and VM code? > grep shows that RESTARTABLE macro and its variants are used throughout hotspot and jdk code. If it were possible to guarantee that no syscalls are ever interrupted, it would surely be much cleaner to remove all these wrappers and loops. With kind regards, Ivan > Thanks, > David > ----- > >> Also, java_io_UnixFileSystem_list was tiny-optimized to avoid >> unnecessary reallocation. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456 >> WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/ >> >> Thanks in advance! >> > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Fri Mar 15 02:02:11 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Mar 2019 19:02:11 -0700 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <8aeed742-f71a-d727-8558-517694e73827@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> Message-ID: <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> Hi David! On 3/14/19 5:28 PM, David Holmes wrote: > Hi Ivan, > > On 15/03/2019 5:49 am, Ivan Gerasimov wrote: >> Hello! >> >> The default implementation of Process.waitFor(long, TimeUnit) does >> not check if the process has exited after the last portion of the >> timeout has expired. > > Please clarify. There is always a race between detecting a timeout and > the process actually terminating. If the process actually terminates > while you're deciding to report a timeout that seems just an > acceptable possibility. No matter what you do the process could > terminate just after you decided to report the timeout. > > Current code for waitFor(...) is 212 do { 213 try { 214 exitValue(); 215 return true; 216 } catch(IllegalThreadStateException ex) { 217 if (rem > 0) 218 Thread.sleep( 219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); 220 } 221 rem = unit.toNanos(timeout) - (System.nanoTime() - startTime); 222 } while (rem > 0); 223 return false; So, if the loop has just processed the last 100 ms portion of the timeout, it ends right away, without checking if the process has exited during this period. Not a big deal of course, but it is more accurate to check if the process has exited at the *end* of the specified timeout, and not 100 milliseconds before the end. With kind regards, Ivan > > David > ----- > >> JDK has two implementations of Process (for Unix and Windows) and >> they both override waitFor(), so it's not an issue for them. >> >> Still, it is better to provide a more accurate default implementation. >> >> I'm not quite certain the regression test needs to be included in the >> fix. The test does demonstrate the issue with the unfixed JDK and >> passed Okay on all tested platforms in Mach5. Yet, I suspect the test >> can still show false negative results, as there are no guaranties >> that even such simple application as `true` will finish in 100 ms. >> I can tag the test as @ignored with a comment, or simply remove it >> from the fix. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >> >> Thanks in advance for reviewing! >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri Mar 15 06:01:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 16:01:50 +1000 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> Message-ID: <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> Hi Ivan, On 15/03/2019 12:02 pm, Ivan Gerasimov wrote: > Hi David! > > > On 3/14/19 5:28 PM, David Holmes wrote: >> Hi Ivan, >> >> On 15/03/2019 5:49 am, Ivan Gerasimov wrote: >>> Hello! >>> >>> The default implementation of Process.waitFor(long, TimeUnit) does >>> not check if the process has exited after the last portion of the >>> timeout has expired. >> >> Please clarify. There is always a race between detecting a timeout and >> the process actually terminating. If the process actually terminates >> while you're deciding to report a timeout that seems just? an >> acceptable possibility. No matter what you do the process could >> terminate just after you decided to report the timeout. >> >> > Current code for waitFor(...) is > > ?212???????? do { > ?213???????????? try { > ?214???????????????? exitValue(); > ?215???????????????? return true; > ?216???????????? } catch(IllegalThreadStateException ex) { > ?217???????????????? if (rem > 0) > ?218???????????????????? Thread.sleep( > ?219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); > ?220???????????? } > ?221???????????? rem = unit.toNanos(timeout) - (System.nanoTime() - > startTime); > ?222???????? } while (rem > 0); > ?223???????? return false; > > So, if the loop has just processed the last 100 ms portion of the > timeout, it ends right away, without checking if the process has exited > during this period. Ah I see. Yes there should be a final check after what will be the last sleep. > Not a big deal of course, but it is more accurate to check if the > process has exited at the *end* of the specified timeout, and not 100 > milliseconds before the end. Agreed. I share Pavel's concern about the implicit overflow in calculating a deadline, rather than comparing elapsed time with the timeout. There has been some effort in core-libs to remove assumptions about how overflows are handled. Thanks, David ----- > With kind regards, > Ivan > >> >> David >> ----- >> >>> JDK has two implementations of Process (for Unix and Windows) and >>> they both override waitFor(), so it's not an issue for them. >>> >>> Still, it is better to provide a more accurate default implementation. >>> >>> I'm not quite certain the regression test needs to be included in the >>> fix.? The test does demonstrate the issue with the unfixed JDK and >>> passed Okay on all tested platforms in Mach5. Yet, I suspect the test >>> can still show false negative results, as there are no guaranties >>> that even such simple application as `true` will finish in 100 ms. >>> I can tag the test as @ignored with a comment, or simply remove it >>> from the fix. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >>> >>> Thanks in advance for reviewing! >>> >> > From david.holmes at oracle.com Fri Mar 15 06:43:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 16:43:11 +1000 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) In-Reply-To: <33d2cb26-3a3d-4268-f1b0-4396cbfe3923@oracle.com> References: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> <3db67b6a-a125-60a6-9b95-ba3ae096dac4@oracle.com> <33d2cb26-3a3d-4268-f1b0-4396cbfe3923@oracle.com> Message-ID: <8d15b2a7-147d-9438-8959-882a1de1355f@oracle.com> Hi Ivan, On 15/03/2019 11:42 am, Ivan Gerasimov wrote: > Thank you David! > > > On 3/14/19 4:48 PM, David Holmes wrote: >> Hi Ivan, >> >> This is an "ancient" bug that you are fixing. I don't think it is valid. >> >> On 15/03/2019 3:29 am, Ivan Gerasimov wrote: >>> Hello! >>> >>> Not all the man pages agree that chmod, access and statvfs64 can be >>> interrupted, but at least on some platforms they are allowed to fail >>> with EINTR:? chmod(2) on MacOS, access(2) on Solaris and statvfs(3) >>> on Linux. >>> >>> So, it would be more accurate to wrap these up into a RESTARTABLE loop. >> >> When Java threads are created, or native threads attach to the VM to >> become Java threads, they all get a very specific signal-mask to block >> most (non synchronous) signals. The signals that we install handlers >> for in the VM are also configured with SA_RESTART. So unless >> specifically specified as not honouring SA_RESTART we should not need >> the RESTARTABLE loop. >> >> > But isn't it possible to install a custom signal handler through JNI, > omitting SA_RESTART flag? It's possible - then you also have to update signal masks. But yes possible. >> >> So I'm not clear exactly what signals we need to be guarding against >> here, or whether this indicates some kind of (historic) mismatch >> between the library and VM code? >> > grep shows that RESTARTABLE macro and its variants are used throughout > hotspot and jdk code. Yes and on closer examination you will find a lot of inconsistencies. RESTARTABLE goes back a long way and many of the I/O APIs have switched locations over the years. Stuff was copied from the HPI layer into hotspot, then back to the JDK and sometimes things were copied with RESTARTABLE and sometimes not; and sometimes ports were written that copied RESTARTABLE and sometimes not; and sometime new APIs were added that were RESTARTABLE and sometimes not. All in all a bit of a mess. For example here are some uses of write in JDK libs: ./share/native/libzip/zlib/gzwrite.c: writ = write(state->fd, state->x.next, put); ./unix/native/libnio/ch/IOUtil.c: return convertReturnVal(env, write(fd, &c, 1), JNI_FALSE); ./unix/native/libnio/ch/FileDispatcherImpl.c: return convertReturnVal(env, write(fd, buf, len), JNI_FALSE); ./unix/native/libnio/fs/UnixCopyFile.c: RESTARTABLE(write((int)dst, bufp, len), n); ./unix/native/libnio/fs/UnixNativeDispatcher.c: RESTARTABLE(write((int)fd, bufp, (size_t)nbytes), n) ./unix/native/libjava/ProcessImpl_md.c: write(c->childenv[1], (char *)&magic, sizeof(magic)); // magic number first ./unix/native/libjava/io_util_md.c: RESTARTABLE(write(fd, buf, len), result); A mix of RESTARTABLE and not. > If it were possible to guarantee that no syscalls are ever interrupted, > it would surely be much cleaner to remove all these wrappers and loops. There is no guarantee as you note - someone could install their own handler for SIGUSR1 (not used by the VM) for example and not use SA_RESTART and cause unexpected EINTR. But that problem could arise today in many different places not just the couple you are changing here. So it comes down to a basic question of signal handling philosophy: do we expect/require SA_RESTART to always be used, or do we always guard against EINTR? The Go folk had a similar choice: https://github.com/golang/go/issues/20400 We're kind of in a messy undecided state. We use SA_RESTART ourselves but don't document its need for others to use, nor do we enforce its use even through libjsig (for signal chaining). We use RESTARTABLE in some places but not in others. So yeah feel free to make these changes, just realize they are only one part of a larger problem (if we intend to allow no SA_RESTART). Cheers, David > With kind regards, > Ivan > >> Thanks, >> David >> ----- >> >>> Also, java_io_UnixFileSystem_list was tiny-optimized to avoid >>> unnecessary reallocation. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/ >>> >>> Thanks in advance! >>> >> > From peter.levart at gmail.com Fri Mar 15 07:03:49 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 08:03:49 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <7df44bd0-68cb-c2c8-e9c7-557be6fa67a0@oracle.com> <80142c4a-38ba-596a-ae01-1bda9553450d@gmail.com> <92a9fe6b-4221-fb0d-8e5e-044441d53e4e@oracle.com> <73C33352-5499-4AD3-81D6-83C15CAD74AF@oracle.com> Message-ID: On 3/15/19 12:16 AM, Stephen Colebourne wrote: > On Thu, 14 Mar 2019 at 19:45, Brian Goetz wrote: >> Why not make `Iterator` implement `IterableOnce`? The default method >> would obviously just return `this`. >> >> Such a default would not conform to the contract, as IO requires that subsequent calls throw. > IterableOnce.wrap(iterator) ? > > Not providing some kind of connection between these types will look > pretty silly I think. > Stephen That makes sense, yes. As a utility method for adapting in situations where there's an unconsumed Iterator at hand and you have to provide a "well behaved" IterableOnce. I would call it IterableOnce.of(Iterator) as it does not really adapt the Iterator, but creates a factory with provided Iterator. Using this would be preferable to sprinkling ad-hoc expressions like: (IterableOnce) () -> iterator as such IterableOnce instances would not conform to the spec. Regards, Peter From ivan.gerasimov at oracle.com Fri Mar 15 07:03:01 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Mar 2019 00:03:01 -0700 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> Message-ID: <7b775c5a-93b6-8279-d7dd-90fcc3a5c621@oracle.com> Thank you David! On 3/14/19 11:01 PM, David Holmes wrote: > Hi Ivan, > > On 15/03/2019 12:02 pm, Ivan Gerasimov wrote: >> Hi David! >> >> >> On 3/14/19 5:28 PM, David Holmes wrote: >>> Hi Ivan, >>> >>> On 15/03/2019 5:49 am, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The default implementation of Process.waitFor(long, TimeUnit) does >>>> not check if the process has exited after the last portion of the >>>> timeout has expired. >>> >>> Please clarify. There is always a race between detecting a timeout >>> and the process actually terminating. If the process actually >>> terminates while you're deciding to report a timeout that seems >>> just an acceptable possibility. No matter what you do the process >>> could terminate just after you decided to report the timeout. >>> >>> >> Current code for waitFor(...) is >> >> 212 do { >> 213 try { >> 214 exitValue(); >> 215 return true; >> 216 } catch(IllegalThreadStateException ex) { >> 217 if (rem > 0) >> 218 Thread.sleep( >> 219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); >> 220 } >> 221 rem = unit.toNanos(timeout) - (System.nanoTime() - >> startTime); >> 222 } while (rem > 0); >> 223 return false; >> >> So, if the loop has just processed the last 100 ms portion of the >> timeout, it ends right away, without checking if the process has >> exited during this period. > > Ah I see. Yes there should be a final check after what will be the > last sleep. > >> Not a big deal of course, but it is more accurate to check if the >> process has exited at the *end* of the specified timeout, and not 100 >> milliseconds before the end. > > Agreed. > > I share Pavel's concern about the implicit overflow in calculating a > deadline, rather than comparing elapsed time with the timeout. There > has been some effort in core-libs to remove assumptions about how > overflows are handled. > We only check sign of the remainingNanos, which is initially strictly positive timeout. Over time it gets decreased by elapsed time. The elapsed time is the difference between System.nanoTime() measured at line 217 and 213, so it is always non-negative (well, strictly positive, as there's sleep in between). I don't really see a possibility of overflow for remainingNanos here. The deadline may overflow, and it is totally fine, as we don't care about its sign. Am I missing something? With kind regards, Ivan > Thanks, > David > ----- > >> With kind regards, >> Ivan >> >>> >>> David >>> ----- >>> >>>> JDK has two implementations of Process (for Unix and Windows) and >>>> they both override waitFor(), so it's not an issue for them. >>>> >>>> Still, it is better to provide a more accurate default implementation. >>>> >>>> I'm not quite certain the regression test needs to be included in >>>> the fix. The test does demonstrate the issue with the unfixed JDK >>>> and passed Okay on all tested platforms in Mach5. Yet, I suspect >>>> the test can still show false negative results, as there are no >>>> guaranties that even such simple application as `true` will finish >>>> in 100 ms. >>>> I can tag the test as @ignored with a comment, or simply remove it >>>> from the fix. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >>>> >>>> Thanks in advance for reviewing! >>>> >>> >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri Mar 15 07:16:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2019 17:16:21 +1000 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <7b775c5a-93b6-8279-d7dd-90fcc3a5c621@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> <7b775c5a-93b6-8279-d7dd-90fcc3a5c621@oracle.com> Message-ID: <750fd388-d857-9d2f-4549-b256cd6b2901@oracle.com> On 15/03/2019 5:03 pm, Ivan Gerasimov wrote: > Thank you David! > > > On 3/14/19 11:01 PM, David Holmes wrote: >> Hi Ivan, >> >> On 15/03/2019 12:02 pm, Ivan Gerasimov wrote: >>> Hi David! >>> >>> >>> On 3/14/19 5:28 PM, David Holmes wrote: >>>> Hi Ivan, >>>> >>>> On 15/03/2019 5:49 am, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> The default implementation of Process.waitFor(long, TimeUnit) does >>>>> not check if the process has exited after the last portion of the >>>>> timeout has expired. >>>> >>>> Please clarify. There is always a race between detecting a timeout >>>> and the process actually terminating. If the process actually >>>> terminates while you're deciding to report a timeout that seems >>>> just? an acceptable possibility. No matter what you do the process >>>> could terminate just after you decided to report the timeout. >>>> >>>> >>> Current code for waitFor(...) is >>> >>> ? 212???????? do { >>> ? 213???????????? try { >>> ? 214???????????????? exitValue(); >>> ? 215???????????????? return true; >>> ? 216???????????? } catch(IllegalThreadStateException ex) { >>> ? 217???????????????? if (rem > 0) >>> ? 218???????????????????? Thread.sleep( >>> ? 219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); >>> ? 220???????????? } >>> ? 221???????????? rem = unit.toNanos(timeout) - (System.nanoTime() - >>> startTime); >>> ? 222???????? } while (rem > 0); >>> ? 223???????? return false; >>> >>> So, if the loop has just processed the last 100 ms portion of the >>> timeout, it ends right away, without checking if the process has >>> exited during this period. >> >> Ah I see. Yes there should be a final check after what will be the >> last sleep. >> >>> Not a big deal of course, but it is more accurate to check if the >>> process has exited at the *end* of the specified timeout, and not 100 >>> milliseconds before the end. >> >> Agreed. >> >> I share Pavel's concern about the implicit overflow in calculating a >> deadline, rather than comparing elapsed time with the timeout. There >> has been some effort in core-libs to remove assumptions about how >> overflows are handled. >> > We only check sign of the remainingNanos, which is initially strictly > positive timeout.? Over time it gets decreased by elapsed time. > The elapsed time is the difference between System.nanoTime() measured at > line 217 and 213, so it is always non-negative (well, strictly positive, > as there's sleep in between). > > I don't really see a possibility of overflow for remainingNanos here. > > The deadline may overflow, and it is totally fine, as we don't care > about its sign. It's deadline that I was flagging. > Am I missing something? Just a code cleanliness issue. I had thought, but now can't find, these kinds of overflowing calculations were being cleaned up in core-libs. But perhaps I'm just mis-remembering. Cheers, David > > With kind regards, > Ivan > >> Thanks, >> David >> ----- >> >>> With kind regards, >>> Ivan >>> >>>> >>>> David >>>> ----- >>>> >>>>> JDK has two implementations of Process (for Unix and Windows) and >>>>> they both override waitFor(), so it's not an issue for them. >>>>> >>>>> Still, it is better to provide a more accurate default implementation. >>>>> >>>>> I'm not quite certain the regression test needs to be included in >>>>> the fix.? The test does demonstrate the issue with the unfixed JDK >>>>> and passed Okay on all tested platforms in Mach5. Yet, I suspect >>>>> the test can still show false negative results, as there are no >>>>> guaranties that even such simple application as `true` will finish >>>>> in 100 ms. >>>>> I can tag the test as @ignored with a comment, or simply remove it >>>>> from the fix. >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >>>>> >>>>> Thanks in advance for reviewing! >>>>> >>>> >>> >> > From ivan.gerasimov at oracle.com Fri Mar 15 07:37:53 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Mar 2019 00:37:53 -0700 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) In-Reply-To: <8d15b2a7-147d-9438-8959-882a1de1355f@oracle.com> References: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> <3db67b6a-a125-60a6-9b95-ba3ae096dac4@oracle.com> <33d2cb26-3a3d-4268-f1b0-4396cbfe3923@oracle.com> <8d15b2a7-147d-9438-8959-882a1de1355f@oracle.com> Message-ID: <98af6322-26cb-379a-0367-6a4bb1a26eab@oracle.com> Thank you David for the detailed analysis! I'm having an impression that the general direction has been to add the RESTARTABLE loops where sensible. (E.g. a recent fix for JDK-8197498, and lots of older similar bugs.) I understand that the fix only touches a small portion of potentially problematic syscalls. The intention was to cover UnixFileSystem_md.c and to close that ancient bug :) With kind regards, Ivan On 3/14/19 11:43 PM, David Holmes wrote: > Hi Ivan, > > On 15/03/2019 11:42 am, Ivan Gerasimov wrote: >> Thank you David! >> >> >> On 3/14/19 4:48 PM, David Holmes wrote: >>> Hi Ivan, >>> >>> This is an "ancient" bug that you are fixing. I don't think it is >>> valid. >>> >>> On 15/03/2019 3:29 am, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Not all the man pages agree that chmod, access and statvfs64 can be >>>> interrupted, but at least on some platforms they are allowed to >>>> fail with EINTR: chmod(2) on MacOS, access(2) on Solaris and >>>> statvfs(3) on Linux. >>>> >>>> So, it would be more accurate to wrap these up into a RESTARTABLE >>>> loop. >>> >>> When Java threads are created, or native threads attach to the VM to >>> become Java threads, they all get a very specific signal-mask to >>> block most (non synchronous) signals. The signals that we install >>> handlers for in the VM are also configured with SA_RESTART. So >>> unless specifically specified as not honouring SA_RESTART we should >>> not need the RESTARTABLE loop. >>> >>> >> But isn't it possible to install a custom signal handler through JNI, >> omitting SA_RESTART flag? > > It's possible - then you also have to update signal masks. But yes > possible. > >>> >>> So I'm not clear exactly what signals we need to be guarding against >>> here, or whether this indicates some kind of (historic) mismatch >>> between the library and VM code? >>> >> grep shows that RESTARTABLE macro and its variants are used >> throughout hotspot and jdk code. > > Yes and on closer examination you will find a lot of inconsistencies. > RESTARTABLE goes back a long way and many of the I/O APIs have > switched locations over the years. Stuff was copied from the HPI layer > into hotspot, then back to the JDK and sometimes things were copied > with RESTARTABLE and sometimes not; and sometimes ports were written > that copied RESTARTABLE and sometimes not; and sometime new APIs were > added that were RESTARTABLE and sometimes not. All in all a bit of a > mess. > > For example here are some uses of write in JDK libs: > > ./share/native/libzip/zlib/gzwrite.c: writ = > write(state->fd, state->x.next, put); > ./unix/native/libnio/ch/IOUtil.c: return convertReturnVal(env, > write(fd, &c, 1), JNI_FALSE); > ./unix/native/libnio/ch/FileDispatcherImpl.c: return > convertReturnVal(env, write(fd, buf, len), JNI_FALSE); > ./unix/native/libnio/fs/UnixCopyFile.c: RESTARTABLE(write((int)dst, > bufp, len), n); > ./unix/native/libnio/fs/UnixNativeDispatcher.c: > RESTARTABLE(write((int)fd, bufp, (size_t)nbytes), n) > ./unix/native/libjava/ProcessImpl_md.c: write(c->childenv[1], (char > *)&magic, sizeof(magic)); // magic number first > ./unix/native/libjava/io_util_md.c: RESTARTABLE(write(fd, buf, > len), result); > > A mix of RESTARTABLE and not. > >> If it were possible to guarantee that no syscalls are ever >> interrupted, it would surely be much cleaner to remove all these >> wrappers and loops. > > There is no guarantee as you note - someone could install their own > handler for SIGUSR1 (not used by the VM) for example and not use > SA_RESTART and cause unexpected EINTR. > > But that problem could arise today in many different places not just > the couple you are changing here. > > So it comes down to a basic question of signal handling philosophy: do > we expect/require SA_RESTART to always be used, or do we always guard > against EINTR? The Go folk had a similar choice: > > https://github.com/golang/go/issues/20400 > > We're kind of in a messy undecided state. We use SA_RESTART ourselves > but don't document its need for others to use, nor do we enforce its > use even through libjsig (for signal chaining). We use RESTARTABLE in > some places but not in others. > > So yeah feel free to make these changes, just realize they are only > one part of a larger problem (if we intend to allow no SA_RESTART). > > Cheers, > David > >> With kind regards, >> Ivan >> >>> Thanks, >>> David >>> ----- >>> >>>> Also, java_io_UnixFileSystem_list was tiny-optimized to avoid >>>> unnecessary reallocation. >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/ >>>> >>>> Thanks in advance! >>>> >>> >> > -- With kind regards, Ivan Gerasimov From peter.levart at gmail.com Fri Mar 15 07:57:10 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 08:57:10 +0100 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> Message-ID: <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> Hi, On 3/14/19 9:51 PM, Remi Forax wrote: > yes, i think i prefer this solution, one Iterable to rule them all. > > First, it's not in the spirit of the Collection API to multiply the interfaces, by example, we have only one kind of Iterator and not an Iterator and a ReadOnlyIterator even if a lot of iterators doesn't implement remove. It's a central design of the Collection API, reduce the number of interfaces to ease the use even if it means that each interface may have a broader definition. The Collection API design has chosen his side between users and library writers (people that provides implementations) because from the library writer point of view you can not specify exactly the semantics you want. > > Then from the user POV, what is point of IterableOnce ? I will not using it as parameter because using Iterable is a super-type (like i will use a List instead of an ArrayList as parameter) and if i using it as return type, codes that call that method can put it in an Iterable, this is exactly what the for-each-loop will do BTW, so it's seems useless. > > Also as Peter said, there are already codes in the wild that create an Iterable that can only be iterated once, ASM has such class, if IterableOnce is added to the JDK, i will have people ask me to retrofit the ASM class to use IterableOnce just for the sake of having the right semantics ? So basically by introducing IterableOnce, all codes that were perfectly fine in term of semantics before introducing IterableOnce are now not quite right because they are not implementing the right interface ? Hum, i think i still not get why we need such interface. > > R?mi The IterableOnce really does not have utility as a static type and I think it might only confuse some (Should I return IterableOnce here? Should I consume IterableOnce here? Many would not get the difference at first). So in this respect it would be better that there is no IterableOnce. But there is a runtime utility (although a marginal one) where the code can take two branches depending on iterable implementing IterableOnce or not. Similar to RandomAccess marker interface with List(s). So the question is whether this situation would be better served by introducing an unrelated marker interface instead of a subtype of Iterable? For example: /** ?* Implementing this interface allows an object to be the target of the enhanced ?* {@code for} statement (sometimes called the "for-each loop" statement). ?*

              ?* There are generally two kinds of {@code Iterable} implementations: ?*

                ?*
              • Those that allow ?* multiple calls to {@link #iterator()} each returning new instance which can ?* be used for independent iterations over elements. {@link java.util.Collection}s ?* are general representatives of this type of {@code Iterable}s. ?*
                • ?*
              • And those that allow only one call to {@link #iterator()}, providing a ?* single iteration and throwing {@link IllegalStateException} on 2nd and subsequent ?* calls. It is recommended that this kind of implementations also implement ?* {@link Once} marker interface to allow code to detect the kind of {@code Iterable} ?* during runtime. {@link java.util.stream.Stream} is an example implementation ?* of this type of {@code Iterable}. ?*
                • ?*
              ?* ?* @param the type of elements returned by the iterator ?* @jls 14.14.2 The enhanced {@code for} statement ?* @since 1.5 ?*/ public interface Iterable { ??? /** ???? * Marker interface used by {@code Iterable} implementations to indicate that ???? * they support only a single call to {@link #iterator()} method while 2nd and ???? * subsequent calls throw {@link IllegalStateException}. The primary ???? * purpose of this interface is to allow generic algorithms to alter their ???? * behavior if they need multiple passes over elements of {@link Iterable}. ???? * ???? * @since 13 ???? */ ??? interface Once {} What do you think of that? Regards, Peter From goetz.lindenmaier at sap.com Fri Mar 15 07:59:45 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Mar 2019 07:59:45 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> Message-ID: Hi Maurizio, > > I second what Mandy says. > > First let me start by saying that this enhancement will be a great > addition to our platform; back in the days when I was teaching some Java > classes at the university, I was very aware of how hard it is to > diagnose a NPE for someone novel to Java programming. A trained eye of > course can quickly scan the line where an exception occurs, and quickly > isolate the couple of problematic spots which could have caused an > exception. But it takes time to get to that point, and having some > helpful messages to help you to get to that point is, IMHO a valuable > goal in itself. Thanks! > I also think that the design space for such an enhancement is non > trivial, and would best be explored (and captured!) in a medium that is > something other than a patch. What kind of improvements should we add to > the NPE exception? What happens if the NPE already has an user-provided > details message? Should the enhancement make use of optional debugging > classfile attributes (you touch this in your nice RFE). And again, what > are the performance considerations we deem important for this work to be > declared successful? And, maintenance-wise, what is the right way to > implement the enhancement? Should we implement that as a pure VM > feature, should we implement it on top of the existing VM, using some > classfile manipulation (**) ? Or a combination of those? I'm working on a text... > As you can see, there are so many question this enhancement raises that > I think going straight for a code review can be a premature move; people > will be coming at the review table with different answers to the above > set of questions (and maybe additional questions too :-)), and that > could make the review process hard and frustrating for all the parties > involved. So I warmly suggest we take a step back from the code, and > formulate a proposal for enhancing NPE messages in Java; in this sense, > a JEP seems to me the most natural way to move forward. Well, I had the code around, so I started this enhancement just showing our code. I guess a prototype is always a good starting point. > (**) I have a quick and dirty prototype of that built using ASM which > I'm happy to share, in case you are interested taking a look when > evaluating alternatives. Yes, it would be nice if you shared that. Best regards, Goetz. > > Cheers > Maurizio > > > On 14/03/2019 00:42, Mandy Chung wrote: > > Hi Goetz, > > > > Roger, Coleen, Maurizio and I talked about this proposed feature. > > We all think that improving NPE message is a useful enhancement for > > the platform and helps developers to tell what causes NPE. > > > > This is not a small enhancement.? Diving into a large code review > > would not be the best way to move this forward as you can see the > > discussion so far. > > > > It would help if you can start with writing down the problem and > > the proposal like what improvements are proposed and under what > > circumstances may be acceptable that NPE message won't be improved. > > This would get the discussion on the proposal feature and then > > the discussion of the best way to to implement it in the VM, library, > > or combination.? You can consider using the JEP template that gives > > you a good structure to follow for the write up. > > > > What do you think? > > > > Mandy From forax at univ-mlv.fr Fri Mar 15 08:03:38 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 15 Mar 2019 09:03:38 +0100 (CET) Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> Message-ID: <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "Remi Forax" > Cc: "Brian Goetz" , "Stuart Marks" , "core-libs-dev" > > Envoy?: Vendredi 15 Mars 2019 08:57:10 > Objet: Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow > Streams > Hi, > > On 3/14/19 9:51 PM, Remi Forax wrote: >> yes, i think i prefer this solution, one Iterable to rule them all. >> >> First, it's not in the spirit of the Collection API to multiply the interfaces, >> by example, we have only one kind of Iterator and not an Iterator and a >> ReadOnlyIterator even if a lot of iterators doesn't implement remove. It's a >> central design of the Collection API, reduce the number of interfaces to ease >> the use even if it means that each interface may have a broader definition. The >> Collection API design has chosen his side between users and library writers >> (people that provides implementations) because from the library writer point of >> view you can not specify exactly the semantics you want. >> >> Then from the user POV, what is point of IterableOnce ? I will not using it as >> parameter because using Iterable is a super-type (like i will use a List >> instead of an ArrayList as parameter) and if i using it as return type, codes >> that call that method can put it in an Iterable, this is exactly what the >> for-each-loop will do BTW, so it's seems useless. >> >> Also as Peter said, there are already codes in the wild that create an Iterable >> that can only be iterated once, ASM has such class, if IterableOnce is added to >> the JDK, i will have people ask me to retrofit the ASM class to use >> IterableOnce just for the sake of having the right semantics ? So basically by >> introducing IterableOnce, all codes that were perfectly fine in term of >> semantics before introducing IterableOnce are now not quite right because they >> are not implementing the right interface ? Hum, i think i still not get why we >> need such interface. >> >> R?mi > > The IterableOnce really does not have utility as a static type and I > think it might only confuse some (Should I return IterableOnce here? > Should I consume IterableOnce here? Many would not get the difference at > first). So in this respect it would be better that there is no > IterableOnce. But there is a runtime utility (although a marginal one) > where the code can take two branches depending on iterable implementing > IterableOnce or not. Similar to RandomAccess marker interface with > List(s). So the question is whether this situation would be better > served by introducing an unrelated marker interface instead of a subtype > of Iterable? For example: > > > /** > ?* Implementing this interface allows an object to be the target of the > enhanced > ?* {@code for} statement (sometimes called the "for-each loop" statement). > ?*

              > ?* There are generally two kinds of {@code Iterable} implementations: > ?*

                > ?*
              • Those that allow > ?* multiple calls to {@link #iterator()} each returning new instance > which can > ?* be used for independent iterations over elements. {@link > java.util.Collection}s > ?* are general representatives of this type of {@code Iterable}s. > ?*
                • > ?*
              • And those that allow only one call to {@link #iterator()}, > providing a > ?* single iteration and throwing {@link IllegalStateException} on 2nd > and subsequent > ?* calls. It is recommended that this kind of implementations also > implement > ?* {@link Once} marker interface to allow code to detect the kind of > {@code Iterable} > ?* during runtime. {@link java.util.stream.Stream} is an example > implementation > ?* of this type of {@code Iterable}. > ?*
                • > ?*
              > ?* > ?* @param the type of elements returned by the iterator > ?* @jls 14.14.2 The enhanced {@code for} statement > ?* @since 1.5 > ?*/ > public interface Iterable { > > ??? /** > ???? * Marker interface used by {@code Iterable} implementations to > indicate that > ???? * they support only a single call to {@link #iterator()} method > while 2nd and > ???? * subsequent calls throw {@link IllegalStateException}. The primary > ???? * purpose of this interface is to allow generic algorithms to > alter their > ???? * behavior if they need multiple passes over elements of {@link > Iterable}. > ???? * > ???? * @since 13 > ???? */ > ??? interface Once {} > > > What do you think of that? It's not clear to me if an annotation, available at runtime, is not a better fit. Anyway, i'm not sure not sure introducing such interface/annotation worth its maintenance cost, as you said the use case is pretty narrow. > > Regards, Peter R?mi From ivan.gerasimov at oracle.com Fri Mar 15 08:08:38 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Mar 2019 01:08:38 -0700 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: <750fd388-d857-9d2f-4549-b256cd6b2901@oracle.com> References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> <7b775c5a-93b6-8279-d7dd-90fcc3a5c621@oracle.com> <750fd388-d857-9d2f-4549-b256cd6b2901@oracle.com> Message-ID: Hi David! The code could be written like following: long start = System.nanoTime(); do { ... long elapsed = System.nanoTime() - start; remainingNanos = timeoutNanos - elapsed; } while (remainingNanos > 0); but then one realizes that this always calculates (start + timeoutNanos), both of which are effectively final. So, the sum can be calculated in advance, and named, say, "deadline" :) With kind regards, Ivan On 3/15/19 12:16 AM, David Holmes wrote: > On 15/03/2019 5:03 pm, Ivan Gerasimov wrote: >> Thank you David! >> >> >> On 3/14/19 11:01 PM, David Holmes wrote: >>> Hi Ivan, >>> >>> On 15/03/2019 12:02 pm, Ivan Gerasimov wrote: >>>> Hi David! >>>> >>>> >>>> On 3/14/19 5:28 PM, David Holmes wrote: >>>>> Hi Ivan, >>>>> >>>>> On 15/03/2019 5:49 am, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> The default implementation of Process.waitFor(long, TimeUnit) >>>>>> does not check if the process has exited after the last portion >>>>>> of the timeout has expired. >>>>> >>>>> Please clarify. There is always a race between detecting a timeout >>>>> and the process actually terminating. If the process actually >>>>> terminates while you're deciding to report a timeout that seems >>>>> just an acceptable possibility. No matter what you do the process >>>>> could terminate just after you decided to report the timeout. >>>>> >>>>> >>>> Current code for waitFor(...) is >>>> >>>> 212 do { >>>> 213 try { >>>> 214 exitValue(); >>>> 215 return true; >>>> 216 } catch(IllegalThreadStateException ex) { >>>> 217 if (rem > 0) >>>> 218 Thread.sleep( >>>> 219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); >>>> 220 } >>>> 221 rem = unit.toNanos(timeout) - (System.nanoTime() >>>> - startTime); >>>> 222 } while (rem > 0); >>>> 223 return false; >>>> >>>> So, if the loop has just processed the last 100 ms portion of the >>>> timeout, it ends right away, without checking if the process has >>>> exited during this period. >>> >>> Ah I see. Yes there should be a final check after what will be the >>> last sleep. >>> >>>> Not a big deal of course, but it is more accurate to check if the >>>> process has exited at the *end* of the specified timeout, and not >>>> 100 milliseconds before the end. >>> >>> Agreed. >>> >>> I share Pavel's concern about the implicit overflow in calculating a >>> deadline, rather than comparing elapsed time with the timeout. There >>> has been some effort in core-libs to remove assumptions about how >>> overflows are handled. >>> >> We only check sign of the remainingNanos, which is initially strictly >> positive timeout. Over time it gets decreased by elapsed time. >> The elapsed time is the difference between System.nanoTime() measured >> at line 217 and 213, so it is always non-negative (well, strictly >> positive, as there's sleep in between). >> >> I don't really see a possibility of overflow for remainingNanos here. >> >> The deadline may overflow, and it is totally fine, as we don't care >> about its sign. > > It's deadline that I was flagging. > >> Am I missing something? > > Just a code cleanliness issue. I had thought, but now can't find, > these kinds of overflowing calculations were being cleaned up in > core-libs. But perhaps I'm just mis-remembering. > > Cheers, > David > >> >> With kind regards, >> Ivan >> >>> Thanks, >>> David >>> ----- >>> >>>> With kind regards, >>>> Ivan >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> JDK has two implementations of Process (for Unix and Windows) and >>>>>> they both override waitFor(), so it's not an issue for them. >>>>>> >>>>>> Still, it is better to provide a more accurate default >>>>>> implementation. >>>>>> >>>>>> I'm not quite certain the regression test needs to be included in >>>>>> the fix. The test does demonstrate the issue with the unfixed >>>>>> JDK and passed Okay on all tested platforms in Mach5. Yet, I >>>>>> suspect the test can still show false negative results, as there >>>>>> are no guaranties that even such simple application as `true` >>>>>> will finish in 100 ms. >>>>>> I can tag the test as @ignored with a comment, or simply remove >>>>>> it from the fix. >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >>>>>> >>>>>> Thanks in advance for reviewing! >>>>>> >>>>> >>>> >>> >> > -- With kind regards, Ivan Gerasimov From peter.levart at gmail.com Fri Mar 15 08:24:53 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 09:24:53 +0100 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> Message-ID: <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote: >> ???? * @since 13 >> ???? */ >> ??? interface Once {} >> >> >> What do you think of that? > It's not clear to me if an annotation, available at runtime, is not a better fit. > Anyway, i'm not sure not sure introducing such interface/annotation worth its maintenance cost, as you said the use case is pretty narrow. > It is narrow, but in a situation like that, where you want to code an optimal generic algorithm and all you have access to is an Iterable, there's no other way (short of providing additional methods, which is ugly). Just think of this situation. You have to decide upfront if you need to buffer the elements obtained from 1st iteration or not, but 1st iteration always succeeds... Annotations are not suitable for that as the check has to be quick and they don't play well with inheritance etc... Peter From peter.levart at gmail.com Fri Mar 15 08:31:10 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 09:31:10 +0100 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> Message-ID: On 3/15/19 9:24 AM, Peter Levart wrote: > > > On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote: >>> ???? * @since 13 >>> ???? */ >>> ??? interface Once {} >>> >>> >>> What do you think of that? >> It's not clear to me if an annotation, available at runtime, is not a better fit. >> Anyway, i'm not sure not sure introducing such interface/annotation worth its maintenance cost, as you said the use case is pretty narrow. >> > > It is narrow, but in a situation like that, where you want to code an > optimal generic algorithm and all you have access to is an Iterable, > there's no other way (short of providing additional methods, which is > ugly). Just think of this situation. You have to decide upfront if you > need to buffer the elements obtained from 1st iteration or not, but > 1st iteration always succeeds... Ok, I confess, there is a way to do it without marker interface, but is ugly: Iterator iterator1 = iterable.iterator(); Iterator iterator2; try { ?? iterator2 = iterable.iterator(); } catch (IllegalStateException e) { ??? // we have one-shot iterable ?? iterator2 = null; } if (iterator2 == null) { ?? // buffer elements of iterator1 while iterating for 2nd and subsequent iterations ??? ... } else { ??? // consume iterator1, then iterator2, then create more iterators for subsequent iterations ??? ... } Peter From ivan.gerasimov at oracle.com Fri Mar 15 08:38:50 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Mar 2019 01:38:50 -0700 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> Message-ID: <8ff64203-9c35-309b-0080-1a1d64ad649b@oracle.com> Hi Peter! On 3/15/19 1:24 AM, Peter Levart wrote: > > > On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote: >>> * @since 13 >>> */ >>> interface Once {} >>> >>> >>> What do you think of that? >> It's not clear to me if an annotation, available at runtime, is not a >> better fit. >> Anyway, i'm not sure not sure introducing such interface/annotation >> worth its maintenance cost, as you said the use case is pretty narrow. >> > > It is narrow, but in a situation like that, where you want to code an > optimal generic algorithm and all you have access to is an Iterable, > there's no other way (short of providing additional methods, which is > ugly). Just think of this situation. You have to decide upfront if you > need to buffer the elements obtained from 1st iteration or not, but > 1st iteration always succeeds... > Can you please explain how the interface Once would help to solve this? If an Iterable does not implement Once, it does not mean it allows multiple passes, right? With kind regards, Ivan > Annotations are not suitable for that as the check has to be quick and > they don't play well with inheritance etc... > > Peter > > -- With kind regards, Ivan Gerasimov From peter.levart at gmail.com Fri Mar 15 08:51:07 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 09:51:07 +0100 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <8ff64203-9c35-309b-0080-1a1d64ad649b@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> <8ff64203-9c35-309b-0080-1a1d64ad649b@oracle.com> Message-ID: On 3/15/19 9:38 AM, Ivan Gerasimov wrote: > Hi Peter! > > > On 3/15/19 1:24 AM, Peter Levart wrote: >> >> >> On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote: >>>> ????? * @since 13 >>>> ????? */ >>>> ???? interface Once {} >>>> >>>> >>>> What do you think of that? >>> It's not clear to me if an annotation, available at runtime, is not >>> a better fit. >>> Anyway, i'm not sure not sure introducing such interface/annotation >>> worth its maintenance cost, as you said the use case is pretty narrow. >>> >> >> It is narrow, but in a situation like that, where you want to code an >> optimal generic algorithm and all you have access to is an Iterable, >> there's no other way (short of providing additional methods, which is >> ugly). Just think of this situation. You have to decide upfront if >> you need to buffer the elements obtained from 1st iteration or not, >> but 1st iteration always succeeds... >> > Can you please explain how the interface Once would help to solve this? > If an Iterable does not implement Once, it does not mean it allows > multiple passes, right? It does not guarantee multiple passes, that's right, but that's legacy. This situation is the same for IterableOnce as a subtype of Iterable, but marker interface has less chance to intrude into "visible" static types that consist of method signatures, type parameters and variable types and therefore does not cause confusion in that area. "Once" is not perfect, but allows generic algorithms to work on those instances that do implement it at least. Regards, Peter > > With kind regards, > Ivan From ivan.gerasimov at oracle.com Fri Mar 15 09:07:08 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Mar 2019 02:07:08 -0700 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> <8ff64203-9c35-309b-0080-1a1d64ad649b@oracle.com> Message-ID: <9610c889-190b-bae7-df42-865fd25a1a96@oracle.com> On 3/15/19 1:51 AM, Peter Levart wrote: > > > On 3/15/19 9:38 AM, Ivan Gerasimov wrote: >> Hi Peter! >> >> >> On 3/15/19 1:24 AM, Peter Levart wrote: >>> >>> >>> On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote: >>>>> * @since 13 >>>>> */ >>>>> interface Once {} >>>>> >>>>> >>>>> What do you think of that? >>>> It's not clear to me if an annotation, available at runtime, is not >>>> a better fit. >>>> Anyway, i'm not sure not sure introducing such interface/annotation >>>> worth its maintenance cost, as you said the use case is pretty narrow. >>>> >>> >>> It is narrow, but in a situation like that, where you want to code >>> an optimal generic algorithm and all you have access to is an >>> Iterable, there's no other way (short of providing additional >>> methods, which is ugly). Just think of this situation. You have to >>> decide upfront if you need to buffer the elements obtained from 1st >>> iteration or not, but 1st iteration always succeeds... >>> >> Can you please explain how the interface Once would help to solve this? >> If an Iterable does not implement Once, it does not mean it allows >> multiple passes, right? > > It does not guarantee multiple passes, that's right, but that's > legacy. This situation is the same for IterableOnce as a subtype of > Iterable, but marker interface has less chance to intrude into > "visible" static types that consist of method signatures, type > parameters and variable types and therefore does not cause confusion > in that area. > > "Once" is not perfect, but allows generic algorithms to work on those > instances that do implement it at least. > Thanks for clarifying! My point was that in the situation you described, an interface Many (or MultiPass, or how ever it's named) would be more appropriate. If an Iterable implements it, there is a guarantee. Otherwise it has to be assumed a one-shot Iterable. With kind regards, Ivan > Regards, Peter > >> >> With kind regards, >> Ivan > > -- With kind regards, Ivan Gerasimov From goetz.lindenmaier at sap.com Fri Mar 15 10:55:21 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Mar 2019 10:55:21 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <20190314143804.400279193@eggemoggin.niobe.net> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> Message-ID: Hi everybody, Mark, I followed your advice and created a JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 Please point me to things I need to improve formally, this is my first JEP. Also feel free to fix the administrative information in the Jira issue if it is wrong. And, naturally, you're welcome to discuss the topic! Best regards, Goetz. > -----Original Message----- > From: mark.reinhold at oracle.com > Sent: Donnerstag, 14. M?rz 2019 22:38 > To: maurizio.cimadamore at oracle.com; Lindenmaier, Goetz > > Cc: mandy.chung at oracle.com; roger.riggs at oracle.com; core-libs- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > 2019/3/14 8:00:20 -0700, maurizio.cimadamore at oracle.com: > > I second what Mandy says. > > > > First let me start by saying that this enhancement will be a great > > addition to our platform; back in the days when I was teaching some Java > > classes at the university, I was very aware of how hard it is to > > diagnose a NPE for someone novel to Java programming. > > Agreed! > > > ... > > > > I also think that the design space for such an enhancement is non > > trivial, and would best be explored (and captured!) in a medium that is > > something other than a patch. ... > > Agreed, also. > > Goetz -- if, per Mandy?s suggestion, you?re going to write something > up using the JEP template, might I suggest that you then submit it as > an actual JEP? Giving visibility to, and recording, such design-space > explorations is one of the primary goals of the JEP process. > > - Mark From maurizio.cimadamore at oracle.com Fri Mar 15 11:33:04 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Mar 2019 11:33:04 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> Message-ID: <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> Hi Goetz, please find the attached ASM-based patch. It is just a PoC, as such it does not provide as fine-grained messages as the one discussed in the RFE/JEP, but can be enhanced to cover custom debugging attribute, I believe. When running this: Object o = null; o.toString(); you get: Exception in thread "main" java.lang.NullPointerException: attempt to dereference 'null' when calling method 'toString' ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) While when running this: Foo foo = null; int y = foo.x; You get this: Exception in thread "main" java.lang.NullPointerException: attempt to dereference 'null' when accessing field 'x' ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) One problem I had is that ASM provides no way to get the instruction given a program counter - which means we have to scan all the bytecodes and update the sizes as we go along, and, ASM unfortunately doesn?t expose opcode sizes either. A more robust solution would be to have a big switch which returned the opcode size of any given opcode. Also, accessing to StackWalker API on exception creation might not be desirable in terms of performances, so this might be one of these area where some VM help could be beneficial. Another problem is that we cannot distinguish between user-generated exceptions (e.g. `throw new NullPointerException`) and genuine NPE issued by the VM. But I guess the upshot is that it works to leave all the gory detail of bytecode grovelling to a bytecode API - if the logic is applied lazily, then the impact on performances should be minimal, and the solution more maintainable longer term. Cheers Maurizio On 15/03/2019 07:59, Lindenmaier, Goetz wrote: > Yes, it would be nice if you shared that. -------------- next part -------------- A non-text attachment was scrubbed... Name: NPEdetails.patch Type: text/x-patch Size: 4845 bytes Desc: not available URL: From Alan.Bateman at oracle.com Fri Mar 15 12:19:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Mar 2019 12:19:08 +0000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <0c282875-2f0b-ed17-4a05-621bd5e0d862@oracle.com> Message-ID: <5fdb4be4-ecd6-ca5f-1cfe-019d18eba7c9@oracle.com> On 14/03/2019 21:33, Igor Ignatyev wrote: > Hi Alan, > > I double checked, the test is linked w/ -ljli, and calls JNI_CreateJavaVM from libjli.so. hence I'll leave JniInvocationTest in jdk/tools/launcher. > Thanks for checking, in which case I think we need to find a better name for this test as JniInvocationTest is a misleading name when it's a JLI rather than JNI test. -Alan. From pavel.rappo at oracle.com Fri Mar 15 12:30:09 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 15 Mar 2019 12:30:09 +0000 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> Message-ID: <1494FFDF-7352-46D1-8348-1B12CF769D6C@oracle.com> Thanks for the clarifications. The change looks fine now. I felt initial unease because, in my experience, it's so easy to overlook some subtlety when working with overflowing integers. For `System.currentTimeMillis` the code like: stopTime - startTime >= timeout doesn't raise one's eyebrows. For one, both `stopTime` and `startTime` are non-negative and stopTime >= startTime. And that will be the case for the next 300 million years [1] of which we have lived the first 50 years or so. For the code in your fix, however, not only can `deadline` be negative, but the value returned by `System.nanoTime` too. What's even worse is that `System.nanoTime` can change the sign between invocations [2]. For the problem like that, I usually draw a circle with wrapping points Long.MAX_VALUE and Long.MIN_VALUE on the paper and satisfy myself by exploring some number of examples that exhaust all (sign) possibilities. There's a significant cognitive load to perform this analysis each and every time. And there is always a possibility of making a mistake [3]. Happy for the people who can do it seamlessly and on the fly. As for me, I wish there were a method that hid all these subtleties, something like long remainingTimeout(long firstMeasurement, long secondMeasurement, long timeout) Or maybe it's just the documentation for `System.nanoTime` and `System.currentTimeMillis` that could be updated so as to explain the right way in details. `System.nanoTime` is already doing a good job there. I've searched through the JDK and found out that kind of timeout calculations are quite abundant. In particular, the one used in your code seems to be an idiom. My guess, it might be true for other projects. -Pavel -------------------------------------------------------------------------------- [1] (2^63) / (10^3 * 24 * 60 * 60 * 365) [2] It's unknown what would the initial (at JVM start) value be. It might be negative. So that's why `System.nanoTime() >= startTime + timeoutNanos` might fail even if the right hand side doesn't overflow. [3] Heck, you can even break your neck trying to find a middle of the index range: [a, b]. While `(a + b) / 2` overflows, `a + (b - a)/2` (or `(a + b) >>> 1`) does not. > On 14 Mar 2019, at 21:32, Ivan Gerasimov wrote: > > Thank you Pavel! > > > On 3/14/19 2:02 PM, Pavel Rappo wrote: >> I have to look at this patch in more detail, however here's what jumped out at >> me straight away: >> >> long deadline = System.nanoTime() + remainingNanos; >> >> It seems like a possibility for an overflow. >> > Not quite. The deadline can surely become negative, which is alright. Later we only check the difference (deadline - System.nanoTime()). > > Actually, the new code mimics what we have in PocessImpl for Unix and Windows. > > With kind regards, > Ivan > >> Documentation for System.nanoTime >> has a special section on this: >> >> For example, to measure how long some code takes to execute: >> >> long startTime = System.nanoTime(); >> // ... the code being measured ... >> long elapsedNanos = System.nanoTime() - startTime; >> >> To compare elapsed time against a timeout, use >> >> if (System.nanoTime() - startTime >= timeoutNanos) ... >> >> instead of >> >> if (System.nanoTime() >= startTime + timeoutNanos) ... >> >> because of the possibility of numerical overflow. >> >> Is that of concern in this case? >> >>> On 14 Mar 2019, at 19:49, Ivan Gerasimov wrote: >>> >>> Hello! >>> >>> The default implementation of Process.waitFor(long, TimeUnit) does not check if the process has exited after the last portion of the timeout has expired. >>> >>> JDK has two implementations of Process (for Unix and Windows) and they both override waitFor(), so it's not an issue for them. >>> >>> Still, it is better to provide a more accurate default implementation. >>> >>> I'm not quite certain the regression test needs to be included in the fix. The test does demonstrate the issue with the unfixed JDK and passed Okay on all tested platforms in Mach5. Yet, I suspect the test can still show false negative results, as there are no guaranties that even such simple application as `true` will finish in 100 ms. >>> I can tag the test as @ignored with a comment, or simply remove it from the fix. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >>> >>> Thanks in advance for reviewing! >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >> > > -- > With kind regards, > Ivan Gerasimov > From Alan.Bateman at oracle.com Fri Mar 15 12:33:42 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Mar 2019 12:33:42 +0000 Subject: RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) In-Reply-To: <8d15b2a7-147d-9438-8959-882a1de1355f@oracle.com> References: <5bb4b347-9e25-f4f8-ed95-09b1997e8e02@oracle.com> <3db67b6a-a125-60a6-9b95-ba3ae096dac4@oracle.com> <33d2cb26-3a3d-4268-f1b0-4396cbfe3923@oracle.com> <8d15b2a7-147d-9438-8959-882a1de1355f@oracle.com> Message-ID: <4adaeca5-564e-0c11-9586-9698583b08f7@oracle.com> On 15/03/2019 06:43, David Holmes wrote: > > Yes and on closer examination you will find a lot of inconsistencies. > RESTARTABLE goes back a long way and many of the I/O APIs have > switched locations over the years. Stuff was copied from the HPI layer > into hotspot, then back to the JDK and sometimes things were copied > with RESTARTABLE and sometimes not; and sometimes ports were written > that copied RESTARTABLE and sometimes not; and sometime new APIs were > added that were RESTARTABLE and sometimes not. All in all a bit of a > mess. > > For example here are some uses of write in JDK libs: > > ./share/native/libzip/zlib/gzwrite.c:??????????????? writ = > write(state->fd, state->x.next, put); > ./unix/native/libnio/ch/IOUtil.c:??? return convertReturnVal(env, > write(fd, &c, 1), JNI_FALSE); > ./unix/native/libnio/ch/FileDispatcherImpl.c:??? return > convertReturnVal(env, write(fd, buf, len), JNI_FALSE); > ./unix/native/libnio/fs/UnixCopyFile.c: RESTARTABLE(write((int)dst, > bufp, len), n); > ./unix/native/libnio/fs/UnixNativeDispatcher.c: > RESTARTABLE(write((int)fd, bufp, (size_t)nbytes), n) > ./unix/native/libjava/ProcessImpl_md.c: write(c->childenv[1], (char > *)&magic, sizeof(magic)); // magic number first > ./unix/native/libjava/io_util_md.c:??? RESTARTABLE(write(fd, buf, > len), result); > > A mix of RESTARTABLE and not. Some of these are in the native methods in the implementation of APIs that support for async close and where a signal is used to interrupt blocking calls. For those cases, the retry is done in the Java code. I think Ivan's patch looks okay but I think you are right with your general point that something else must be going on if we are running into this now. It would require native code or a bug something to have these system calls falling with EINTR. At some point we need to replace the UnixFileSystem implementation too but that is for another discussion. -Alan From goetz.lindenmaier at sap.com Fri Mar 15 13:11:39 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Mar 2019 13:11:39 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> Message-ID: Hi Maurizio, thanks for sharing your patch! This is about what I thought about so far, just that it's working already :) It prints the information of the failing bytecode. Adding the dataflow analysis, the other information could be printed as well. The major problem I see is here: + File f = new File(location.getFile(), + clazz.getCanonicalName().replaceAll("\\.", "/") + ".class"); + ClassReader cr = new ClassReader(new FileInputStream(f)); + ClassNode classNode = new ClassNode(); + cr.accept(classNode, 0); As I understand, this reads the Bytecode from the classfile. The bytecode in the classfile must not match that executed by the VM, i.e, the pc you get from the stackWalker will not reference the bytecode that caused the NPE. Other issues have been discussed in the mail thread before. Good that you point this out, I'll add it to the JEP. Best regards, Goetz ... Sorry, I missed the "reply all" on my first reply. > -----Original Message----- > From: Maurizio Cimadamore > Sent: Freitag, 15. M?rz 2019 12:33 > To: Lindenmaier, Goetz ; Mandy Chung > ; Roger Riggs > Cc: Java Core Libs ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > please find the attached ASM-based patch. It is just a PoC, as such it > does not provide as fine-grained messages as the one discussed in the > RFE/JEP, but can be enhanced to cover custom debugging attribute, I believe. > > When running this: > > Object o = null; > o.toString(); > > you get: > > Exception in thread "main" java.lang.NullPointerException: attempt to > dereference 'null' when calling method 'toString' > ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) > > While when running this: > > Foo foo = null; > int y = foo.x; > > You get this: > > Exception in thread "main" java.lang.NullPointerException: attempt to > dereference 'null' when accessing field 'x' > ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) > > One problem I had is that ASM provides no way to get the instruction > given a program counter - which means we have to scan all the bytecodes > and update the sizes as we go along, and, ASM unfortunately doesn?t > expose opcode sizes either. A more robust solution would be to have a > big switch which returned the opcode size of any given opcode. Also, > accessing to StackWalker API on exception creation might not be > desirable in terms of performances, so this might be one of these area > where some VM help could be beneficial. Another problem is that we > cannot distinguish between user-generated exceptions (e.g. `throw new > NullPointerException`) and genuine NPE issued by the VM. > > But I guess the upshot is that it works to leave all the gory detail of > bytecode grovelling to a bytecode API - if the logic is applied lazily, > then the impact on performances should be minimal, and the solution more > maintainable longer term. > > Cheers > Maurizio > > On 15/03/2019 07:59, Lindenmaier, Goetz wrote: > > Yes, it would be nice if you shared that. From claes.redestad at oracle.com Fri Mar 15 13:45:20 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 Mar 2019 14:45:20 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> References: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> Message-ID: <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> Hi, On 2019-03-14 18:20, Claes Redestad wrote: > > On 2019-03-14 18:13, Alan Bateman wrote: >> >> For the current webrev then I'm concerned it is brings back legacy >> attributes. The concept of "installed optional packages" was removed >> in Java SE 9, as was the ability for JAR packaged applets to trigger >> downloading of optional packages. I don't think the later was ever >> implemented in the JDK so surprising that we are finding JAR files >> with those attributes now. If we can prune that down then I think the >> changes will be okay. > > Ok. I stumbled on some new test issues in SA with this patch, so I'll > need to pause this one for a while anyhow. I have a solution to the heap dump issues out for review[1], so I've cleaned up this patch, verified the failing tests pass locally and am running both through tier1-3: http://cr.openjdk.java.net/~redestad/8214712/open.01/ Thanks! /Claes [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027455.html From Alan.Bateman at oracle.com Fri Mar 15 15:01:00 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Mar 2019 15:01:00 +0000 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> References: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> Message-ID: <0a310b12-f91c-8195-4463-fa5c0e47240d@oracle.com> On 15/03/2019 13:45, Claes Redestad wrote: > > I have a solution to the heap dump issues out for review[1], so I've > cleaned up this patch, verified the failing tests pass locally and am > running both through tier1-3: > > http://cr.openjdk.java.net/~redestad/8214712/open.01/ This version looks good to me. -Alan From peter.levart at gmail.com Fri Mar 15 16:07:27 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 17:07:27 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> References: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> Message-ID: Hi Claes, If you have observed memory churn allocating Name objects when reading jar files, then perhaps we could do something to the logic of Attributes class so that lazily allocated Name(s) would get interned too? As a separate change of course. This looks good as is. Regards, Peter On 3/15/19 2:45 PM, Claes Redestad wrote: > Hi, > > On 2019-03-14 18:20, Claes Redestad wrote: >> >> On 2019-03-14 18:13, Alan Bateman wrote: >>> >>> For the current webrev then I'm concerned it is brings back legacy >>> attributes. The concept of "installed optional packages" was removed >>> in Java SE 9, as was the ability for JAR packaged applets to trigger >>> downloading of optional packages. I don't think the later was ever >>> implemented in the JDK so surprising that we are finding JAR files >>> with those attributes now. If we can prune that down then I think >>> the changes will be okay. >> >> Ok. I stumbled on some new test issues in SA with this patch, so I'll >> need to pause this one for a while anyhow. > > I have a solution to the heap dump issues out for review[1], so I've > cleaned up this patch, verified the failing tests pass locally and am > running both through tier1-3: > > http://cr.openjdk.java.net/~redestad/8214712/open.01/ > > Thanks! > > /Claes > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027455.html From claes.redestad at oracle.com Fri Mar 15 16:14:31 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 Mar 2019 17:14:31 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> Message-ID: Hi Peter, thanks for reviewing! Interning arbitrary attribute names might have some unfortunate side- effects, but a tiny - maybe one or two element - cache might be sufficient to keep the churn low in practice. Name and SHA1-Digest are the most commonly repeated non-constant attribute, generated by the jarsigner tool. Often appearing many times in a single manifest. I also added SHA-256-Digest because that's what you'd typically get if you signed a JAR file today. /Claes On 2019-03-15 17:07, Peter Levart wrote: > Hi Claes, > > If you have observed memory churn allocating Name objects when reading > jar files, then perhaps we could do something to the logic of Attributes > class so that lazily allocated Name(s) would get interned too? > > As a separate change of course. This looks good as is. > > Regards, Peter > > On 3/15/19 2:45 PM, Claes Redestad wrote: >> Hi, >> >> On 2019-03-14 18:20, Claes Redestad wrote: >>> >>> On 2019-03-14 18:13, Alan Bateman wrote: >>>> >>>> For the current webrev then I'm concerned it is brings back legacy >>>> attributes. The concept of "installed optional packages" was removed >>>> in Java SE 9, as was the ability for JAR packaged applets to trigger >>>> downloading of optional packages. I don't think the later was ever >>>> implemented in the JDK so surprising that we are finding JAR files >>>> with those attributes now. If we can prune that down then I think >>>> the changes will be okay. >>> >>> Ok. I stumbled on some new test issues in SA with this patch, so I'll >>> need to pause this one for a while anyhow. >> >> I have a solution to the heap dump issues out for review[1], so I've >> cleaned up this patch, verified the failing tests pass locally and am >> running both through tier1-3: >> >> http://cr.openjdk.java.net/~redestad/8214712/open.01/ >> >> Thanks! >> >> /Claes >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027455.html >> > From maurizio.cimadamore at oracle.com Fri Mar 15 17:34:28 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Mar 2019 17:34:28 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> Message-ID: You touch an important point here - who is this feature for? Is it for the casual developer in need of some hand holding? Or is it for diagnosing complex instrumented stacks? I think the two use cases are not necessarily similar and might be served by different sets of enhancements. In the latter case it might be ok, for instance, to say "and, btw, the NPE came from local[1]". But for users in the former bucket (and most users, really), this level of detail will simply be unacceptable (since now they have to understand the JVMS to parse the message :-)). I suggest we separate the use cases, at least for the purpose of the design discussion. Maurizio On 15/03/2019 13:11, Lindenmaier, Goetz wrote: > Hi Maurizio, > > thanks for sharing your patch! This is about what I thought about > so far, just that it's working already :) > > It prints the information of the failing bytecode. Adding the dataflow > analysis, the other information could be printed as well. > > The major problem I see is here: > + File f = new File(location.getFile(), > + clazz.getCanonicalName().replaceAll("\\.", "/") + ".class"); > + ClassReader cr = new ClassReader(new FileInputStream(f)); > + ClassNode classNode = new ClassNode(); > + cr.accept(classNode, 0); > > As I understand, this reads the Bytecode from the classfile. > The bytecode in the classfile must not match that executed > by the VM, i.e, the pc you get from the stackWalker will not > reference the bytecode that caused the NPE. > > Other issues have been discussed in the mail thread before. > Good that you point this out, I'll add it to the JEP. > > Best regards, > Goetz > > ... Sorry, I missed the "reply all" on my first reply. > > > > >> -----Original Message----- >> From: Maurizio Cimadamore >> Sent: Freitag, 15. M?rz 2019 12:33 >> To: Lindenmaier, Goetz ; Mandy Chung >> ; Roger Riggs >> Cc: Java Core Libs ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >> >> Hi Goetz, >> please find the attached ASM-based patch. It is just a PoC, as such it >> does not provide as fine-grained messages as the one discussed in the >> RFE/JEP, but can be enhanced to cover custom debugging attribute, I believe. >> >> When running this: >> >> Object o = null; >> o.toString(); >> >> you get: >> >> Exception in thread "main" java.lang.NullPointerException: attempt to >> dereference 'null' when calling method 'toString' >> ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) >> >> While when running this: >> >> Foo foo = null; >> int y = foo.x; >> >> You get this: >> >> Exception in thread "main" java.lang.NullPointerException: attempt to >> dereference 'null' when accessing field 'x' >> ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) >> >> One problem I had is that ASM provides no way to get the instruction >> given a program counter - which means we have to scan all the bytecodes >> and update the sizes as we go along, and, ASM unfortunately doesn?t >> expose opcode sizes either. A more robust solution would be to have a >> big switch which returned the opcode size of any given opcode. Also, >> accessing to StackWalker API on exception creation might not be >> desirable in terms of performances, so this might be one of these area >> where some VM help could be beneficial. Another problem is that we >> cannot distinguish between user-generated exceptions (e.g. `throw new >> NullPointerException`) and genuine NPE issued by the VM. >> >> But I guess the upshot is that it works to leave all the gory detail of >> bytecode grovelling to a bytecode API - if the logic is applied lazily, >> then the impact on performances should be minimal, and the solution more >> maintainable longer term. >> >> Cheers >> Maurizio >> >> On 15/03/2019 07:59, Lindenmaier, Goetz wrote: >>> Yes, it would be nice if you shared that. From mik3hall at gmail.com Fri Mar 15 18:03:16 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 15 Mar 2019 13:03:16 -0500 Subject: jpackage ALL-SYSTEM In-Reply-To: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> References: <45680E36-2502-4609-A4CD-496CFA403AD4@gmail.com> Message-ID: <82B78BEA-C8B6-41E1-8059-34E40B1ED308@gmail.com> > On Mar 8, 2019, at 8:57 AM, Michael Hall wrote: > > I have made changes to my application that make it mostly functional with the exception of JMX pid attach as built by jpackage. > I thought I had this functionality working when I first got the application to use Java 9 but it no longer appears to work again now, either with my Java 9 app or my 13-internal+0-jdk13-jpackage.17 version app. > I understand for this issue serviceability-dev might be a better list for this but there may be one jpackage issue concerned as well. > Again, I don?t consider this a jpackage problem, my application now builds as successfully as it currently can with jpackage as-is. > What I get attempting a JMX attach is? > 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed Briefly this turned out to be a parameter change. With a legacy OS X application bundler I used to have? -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy With $APP_ROOT not available and assuming no suitable jpackage alternative, I changed to doing the security related programmatically. JMX must do it?s processing with a different ClassLoader. So, attach provider and attach authorization failed as initially indicated and shown above. This is a drawback to doing programatic security setup. Unable to determine anyway around that, for jpackage I changed the legacy parameter to? -Djava.security.policy=../JavaApp/all.policy Using the jpackage user.dir setting for a relative path. It works as before, including for jconsole. Modules had nothing to do with it. Thanks. From peter.levart at gmail.com Fri Mar 15 18:06:58 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Mar 2019 19:06:58 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> Message-ID: On 3/15/19 5:14 PM, Claes Redestad wrote: > Hi Peter, > > thanks for reviewing! > > Interning arbitrary attribute names might have some unfortunate side- > effects, You mean if the number of different names would get larger and larger on a long-running JVM, the cache would grow without bounds? I noticed that the Name constructor: ??????? public Name(String name) { ??????????? this.hashCode = hash(name); ??????????? this.name = name.intern(); ??????? } ...interns the String name. Do interned strings have a weak cache or are they kept for the entire life of JVM? Regards, Peter > but a tiny - maybe one or two element - cache might be > sufficient to keep the churn low in practice. > > Name and SHA1-Digest are the most commonly repeated non-constant > attribute, generated by the jarsigner tool. Often appearing many times > in a single manifest. I also added SHA-256-Digest because that's what > you'd typically get if you signed a JAR file today. > > /Claes > > On 2019-03-15 17:07, Peter Levart wrote: >> Hi Claes, >> >> If you have observed memory churn allocating Name objects when >> reading jar files, then perhaps we could do something to the logic of >> Attributes class so that lazily allocated Name(s) would get interned >> too? >> >> As a separate change of course. This looks good as is. >> >> Regards, Peter >> >> On 3/15/19 2:45 PM, Claes Redestad wrote: >>> Hi, >>> >>> On 2019-03-14 18:20, Claes Redestad wrote: >>>> >>>> On 2019-03-14 18:13, Alan Bateman wrote: >>>>> >>>>> For the current webrev then I'm concerned it is brings back legacy >>>>> attributes. The concept of "installed optional packages" was >>>>> removed in Java SE 9, as was the ability for JAR packaged applets >>>>> to trigger downloading of optional packages. I don't think the >>>>> later was ever implemented in the JDK so surprising that we are >>>>> finding JAR files with those attributes now. If we can prune that >>>>> down then I think the changes will be okay. >>>> >>>> Ok. I stumbled on some new test issues in SA with this patch, so I'll >>>> need to pause this one for a while anyhow. >>> >>> I have a solution to the heap dump issues out for review[1], so I've >>> cleaned up this patch, verified the failing tests pass locally and >>> am running both through tier1-3: >>> >>> http://cr.openjdk.java.net/~redestad/8214712/open.01/ >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027455.html >>> >> From Roger.Riggs at oracle.com Fri Mar 15 18:39:21 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 Mar 2019 14:39:21 -0400 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> <7b775c5a-93b6-8279-d7dd-90fcc3a5c621@oracle.com> <750fd388-d857-9d2f-4549-b256cd6b2901@oracle.com> Message-ID: Hi Ivan, The updated code looks fine except for style. Please put the return and the if's on different lines (by the style conventions). Line 210 and 211, and 216. Thanks, Roger On 03/15/2019 04:08 AM, Ivan Gerasimov wrote: > Hi David! > > The code could be written like following: > > long start = System.nanoTime(); > do { > ??? ... > ??? long elapsed = System.nanoTime() - start; > ??? remainingNanos = timeoutNanos - elapsed; > } while (remainingNanos > 0); > > but then one realizes that this always calculates (start + > timeoutNanos), both of which are effectively final. > So, the sum can be calculated in advance, and named, say, "deadline" :) > > With kind regards, > Ivan > > On 3/15/19 12:16 AM, David Holmes wrote: >> On 15/03/2019 5:03 pm, Ivan Gerasimov wrote: >>> Thank you David! >>> >>> >>> On 3/14/19 11:01 PM, David Holmes wrote: >>>> Hi Ivan, >>>> >>>> On 15/03/2019 12:02 pm, Ivan Gerasimov wrote: >>>>> Hi David! >>>>> >>>>> >>>>> On 3/14/19 5:28 PM, David Holmes wrote: >>>>>> Hi Ivan, >>>>>> >>>>>> On 15/03/2019 5:49 am, Ivan Gerasimov wrote: >>>>>>> Hello! >>>>>>> >>>>>>> The default implementation of Process.waitFor(long, TimeUnit) >>>>>>> does not check if the process has exited after the last portion >>>>>>> of the timeout has expired. >>>>>> >>>>>> Please clarify. There is always a race between detecting a >>>>>> timeout and the process actually terminating. If the process >>>>>> actually terminates while you're deciding to report a timeout >>>>>> that seems just? an acceptable possibility. No matter what you do >>>>>> the process could terminate just after you decided to report the >>>>>> timeout. >>>>>> >>>>>> >>>>> Current code for waitFor(...) is >>>>> >>>>> ? 212???????? do { >>>>> ? 213???????????? try { >>>>> ? 214???????????????? exitValue(); >>>>> ? 215???????????????? return true; >>>>> ? 216???????????? } catch(IllegalThreadStateException ex) { >>>>> ? 217???????????????? if (rem > 0) >>>>> ? 218???????????????????? Thread.sleep( >>>>> ? 219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); >>>>> ? 220???????????? } >>>>> ? 221???????????? rem = unit.toNanos(timeout) - (System.nanoTime() >>>>> - startTime); >>>>> ? 222???????? } while (rem > 0); >>>>> ? 223???????? return false; >>>>> >>>>> So, if the loop has just processed the last 100 ms portion of the >>>>> timeout, it ends right away, without checking if the process has >>>>> exited during this period. >>>> >>>> Ah I see. Yes there should be a final check after what will be the >>>> last sleep. >>>> >>>>> Not a big deal of course, but it is more accurate to check if the >>>>> process has exited at the *end* of the specified timeout, and not >>>>> 100 milliseconds before the end. >>>> >>>> Agreed. >>>> >>>> I share Pavel's concern about the implicit overflow in calculating >>>> a deadline, rather than comparing elapsed time with the timeout. >>>> There has been some effort in core-libs to remove assumptions about >>>> how overflows are handled. >>>> >>> We only check sign of the remainingNanos, which is initially >>> strictly positive timeout.? Over time it gets decreased by elapsed >>> time. >>> The elapsed time is the difference between System.nanoTime() >>> measured at line 217 and 213, so it is always non-negative (well, >>> strictly positive, as there's sleep in between). >>> >>> I don't really see a possibility of overflow for remainingNanos here. >>> >>> The deadline may overflow, and it is totally fine, as we don't care >>> about its sign. >> >> It's deadline that I was flagging. >> >>> Am I missing something? >> >> Just a code cleanliness issue. I had thought, but now can't find, >> these kinds of overflowing calculations were being cleaned up in >> core-libs. But perhaps I'm just mis-remembering. >> >> Cheers, >> David >> >>> >>> With kind regards, >>> Ivan >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> With kind regards, >>>>> Ivan >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> JDK has two implementations of Process (for Unix and Windows) >>>>>>> and they both override waitFor(), so it's not an issue for them. >>>>>>> >>>>>>> Still, it is better to provide a more accurate default >>>>>>> implementation. >>>>>>> >>>>>>> I'm not quite certain the regression test needs to be included >>>>>>> in the fix.? The test does demonstrate the issue with the >>>>>>> unfixed JDK and passed Okay on all tested platforms in Mach5. >>>>>>> Yet, I suspect the test can still show false negative results, >>>>>>> as there are no guaranties that even such simple application as >>>>>>> `true` will finish in 100 ms. >>>>>>> I can tag the test as @ignored with a comment, or simply remove >>>>>>> it from the fix. >>>>>>> >>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 >>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ >>>>>>> >>>>>>> Thanks in advance for reviewing! >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Fri Mar 15 18:43:21 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Mar 2019 11:43:21 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> Message-ID: That's a good suggestion. The JDK out-of-the-box case and the complex environment case with instrumentation agents transforming the bytecodes are two different use cases. This brings up one issue that when constructing the enhanced NPE message, a method might become obsolete due to redefintion, it should handle gracefully. Mandy On 3/15/19 10:34 AM, Maurizio Cimadamore wrote: > You touch an important point here - who is this feature for? Is it for > the casual developer in need of some hand holding? Or is it for > diagnosing complex instrumented stacks? I think the two use cases are > not necessarily similar and might be served by different sets of > enhancements. In the latter case it might be ok, for instance, to say > "and, btw, the NPE came from local[1]". But for users in the former > bucket (and most users, really), this level of detail will simply be > unacceptable (since now they have to understand the JVMS to parse the > message :-)). > > I suggest we separate the use cases, at least for the purpose of the > design discussion. > > Maurizio > > On 15/03/2019 13:11, Lindenmaier, Goetz wrote: >> Hi Maurizio, >> >> thanks for sharing your patch!? This is about what I thought about >> so far, just that it's working already :) >> >> It prints the information of the failing bytecode.? Adding the dataflow >> analysis, the other information could be printed as well. >> >> The major problem I see is here: >> +??????????? File f = new File(location.getFile(), >> +??????????????????? clazz.getCanonicalName().replaceAll("\\.", "/") + >> ".class"); >> +??????????? ClassReader cr = new ClassReader(new FileInputStream(f)); >> +??????????? ClassNode classNode = new ClassNode(); >> +??????????? cr.accept(classNode, 0); >> >> As I understand, this reads the Bytecode from the classfile. >> The bytecode in the classfile must not match that executed >> by the VM, i.e, the pc you get from the stackWalker will not >> reference the bytecode that caused the NPE. >> >> Other issues have been discussed in the mail thread before. >> Good that you point this out, I'll add it to the JEP. >> >> Best regards, >> ?? Goetz >> >> ... Sorry, I missed the "reply all" on my first reply. >> >> >> >> >>> -----Original Message----- >>> From: Maurizio Cimadamore >>> Sent: Freitag, 15. M?rz 2019 12:33 >>> To: Lindenmaier, Goetz ; Mandy Chung >>> ; Roger Riggs >>> Cc: Java Core Libs ; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(L): 8218628: Add detailed message to >>> NullPointerException >>> describing what is null. >>> >>> Hi Goetz, >>> please find the attached ASM-based patch. It is just a PoC, as such it >>> does not provide as fine-grained messages as the one discussed in the >>> RFE/JEP, but can be enhanced to cover custom debugging attribute, I >>> believe. >>> >>> When running this: >>> >>> Object o = null; >>> o.toString(); >>> >>> you get: >>> >>> Exception in thread "main" java.lang.NullPointerException: attempt to >>> dereference 'null' when calling method 'toString' >>> ? ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) >>> >>> While when running this: >>> >>> Foo foo = null; >>> int y = foo.x; >>> >>> You get this: >>> >>> Exception in thread "main" java.lang.NullPointerException: attempt to >>> dereference 'null' when accessing field 'x' >>> ? ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) >>> >>> One problem I had is that ASM provides no way to get the instruction >>> given a program counter - which means we have to scan all the bytecodes >>> and update the sizes as we go along, and, ASM unfortunately doesn?t >>> expose opcode sizes either. A more robust solution would be to have a >>> big switch which returned the opcode size of any given opcode. Also, >>> accessing to StackWalker API on exception creation might not be >>> desirable in terms of performances, so this might be one of these area >>> where some VM help could be beneficial. Another problem is that we >>> cannot distinguish between user-generated exceptions (e.g. `throw new >>> NullPointerException`) and genuine NPE issued by the VM. >>> >>> But I guess the upshot is that it works to leave all the gory detail of >>> bytecode grovelling to a bytecode API - if the logic is applied lazily, >>> then the impact on performances should be minimal, and the solution more >>> maintainable longer term. >>> >>> Cheers >>> Maurizio >>> >>> On 15/03/2019 07:59, Lindenmaier, Goetz wrote: >>>> Yes, it would be nice if you shared that. From martinrb at google.com Fri Mar 15 19:14:48 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Mar 2019 12:14:48 -0700 Subject: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout In-Reply-To: References: <3930b938-e802-47a7-4060-f867da2a6da7@oracle.com> <8aeed742-f71a-d727-8558-517694e73827@oracle.com> <73535341-0cb4-efdc-9b07-f74a2c9d594c@oracle.com> <11e1c523-afec-4dd6-31cc-cafa7e8995e5@oracle.com> <7b775c5a-93b6-8279-d7dd-90fcc3a5c621@oracle.com> <750fd388-d857-9d2f-4549-b256cd6b2901@oracle.com> Message-ID: There are many nanoTime-based calculations in j.u.concurrent and indeed we use a variable named "deadline" a lot. final long deadline = System.nanoTime() + nanosTimeout; But different classes use nanoTime in subtly different ways so there's no copy/paste idiom. When we updated the spec for nanoTime to address integer wraparound, we didn't think about where else such clarifications might be needed. On Fri, Mar 15, 2019 at 1:11 AM Ivan Gerasimov wrote: > Hi David! > > The code could be written like following: > > long start = System.nanoTime(); > do { > ... > long elapsed = System.nanoTime() - start; > remainingNanos = timeoutNanos - elapsed; > } while (remainingNanos > 0); > > but then one realizes that this always calculates (start + > timeoutNanos), both of which are effectively final. > So, the sum can be calculated in advance, and named, say, "deadline" :) > > With kind regards, > Ivan > > On 3/15/19 12:16 AM, David Holmes wrote: > > On 15/03/2019 5:03 pm, Ivan Gerasimov wrote: > >> Thank you David! > >> > >> > >> On 3/14/19 11:01 PM, David Holmes wrote: > >>> Hi Ivan, > >>> > >>> On 15/03/2019 12:02 pm, Ivan Gerasimov wrote: > >>>> Hi David! > >>>> > >>>> > >>>> On 3/14/19 5:28 PM, David Holmes wrote: > >>>>> Hi Ivan, > >>>>> > >>>>> On 15/03/2019 5:49 am, Ivan Gerasimov wrote: > >>>>>> Hello! > >>>>>> > >>>>>> The default implementation of Process.waitFor(long, TimeUnit) > >>>>>> does not check if the process has exited after the last portion > >>>>>> of the timeout has expired. > >>>>> > >>>>> Please clarify. There is always a race between detecting a timeout > >>>>> and the process actually terminating. If the process actually > >>>>> terminates while you're deciding to report a timeout that seems > >>>>> just an acceptable possibility. No matter what you do the process > >>>>> could terminate just after you decided to report the timeout. > >>>>> > >>>>> > >>>> Current code for waitFor(...) is > >>>> > >>>> 212 do { > >>>> 213 try { > >>>> 214 exitValue(); > >>>> 215 return true; > >>>> 216 } catch(IllegalThreadStateException ex) { > >>>> 217 if (rem > 0) > >>>> 218 Thread.sleep( > >>>> 219 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); > >>>> 220 } > >>>> 221 rem = unit.toNanos(timeout) - (System.nanoTime() > >>>> - startTime); > >>>> 222 } while (rem > 0); > >>>> 223 return false; > >>>> > >>>> So, if the loop has just processed the last 100 ms portion of the > >>>> timeout, it ends right away, without checking if the process has > >>>> exited during this period. > >>> > >>> Ah I see. Yes there should be a final check after what will be the > >>> last sleep. > >>> > >>>> Not a big deal of course, but it is more accurate to check if the > >>>> process has exited at the *end* of the specified timeout, and not > >>>> 100 milliseconds before the end. > >>> > >>> Agreed. > >>> > >>> I share Pavel's concern about the implicit overflow in calculating a > >>> deadline, rather than comparing elapsed time with the timeout. There > >>> has been some effort in core-libs to remove assumptions about how > >>> overflows are handled. > >>> > >> We only check sign of the remainingNanos, which is initially strictly > >> positive timeout. Over time it gets decreased by elapsed time. > >> The elapsed time is the difference between System.nanoTime() measured > >> at line 217 and 213, so it is always non-negative (well, strictly > >> positive, as there's sleep in between). > >> > >> I don't really see a possibility of overflow for remainingNanos here. > >> > >> The deadline may overflow, and it is totally fine, as we don't care > >> about its sign. > > > > It's deadline that I was flagging. > > > >> Am I missing something? > > > > Just a code cleanliness issue. I had thought, but now can't find, > > these kinds of overflowing calculations were being cleaned up in > > core-libs. But perhaps I'm just mis-remembering. > > > > Cheers, > > David > > > >> > >> With kind regards, > >> Ivan > >> > >>> Thanks, > >>> David > >>> ----- > >>> > >>>> With kind regards, > >>>> Ivan > >>>> > >>>>> > >>>>> David > >>>>> ----- > >>>>> > >>>>>> JDK has two implementations of Process (for Unix and Windows) and > >>>>>> they both override waitFor(), so it's not an issue for them. > >>>>>> > >>>>>> Still, it is better to provide a more accurate default > >>>>>> implementation. > >>>>>> > >>>>>> I'm not quite certain the regression test needs to be included in > >>>>>> the fix. The test does demonstrate the issue with the unfixed > >>>>>> JDK and passed Okay on all tested platforms in Mach5. Yet, I > >>>>>> suspect the test can still show false negative results, as there > >>>>>> are no guaranties that even such simple application as `true` > >>>>>> will finish in 100 ms. > >>>>>> I can tag the test as @ignored with a comment, or simply remove > >>>>>> it from the fix. > >>>>>> > >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8220684 > >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8220684/00/webrev/ > >>>>>> > >>>>>> Thanks in advance for reviewing! > >>>>>> > >>>>> > >>>> > >>> > >> > > > > -- > With kind regards, > Ivan Gerasimov > > From brian.burkhalter at oracle.com Fri Mar 15 19:24:49 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 12:24:49 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions Message-ID: For [1] please review the proposed fix [2]. It is possible to preemptively detect a sufficient condition for when the length of the modified UTF-8 encoding of the string parameter will exceed the maximum allowed value and thereby avert any numerical overflow in incrementing the accumulator which counts the number of encoded characters. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8219196 [2] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ From martinrb at google.com Fri Mar 15 19:40:36 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Mar 2019 12:40:36 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Consider changing utflen to a long. On Fri, Mar 15, 2019 at 12:25 PM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > For [1] please review the proposed fix [2]. It is possible to preemptively > detect a sufficient condition for when the length of the modified UTF-8 > encoding of the string parameter will exceed the maximum allowed value and > thereby avert any numerical overflow in incrementing the accumulator which > counts the number of encoded characters. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8219196 > [2] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ From brian.burkhalter at oracle.com Fri Mar 15 19:46:12 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 12:46:12 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: <8047579C-332C-43A0-AF9E-370BFBCE1E9C@oracle.com> May I ask ?why? if it cannot exceed 65535? > On Mar 15, 2019, at 12:40 PM, Martin Buchholz wrote: > > Consider changing utflen to a long. > > On Fri, Mar 15, 2019 at 12:25 PM Brian Burkhalter > wrote: > For [1] please review the proposed fix [2]. It is possible to preemptively detect a sufficient condition for when the length of the modified UTF-8 encoding of the string parameter will exceed the maximum allowed value and thereby avert any numerical overflow in incrementing the accumulator which counts the number of encoded characters. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8219196 > [2] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ From martinrb at google.com Fri Mar 15 19:54:07 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Mar 2019 12:54:07 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: <8047579C-332C-43A0-AF9E-370BFBCE1E9C@oracle.com> References: <8047579C-332C-43A0-AF9E-370BFBCE1E9C@oracle.com> Message-ID: On Fri, Mar 15, 2019 at 12:46 PM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > May I ask ?why? if it cannot exceed 65535? > You're right, that was a bad idea ... The repetition of the overflow check bothers me. Another idea: simply move the existing utflen > 65535 into the loop. With modern processors, that should be close to free. > On Mar 15, 2019, at 12:40 PM, Martin Buchholz wrote: > > Consider changing utflen to a long. > > On Fri, Mar 15, 2019 at 12:25 PM Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> For [1] please review the proposed fix [2]. It is possible to >> preemptively detect a sufficient condition for when the length of the >> modified UTF-8 encoding of the string parameter will exceed the maximum >> allowed value and thereby avert any numerical overflow in incrementing the >> accumulator which counts the number of encoded characters. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219196 >> [2] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ > > > From Roger.Riggs at oracle.com Fri Mar 15 19:57:35 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 Mar 2019 15:57:35 -0400 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Hi Brian, Looks ok. In the test, you could probably create the string using. ??? "\u0800".repeat(size); Instead of disabling the test statically, you could make it conditional on Runtime.maxMemory but the test will fail quickly anyway. DataOutputStream.java: Can you fix the indent lines 387-389, it seems to be only 3 chars. Regards, Roger On 03/15/2019 03:40 PM, Martin Buchholz wrote: > Consider changing utflen to a long. > > > On Fri, Mar 15, 2019 at 12:25 PM Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> For [1] please review the proposed fix [2]. It is possible to preemptively >> detect a sufficient condition for when the length of the modified UTF-8 >> encoding of the string parameter will exceed the maximum allowed value and >> thereby avert any numerical overflow in incrementing the accumulator which >> counts the number of encoded characters. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219196 >> [2] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ From brian.burkhalter at oracle.com Fri Mar 15 19:59:51 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 12:59:51 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <8047579C-332C-43A0-AF9E-370BFBCE1E9C@oracle.com> Message-ID: <09F63F09-828C-49F2-A462-2833BAC8F062@oracle.com> So like this: static int writeUTF(String str, DataOutput out) throws IOException { int strlen = str.length(); // use charAt instead of copying String to char array int utflen = 0; for (int i = 0; i < strlen && utflen < 65536; i++) { int c = str.charAt(i); if ((c >= 0x0001) && (c <= 0x007F)) { utflen++; } else if (c > 0x07FF) { utflen += 3; } else { utflen += 2; } } if (utflen > 65535) throw new UTFDataFormatException("encoded string too long"); > On Mar 15, 2019, at 12:54 PM, Martin Buchholz wrote: > > Another idea: simply move the existing utflen > 65535 into the loop. > With modern processors, that should be close to free. From brian.burkhalter at oracle.com Fri Mar 15 20:05:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 13:05:08 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Hi Roger, > On Mar 15, 2019, at 12:57 PM, Roger Riggs wrote: > > Looks ok. > > In the test, you could probably create the string using. > "\u0800".repeat(size); Good idea. > Instead of disabling the test statically, you could make it conditional > on Runtime.maxMemory but the test will fail quickly anyway. > > > DataOutputStream.java: > > Can you fix the indent lines 387-389, it seems to be only 3 chars. Will do. Thanks, Brian From brian.burkhalter at oracle.com Fri Mar 15 21:06:19 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 14:06:19 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ > On Mar 15, 2019, at 1:05 PM, Brian Burkhalter wrote: > >> On Mar 15, 2019, at 12:57 PM, Roger Riggs > wrote: >> >> Looks ok. >> >> In the test, you could probably create the string using. >> "\u0800".repeat(size); > > Good idea. > >> Instead of disabling the test statically, you could make it conditional >> on Runtime.maxMemory but the test will fail quickly anyway. For this I simply added the requirement to the jtreg tags instead. >> DataOutputStream.java: >> >> Can you fix the indent lines 387-389, it seems to be only 3 chars. > > Will do. Thanks, Brian From martinrb at google.com Fri Mar 15 22:13:29 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Mar 2019 15:13:29 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Looks good to me. On Fri, Mar 15, 2019 at 2:06 PM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ > > On Mar 15, 2019, at 1:05 PM, Brian Burkhalter > wrote: > > On Mar 15, 2019, at 12:57 PM, Roger Riggs wrote: > > Looks ok. > > In the test, you could probably create the string using. > "\u0800".repeat(size); > > > Good idea. > > Instead of disabling the test statically, you could make it conditional > on Runtime.maxMemory but the test will fail quickly anyway. > > > For this I simply added the requirement to the jtreg tags instead. > > DataOutputStream.java: > > Can you fix the indent lines 387-389, it seems to be only 3 chars. > > > Will do. > > > Thanks, > > Brian > From alexander.matveev at oracle.com Sat Mar 16 00:07:13 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 15 Mar 2019 17:07:13 -0700 Subject: RFR: JDK-8220264: msi installer does not remove some files if app installed into non-default location Message-ID: <1d049b4b-14b7-7d89-990e-8b9c9637f806@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Problem was that we did not restore APPLICATIONFOLDER correctly and it was set to default value. Fixed by forcing reading registry from 64-bit. [1] https://bugs.openjdk.java.net/browse/JDK-8220264 [2] http://cr.openjdk.java.net/~almatvee/8220264/webrev.00/ Thanks, Alexander From claes.redestad at oracle.com Sat Mar 16 00:43:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 16 Mar 2019 01:43:28 +0100 Subject: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES In-Reply-To: References: <64e5c960-259c-1cca-9528-82ceca3d0dbc@oracle.com> <4f086575-1f20-dd78-ab1d-4a60cd919623@oracle.com> Message-ID: <5256ce5a-34c0-090b-01cb-0166a46aea51@oracle.com> On 2019-03-15 19:06, Peter Levart wrote: > On 3/15/19 5:14 PM, Claes Redestad wrote: >> Hi Peter, >> >> thanks for reviewing! >> >> Interning arbitrary attribute names might have some unfortunate side- >> effects, > > You mean if the number of different names would get larger and larger on > a long-running JVM, the cache would grow without bounds? Yes. > > I noticed that the Name constructor: > > ??????? public Name(String name) { > ??????????? this.hashCode = hash(name); > ??????????? this.name = name.intern(); > ??????? } > > ...interns the String name. Do interned strings have a weak cache or are > they kept for the entire life of JVM? I think you can think of them as only weakly referenced by the VM, so yes, they will be GCd if no-one keeps them alive. /Claes From stuart.marks at oracle.com Sat Mar 16 01:04:05 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 15 Mar 2019 18:04:05 -0700 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> Message-ID: <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> > I'm talking about the perf difference between stream.forEach and for(var element: stream), forEachRemaining may be slower because for the VM the ideal case is to see the creation of the Stream and the call to the terminal operation inside the same inlining horizon so the creation of the Stream itself can be elided. > > A bit of history: they have been several prototypes of how to implement the stream API before the current one, one of them (i think it's the first one) was based on iterators and iterators of iterators, one for each step of the Stream. The perf of that implementation was good until there was too many intermediary ops calls on the Stream and at that point perf were really bad. It's because the VM has two way to find the type of something in a generic code, it can build a profile by remembering what class was used for a method call or it can propagate the type of an argument to the type of the corresponding parameter. Because an iterator stores the element to return in a field, you are loosing the later way to optimize and the former only work if you have no more than 2 different classes in the profile. > So while Stream.iterator() may be optimized, it's not that simple. Yes, I remember this prototype. Sure, iterating from stream.iterator() will likely be slower than stream.forEach(), because of (current) limitations in JIT compilation. This may be important for performance-critical applications. So if you have such an application, you should be aware of possible performance issues using such an iterator(), measure, and recode if necessary. Is this an argument not to allow Stream in a for-loop? I don't think so. There's a (fairly narrow) set of use cases where it's really necessary, and in most cases performance isn't an issue. After all, people use things like List which is known to be terrible for large, performance-critical applications. But most apps are small and aren't performance critical, and for those, it's just fine. >>> This proposal has the side effect of making Stream more different from its >>> primitive counterpart IntStream, LongStream and DoubleStream which may be >>> problematic because we are trying to introduce reified generics as part of >>> Valhalla (there is a recent mail of Brian about not adding methods to >>> OptionalInt for the same reason). >> >> Well, yes, I think that it means that Stream evolves somewhat independently of >> Int/Long/DoubleStream, but I don't see that this imposes an impediment on >> generic specialization in Valhalla. In that world, Stream should (mostly) >> just work. It may also be possible in a specialized world to add the specific >> things from IntStream (such as sum() and max()) to Stream. > > We may want more here, like having Stream being a subtype of IntStream so there is only one implementation for IntStream and Stream. > Thus adding a method that make IntStream and Stream different just make this kind of retrofitting more unlikely. I think the argument about specialization runs the other way, which is not to add stuff to IntStream. Adding IterableOnce to Stream shouldn't really affect anything with respect to generic specialization. The type is already Stream. The Iterable methods that are inherited (iterator, spliterator, forEach) all match existing methods on Stream, at least structurally. So I don't see that this would cause a problem. (Hm, I note that there is a slight semantic disagreement between Iterable::forEach and Stream::forEach. Stream::forEach allows parallelism, which isn't mentioned in Iterable::forEach. Somebody could conceivably call Iterable::forEach with a consumer that's not thread-safe, and if a parallel stream gets passed in, it would break that consumer. This strikes me as an edge case to be filed off, rather than a fatal problem, though.) >>> And, the real issue is how to deal with checked exceptions inside the Stream >>> API, i would prefer to fix that issue instead of trying to find a way to >>> workaround it. >> >> Well I'd like to have a solution for checked exceptions as well, but there >> doesn't appear to be one on the horizon. I mean, there are some ideas floating >> around, but nobody is working on them as far as I know. > > as far as i know, there are two of them, > - one is to get ride of checked exception, even Kotlin which tout itself as a language that is more safe that Java doesn't have checked exception, basically Java is the only language that run of the JVM and have checked exception. > - the other is to automatically wrap checked exceptions into a corresponding unchecked exception by letting the compiler generate the code that users currently write when the checked exception appear some context > by example with the keyword autowrap, > - you have the autowrap block (syntactically like a synchronized block) > autowrap { > return Files.newInputStream(path); // IOException is transformed to UncheckedIOException by calling IOException.wrap() > } > - you can use autowrap on a method declaration > void foo(Path path) autowrap { > return Files.newInputStream(path); // IOException is transformed to UncheckedIOException by calling IOException.wrap() > } > - you can use autowrap with a functional interface > void runBlock(autoWrap Consumer consumer) { ... } > ... > runblock(() -> { > Files.newInputStream(path); // IOException is transformed to UncheckedIOException by calling IOException.wrap() > }); I can think of several other approaches but I don't want to discuss them here. >> But checked exceptions aren't the only reason to prefer iteration in some cases; >> loops offer more flexible control flow (break/continue) and easier handling of >> side effects. The Streams+IterableOnce feature benefits these cases as well as >> exception handling. > > the break/continue equivalent on Stream are skip/limit/findFirst/takeWhile/dropWhile i.e. any short-circuit terminal operations. Right: many, but not all loops with "break" can be rewritten to use streams with a short-circuit terminal operation. But sometimes it's difficult, or you have to contort the stream in a particular way in order to get the result you want. For cases like those, sometimes it's just easier to write a loop. s'marks From peter.levart at gmail.com Mon Mar 18 09:37:06 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 18 Mar 2019 10:37:06 +0100 Subject: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <9610c889-190b-bae7-df42-865fd25a1a96@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <02349cb6-38f4-b444-e9db-ab2ee733ca8a@oracle.com> <233814698.1136383.1552596662338.JavaMail.zimbra@u-pem.fr> <94d2908a-0c56-8cb7-9ca9-8e17ad9d729b@gmail.com> <1961759036.1187933.1552637018656.JavaMail.zimbra@u-pem.fr> <24d84cc6-8e21-b6df-1af8-f0e56be1b75c@gmail.com> <8ff64203-9c35-309b-0080-1a1d64ad649b@oracle.com> <9610c889-190b-bae7-df42-865fd25a1a96@oracle.com> Message-ID: On 3/15/19 10:07 AM, Ivan Gerasimov wrote: > > > On 3/15/19 1:51 AM, Peter Levart wrote: >> >> >> On 3/15/19 9:38 AM, Ivan Gerasimov wrote: >>> Hi Peter! >>> >>> >>> On 3/15/19 1:24 AM, Peter Levart wrote: >>>> >>>> >>>> On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote: >>>>>> ????? * @since 13 >>>>>> ????? */ >>>>>> ???? interface Once {} >>>>>> >>>>>> >>>>>> What do you think of that? >>>>> It's not clear to me if an annotation, available at runtime, is >>>>> not a better fit. >>>>> Anyway, i'm not sure not sure introducing such >>>>> interface/annotation worth its maintenance cost, as you said the >>>>> use case is pretty narrow. >>>>> >>>> >>>> It is narrow, but in a situation like that, where you want to code >>>> an optimal generic algorithm and all you have access to is an >>>> Iterable, there's no other way (short of providing additional >>>> methods, which is ugly). Just think of this situation. You have to >>>> decide upfront if you need to buffer the elements obtained from 1st >>>> iteration or not, but 1st iteration always succeeds... >>>> >>> Can you please explain how the interface Once would help to solve this? >>> If an Iterable does not implement Once, it does not mean it allows >>> multiple passes, right? >> >> It does not guarantee multiple passes, that's right, but that's >> legacy. This situation is the same for IterableOnce as a subtype of >> Iterable, but marker interface has less chance to intrude into >> "visible" static types that consist of method signatures, type >> parameters and variable types and therefore does not cause confusion >> in that area. >> >> "Once" is not perfect, but allows generic algorithms to work on those >> instances that do implement it at least. >> > Thanks for clarifying! > My point was that in the situation you described, an interface Many > (or MultiPass, or how ever it's named) would be more appropriate. > If an Iterable implements it, there is a guarantee.? Otherwise it has > to be assumed a one-shot Iterable. > > With kind regards, > Ivan Yes, that would be safer, but also less useful as most current implementations support multi-pass iteration and would have to be updated to implement this new interface. Unless majority of multi-pass capable implementations consist of Collection(s) in which case this "MultiPass" interface could be added as a super-interface to java.util.Collection. If this is true, then testing against java.util.Collection could be a usefull-enough runtime check for the edge cases of hypothetical generic algorithms that need multiple passes and we don't even need the "MultiPass" interface... Regards, Peter From goetz.lindenmaier at sap.com Mon Mar 18 09:57:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Mar 2019 09:57:17 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> Message-ID: Hi, > You touch an important point here - who is this feature for? Is it for > the casual developer in need of some hand holding? Or is it for > diagnosing complex instrumented stacks? I think the two use cases are > not necessarily similar and might be served by different sets of > enhancements. Do you propose to have two different messages, to be selected by some flag or the like? To my knowledge exceptions have only one message, and it should be as helpful as possible I think. > In the latter case it might be ok, for instance, to say > "and, btw, the NPE came from local[1]". But for users in the former > bucket (and most users, really), this level of detail will simply be > unacceptable >(since now they have to understand the JVMS to parse the > message :-)). Can you please elaborate why they have to understand the JVMS? And why would information you don't need be unacceptable? You can just ignore it ... Best regards, Goetz. > I suggest we separate the use cases, at least for the purpose of the > design discussion. > > Maurizio > > On 15/03/2019 13:11, Lindenmaier, Goetz wrote: > > Hi Maurizio, > > > > thanks for sharing your patch! This is about what I thought about > > so far, just that it's working already :) > > > > It prints the information of the failing bytecode. Adding the dataflow > > analysis, the other information could be printed as well. > > > > The major problem I see is here: > > + File f = new File(location.getFile(), > > + clazz.getCanonicalName().replaceAll("\\.", "/") + ".class"); > > + ClassReader cr = new ClassReader(new FileInputStream(f)); > > + ClassNode classNode = new ClassNode(); > > + cr.accept(classNode, 0); > > > > As I understand, this reads the Bytecode from the classfile. > > The bytecode in the classfile must not match that executed > > by the VM, i.e, the pc you get from the stackWalker will not > > reference the bytecode that caused the NPE. > > > > Other issues have been discussed in the mail thread before. > > Good that you point this out, I'll add it to the JEP. > > > > Best regards, > > Goetz > > > > ... Sorry, I missed the "reply all" on my first reply. > > > > > > > > > >> -----Original Message----- > >> From: Maurizio Cimadamore > >> Sent: Freitag, 15. M?rz 2019 12:33 > >> To: Lindenmaier, Goetz ; Mandy Chung > >> ; Roger Riggs > >> Cc: Java Core Libs ; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > >> describing what is null. > >> > >> Hi Goetz, > >> please find the attached ASM-based patch. It is just a PoC, as such it > >> does not provide as fine-grained messages as the one discussed in the > >> RFE/JEP, but can be enhanced to cover custom debugging attribute, I > believe. > >> > >> When running this: > >> > >> Object o = null; > >> o.toString(); > >> > >> you get: > >> > >> Exception in thread "main" java.lang.NullPointerException: attempt to > >> dereference 'null' when calling method 'toString' > >> ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) > >> > >> While when running this: > >> > >> Foo foo = null; > >> int y = foo.x; > >> > >> You get this: > >> > >> Exception in thread "main" java.lang.NullPointerException: attempt to > >> dereference 'null' when accessing field 'x' > >> ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) > >> > >> One problem I had is that ASM provides no way to get the instruction > >> given a program counter - which means we have to scan all the bytecodes > >> and update the sizes as we go along, and, ASM unfortunately doesn?t > >> expose opcode sizes either. A more robust solution would be to have a > >> big switch which returned the opcode size of any given opcode. Also, > >> accessing to StackWalker API on exception creation might not be > >> desirable in terms of performances, so this might be one of these area > >> where some VM help could be beneficial. Another problem is that we > >> cannot distinguish between user-generated exceptions (e.g. `throw new > >> NullPointerException`) and genuine NPE issued by the VM. > >> > >> But I guess the upshot is that it works to leave all the gory detail of > >> bytecode grovelling to a bytecode API - if the logic is applied lazily, > >> then the impact on performances should be minimal, and the solution more > >> maintainable longer term. > >> > >> Cheers > >> Maurizio > >> > >> On 15/03/2019 07:59, Lindenmaier, Goetz wrote: > >>> Yes, it would be nice if you shared that. From goetz.lindenmaier at sap.com Mon Mar 18 10:01:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Mar 2019 10:01:08 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <13d21753-689e-547e-a0c7-9dbf9c9bee7f@oracle.com> Message-ID: Hi Mandy, > ... This brings up one > issue that when constructing the enhanced NPE message, a method > might become obsolete due to redefintion, it should handle > gracefully. The C++ solution has access to the proper version of redefined codes, so this is no problem. It is attached to the backtrace. And yes, in the Java variant we could just skip the message if we don't have the proper variant of the bytecode at hand. But we need a way to find out that this is the case. It's unclear to me how this should work ... it also depends on the way we retrieve the bytecodes to analyze. Best regards, Goetz. > Mandy > > On 3/15/19 10:34 AM, Maurizio Cimadamore wrote: > > You touch an important point here - who is this feature for? Is it for > > the casual developer in need of some hand holding? Or is it for > > diagnosing complex instrumented stacks? I think the two use cases are > > not necessarily similar and might be served by different sets of > > enhancements. In the latter case it might be ok, for instance, to say > > "and, btw, the NPE came from local[1]". But for users in the former > > bucket (and most users, really), this level of detail will simply be > > unacceptable (since now they have to understand the JVMS to parse the > > message :-)). > > > > I suggest we separate the use cases, at least for the purpose of the > > design discussion. > > > > Maurizio > > > > On 15/03/2019 13:11, Lindenmaier, Goetz wrote: > >> Hi Maurizio, > >> > >> thanks for sharing your patch!? This is about what I thought about > >> so far, just that it's working already :) > >> > >> It prints the information of the failing bytecode.? Adding the dataflow > >> analysis, the other information could be printed as well. > >> > >> The major problem I see is here: > >> +??????????? File f = new File(location.getFile(), > >> +??????????????????? clazz.getCanonicalName().replaceAll("\\.", "/") + > >> ".class"); > >> +??????????? ClassReader cr = new ClassReader(new FileInputStream(f)); > >> +??????????? ClassNode classNode = new ClassNode(); > >> +??????????? cr.accept(classNode, 0); > >> > >> As I understand, this reads the Bytecode from the classfile. > >> The bytecode in the classfile must not match that executed > >> by the VM, i.e, the pc you get from the stackWalker will not > >> reference the bytecode that caused the NPE. > >> > >> Other issues have been discussed in the mail thread before. > >> Good that you point this out, I'll add it to the JEP. > >> > >> Best regards, > >> ?? Goetz > >> > >> ... Sorry, I missed the "reply all" on my first reply. > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Maurizio Cimadamore > >>> Sent: Freitag, 15. M?rz 2019 12:33 > >>> To: Lindenmaier, Goetz ; Mandy Chung > >>> ; Roger Riggs > >>> Cc: Java Core Libs ; hotspot-runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR(L): 8218628: Add detailed message to > >>> NullPointerException > >>> describing what is null. > >>> > >>> Hi Goetz, > >>> please find the attached ASM-based patch. It is just a PoC, as such it > >>> does not provide as fine-grained messages as the one discussed in the > >>> RFE/JEP, but can be enhanced to cover custom debugging attribute, I > >>> believe. > >>> > >>> When running this: > >>> > >>> Object o = null; > >>> o.toString(); > >>> > >>> you get: > >>> > >>> Exception in thread "main" java.lang.NullPointerException: attempt to > >>> dereference 'null' when calling method 'toString' > >>> ? ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) > >>> > >>> While when running this: > >>> > >>> Foo foo = null; > >>> int y = foo.x; > >>> > >>> You get this: > >>> > >>> Exception in thread "main" java.lang.NullPointerException: attempt to > >>> dereference 'null' when accessing field 'x' > >>> ? ??? at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) > >>> > >>> One problem I had is that ASM provides no way to get the instruction > >>> given a program counter - which means we have to scan all the bytecodes > >>> and update the sizes as we go along, and, ASM unfortunately doesn?t > >>> expose opcode sizes either. A more robust solution would be to have a > >>> big switch which returned the opcode size of any given opcode. Also, > >>> accessing to StackWalker API on exception creation might not be > >>> desirable in terms of performances, so this might be one of these area > >>> where some VM help could be beneficial. Another problem is that we > >>> cannot distinguish between user-generated exceptions (e.g. `throw new > >>> NullPointerException`) and genuine NPE issued by the VM. > >>> > >>> But I guess the upshot is that it works to leave all the gory detail of > >>> bytecode grovelling to a bytecode API - if the logic is applied lazily, > >>> then the impact on performances should be minimal, and the solution > more > >>> maintainable longer term. > >>> > >>> Cheers > >>> Maurizio > >>> > >>> On 15/03/2019 07:59, Lindenmaier, Goetz wrote: > >>>> Yes, it would be nice if you shared that. From sgehwolf at redhat.com Mon Mar 18 10:06:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Mar 2019 11:06:02 +0100 Subject: [PING] RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: Hi, Could I get a review from an OpenJDK Reviewer for this, please? Bob is already OK with it. Thanks, Severin On Thu, 2019-03-14 at 13:58 -0400, Bob Vandette wrote: > The change looks good. Thanks for fixing this. > > I?d send this to core-libs (cc?d). > > Bob. > > > > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf wrote: > > > > Hi, > > > > I'm not sure what the right list for Metrics.java[1] is. Assuming it's > > serviceability-dev: > > > > Please review this one-liner for for SubSystem.java which currently > > behaves differently from the native implementation in > > osContainer_linux.cpp. Please see the details in the bug. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ > > > > Testing: > > Manual testing of JDK-8217338 with Metrics.java support with/without > > this fix on Linux x86_64. Metrics tests and Docker tests continue to > > pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, which > > was fun). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > > From adinn at redhat.com Mon Mar 18 10:14:56 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 18 Mar 2019 10:14:56 +0000 Subject: [PING] RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: On 18/03/2019 10:06, Severin Gehwolf wrote: > Could I get a review from an OpenJDK Reviewer for this, please? Bob is > already OK with it. Yes, this is fine. Reviewed. regards, Andrew Dinn ----------- From andy.herrick at oracle.com Mon Mar 18 12:51:11 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 18 Mar 2019 08:51:11 -0400 Subject: RFR: JDK-8220264: msi installer does not remove some files if app installed into non-default location In-Reply-To: <1d049b4b-14b7-7d89-990e-8b9c9637f806@oracle.com> References: <1d049b4b-14b7-7d89-990e-8b9c9637f806@oracle.com> Message-ID: <2fc1455c-8a9d-8623-0776-9b13b28fcb60@oracle.com> looks good. On 3/15/2019 8:07 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Problem was that we did not restore APPLICATIONFOLDER correctly and > it was set to default value. Fixed by forcing reading registry from > 64-bit. > > [1] https://bugs.openjdk.java.net/browse/JDK-8220264 > > [2] http://cr.openjdk.java.net/~almatvee/8220264/webrev.00/ > > Thanks, > Alexander From Roger.Riggs at oracle.com Mon Mar 18 13:40:41 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 Mar 2019 09:40:41 -0400 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Hi Brian, On 03/15/2019 05:06 PM, Brian Burkhalter wrote: > Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ > I'm at odds with Martin on including utflen in the loop.? (Or that's not what he meant). Now it has to do two comparisons for every input byte instead of 1. There is no need to have an early exit for input strings that are too long. It is a very unusual case, probably never except in testing. There might be a case for checking that? strlen <= 65535, (even at 1 input byte per output byte it would be too large). But even that is probably not worth the compare and branch. > >>> Instead of disabling the test statically, you could make it conditional >>> on Runtime.maxMemory but the test will fail quickly anyway. > > For this I simply added the requirement to the jtreg tags instead. With the fix, it will throw immediately before any allocation, so there is no need for a restriction on memory size. The only time that would be necessary would be running the test on a runtime without the fix. The @requires >4g restriction is unnecessary. $.02, Roger From sgehwolf at redhat.com Mon Mar 18 14:12:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Mar 2019 15:12:16 +0100 Subject: RFR: Container Fixes (8219652, 8217766, 8212528) In-Reply-To: References: Message-ID: <7df6979dc9df98b6f263d95e9a53cf899db82677.camel@redhat.com> Hi Bob, Changes look OK to me. I'd prefer if those issues would get addressed separately, though. 3 webrevs for 3 bugs, over lumping 3 bugs into 1 webrev. This makes it A) easier to review B) easier to backport to older releases if/when the time comes. Some of those issues are rather unrelated after all. Thanks, Severin On Thu, 2019-03-14 at 10:15 -0400, Bob Vandette wrote: > Ping ... > > > Please review these three fixes for Linux Docker/cgroup container > support. > > WEBREV: > > http://cr.openjdk.java.net/~bobv/8217766/webrev.0 > > ISSUE1: > > https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in > osContainer_linux.cpp#L102 appears unreachable > > This change corrects a rarely used hotspot code path making it > compatible with the Java based Metrics. > > ISSUE2: > > https://bugs.openjdk.java.net/browse/JDK-8212528 - Wrong cgroup > subsystem being used for some CPU Container Metrics > > Most Linux distros provide symbolic links for cpuacct and cpu > controller directories. Docker on the Mac does not. > This causes some of the cpu statistics to be unreported since the > directory name was incorrect. > > ISSUE3: > > https://bugs.openjdk.java.net/browse/JDK-8217766 - Container Support > doesn't work for some Join Controllers combinations > > The cgroup identification -implemented by parsing > /proc/self/mountinfo > and /proc/self/cgroup- assumed each cgroup controller was mounted > disjoint from the others (except for "cpu" and "cpuacct" > controllers). > Which means, we expected one single controller per mountinfo line. > > This matches the way most Linux distributions currently configure > cgroupsv1 by default. Yet controllers can be grouped arbitrarily. > For instance, using the systemd directive. > One use case for that is to let Kubernetes' kubelet discover his own > dedicated and reserved cgroup hierarchy. In that situation, the JVM > fails to discover the expected cgroup controllers set, and, when > running > containerized, default to a suboptimal understanding of available > resources. > > Supporting arbitrarily controllers groups per mountpoint actually > allows for simpler and easier to follow code, as we don't need nested > if/else for every controller. > > This fix also updates the Containers Metrics, to support joint > controllers. > > > Bob. From bob.vandette at oracle.com Mon Mar 18 14:49:49 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 18 Mar 2019 10:49:49 -0400 Subject: RFR: Container Fixes (8219652, 8217766, 8212528) In-Reply-To: <7df6979dc9df98b6f263d95e9a53cf899db82677.camel@redhat.com> References: <7df6979dc9df98b6f263d95e9a53cf899db82677.camel@redhat.com> Message-ID: <82A38EBF-2341-4D82-BC28-2546B374DA18@oracle.com> I will be committing each change individually but thought I?d save some time testing/reviewing. Thanks, Bob. > On Mar 18, 2019, at 10:12 AM, Severin Gehwolf wrote: > > Hi Bob, > > Changes look OK to me. > > I'd prefer if those issues would get addressed separately, though. 3 > webrevs for 3 bugs, over lumping 3 bugs into 1 webrev. This makes it > A) easier to review B) easier to backport to older releases if/when the > time comes. Some of those issues are rather unrelated after all. > > Thanks, > Severin > > On Thu, 2019-03-14 at 10:15 -0400, Bob Vandette wrote: >> Ping ... >> >> >> Please review these three fixes for Linux Docker/cgroup container >> support. >> >> WEBREV: >> >> http://cr.openjdk.java.net/~bobv/8217766/webrev.0 >> >> ISSUE1: >> >> https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in >> osContainer_linux.cpp#L102 appears unreachable >> >> This change corrects a rarely used hotspot code path making it >> compatible with the Java based Metrics. >> >> ISSUE2: >> >> https://bugs.openjdk.java.net/browse/JDK-8212528 - Wrong cgroup >> subsystem being used for some CPU Container Metrics >> >> Most Linux distros provide symbolic links for cpuacct and cpu >> controller directories. Docker on the Mac does not. >> This causes some of the cpu statistics to be unreported since the >> directory name was incorrect. >> >> ISSUE3: >> >> https://bugs.openjdk.java.net/browse/JDK-8217766 - Container Support >> doesn't work for some Join Controllers combinations >> >> The cgroup identification -implemented by parsing >> /proc/self/mountinfo >> and /proc/self/cgroup- assumed each cgroup controller was mounted >> disjoint from the others (except for "cpu" and "cpuacct" >> controllers). >> Which means, we expected one single controller per mountinfo line. >> >> This matches the way most Linux distributions currently configure >> cgroupsv1 by default. Yet controllers can be grouped arbitrarily. >> For instance, using the systemd directive. >> One use case for that is to let Kubernetes' kubelet discover his own >> dedicated and reserved cgroup hierarchy. In that situation, the JVM >> fails to discover the expected cgroup controllers set, and, when >> running >> containerized, default to a suboptimal understanding of available >> resources. >> >> Supporting arbitrarily controllers groups per mountpoint actually >> allows for simpler and easier to follow code, as we don't need nested >> if/else for every controller. >> >> This fix also updates the Containers Metrics, to support joint >> controllers. >> >> >> Bob. > From christoph.langer at sap.com Mon Mar 18 14:51:36 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 18 Mar 2019 14:51:36 +0000 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails Message-ID: Hi, please review a fix for 8172695, where java/util/Scanner/ScanTest.java fails. It reproducibly fails on one of our Mac servers, where the locale is set to en_DE. The test in its current form checks if the test VM is run with a supported default Locale by just checking the language to be one of "en", "zh", "ko", "ja". But it turns out, that also the country part seems to be important. I suggest to change the test case to test whether the VM's default locale is one of a restricted set of locales and if it isn't, it shall try to run with "ENGLISH". I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to work on my machine. Before pushing, I'd run it through the submit repo. bug: https://bugs.openjdk.java.net/browse/JDK-8172695 webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ Thanks Christoph From Roger.Riggs at oracle.com Mon Mar 18 15:59:07 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 Mar 2019 11:59:07 -0400 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> References: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> Message-ID: <69f1e5bd-d91b-410b-642c-a116dde15e14@oracle.com> Hi Alan, I checked the bytecode counts of the two versions and did not see a material difference so it is due to the lack of optimizations in fastdebug. $0.002, Roger On 03/14/2019 11:23 AM, Roger Riggs wrote: > Hi Alan, > > I didn't have a good idea where to look, the times do seem excessive. > Suggestions? > > Thanks, Roger > > > On 03/14/2019 11:09 AM, Alan Bateman wrote: >> On 14/03/2019 14:37, Roger Riggs wrote: >> Looks okay but the fastdebug times looks very long compared to other >> tests - do you know if there a specific assertion that is the issue >> here? >> > From brent.christian at oracle.com Mon Mar 18 16:49:49 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 18 Mar 2019 09:49:49 -0700 Subject: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp In-Reply-To: <3f558d46-9c37-334c-dfbc-5afba133a3a2@oracle.com> References: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> <3f558d46-9c37-334c-dfbc-5afba133a3a2@oracle.com> Message-ID: On 3/14/19 10:41 AM, Brent Christian wrote: > On 3/13/19 6:08 PM, Martin Buchholz wrote: >> >> Why not?Reference.reachabilityFence ? > > http://cr.openjdk.java.net/~bchristi/8220088/webrev.01/ > This looks good now, yes? -Brent From shade at redhat.com Mon Mar 18 17:12:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Mar 2019 18:12:52 +0100 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> References: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> Message-ID: <8d702d96-c889-65db-5dd3-186e305db404@redhat.com> On 3/14/19 4:23 PM, Roger Riggs wrote: > I didn't have a good idea where to look, the times do seem excessive. > Suggestions? You do it with profilers. Since fastdebug probably has the bottleneck in the JVM code, you need a native profiler. On Linux, you do this: $ CONF=linux-x86_64-server-fastdebug perf record -g make images run-test TEST=java/util/Arrays/TimSortStackSize2.java ...and then open "perf report" and meditate. Sometimes it is easier to produce the high-level flamegraph, for instance with https://github.com/KDAB/hotspot: http://cr.openjdk.java.net/~shade/8220613/perf-fastdebug.png What can you see here? G1 ConcurrentRefineThread spends a lot of time verifying stuff, as it would in fastdebug builds. This is one of the major contributors to this difference: release timing: real 0m12.485s user 0m40.930s sys 0m3.840s fastdebug timing: real 0m32.030s user 1m58.519s sys 0m5.172s So, there is 3-4x difference. It is way off the stated in original problem: Release images build: 4 seconds Fastdebug images build: 2.5 minutes Anyway, if you apply this: diff -r 98e21d4da074 test/jdk/java/util/Arrays/TimSortStackSize2.java --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java Mon Mar 18 15:21:33 2019 +0100 +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java Mon Mar 18 17:52:09 2019 +0100 @@ -71,4 +71,5 @@ OutputAnalyzer output = ProcessTools.executeTestJava(xmsValue, xmxValue, + "-XX:+UseParallelGC", "TimSortStackSize2", "67108864"); Then timings become: release: real 0m16.004s user 0m41.382s sys 0m4.660s fastdebug: real 0m17.292s user 1m8.225s sys 0m4.068s You repeat the profiling step to discover C2 becomes hot. Falling back to C1 would not help fastdebug timing, though, because less optimized code is not offsetting the better compiler performance. -Aleksey From mandy.chung at oracle.com Mon Mar 18 17:25:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 18 Mar 2019 10:25:49 -0700 Subject: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp In-Reply-To: <3f558d46-9c37-334c-dfbc-5afba133a3a2@oracle.com> References: <5c2db910-f1bb-bdb2-861b-3f01dc22f633@oracle.com> <3f558d46-9c37-334c-dfbc-5afba133a3a2@oracle.com> Message-ID: <34b83493-a574-2eed-a0fc-64191a53d5a7@oracle.com> On 3/14/19 10:41 AM, Brent Christian wrote: > On 3/13/19 6:08 PM, Martin Buchholz wrote: >> Why not?Reference.reachabilityFence ? > > You mean the mechanism for this precise situation.? Yeah, OK. > > http://cr.openjdk.java.net/~bchristi/8220088/webrev.01/ The use of Reference.reachabilityFence is good. You mentioned at one point that you wanted to move ForceGC utility to test library. This test can convert to that when it's available. The other part of this patch is to remove the shell test. Some suggested cleanup: I would suggest to use jdk.test.lib.compiler.CompilerUtils to compile A, B and C classes. and replace getClassImplFromDataBase with Paths.readAllBytes. Mandy From brian.burkhalter at oracle.com Mon Mar 18 17:41:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 18 Mar 2019 10:41:27 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: <16BAB7A8-E444-4378-8DE8-ABB40CA86F57@oracle.com> Hi Roger, > On Mar 18, 2019, at 6:40 AM, Roger Riggs wrote: > > On 03/15/2019 05:06 PM, Brian Burkhalter wrote: >> Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ > > I'm at odds with Martin on including utflen in the loop. (Or that's not what he meant). > Now it has to do two comparisons for every input byte instead of 1. That was my original thinking. > There is no need to have an early exit for input strings that are too long. > It is a very unusual case, probably never except in testing. > > There might be a case for checking that strlen <= 65535, > (even at 1 input byte per output byte it would be too large). > But even that is probably not worth the compare and branch. This is not clear to me. Are you saying that the proposed fix is not worth doing at all? If that?s not the case then perhaps it should revert to the first version [0] with the test modified to remove ?enabled = false?. Thanks, Brian [0] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ From martinrb at google.com Mon Mar 18 17:43:31 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2019 10:43:31 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: Hmmmm .... I took another look at this and Roger tickled my UTF-8 optimization spidey sense. Rewritten using Martin style: static int writeUTF(String str, DataOutput out) throws IOException { int strlen = str.length(); int utflen = strlen; // optimized for ASCII for (int i = 0; i < strlen; i++) { int c = str.charAt(i); if (c >= 0x80 || c == 0) utflen += (c >= 0x800) ? 2 : 1; } if (utflen > 65535) throw new UTFDataFormatException( "encoded string too long: " + utflen + " bytes"); final byte[] bytearr; if (out instanceof DataOutputStream) { DataOutputStream dos = (DataOutputStream)out; if (dos.bytearr == null || (dos.bytearr.length < (utflen + 2))) dos.bytearr = new byte[(utflen*2) + 2]; bytearr = dos.bytearr; } else { bytearr = new byte[utflen + 2]; } int count = 0; bytearr[count++] = (byte) ((utflen >>> 8) & 0xFF); bytearr[count++] = (byte) ((utflen >>> 0) & 0xFF); int i = 0; for (i = 0; i < strlen; i++) { // optimized for initial run of ASCII int c = str.charAt(i); if (c >= 0x80 || c == 0) break; bytearr[count++] = (byte) c; } for (; i < strlen; i++) { int c = str.charAt(i); if (c < 0x80 && c != 0) { bytearr[count++] = (byte) c; } else if (c >= 0x800) { bytearr[count++] = (byte) (0xE0 | ((c >> 12) & 0x0F)); bytearr[count++] = (byte) (0x80 | ((c >> 6) & 0x3F)); bytearr[count++] = (byte) (0x80 | ((c >> 0) & 0x3F)); } else { bytearr[count++] = (byte) (0xC0 | ((c >> 6) & 0x1F)); bytearr[count++] = (byte) (0x80 | ((c >> 0) & 0x3F)); } } out.write(bytearr, 0, utflen + 2); return utflen + 2; } On Mon, Mar 18, 2019 at 6:41 AM Roger Riggs wrote: > Hi Brian, > > On 03/15/2019 05:06 PM, Brian Burkhalter wrote: > > Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ > > > I'm at odds with Martin on including utflen in the loop. (Or that's not > what he meant). > Now it has to do two comparisons for every input byte instead of 1. > > There is no need to have an early exit for input strings that are too long. > It is a very unusual case, probably never except in testing. > > There might be a case for checking that strlen <= 65535, > (even at 1 input byte per output byte it would be too large). > But even that is probably not worth the compare and branch. > > > Instead of disabling the test statically, you could make it conditional > on Runtime.maxMemory but the test will fail quickly anyway. > > > For this I simply added the requirement to the jtreg tags instead. > > With the fix, it will throw immediately before any allocation, so there is > no need for a restriction on memory size. > The only time that would be necessary would be running the test on a > runtime without the fix. > > The @requires >4g restriction is unnecessary. > > $.02, Roger > > > From brian.burkhalter at oracle.com Mon Mar 18 17:57:59 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 18 Mar 2019 10:57:59 -0700 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: Message-ID: Hi Christoph, Not a locale expert here so you probably need to hear from someone else, but this looks like a reasonable approach to me. One minor comment is to perhaps use format() at lines 67-68 instead of println(). Thanks, Brian > On Mar 18, 2019, at 7:51 AM, Langer, Christoph wrote: > > please review a fix for 8172695, where java/util/Scanner/ScanTest.java fails. It reproducibly fails on one of our Mac servers, where the locale is set to en_DE. > > The test in its current form checks if the test VM is run with a supported default Locale by just checking the language to be one of ?en?, ?zh?, ?ko?, ?ja?. But it turns out, that also the country part seems to be important. I suggest to change the test case to test whether the VM?s default locale is one of a restricted set of locales and if it isn?t, it shall try to run with ?ENGLISH?. > > I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to work on my machine. Before pushing, I?d run it through the submit repo. > > bug: https://bugs.openjdk.java.net/browse/JDK-8172695 > webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ From Roger.Riggs at oracle.com Mon Mar 18 18:35:46 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 Mar 2019 14:35:46 -0400 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: Message-ID: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> Hi, Collapsing a couple of emails. On 03/18/2019 01:43 PM, Martin Buchholz wrote: > Hmmmm .... > > I took another look at this and Roger tickled my UTF-8 optimization > spidey sense.? Rewritten using Martin style: > > ? ? static int writeUTF(String str, DataOutput out) throws IOException { > ? ? ? ? int strlen = str.length(); > ? ? ? ? int utflen = strlen;? ? // optimized for ASCII > > ? ? ? ? for (int i = 0; i < strlen; i++) { > ? ? ? ? ? ? int c = str.charAt(i); > ? ? ? ? ? ? if (c >= 0x80 || c == 0) > ? ? ? ? ? ? ? ? utflen += (c >= 0x800) ? 2 : 1; > ? ? ? ? } @Martin, you'd need uftlen to be a long to avoid the original overflow to negative problem for an input string length > MAXINT / 3.? And that might be the cleanest. Compared to adding extra conditions in the loop. Otherwise, this code looks good, it might optimize to fewer branches than the original. > > ? ? ? ? if (utflen > 65535) > ? ? ? ? ? ? throw new UTFDataFormatException( > ? ? ? ? ? ? ? ? "encoded string too long: " + utflen + " bytes"); > > ? ? ? ? final byte[] bytearr; > ? ? ? ? if (out instanceof DataOutputStream) { > ? ? ? ? ? ? DataOutputStream dos = (DataOutputStream)out; > ? ? ? ? ? ? if (dos.bytearr == null || (dos.bytearr.length < (utflen + > 2))) > ? ? ? ? ? ? ? ? dos.bytearr = new byte[(utflen*2) + 2]; > ? ? ? ? ? ? bytearr = dos.bytearr; > ? ? ? ? } else { > ? ? ? ? ? ? bytearr = new byte[utflen + 2]; > ? ? ? ? } > > ? ? ? ? int count = 0; > ? ? ? ? bytearr[count++] = (byte) ((utflen >>> 8) & 0xFF); > ? ? ? ? bytearr[count++] = (byte) ((utflen >>> 0) & 0xFF); > > ? ? ? ? int i = 0; > ? ? ? ? for (i = 0; i < strlen; i++) { // optimized for initial run of > ASCII > ? ? ? ? ? ? int c = str.charAt(i); > ? ? ? ? ? ? if (c >= 0x80 || c == 0) break; > ? ? ? ? ? ? bytearr[count++] = (byte) c; > ? ? ? ? } > > ? ? ? ? for (; i < strlen; i++) { > ? ? ? ? ? ? int c = str.charAt(i); > ? ? ? ? ? ? if (c < 0x80 && c != 0) { > ? ? ? ? ? ? ? ? bytearr[count++] = (byte) c; > ? ? ? ? ? ? } > ? ? ? ? ? ? else if (c >= 0x800) { > ? ? ? ? ? ? ? ? bytearr[count++] = (byte) (0xE0 | ((c >> 12) & 0x0F)); > ? ? ? ? ? ? ? ? bytearr[count++] = (byte) (0x80 | ((c >>? 6) & 0x3F)); > ? ? ? ? ? ? ? ? bytearr[count++] = (byte) (0x80 | ((c >>? 0) & 0x3F)); > ? ? ? ? ? ? } else { > ? ? ? ? ? ? ? ? bytearr[count++] = (byte) (0xC0 | ((c >>? 6) & 0x1F)); > ? ? ? ? ? ? ? ? bytearr[count++] = (byte) (0x80 | ((c >>? 0) & 0x3F)); > ? ? ? ? ? ? } > ? ? ? ? } > ? ? ? ? out.write(bytearr, 0, utflen + 2); > ? ? ? ? return utflen + 2; > ? ? } > > > On Mon, Mar 18, 2019 at 6:41 AM Roger Riggs > wrote: > > Hi Brian, > > On 03/15/2019 05:06 PM, Brian Burkhalter wrote: >> Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ >> > > I'm at odds with Martin on including utflen in the loop. (Or > that's not what he meant). > Now it has to do two comparisons for every input byte instead of 1. > > There is no need to have an early exit for input strings that are > too long. > It is a very unusual case, probably never except in testing. > > There might be a case for checking that? strlen <= 65535, > (even at 1 input byte per output byte it would be too large). > But even that is probably not worth the compare and branch. > The test only needs enough memory to create the input string (MAXINT/3+1) and a bit more for the default sized ByteArrayOutputStream. So it should run in 2G configurations. So yes, removing the enabled = false is ok. Roger > >> >>>> Instead of disabling the test statically, you could make it >>>> conditional >>>> on Runtime.maxMemory but the test will fail quickly anyway. >> >> For this I simply added the requirement to the jtreg tags instead. > With the fix, it will throw immediately before any allocation, so > there is > no need for a restriction on memory size. > The only time that would be necessary would be running the test on > a runtime without the fix. > > The @requires >4g restriction is unnecessary. > > $.02, Roger > > From sergei.tsypanov at yandex.ru Mon Mar 18 19:09:26 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 18 Mar 2019 21:09:26 +0200 Subject: [PATCH] Some improvements for java.lang.Class In-Reply-To: Message-ID: <2796501552936166@myt6-add70abb4f02.qloud-c.yandex.net> Hi, I have an enhancement proposal for java.lang.Class.methodToString and java.lang.Class.getTypeName. First one is used when NoSuchMethodException is thrown from Class::getMethod which is in turn widely used in Spring Framework and often throws. In current implementation we have 2 major problems: - we create stream for the case when argTypes is not null but empty (which happens e. g. when Class::getMethod is called without vararg and throws) - we have torn StringBuilder::append chain I?ve modified the method to skip creation of Stream for empty array and used separate StringBuilder for each case. Latter allowed to rid SB completely and use invokedynamic-based concatenation. I?ve compared both approaches for 2 cases: 1) argTypes is empty 2) argTypes.length == 1 Benchmark Mode Cnt Score Error Units methodToString_noArgs avgt 25 170,986 ? 5,708 ns/op methodToString_noArgs_patched avgt 25 26,883 ? 2,906 ns/op methodToString_1arg avgt 25 183,012 ? 0,701 ns/op methodToString_1arg_patched avgt 25 112,784 ? 0,920 ns/op methodToString_noArgs:?gc.alloc.rate.norm avgt 25 881,600 ? 9,786 B/op methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 25 128,000 ? 0,001 B/op methodToString_1arg:?gc.alloc.rate.norm avgt 25 960,000 ? 0,001 B/op methodToString_1arg_patched:?gc.alloc.rate.norm avgt 25 552,000 ? 0,001 B/op We have the same problem regarding misusage of StringBuilder in Class:: getTypeName: StringBuilder sb = new StringBuilder(); sb.append(cl.getName()); for (int i = 0; i < dimensions; i++) { ??? sb.append("[]"); } return sb.toString(); I suggest to use String::repeat instead of the loop: this again allows to get rid of StringBuilder and replace mentioned code with return cl.getName() + "[]".repeat(dimensions); Here are benchmark results executed for type Object[].class: Mode Cnt Score Error Units getTypeName_patched avgt 25 16,037 ? 0,431 ns/op getTypeName_patched:?gc.alloc.rate.norm avgt 25 64,000 ? 0,001 B/op getTypeName avgt 25 34,274 ? 1,432 ns/op getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op Regards, Sergei Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: klass.patch Type: text/x-diff Size: 2028 bytes Desc: not available URL: From martinrb at google.com Mon Mar 18 20:03:13 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Mar 2019 13:03:13 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> Message-ID: You've again caught me only half paying attention. Below is another attempt at micro-optimization (might be too tricky!), BUT: - consider documenting the UTFDataFormatException and the 64k length limit - error message would actually be more useful if it contained a few chars from head and tail instead of length static int writeUTF(String str, DataOutput out) throws IOException { final int strlen = str.length(); int utflen = strlen; // optimized for ASCII for (int i = 0; i < strlen; i++) { int c = str.charAt(i); if (c >= 0x80 || c == 0) utflen += (c >= 0x800) ? 2 : 1; } if (utflen > 65535 || /* overflow */ utflen < strlen) throw new UTFDataFormatException(tooLongMsg(utflen)); final byte[] bytearr; if (out instanceof DataOutputStream) { DataOutputStream dos = (DataOutputStream)out; if (dos.bytearr == null || (dos.bytearr.length < (utflen + 2))) dos.bytearr = new byte[(utflen*2) + 2]; bytearr = dos.bytearr; } else { bytearr = new byte[utflen + 2]; } int count = 0; bytearr[count++] = (byte) ((utflen >>> 8) & 0xFF); bytearr[count++] = (byte) ((utflen >>> 0) & 0xFF); int i = 0; for (i = 0; i < strlen; i++) { // optimized for initial run of ASCII int c = str.charAt(i); if (c >= 0x80 || c == 0) break; bytearr[count++] = (byte) c; } for (; i < strlen; i++) { int c = str.charAt(i); if (c < 0x80 && c != 0) { bytearr[count++] = (byte) c; } else if (c >= 0x800) { bytearr[count++] = (byte) (0xE0 | ((c >> 12) & 0x0F)); bytearr[count++] = (byte) (0x80 | ((c >> 6) & 0x3F)); bytearr[count++] = (byte) (0x80 | ((c >> 0) & 0x3F)); } else { bytearr[count++] = (byte) (0xC0 | ((c >> 6) & 0x1F)); bytearr[count++] = (byte) (0x80 | ((c >> 0) & 0x3F)); } } out.write(bytearr, 0, utflen + 2); return utflen + 2; } private static String tooLongMsg(int bits32) { long actualLength = (bits32 > 0xFFFF) ? bits32 // handle int overflow : ((bits32 < 0) ? ((long)bits32 & 0xFFFFL) : bits32 + 0x10000L); return "encoded string too long: " + actualLength + " bytes"; } On Mon, Mar 18, 2019 at 11:36 AM Roger Riggs wrote: > Hi, > > Collapsing a couple of emails. > > On 03/18/2019 01:43 PM, Martin Buchholz wrote: > > Hmmmm .... > > I took another look at this and Roger tickled my UTF-8 optimization spidey > sense. Rewritten using Martin style: > > static int writeUTF(String str, DataOutput out) throws IOException { > int strlen = str.length(); > int utflen = strlen; // optimized for ASCII > > for (int i = 0; i < strlen; i++) { > int c = str.charAt(i); > if (c >= 0x80 || c == 0) > utflen += (c >= 0x800) ? 2 : 1; > } > > @Martin, you'd need uftlen to be a long to avoid the original overflow to > negative problem > for an input string length > MAXINT / 3. And that might be the cleanest. > Compared to adding > extra conditions in the loop. > > Otherwise, this code looks good, it might optimize to fewer branches than > the original. > > > if (utflen > 65535) > throw new UTFDataFormatException( > "encoded string too long: " + utflen + " bytes"); > > final byte[] bytearr; > if (out instanceof DataOutputStream) { > DataOutputStream dos = (DataOutputStream)out; > if (dos.bytearr == null || (dos.bytearr.length < (utflen + 2))) > dos.bytearr = new byte[(utflen*2) + 2]; > bytearr = dos.bytearr; > } else { > bytearr = new byte[utflen + 2]; > } > > int count = 0; > bytearr[count++] = (byte) ((utflen >>> 8) & 0xFF); > bytearr[count++] = (byte) ((utflen >>> 0) & 0xFF); > > int i = 0; > for (i = 0; i < strlen; i++) { // optimized for initial run of > ASCII > int c = str.charAt(i); > if (c >= 0x80 || c == 0) break; > bytearr[count++] = (byte) c; > } > > for (; i < strlen; i++) { > int c = str.charAt(i); > if (c < 0x80 && c != 0) { > bytearr[count++] = (byte) c; > } > else if (c >= 0x800) { > bytearr[count++] = (byte) (0xE0 | ((c >> 12) & 0x0F)); > bytearr[count++] = (byte) (0x80 | ((c >> 6) & 0x3F)); > bytearr[count++] = (byte) (0x80 | ((c >> 0) & 0x3F)); > } else { > bytearr[count++] = (byte) (0xC0 | ((c >> 6) & 0x1F)); > bytearr[count++] = (byte) (0x80 | ((c >> 0) & 0x3F)); > } > } > out.write(bytearr, 0, utflen + 2); > return utflen + 2; > } > > > On Mon, Mar 18, 2019 at 6:41 AM Roger Riggs > wrote: > >> Hi Brian, >> >> On 03/15/2019 05:06 PM, Brian Burkhalter wrote: >> >> Updated: http://cr.openjdk.java.net/~bpb/8219196/webrev.01/ >> >> >> I'm at odds with Martin on including utflen in the loop. (Or that's not >> what he meant). >> Now it has to do two comparisons for every input byte instead of 1. >> >> There is no need to have an early exit for input strings that are too >> long. >> It is a very unusual case, probably never except in testing. >> >> There might be a case for checking that strlen <= 65535, >> (even at 1 input byte per output byte it would be too large). >> But even that is probably not worth the compare and branch. >> > > The test only needs enough memory to create the input string (MAXINT/3+1) > and a bit more for the default sized ByteArrayOutputStream. > So it should run in 2G configurations. > > So yes, removing the enabled = false is ok. > > Roger > > > >> >> Instead of disabling the test statically, you could make it conditional >> on Runtime.maxMemory but the test will fail quickly anyway. >> >> >> For this I simply added the requirement to the jtreg tags instead. >> >> With the fix, it will throw immediately before any allocation, so there >> is >> no need for a restriction on memory size. >> The only time that would be necessary would be running the test on a >> runtime without the fix. >> >> The @requires >4g restriction is unnecessary. >> >> $.02, Roger >> >> >> > From Roger.Riggs at oracle.com Mon Mar 18 20:08:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 Mar 2019 16:08:51 -0400 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: <8d702d96-c889-65db-5dd3-186e305db404@redhat.com> References: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> <8d702d96-c889-65db-5dd3-186e305db404@redhat.com> Message-ID: <5b17876e-3a1e-ac8c-7229-852d689fdf25@oracle.com> Hi Akelsey, Thanks for the suggestions. The biggest difference seems to come from the -XX:-UseCompressedOops flag both release and fastdebug builds. The purpose of the test was to check that the stack size required is not excessive.? So what I think I need to answer is whether it is beneficial to run this test and under what conditions. The sort algorithm itself is not going change since the data to be sorted is generated. So the only variable is how much stack is used for each call. And is it a beneficial use of 2.5 minutes of test time? Thanks, Roger On 03/18/2019 01:12 PM, Aleksey Shipilev wrote: > On 3/14/19 4:23 PM, Roger Riggs wrote: >> I didn't have a good idea where to look, the times do seem excessive. >> Suggestions? > You do it with profilers. Since fastdebug probably has the bottleneck in the JVM code, you need a > native profiler. On Linux, you do this: > > $ CONF=linux-x86_64-server-fastdebug perf record -g make images run-test > TEST=java/util/Arrays/TimSortStackSize2.java > > ...and then open "perf report" and meditate. Sometimes it is easier to produce the high-level > flamegraph, for instance with https://github.com/KDAB/hotspot: > http://cr.openjdk.java.net/~shade/8220613/perf-fastdebug.png > > What can you see here? G1 ConcurrentRefineThread spends a lot of time verifying stuff, as it would > in fastdebug builds. This is one of the major contributors to this difference: > > release timing: > real 0m12.485s > user 0m40.930s > sys 0m3.840s > > fastdebug timing: > real 0m32.030s > user 1m58.519s > sys 0m5.172s > > So, there is 3-4x difference. It is way off the stated in original problem: > Release images build: 4 seconds > Fastdebug images build: 2.5 minutes > > Anyway, if you apply this: > > diff -r 98e21d4da074 test/jdk/java/util/Arrays/TimSortStackSize2.java > --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java Mon Mar 18 15:21:33 2019 +0100 > +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java Mon Mar 18 17:52:09 2019 +0100 > @@ -71,4 +71,5 @@ > OutputAnalyzer output = ProcessTools.executeTestJava(xmsValue, > xmxValue, > + "-XX:+UseParallelGC", > "TimSortStackSize2", > "67108864"); > > Then timings become: > > release: > real 0m16.004s > user 0m41.382s > sys 0m4.660s > > > fastdebug: > real 0m17.292s > user 1m8.225s > sys 0m4.068s > > You repeat the profiling step to discover C2 becomes hot. Falling back to C1 would not help > fastdebug timing, though, because less optimized code is not offsetting the better compiler performance. > > > -Aleksey > From Alan.Bateman at oracle.com Mon Mar 18 20:10:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Mar 2019 20:10:36 +0000 Subject: RFR 8220613: [TEST] java/util/Arrays/TimSortStackSize2.java times out with fastdebug build In-Reply-To: <69f1e5bd-d91b-410b-642c-a116dde15e14@oracle.com> References: <8d136564-fc85-6c38-cffe-99d40a168699@oracle.com> <6dda4566-4486-ec5c-64d9-84e31259cabc@oracle.com> <69f1e5bd-d91b-410b-642c-a116dde15e14@oracle.com> Message-ID: <780806e8-03c7-592b-4f23-25d0c6f47910@oracle.com> On 18/03/2019 15:59, Roger Riggs wrote: > Hi Alan, > > I checked the bytecode counts of the two versions and did not see > a material difference so it is due to the lack of optimizations in > fastdebug. What I meant is whether profiling has hinted at anything obvious, maybe an expense assert or some non-product code. In any case, I think what you have is fine and it would be good to get it off the exclude list (it should not have been put there in the first place of course). -Alan From kim.barrett at oracle.com Mon Mar 18 23:17:58 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Mar 2019 19:17:58 -0400 Subject: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs In-Reply-To: <4a589284-4e4d-5d4c-7441-6d00a9725fe3@oracle.com> References: <97572862-2C28-4ED7-ACEA-E23C6A148526@oracle.com> <6F6648D3-2536-4047-B73B-0A0411960F49@oracle.com> <4a589284-4e4d-5d4c-7441-6d00a9725fe3@oracle.com> Message-ID: <191DEA12-EFCB-4A5F-80BE-4B7F95DB22C7@oracle.com> > On Mar 14, 2019, at 12:40 AM, David Holmes wrote: > > Looks good. > > Thanks Kim! > > David Thanks. From forax at univ-mlv.fr Mon Mar 18 23:38:24 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 19 Mar 2019 00:38:24 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> Message-ID: <765913287.277879.1552952304666.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Samedi 16 Mars 2019 02:04:05 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams >> I'm talking about the perf difference between stream.forEach and for(var >> element: stream), forEachRemaining may be slower because for the VM the ideal >> case is to see the creation of the Stream and the call to the terminal >> operation inside the same inlining horizon so the creation of the Stream itself >> can be elided. >> >> A bit of history: they have been several prototypes of how to implement the >> stream API before the current one, one of them (i think it's the first one) was >> based on iterators and iterators of iterators, one for each step of the Stream. >> The perf of that implementation was good until there was too many intermediary >> ops calls on the Stream and at that point perf were really bad. It's because >> the VM has two way to find the type of something in a generic code, it can >> build a profile by remembering what class was used for a method call or it can >> propagate the type of an argument to the type of the corresponding parameter. >> Because an iterator stores the element to return in a field, you are loosing >> the later way to optimize and the former only work if you have no more than 2 >> different classes in the profile. >> So while Stream.iterator() may be optimized, it's not that simple. > > Yes, I remember this prototype. Sure, iterating from stream.iterator() will > likely be slower than stream.forEach(), because of (current) limitations in JIT > compilation. This may be important for performance-critical applications. So if > you have such an application, you should be aware of possible performance issues > using such an iterator(), measure, and recode if necessary. > > Is this an argument not to allow Stream in a for-loop? I don't think so. There's > a (fairly narrow) set of use cases where it's really necessary, and in most > cases performance isn't an issue. After all, people use things like > List which is known to be terrible for large, performance-critical > applications. But most apps are small and aren't performance critical, and for > those, it's just fine. I suppose that if you do a presentation a devoxx on that subject and if IDEs recommend to use Stream.forEach instead of the enhanced for loop when possible then it will be fine. > >>>> This proposal has the side effect of making Stream more different from its >>>> primitive counterpart IntStream, LongStream and DoubleStream which may be >>>> problematic because we are trying to introduce reified generics as part of >>>> Valhalla (there is a recent mail of Brian about not adding methods to >>>> OptionalInt for the same reason). >>> >>> Well, yes, I think that it means that Stream evolves somewhat independently of >>> Int/Long/DoubleStream, but I don't see that this imposes an impediment on >>> generic specialization in Valhalla. In that world, Stream should (mostly) >>> just work. It may also be possible in a specialized world to add the specific >>> things from IntStream (such as sum() and max()) to Stream. >> >> We may want more here, like having Stream being a subtype of IntStream so >> there is only one implementation for IntStream and Stream. >> Thus adding a method that make IntStream and Stream different just make >> this kind of retrofitting more unlikely. > > I think the argument about specialization runs the other way, which is not to > add stuff to IntStream. > > Adding IterableOnce to Stream shouldn't really affect anything with respect to > generic specialization. The type is already Stream. The Iterable methods > that are inherited (iterator, spliterator, forEach) all match existing methods > on Stream, at least structurally. So I don't see that this would cause a > problem. > > (Hm, I note that there is a slight semantic disagreement between > Iterable::forEach and Stream::forEach. Stream::forEach allows parallelism, which > isn't mentioned in Iterable::forEach. Somebody could conceivably call > Iterable::forEach with a consumer that's not thread-safe, and if a parallel > stream gets passed in, it would break that consumer. This strikes me as an edge > case to be filed off, rather than a fatal problem, though.) My fear is more than we will want in the future to have one code for all kinds of Stream, but Stream will have to implement Iterable while Stream will not, this not something you can actually do with the current generics, we may be able to do that with the reified generics but some languages that already have reified generics like Swift are not able to do that. So by making Stream to have different set of supertypes than Stream, you are forcing the future reified generics implementation to work on this case because we will never introduce an implementation of reified generics that doesn't support the classe of java.util. > > >>>> And, the real issue is how to deal with checked exceptions inside the Stream >>>> API, i would prefer to fix that issue instead of trying to find a way to >>>> workaround it. >>> >>> Well I'd like to have a solution for checked exceptions as well, but there >>> doesn't appear to be one on the horizon. I mean, there are some ideas floating >>> around, but nobody is working on them as far as I know. >> >> as far as i know, there are two of them, >> - one is to get ride of checked exception, even Kotlin which tout itself as a >> language that is more safe that Java doesn't have checked exception, basically >> Java is the only language that run of the JVM and have checked exception. >> - the other is to automatically wrap checked exceptions into a corresponding >> unchecked exception by letting the compiler generate the code that users >> currently write when the checked exception appear some context >> by example with the keyword autowrap, >> - you have the autowrap block (syntactically like a synchronized block) >> autowrap { >> return Files.newInputStream(path); // IOException is transformed to >> UncheckedIOException by calling IOException.wrap() >> } >> - you can use autowrap on a method declaration >> void foo(Path path) autowrap { >> return Files.newInputStream(path); // IOException is transformed to >> UncheckedIOException by calling IOException.wrap() >> } >> - you can use autowrap with a functional interface >> void runBlock(autoWrap Consumer consumer) { ... } >> ... >> runblock(() -> { >> Files.newInputStream(path); // IOException is transformed to >> UncheckedIOException by calling IOException.wrap() >> }); > > I can think of several other approaches but I don't want to discuss them here. the thing is that we have already established that we only want the enhanced for loop in a small number of use cases, if we get ride of checked exceptions one way or another, we may end up will a really small number of use cases, for the enhanced for loop over a stream. > >>> But checked exceptions aren't the only reason to prefer iteration in some cases; >>> loops offer more flexible control flow (break/continue) and easier handling of >>> side effects. The Streams+IterableOnce feature benefits these cases as well as >>> exception handling. >> >> the break/continue equivalent on Stream are >> skip/limit/findFirst/takeWhile/dropWhile i.e. any short-circuit terminal >> operations. > > Right: many, but not all loops with "break" can be rewritten to use streams with > a short-circuit terminal operation. But sometimes it's difficult, or you have to > contort the stream in a particular way in order to get the result you want. For > cases like those, sometimes it's just easier to write a loop. fair enough. so to summarize, i'm not against the making the enhanced for loop working with streams - if Brian think it's Ok to have Stream and IntStream to have different super types - if people are Ok that maybe the enhanced for loop is slower than a call to stream.forEach and that's fine - if the semantics of Iterable is fixed to allow to use the iterator only once instead of introducing IterableOnce. > > s'marks regards, R?mi From stuart.marks at oracle.com Mon Mar 18 23:43:34 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 18 Mar 2019 16:43:34 -0700 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: Message-ID: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> Hi Christoph, After looking at this for a little bit I realized that it's not necessary to have a system particular default locale in order to get the test case to fail. It's possible create a locale that causes test case to fail, like so: Locale.setDefault(new Locale("en", "DE")) Scanner sc = new Scanner("\u0f23.\u0f27"); sc.nextFloat(); ^ throws InputMismatchException (This is because using "DE" as the locale's country causes texpects , instead of . as the decimal separator.) The test already saves the current default locale and attempts to find a known good locale for running the tests. The difficulty seems to be finding a "known good" locale. The current check for the language of English doesn't work if the default is en_DE. Instead, I'd suggest we use the root locale Locale.ROOT as the known good locale for running the tests. We could then do something like this: Locale reservedLocale = Locale.getDefault(); try { Locale.setDefault(Locale.ROOT); // run all the tests } finally { // restore the default locale Locale.setDefault(reservedLocale); } and dispense with the logic of searching the existing locales for one that we think is suitable. (Actually, since the test is being run in /othervm mode, it's not clear to me that restoring the previous default locale is necessary. But that's kind of a separate discussion. I'm ok with leaving the save/restore in place.) s'marks On 3/18/19 10:57 AM, Brian Burkhalter wrote: > Hi Christoph, > > Not a locale expert here so you probably need to hear from someone else, but this looks like a reasonable approach to me. One minor comment is to perhaps use format() at lines 67-68 instead of println(). > > Thanks, > > Brian > >> On Mar 18, 2019, at 7:51 AM, Langer, Christoph wrote: >> >> please review a fix for 8172695, where java/util/Scanner/ScanTest.java fails. It reproducibly fails on one of our Mac servers, where the locale is set to en_DE. >> >> The test in its current form checks if the test VM is run with a supported default Locale by just checking the language to be one of ?en?, ?zh?, ?ko?, ?ja?. But it turns out, that also the country part seems to be important. I suggest to change the test case to test whether the VM?s default locale is one of a restricted set of locales and if it isn?t, it shall try to run with ?ENGLISH?. >> >> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to work on my machine. Before pushing, I?d run it through the submit repo. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 >> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ From brian.goetz at oracle.com Mon Mar 18 23:58:04 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 18 Mar 2019 19:58:04 -0400 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <765913287.277879.1552952304666.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> <765913287.277879.1552952304666.JavaMail.zimbra@u-pem.fr> Message-ID: <1409f831-2153-997d-b23a-bccb02e2600a@oracle.com> > My fear is more than we will want in the future to have one code for all kinds of Stream, but Stream will have to implement Iterable while Stream will not, this not something you can actually do with the current generics, we may be able to do that with the reified generics but some languages that already have reified generics like Swift are not able to do that. > So by making Stream to have different set of supertypes than Stream, you are forcing the future reified generics implementation to work on this case because we will never introduce an implementation of reified generics that doesn't support the classe of java.util. This will work fine; Stream <: IterableOnce, and when we can instantiate T=int in the first, we'll be able to do so in the second as well.? (Having spent hundreds of hours banging my head against how we're going to migrate collections and stream to specialization, this one is not even on the list.) From andy.herrick at oracle.com Tue Mar 19 00:44:49 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 18 Mar 2019 20:44:49 -0400 Subject: RFR: JDK-8220804: Help message for @ argfile option is printed in the wrong place Message-ID: <38e4a70f-75ef-188a-cdaf-8a7fee2ab742@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8220804 [2] http://cr.openjdk.java.net/~herrick/8220804/ /Andy From thomas.stuefe at gmail.com Tue Mar 19 07:33:04 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Mar 2019 08:33:04 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: Hi Andrew, This would be good to have in jdk11 for the following reason: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of reported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitely choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analysing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so. In addition to that, as David Loyd mentioned, vfork(3) is marked as obsolete and may be vanish at some point in the life span of JDK 11. I admit the chance of this happening is low. Kind Regards, Thomas On Fri, Mar 8, 2019 at 4:20 PM Andrew Haley wrote: > On 3/8/19 2:39 PM, Langer, Christoph wrote: > > please review the CSR backport > https://bugs.openjdk.java.net/browse/JDK-8220362. > > > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 > to JDK11. > > > > We want to backport JDK-8212828< > https://bugs.openjdk.java.net/browse/JDK-8212828> to jdk11u and hence > backporting the CSR is a prerequisite. The CSR is, however, more or less > identical for 11u. > > I don't see any explanation of why this should go into jdk11. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From christoph.langer at sap.com Tue Mar 19 08:22:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 19 Mar 2019 08:22:00 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: I have removed the jdk11u-fix-no label from the bug and added a fix request comment to trigger reconsideration. /Christoph From: Thomas St?fe Sent: Dienstag, 19. M?rz 2019 08:33 To: Andrew Haley Cc: Langer, Christoph ; Java Core Libs ; Alan Bateman ; Roger Riggs ; jdk-updates-dev at openjdk.java.net; David Lloyd Subject: Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux Hi Andrew, This would be good to have in jdk11 for the following reason: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of reported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitely choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analysing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so. In addition to that, as David Loyd mentioned, vfork(3) is marked as obsolete and may be vanish at some point in the life span of JDK 11. I admit the chance of this happening is low. Kind Regards, Thomas On Fri, Mar 8, 2019 at 4:20 PM Andrew Haley > wrote: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. I don't see any explanation of why this should go into jdk11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Mar 19 08:46:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 19 Mar 2019 08:46:26 +0000 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> References: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> Message-ID: Hi Stuart, thanks for your analysis of this. So you are suggesting to use Locale.ROOT for this test unconditionally? I agree ?? The test coding as it is right now is not ready to support arbitrary locales, as the comment already suggests. Generally, the test probably needs some overhaul. The scanned Strings should for instance use the Locale's decimal separators instead of hard coding ".". Maybe there are other shortcomings. But as long as this is not done, using Locale ROOT seems to be safe for all possible scenarios. I've updated the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.1/ Are you ok with that? Brian also? Thanks Christoph > -----Original Message----- > From: Stuart Marks > Sent: Dienstag, 19. M?rz 2019 00:44 > To: Langer, Christoph > Cc: Brian Burkhalter ; core-libs-dev libs-dev at openjdk.java.net> > Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails > > Hi Christoph, > > After looking at this for a little bit I realized that it's not necessary to > have a system particular default locale in order to get the test case to fail. > It's possible create a locale that causes test case to fail, like so: > > Locale.setDefault(new Locale("en", "DE")) > Scanner sc = new Scanner("\u0f23.\u0f27"); > sc.nextFloat(); > ^ throws InputMismatchException > > (This is because using "DE" as the locale's country causes texpects , instead of > . as the decimal separator.) > > The test already saves the current default locale and attempts to find a > known > good locale for running the tests. The difficulty seems to be finding a "known > good" locale. The current check for the language of English doesn't work if > the > default is en_DE. > > Instead, I'd suggest we use the root locale Locale.ROOT as the known good > locale > for running the tests. We could then do something like this: > > Locale reservedLocale = Locale.getDefault(); > try { > Locale.setDefault(Locale.ROOT); > // run all the tests > } finally { > // restore the default locale > Locale.setDefault(reservedLocale); > } > > and dispense with the logic of searching the existing locales for one that we > think is suitable. > > (Actually, since the test is being run in /othervm mode, it's not clear to me > that restoring the previous default locale is necessary. But that's kind of a > separate discussion. I'm ok with leaving the save/restore in place.) > > s'marks > > On 3/18/19 10:57 AM, Brian Burkhalter wrote: > > Hi Christoph, > > > > Not a locale expert here so you probably need to hear from someone else, > but this looks like a reasonable approach to me. One minor comment is to > perhaps use format() at lines 67-68 instead of println(). > > > > Thanks, > > > > Brian > > > >> On Mar 18, 2019, at 7:51 AM, Langer, Christoph > wrote: > >> > >> please review a fix for 8172695, where java/util/Scanner/ScanTest.java > fails. It reproducibly fails on one of our Mac servers, where the locale is set to > en_DE. > >> > >> The test in its current form checks if the test VM is run with a supported > default Locale by just checking the language to be one of ?en?, ?zh?, ?ko?, > ?ja?. But it turns out, that also the country part seems to be important. I > suggest to change the test case to test whether the VM?s default locale is > one of a restricted set of locales and if it isn?t, it shall try to run with > ?ENGLISH?. > >> > >> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to work > on my machine. Before pushing, I?d run it through the submit repo. > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 > > >> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ > From christoph.langer at sap.com Tue Mar 19 09:00:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 19 Mar 2019 09:00:30 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: Hm, I?m not sure about the ?reconsideration? process? I restored jdk11u-fix-no, because it?s probably not in my powers to remove it. But still the request for reconsideration remains ?? /Christoph From: Langer, Christoph Sent: Dienstag, 19. M?rz 2019 09:22 To: Thomas St?fe ; Andrew Haley Cc: Java Core Libs ; Alan Bateman ; Roger Riggs ; jdk-updates-dev at openjdk.java.net; David Lloyd Subject: RE: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux I have removed the jdk11u-fix-no label from the bug and added a fix request comment to trigger reconsideration. /Christoph From: Thomas St?fe > Sent: Dienstag, 19. M?rz 2019 08:33 To: Andrew Haley > Cc: Langer, Christoph >; Java Core Libs >; Alan Bateman >; Roger Riggs >; jdk-updates-dev at openjdk.java.net; David Lloyd > Subject: Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux Hi Andrew, This would be good to have in jdk11 for the following reason: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of reported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitely choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analysing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so. In addition to that, as David Loyd mentioned, vfork(3) is marked as obsolete and may be vanish at some point in the life span of JDK 11. I admit the chance of this happening is low. Kind Regards, Thomas On Fri, Mar 8, 2019 at 4:20 PM Andrew Haley > wrote: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. I don't see any explanation of why this should go into jdk11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 19 09:34:19 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 09:34:19 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: <98e664a5-9511-db44-5528-5ad57eb30c91@redhat.com> On 3/11/19 1:09 PM, David Lloyd wrote: > Is vfork still guaranteed to be functional by the end of the Java 11 > support frame, from the perspective of any organization which supports > JDKs of this version? It's extremely unlikely to be made nonfunctional. Linux backwards compatibility is excellent. Besides, if vfork() is nonfunctional we'll need to change the Linux default -- not just provide an alternative -- so this patch will be inadequate. All this patch does is provide an alternative to experiment with. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 19 09:39:18 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 09:39:18 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On 3/19/19 7:33 AM, Thomas St?fe wrote: > The established (since decades) method of forking off on Linux JDKs > has been to use vfork(3). Using vfork is risky. There are chances of > crashing the parent process. The risk of this happening is very low, > but not zero. Do you have a reference to this? If we're at risk, I'd like to know exactly what the risk is. > Since analyzing those crashes and attributing them to vfork(3) is > very difficult, there may be a number of reported cases not > associated with vfork(3) but in fact caused by it. > The patch adds a second, safer way to fork off childs, using > posix_spawn(3). This one has been the default on other platforms for > quite some while. The patch does not change the default fork mode - > which remains vfork(3). So installations would not be affected > unless they explicitely choose to use vfork(3). > > Having this possibility would allow us to use posix_spawn(3) in > situations where we are analysing crashes and want to exclude > vfork(3) as a cause. It also would enable us to use posix_spawn(3) > as a safe alternative by default if we choose to do so. > > In addition to that, as David Loyd mentioned, vfork(3) is marked as > obsolete and may be vanish at some point in the life span of JDK > 11. I admit the chance of this happening is low. Sure, but as I replied to him, this patch doesn't solve that problem. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 19 09:39:42 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 09:39:42 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue Mar 19 10:51:35 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Mar 2019 11:51:35 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On Tue, Mar 19, 2019 at 10:39 AM Andrew Haley wrote: > On 3/19/19 7:33 AM, Thomas St?fe wrote: > > > The established (since decades) method of forking off on Linux JDKs > > has been to use vfork(3). Using vfork is risky. There are chances of > > crashing the parent process. The risk of this happening is very low, > > but not zero. > > Do you have a reference to this? If we're at risk, I'd like to know > exactly what the risk is. > Sure, see here an old mail from me to core libs last year: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html (Please ignore my proposed fix, turned out David Loyd's posix_spawn proposal was a way simpler solution.) very short version: After child process is spawned via vfork() but before it calls exec() both parent and child are vulnerable in the following way: A signal received by the child may damage or kill the parent. True for both synchronous (error) signals in the child and outside signals sent to the child. - since the child process code is old and stable, error signals are not likely, with one possible exception: hitting a stack overflow in the child process (e.g. when calling fork in a low stack situation) - asynchronous signals could be sent from the outside. Unlikely to be a targeted kill, since the parent cannot yet have communicated the child pid to the outside; but could be a group kill. Note that the risk depends on the the length of the time span between fork and exec, which depends on the number of open file descriptors in the parent. As I wrote, the risk is low - a freak accident - but not zero and has a question mark around it since these crashes are hard to attribute to vfork. Typical symptom is that the parent process just dies without a trace. --- As to the question: if it is so important why do we not switch the default? This is the result of a discussion with the core-libs maintainers and a trade off between the vfork() risk and the risk of adding this patch. Roger preferred to provide the non-default alternative for 12 and switch the default to posix_spawn() for 13. I think long term it definitely will make sense to switch the default to posix_spawn on 11 and 12 too, maybe after a grace period. Cheers, Thomas > > Since analyzing those crashes and attributing them to vfork(3) is > > very difficult, there may be a number of reported cases not > > associated with vfork(3) but in fact caused by it. > > > The patch adds a second, safer way to fork off childs, using > > posix_spawn(3). This one has been the default on other platforms for > > quite some while. The patch does not change the default fork mode - > > which remains vfork(3). So installations would not be affected > > unless they explicitely choose to use vfork(3). > > > > Having this possibility would allow us to use posix_spawn(3) in > > situations where we are analysing crashes and want to exclude > > vfork(3) as a cause. It also would enable us to use posix_spawn(3) > > as a safe alternative by default if we choose to do so. > > > > In addition to that, as David Loyd mentioned, vfork(3) is marked as > > obsolete and may be vanish at some point in the life span of JDK > > 11. I admit the chance of this happening is low. > > Sure, but as I replied to him, this patch doesn't solve that problem. > Fair enough. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From lenborje at gmail.com Tue Mar 19 11:11:53 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 19 Mar 2019 12:11:53 +0100 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> <8FD446A3-EBB3-4B9B-962E-758315584645@gmail.com> Message-ID: <9D4EC498-CF64-4DE5-85BA-A812AD7AAF14@gmail.com> While the EA build 30 seems to solve my Mac problems, there still seems to be a similar problem on Linux: Succeeded in building RPM Bundle bundle jdk.jpackage.internal.PackagerException: Bundler DEB Installer skipped because of a configuration problem: Can not find dpkg-deb. Advice to fix: Please install required packages. at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:709) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:577) at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) Caused by: jdk.jpackage.internal.ConfigException: Can not find dpkg-deb. at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.validate(LinuxDebBundler.java:239) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:682) ... 3 more After which jpackage exits with error 255. From kevin.rushforth at oracle.com Tue Mar 19 12:52:53 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Mar 2019 05:52:53 -0700 Subject: RFR: JDK-8220804: Help message for @ argfile option is printed in the wrong place In-Reply-To: <38e4a70f-75ef-188a-cdaf-8a7fee2ab742@oracle.com> References: <38e4a70f-75ef-188a-cdaf-8a7fee2ab742@oracle.com> Message-ID: Looks good. -- Kevin On 3/18/2019 5:44 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] https://bugs.openjdk.java.net/browse/JDK-8220804 > > [2] http://cr.openjdk.java.net/~herrick/8220804/ > > /Andy > From andy.herrick at oracle.com Tue Mar 19 12:55:21 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 19 Mar 2019 08:55:21 -0400 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: <9D4EC498-CF64-4DE5-85BA-A812AD7AAF14@gmail.com> References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> <8FD446A3-EBB3-4B9B-962E-758315584645@gmail.com> <9D4EC498-CF64-4DE5-85BA-A812AD7AAF14@gmail.com> Message-ID: <5622f78f-048f-52bc-dcfb-36a0dd5bcb20@oracle.com> Thanks. I have filed bug JDK-8221075 and we will address it . /Andy On 3/19/2019 7:11 AM, Lennart B?rjeson wrote: > While the EA build 30 seems to solve my Mac problems, there still > seems to be a similar problem on Linux: > > Succeeded in building RPM Bundle bundle > jdk.jpackage.internal.PackagerException: Bundler DEB Installer skipped > because of a configuration problem: Can not find dpkg-deb. > Advice to fix: Please install required packages. > at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:709) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:577) > at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:91) > at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) > Caused by: jdk.jpackage.internal.ConfigException: Can not find dpkg-deb. > at > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.validate(LinuxDebBundler.java:239) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:682) > ... 3 more > > After which jpackage exits with error 255. > > From lenborje at gmail.com Tue Mar 19 13:48:20 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 19 Mar 2019 14:48:20 +0100 Subject: jpackage --create-installer problem on Mac when installer-type is unspecified In-Reply-To: <5622f78f-048f-52bc-dcfb-36a0dd5bcb20@oracle.com> References: <27F94CE2-B807-40D4-9CE0-604C585F284E@gmail.com> <3d7433ee-7e08-ca2a-1ae9-78a5c0bd1d82@oracle.com> <8FD446A3-EBB3-4B9B-962E-758315584645@gmail.com> <9D4EC498-CF64-4DE5-85BA-A812AD7AAF14@gmail.com> <5622f78f-048f-52bc-dcfb-36a0dd5bcb20@oracle.com> Message-ID: <65BA6F9F-7078-4E6D-9D05-BB66B6DA6AB9@gmail.com> Thank you. In the bug description, you write: "LinuxDebBundler.supported() should return false if not on Debian Linux.". I my opinion, that is not entirely correct. I have previously used javafxpackager on RedHat to produce both an rpm and a deb package. The "only" requirement is that the requisite tool, dpkg-deb, should be available. Best regards, /Lennart B?rjeson > 19 mars 2019 kl. 13:55 skrev Andy Herrick : > > Thanks. > > I have filed bug JDK-8221075 and we will address it . > > /Andy > From cpovirk at google.com Tue Mar 19 15:58:53 2019 From: cpovirk at google.com (Chris Povirk) Date: Tue, 19 Mar 2019 11:58:53 -0400 Subject: Stream implements Iterable, thoughts from Guava Message-ID: Hi. Kevin Bourrillion pointed me at the JDK-8148917 thread, since he and I have discussed one-shot Iterables a number of times. >From my reading of the discussion so far, it sounds like the expectation is that "Stream implements IterableOnce" will be a net win for foreach but possibly a net loss for Iterable-accepting methods. Since Google's codebase (including Guava and including Truth, our equivalent to AssertJ) contains a lot of Iterable-accepting methods, I'll offer some anecdotes (and maybe a smidge of data). First, I picked a random sample of 40 Iterable-accepting methods from Google's codebase. I found that 5 of them iterate the Iterable multiple times. The reasons I saw were: - performing an emptiness check before doing more expensive work (could be done with a single iterator and hasNext() -- unless the other work requires passing in an Iterable) - retrieving the first element to extract some fields that are expected to match for all inputs (ditto) - iterating more than once because it was natural to (I didn't investigate enough to see if it was possible to avoid, except of course by copying the full input) I have mixed feelings about these methods. On the one hand, project-specific methods can generally get away with multiple iteration just fine. But ideally, an implementation would iterate only once. That way, it can accept, say, a CopyOnWriteArrayList and operate on a consistent view of it. Additionally, repeat iteration may perform worse. For these reasons, Guava and Truth generally try to iterate an input only once. Well, those reasons, plus the fact that we do occasionally encounter one-shot Iterables. We discourage them, but when our methods are used so often (e.g., ImmutableList.copyOf(Iterable)), we end up needing to accommodate them. It does look like we have at least one lesser-used Guava method that iterates multiple times, presumably because no one has called it with a one-shot Iterable. We'll certainly change it if Stream becomes an Iterable: https://github.com/google/guava/blob/74fc49faf283f106302794f7af82c7ab1fcb5412/guava/src/com/google/common/collect/Range.java#L452 Our biggest single concern will be in Truth. It's the concern that Stuart called out in his original proposal: assertThat(stream).containsExactly(...). We actually already avoid iterating the inputs multiple times (again because of occasional problems) but currently only in *some* of our methods. We will have to extend that support to the other methods -- which is doable, either by cleverness or by brute-force copying. I will have to look into the performance of brute-force copying. And I guess we'll have to hope that no one passes an infinite stream :) I do suspect that brute-force copying may be necessary. That is, I don't think that `instanceof IterableOnce` or even Peter Levart's trick ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059060.html) is enough. That's primarily because of "view Iterables," especially our Iterables.concat(Iterable>) ( https://google.github.io/guava/releases/snapshot-jre/api/docs/com/google/common/collect/Iterables.html#concat-java.lang.Iterable-). That method (and its callers) can't tell whether it's produced a one-shot Iterable until its caller has fully iterated its inputs. (In principle, it doesn't necessarily even know then, since the inputs could change (though of course that's a whole new can of worms).) I don't know if this will be a problem in practice, but I'd at least expect some one-shot Iterables that fail to impement IterableOnce. Nevertheless, IterableOnce is probably worthwhile as *documentation* (and for some static analysis). I'm just unsure whether we'll rely on it at *runtime*. Another part of the story is that Truth has two parts to its operation: 1. test whether the Iterable contains the expected elements 2. report a failure Above, I've focused mostly on #1. For #2, we historically have been willing to iterate over the inputs a second time. That's worked tolerably. That's because the occasional one-shot Iterables we've encountered typically "support" multiple iterator() calls (by making later calls return the same iterator instance) or because they return a toString() that doesn't try to access the contents -- or because those tests just haven't failed yet! All of those scenarios are likely to result in a subpar failure message for users. (And in fact we have a special assertThat(Stream) method, partly because Stream doesn't currently implement Iterable now but also partly so that we can eagerly collect the values to a list for multiple iteration, including in failure messages.) This hints at one potential class of edge cases: methods that iterate twice *sometimes*. I could imagine seeing this with logging or error messages. However, my guess is that most callers will log the default Stream.toString(), so there will be no issue -- other than that the user may have expected to get "real" data, since the average Iterable is usually a Collection with an informative toString(). There might be other odd cases, like a method that accepts two Iterables and doesn't iterate the one if the other is empty. And of course there might be breakages at a distance when a method switches from returning a multiple-use Iterable to a one-shot Iterable. I don't think the world will catch fire, but hopefully this adds to the overall picture. Another tiny point: We also find ourselves in the business of maintaining compatibility with older versions of Java for a while. I would expect for "passing a Stream to a method that accepts an Iterable" to be an incompatible change that's not caught by current enforcement tools (like Animal Sniffer), since Stream isn't a new type and the Iterable-accepting method isn't a new method. (I haven't verified this.) This could be fixed (and it's potentially a problem anywhere that you introduce a new supertype), but I would expect sporadic problems at scale. The other information that I *wish* I had is the other side of the picture: I can offer anecdotes about Iterable-accepting methods, but I have few anecdotes about foreach over Streams. I do have some, as we have an internal Stream->Iterable adapter. And in fact it's now enforced by static analysis to be used only with foreach, since we found that nearly all the first batch of usages were for Iterable-accepting methods, rather than for foreach! (Interestingly, that was the case even though those users could use plain stream::iterator.) Again, Google may be unusual in having so many Iterable-accepting methods -- though perhaps "Stream implements Iterable" will encourage that pattern. I did look through some of those users. As you'd expect, many *could* be rewritten to avoid Stream entirely. (Some arguably *should*, even setting foreach aside, as they're using Stream in ways I've seen discouraged, like for streaming RPCs.) But this doesn't get at the heart of the question: How often do people really need foreach over a Stream, *and* how often are people annoyed to have to switch from the Stream model to the foreach model when they *could* but shouldn't really have to? (Certainly we hear complaints, as you do.) Good data could help weigh the benefits against the costs. But all the data I have is "Google was using a Stream->Iterable adapter more for Iterable-accepting methods than for foreach," and I don't know how representative we are, nor do I know how many people gave up and abandoned Stream without finding the adapter. To recap: It would be nice to be able to compare the benefits to foreach with the costs to Iterable-accepting methods. I have more to say about Iterable-accepting methods: Some will definitely fail when passed a Stream; others will *sometimes* fail when passed a Stream. These problems are fixable but might require brute-force eager copying. "Stream implements Iterable" might encourage more Iterable-accepting methods, and there's some chance of compatibility concerns or unexpectedly bad toString(). None of these concerns are fatal, but I haven't seen much discussion of them other than in Stuart's mention of AssertJ, so I wanted to weigh in. Sorry for the length. From martinrb at google.com Tue Mar 19 16:10:16 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2019 09:10:16 -0700 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: I'm the one who introduced vfork for process spawning, and I support Thomas' plan to switch to posix_spawn. (although I have not seen a crash attributed to using vfork on Linux) From andy.herrick at oracle.com Tue Mar 19 16:17:41 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 19 Mar 2019 12:17:41 -0400 Subject: jpackage Packaging Tool Early Access Update 4 Message-ID: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> The fourth EA build (Build 30) of jpackage tool is available at https://jdk.java.net/jpackage/ Note this build contains significant Command Line Interface changes. Issues addressed since EA 3 (build 17): JDK-8217798???? modular jar linking in jpackage JDK-8218055???? Use ToolProvider instead of AppRuntimeImageBuilder. JDK-8219678???? CLI changes in jpackage JDK-8219679???? Help text changes in jpackage JDK-8217902???? jpackage fails with --app-image option on mac JDK-8219144???? Cannot find installed application on Mac JDK-8212091???? Move jpackage native code under platform specific folders and files JDK-8171959???? add-launcher is not working when normal jar is used for first launcher and module is used for second launcher JDK-8215574???? Investigate and document usage of --category, --copyright, --vendor and --description JDK-8214566???? --win-dir-chooser does not prompt if destination folder is not empty JDK-8218681???? Windows exe's generated by jpackage have wrong info JDK-8219695???? Use a copy of javac's implementation of @argfile in jpackager JDK-8217802???? Invalid Option warning message. JDK-8191709???? javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code JDK-8219889???? Update jpackage tests for JDK-8219678 changes JDK-8220616???? test failures on linux, mac JDK-8220471???? two test fixes missed in push. please send feedback to core-libs-dev at openjdk.java.net /Andy Herrick From aph at redhat.com Tue Mar 19 16:42:24 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 16:42:24 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> On 3/19/19 4:10 PM, Martin Buchholz wrote: > I'm the one who introduced vfork for process spawning, and I support Thomas' plan to switch to posix_spawn. > (although I have not seen a crash attributed to using vfork on Linux) Thanks. I get that, I'm just questioning the need to backport it to 11. No matter, I've approved it now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue Mar 19 17:32:08 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Mar 2019 18:32:08 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: Thank you, Andrew .. Thomas On Tue, Mar 19, 2019, 5:42 PM Andrew Haley wrote: > On 3/19/19 4:10 PM, Martin Buchholz wrote: > > I'm the one who introduced vfork for process spawning, and I support > Thomas' plan to switch to posix_spawn. > > (although I have not seen a crash attributed to using vfork on Linux) > > Thanks. I get that, I'm just questioning the need to backport it to 11. > No matter, I've approved it now. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From brian.burkhalter at oracle.com Tue Mar 19 18:12:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Mar 2019 11:12:08 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> Message-ID: <85539BC3-FB6D-4782-956E-9AF789BFEC71@oracle.com> > On Mar 18, 2019, at 1:03 PM, Martin Buchholz wrote: > > You've again caught me only half paying attention. > Below is another attempt at micro-optimization (might be too tricky!), BUT: This has blossomed considerably from my original effectively one line change. ;-) Might there be any performance numbers on this version versus the one currently in the repo? > - consider documenting the UTFDataFormatException and the 64k length limit > - error message would actually be more useful if it contained a few chars > from head and tail instead of length Good ideas. From martinrb at google.com Tue Mar 19 19:06:14 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2019 12:06:14 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: <85539BC3-FB6D-4782-956E-9AF789BFEC71@oracle.com> References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <85539BC3-FB6D-4782-956E-9AF789BFEC71@oracle.com> Message-ID: On Tue, Mar 19, 2019 at 11:12 AM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > > On Mar 18, 2019, at 1:03 PM, Martin Buchholz wrote: > > You've again caught me only half paying attention. > Below is another attempt at micro-optimization (might be too tricky!), BUT: > > > This has blossomed considerably from my original effectively one line > change. ;-) > Feel free to ignore/postpone. > > Might there be any performance numbers on this version versus the one > currently in the repo? > Nope, but they're the sort of non-tradeoff optimization that is known to help and "can't hurt". UTF-8 encoding is likely to always be performance sensitive. (another thought: can we elide the creation of an intermediate byte[] and write directly to the output?) From brian.burkhalter at oracle.com Tue Mar 19 19:35:53 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Mar 2019 12:35:53 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <85539BC3-FB6D-4782-956E-9AF789BFEC71@oracle.com> Message-ID: <22AD38D4-30F3-4F24-A0AE-A9102416FB2F@oracle.com> > On Mar 19, 2019, at 12:06 PM, Martin Buchholz wrote: > > On Tue, Mar 19, 2019 at 11:12 AM Brian Burkhalter > wrote: > >> On Mar 18, 2019, at 1:03 PM, Martin Buchholz > wrote: >> >> You've again caught me only half paying attention. >> Below is another attempt at micro-optimization (might be too tricky!), BUT: > > This has blossomed considerably from my original effectively one line change. ;-) > > Feel free to ignore/postpone. Probably I should hack up a JMH to check. > > > Might there be any performance numbers on this version versus the one currently in the repo? > > Nope, but they're the sort of non-tradeoff optimization that is known to help and "can't hurt". > > UTF-8 encoding is likely to always be performance sensitive. > > (another thought: can we elide the creation of an intermediate byte[] and write directly to the output?) Will check out. Thanks ... From alexander.matveev at oracle.com Tue Mar 19 21:24:16 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 19 Mar 2019 14:24:16 -0700 Subject: RFR: JDK-8220804: Help message for @ argfile option is printed in the wrong place In-Reply-To: <38e4a70f-75ef-188a-cdaf-8a7fee2ab742@oracle.com> References: <38e4a70f-75ef-188a-cdaf-8a7fee2ab742@oracle.com> Message-ID: Hi Andy, Looks good. Thanks, Alexander On 3/18/2019 5:44 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] https://bugs.openjdk.java.net/browse/JDK-8220804 > > [2] http://cr.openjdk.java.net/~herrick/8220804/ > > /Andy > From georgeradev at gmail.com Tue Mar 19 14:41:42 2019 From: georgeradev at gmail.com (George Radev) Date: Tue, 19 Mar 2019 16:41:42 +0200 Subject: about AbstractStringBuilder.delete() Message-ID: Dear Team, Recently I've encountered a time difference between delete() and setLength() in AbstractStringBuilder when removing elements from the end of the buffer because of the System.arraycopy call by shift function (~20% if the buffer is larger). An example autogenerated code for uddl files: @Override public String toString() { StringBuilder builder = new StringBuilder("SimpleAttribute ["); builder.append("name=").append(name).append(", "); builder.append("value=").append(value).append(", "); // Remove the trailing ", " * builder.delete(builder.length() - 2, builder.length()); * * //delete() used instead of setLength(builder.length() - 2);* builder.append("]"); return builder.toString(); } If there is no reason to favor delete() instead of setLength() in such border case, and they are equivalent: a very easy correction is possible, since there is already a check for end >= count in delete(), and adding the setLength(start) behavior in that case will make the same performance. Please, consider such change that will make deletion more gnostic, Thank you for your time, Best regards, George From stuart.marks at oracle.com Tue Mar 19 22:21:38 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 19 Mar 2019 15:21:38 -0700 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> Message-ID: <352429d9-6bce-e5e4-e668-ceed17ae127e@oracle.com> Hi Christoph, I spoke with Naoto Sato (internationalization) and he recommends using Locale.US instead of Locale.ROOT. (Sorry for having misdirected you.) The test case in question, parsing float strings, relies on the decimal separator, which isn't defined in the ROOT locale. Of course it's "." in the US locale. Also, the US locale is the only one that's guaranteed to be available; see Locale::getAvailableLocales. So I think your current changeset will be fine if Locale.ROOT is replaced with Locale.US. Assuming it passes test runs. :-) s'marks On 3/19/19 1:46 AM, Langer, Christoph wrote: > Hi Stuart, > > thanks for your analysis of this. > > So you are suggesting to use Locale.ROOT for this test unconditionally? I agree ?? > > The test coding as it is right now is not ready to support arbitrary locales, as the comment already suggests. Generally, the test probably needs some overhaul. The scanned Strings should for instance use the Locale's decimal separators instead of hard coding ".". Maybe there are other shortcomings. But as long as this is not done, using Locale ROOT seems to be safe for all possible scenarios. > > I've updated the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.1/ > > Are you ok with that? Brian also? > > Thanks > Christoph > > >> -----Original Message----- >> From: Stuart Marks >> Sent: Dienstag, 19. M?rz 2019 00:44 >> To: Langer, Christoph >> Cc: Brian Burkhalter ; core-libs-dev > libs-dev at openjdk.java.net> >> Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails >> >> Hi Christoph, >> >> After looking at this for a little bit I realized that it's not necessary to >> have a system particular default locale in order to get the test case to fail. >> It's possible create a locale that causes test case to fail, like so: >> >> Locale.setDefault(new Locale("en", "DE")) >> Scanner sc = new Scanner("\u0f23.\u0f27"); >> sc.nextFloat(); >> ^ throws InputMismatchException >> >> (This is because using "DE" as the locale's country causes texpects , instead of >> . as the decimal separator.) >> >> The test already saves the current default locale and attempts to find a >> known >> good locale for running the tests. The difficulty seems to be finding a "known >> good" locale. The current check for the language of English doesn't work if >> the >> default is en_DE. >> >> Instead, I'd suggest we use the root locale Locale.ROOT as the known good >> locale >> for running the tests. We could then do something like this: >> >> Locale reservedLocale = Locale.getDefault(); >> try { >> Locale.setDefault(Locale.ROOT); >> // run all the tests >> } finally { >> // restore the default locale >> Locale.setDefault(reservedLocale); >> } >> >> and dispense with the logic of searching the existing locales for one that we >> think is suitable. >> >> (Actually, since the test is being run in /othervm mode, it's not clear to me >> that restoring the previous default locale is necessary. But that's kind of a >> separate discussion. I'm ok with leaving the save/restore in place.) >> >> s'marks >> >> On 3/18/19 10:57 AM, Brian Burkhalter wrote: >>> Hi Christoph, >>> >>> Not a locale expert here so you probably need to hear from someone else, >> but this looks like a reasonable approach to me. One minor comment is to >> perhaps use format() at lines 67-68 instead of println(). >>> >>> Thanks, >>> >>> Brian >>> >>>> On Mar 18, 2019, at 7:51 AM, Langer, Christoph >> wrote: >>>> >>>> please review a fix for 8172695, where java/util/Scanner/ScanTest.java >> fails. It reproducibly fails on one of our Mac servers, where the locale is set to >> en_DE. >>>> >>>> The test in its current form checks if the test VM is run with a supported >> default Locale by just checking the language to be one of ?en?, ?zh?, ?ko?, >> ?ja?. But it turns out, that also the country part seems to be important. I >> suggest to change the test case to test whether the VM?s default locale is >> one of a restricted set of locales and if it isn?t, it shall try to run with >> ?ENGLISH?. >>>> >>>> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to work >> on my machine. Before pushing, I?d run it through the submit repo. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 >> >>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ >> From mandy.chung at oracle.com Tue Mar 19 23:21:48 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2019 16:21:48 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> Message-ID: <9140740e-a4db-71ee-2b2e-c4c9dc2aba84@oracle.com> Hi Goetz, Sorry I have been busy on other time-critical things. I will get to it hopefully next week. Mandy On 3/15/19 3:55 AM, Lindenmaier, Goetz wrote: > Hi everybody, Mark, > > I followed your advice and created a JEP: > https://bugs.openjdk.java.net/browse/JDK-8220715 > > Please point me to things I need to improve formally, this is my first > JEP. Also feel free to fix the administrative information in the > Jira issue if it is wrong. > > And, naturally, you're welcome to discuss the topic! > > Best regards, > Goetz. > >> -----Original Message----- >> From: mark.reinhold at oracle.com >> Sent: Donnerstag, 14. M?rz 2019 22:38 >> To: maurizio.cimadamore at oracle.com; Lindenmaier, Goetz >> >> Cc: mandy.chung at oracle.com; roger.riggs at oracle.com; core-libs- >> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >> >> 2019/3/14 8:00:20 -0700, maurizio.cimadamore at oracle.com: >>> I second what Mandy says. >>> >>> First let me start by saying that this enhancement will be a great >>> addition to our platform; back in the days when I was teaching some Java >>> classes at the university, I was very aware of how hard it is to >>> diagnose a NPE for someone novel to Java programming. >> >> Agreed! >> >>> ... >>> >>> I also think that the design space for such an enhancement is non >>> trivial, and would best be explored (and captured!) in a medium that is >>> something other than a patch. ... >> >> Agreed, also. >> >> Goetz -- if, per Mandy?s suggestion, you?re going to write something >> up using the JEP template, might I suggest that you then submit it as >> an actual JEP? Giving visibility to, and recording, such design-space >> explorations is one of the primary goals of the JEP process. >> >> - Mark From mandy.chung at oracle.com Wed Mar 20 05:08:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2019 22:08:37 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: Hi Adam, I imported your patch but there is one test failure: test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java This test needs update of this change. Can you please send an updated patch and run all test/jdk/java/lang/invoke tests. Mandy On 3/6/19 8:28 AM, Adam Farley8 wrote: > Hi Mandy, > > The webrev has been updated with the new test: > http://cr.openjdk.java.net/~afarley/8216558/webrev/ > > Note that I included a handful of small improvements, and that the final > fields are all setAccessible by default, because (a) it seemed cleaner > than adding a new control bit, and (b) nobody is meant to be changing > final fields anyway. > > Open for review. > > Best Regards > > Adam Farley > IBM Runtimes From christoph.langer at sap.com Wed Mar 20 08:02:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 08:02:12 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: Hi Andrew, > Thanks. I get that, I'm just questioning the need to backport it to 11. > No matter, I've approved it now. What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. In case you approve JDK-8220362, I'll set the CSR (JDK-8220362 [1]) to finalized, referring to your approval. Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8212828 [1] https://bugs.openjdk.java.net/browse/JDK-8220362 From thomas.stuefe at gmail.com Wed Mar 20 08:37:52 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 20 Mar 2019 09:37:52 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On Tue, Mar 19, 2019 at 5:10 PM Martin Buchholz wrote: > I'm the one who introduced vfork for process spawning, and I support > Thomas' plan to switch to posix_spawn. > (although I have not seen a crash attributed to using vfork on Linux) > Thanks Martin. I think for a long time vfork was the best alternative. I remember seeing one or two cases in the last five years which could have been caused by vfork. In both cases, in a fork-heavy environment with many short-lived processes, a broken script killed the wrong pid - a just spawned child - and pid's father disappeared at the same time without a trace. Cheers, Thomas From goetz.lindenmaier at sap.com Wed Mar 20 08:54:46 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Mar 2019 08:54:46 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <9140740e-a4db-71ee-2b2e-c4c9dc2aba84@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <9140740e-a4db-71ee-2b2e-c4c9dc2aba84@oracle.com> Message-ID: Hi Mandy, > Sorry I have been busy on other time-critical things. I will > get to it hopefully next week. No problem, I have been improving the text slightly anyways. I also pushed my change and a follow up needed to the sandbox repos so it can be played with. Should I move the JEP to status 'submitted'? Best regards, Goetz > > Mandy > > On 3/15/19 3:55 AM, Lindenmaier, Goetz wrote: > > Hi everybody, Mark, > > > > I followed your advice and created a JEP: > > https://bugs.openjdk.java.net/browse/JDK-8220715 > > > > Please point me to things I need to improve formally, this is my first > > JEP. Also feel free to fix the administrative information in the > > Jira issue if it is wrong. > > > > And, naturally, you're welcome to discuss the topic! > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: mark.reinhold at oracle.com > >> Sent: Donnerstag, 14. M?rz 2019 22:38 > >> To: maurizio.cimadamore at oracle.com; Lindenmaier, Goetz > >> > >> Cc: mandy.chung at oracle.com; roger.riggs at oracle.com; core-libs- > >> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > >> describing what is null. > >> > >> 2019/3/14 8:00:20 -0700, maurizio.cimadamore at oracle.com: > >>> I second what Mandy says. > >>> > >>> First let me start by saying that this enhancement will be a great > >>> addition to our platform; back in the days when I was teaching some Java > >>> classes at the university, I was very aware of how hard it is to > >>> diagnose a NPE for someone novel to Java programming. > >> > >> Agreed! > >> > >>> ... > >>> > >>> I also think that the design space for such an enhancement is non > >>> trivial, and would best be explored (and captured!) in a medium that is > >>> something other than a patch. ... > >> > >> Agreed, also. > >> > >> Goetz -- if, per Mandy?s suggestion, you?re going to write something > >> up using the JEP template, might I suggest that you then submit it as > >> an actual JEP? Giving visibility to, and recording, such design-space > >> explorations is one of the primary goals of the JEP process. > >> > >> - Mark From christoph.langer at sap.com Wed Mar 20 09:10:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 09:10:27 +0000 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: <352429d9-6bce-e5e4-e668-ceed17ae127e@oracle.com> References: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> <352429d9-6bce-e5e4-e668-ceed17ae127e@oracle.com> Message-ID: Hi Stuart, thanks for consulting with Naoto and providing the update. So I'll run the fix through jdk-submit and our test system at SAP with Locale.US. Provided I don't see issues, I'll push it thereafter... Best regards Christoph > -----Original Message----- > From: Stuart Marks > Sent: Dienstag, 19. M?rz 2019 23:22 > To: Langer, Christoph > Cc: Brian Burkhalter ; core-libs-dev libs-dev at openjdk.java.net> > Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails > > Hi Christoph, > > I spoke with Naoto Sato (internationalization) and he recommends using > Locale.US > instead of Locale.ROOT. (Sorry for having misdirected you.) > > The test case in question, parsing float strings, relies on the decimal > separator, which isn't defined in the ROOT locale. Of course it's "." in the US > locale. Also, the US locale is the only one that's guaranteed to be available; > see Locale::getAvailableLocales. > > So I think your current changeset will be fine if Locale.ROOT is replaced with > Locale.US. Assuming it passes test runs. :-) > > s'marks > > > On 3/19/19 1:46 AM, Langer, Christoph wrote: > > Hi Stuart, > > > > thanks for your analysis of this. > > > > So you are suggesting to use Locale.ROOT for this test unconditionally? I > agree ?? > > > > The test coding as it is right now is not ready to support arbitrary locales, as > the comment already suggests. Generally, the test probably needs some > overhaul. The scanned Strings should for instance use the Locale's decimal > separators instead of hard coding ".". Maybe there are other shortcomings. > But as long as this is not done, using Locale ROOT seems to be safe for all > possible scenarios. > > > > I've updated the webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8172695.1/ > > > > Are you ok with that? Brian also? > > > > Thanks > > Christoph > > > > > >> -----Original Message----- > >> From: Stuart Marks > >> Sent: Dienstag, 19. M?rz 2019 00:44 > >> To: Langer, Christoph > >> Cc: Brian Burkhalter ; core-libs-dev >> libs-dev at openjdk.java.net> > >> Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java > fails > >> > >> Hi Christoph, > >> > >> After looking at this for a little bit I realized that it's not necessary to > >> have a system particular default locale in order to get the test case to fail. > >> It's possible create a locale that causes test case to fail, like so: > >> > >> Locale.setDefault(new Locale("en", "DE")) > >> Scanner sc = new Scanner("\u0f23.\u0f27"); > >> sc.nextFloat(); > >> ^ throws InputMismatchException > >> > >> (This is because using "DE" as the locale's country causes texpects , > instead of > >> . as the decimal separator.) > >> > >> The test already saves the current default locale and attempts to find a > >> known > >> good locale for running the tests. The difficulty seems to be finding a > "known > >> good" locale. The current check for the language of English doesn't work if > >> the > >> default is en_DE. > >> > >> Instead, I'd suggest we use the root locale Locale.ROOT as the known > good > >> locale > >> for running the tests. We could then do something like this: > >> > >> Locale reservedLocale = Locale.getDefault(); > >> try { > >> Locale.setDefault(Locale.ROOT); > >> // run all the tests > >> } finally { > >> // restore the default locale > >> Locale.setDefault(reservedLocale); > >> } > >> > >> and dispense with the logic of searching the existing locales for one that > we > >> think is suitable. > >> > >> (Actually, since the test is being run in /othervm mode, it's not clear to me > >> that restoring the previous default locale is necessary. But that's kind of a > >> separate discussion. I'm ok with leaving the save/restore in place.) > >> > >> s'marks > >> > >> On 3/18/19 10:57 AM, Brian Burkhalter wrote: > >>> Hi Christoph, > >>> > >>> Not a locale expert here so you probably need to hear from someone > else, > >> but this looks like a reasonable approach to me. One minor comment is to > >> perhaps use format() at lines 67-68 instead of println(). > >>> > >>> Thanks, > >>> > >>> Brian > >>> > >>>> On Mar 18, 2019, at 7:51 AM, Langer, Christoph > >> wrote: > >>>> > >>>> please review a fix for 8172695, where java/util/Scanner/ScanTest.java > >> fails. It reproducibly fails on one of our Mac servers, where the locale is > set to > >> en_DE. > >>>> > >>>> The test in its current form checks if the test VM is run with a > supported > >> default Locale by just checking the language to be one of ?en?, ?zh?, ?ko?, > >> ?ja?. But it turns out, that also the country part seems to be important. I > >> suggest to change the test case to test whether the VM?s default locale is > >> one of a restricted set of locales and if it isn?t, it shall try to run with > >> ?ENGLISH?. > >>>> > >>>> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to > work > >> on my machine. Before pushing, I?d run it through the submit repo. > >>>> > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 > >> > >>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ > >> From goetz.lindenmaier at sap.com Wed Mar 20 09:20:36 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Mar 2019 09:20:36 +0000 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> <352429d9-6bce-e5e4-e668-ceed17ae127e@oracle.com> Message-ID: Hi, if it is only about parsing floats, why not use NumberFormat.getInstance().parse(value)? I did 8205108: [testbug] Fix pattern matching in jstatd tests. http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1637a4e50fc9?revcount=80 some while ago, because we had wrong float parsing on mac in our tests. ... just a hint to think about, you don't need to redo the change ... Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Langer, Christoph > Sent: Mittwoch, 20. M?rz 2019 10:10 > To: Stuart Marks > Cc: core-libs-dev > Subject: [CAUTION] RE: RFR(S): 8172695: (scanner) > java/util/Scanner/ScanTest.java fails > > Hi Stuart, > > thanks for consulting with Naoto and providing the update. > > So I'll run the fix through jdk-submit and our test system at SAP with Locale.US. > Provided I don't see issues, I'll push it thereafter... > > Best regards > Christoph > > > -----Original Message----- > > From: Stuart Marks > > Sent: Dienstag, 19. M?rz 2019 23:22 > > To: Langer, Christoph > > Cc: Brian Burkhalter ; core-libs-dev > libs-dev at openjdk.java.net> > > Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails > > > > Hi Christoph, > > > > I spoke with Naoto Sato (internationalization) and he recommends using > > Locale.US > > instead of Locale.ROOT. (Sorry for having misdirected you.) > > > > The test case in question, parsing float strings, relies on the decimal > > separator, which isn't defined in the ROOT locale. Of course it's "." in the US > > locale. Also, the US locale is the only one that's guaranteed to be available; > > see Locale::getAvailableLocales. > > > > So I think your current changeset will be fine if Locale.ROOT is replaced with > > Locale.US. Assuming it passes test runs. :-) > > > > s'marks > > > > > > On 3/19/19 1:46 AM, Langer, Christoph wrote: > > > Hi Stuart, > > > > > > thanks for your analysis of this. > > > > > > So you are suggesting to use Locale.ROOT for this test unconditionally? I > > agree ?? > > > > > > The test coding as it is right now is not ready to support arbitrary locales, as > > the comment already suggests. Generally, the test probably needs some > > overhaul. The scanned Strings should for instance use the Locale's decimal > > separators instead of hard coding ".". Maybe there are other shortcomings. > > But as long as this is not done, using Locale ROOT seems to be safe for all > > possible scenarios. > > > > > > I've updated the webrev: > > http://cr.openjdk.java.net/~clanger/webrevs/8172695.1/ > > > > > > Are you ok with that? Brian also? > > > > > > Thanks > > > Christoph > > > > > > > > >> -----Original Message----- > > >> From: Stuart Marks > > >> Sent: Dienstag, 19. M?rz 2019 00:44 > > >> To: Langer, Christoph > > >> Cc: Brian Burkhalter ; core-libs-dev > >> libs-dev at openjdk.java.net> > > >> Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java > > fails > > >> > > >> Hi Christoph, > > >> > > >> After looking at this for a little bit I realized that it's not necessary to > > >> have a system particular default locale in order to get the test case to fail. > > >> It's possible create a locale that causes test case to fail, like so: > > >> > > >> Locale.setDefault(new Locale("en", "DE")) > > >> Scanner sc = new Scanner("\u0f23.\u0f27"); > > >> sc.nextFloat(); > > >> ^ throws InputMismatchException > > >> > > >> (This is because using "DE" as the locale's country causes texpects , > > instead of > > >> . as the decimal separator.) > > >> > > >> The test already saves the current default locale and attempts to find a > > >> known > > >> good locale for running the tests. The difficulty seems to be finding a > > "known > > >> good" locale. The current check for the language of English doesn't work if > > >> the > > >> default is en_DE. > > >> > > >> Instead, I'd suggest we use the root locale Locale.ROOT as the known > > good > > >> locale > > >> for running the tests. We could then do something like this: > > >> > > >> Locale reservedLocale = Locale.getDefault(); > > >> try { > > >> Locale.setDefault(Locale.ROOT); > > >> // run all the tests > > >> } finally { > > >> // restore the default locale > > >> Locale.setDefault(reservedLocale); > > >> } > > >> > > >> and dispense with the logic of searching the existing locales for one that > > we > > >> think is suitable. > > >> > > >> (Actually, since the test is being run in /othervm mode, it's not clear to me > > >> that restoring the previous default locale is necessary. But that's kind of a > > >> separate discussion. I'm ok with leaving the save/restore in place.) > > >> > > >> s'marks > > >> > > >> On 3/18/19 10:57 AM, Brian Burkhalter wrote: > > >>> Hi Christoph, > > >>> > > >>> Not a locale expert here so you probably need to hear from someone > > else, > > >> but this looks like a reasonable approach to me. One minor comment is to > > >> perhaps use format() at lines 67-68 instead of println(). > > >>> > > >>> Thanks, > > >>> > > >>> Brian > > >>> > > >>>> On Mar 18, 2019, at 7:51 AM, Langer, Christoph > > >> wrote: > > >>>> > > >>>> please review a fix for 8172695, where java/util/Scanner/ScanTest.java > > >> fails. It reproducibly fails on one of our Mac servers, where the locale is > > set to > > >> en_DE. > > >>>> > > >>>> The test in its current form checks if the test VM is run with a > > supported > > >> default Locale by just checking the language to be one of ?en?, ?zh?, ?ko?, > > >> ?ja?. But it turns out, that also the country part seems to be important. I > > >> suggest to change the test case to test whether the VM?s default locale is > > >> one of a restricted set of locales and if it isn?t, it shall try to run with > > >> ?ENGLISH?. > > >>>> > > >>>> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to > > work > > >> on my machine. Before pushing, I?d run it through the submit repo. > > >>>> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 > > >> > > >>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ > > >> From christoph.langer at sap.com Wed Mar 20 09:23:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 09:23:46 +0000 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> <352429d9-6bce-e5e4-e668-ceed17ae127e@oracle.com> Message-ID: Hi Goetz, this test is specifically for java.util.Scanner. Generally, it could probably be overhauled to make it run with any Locale. However, then the input data for scanning will need to be written in the Locale that the scanner uses. This is a bit out of scope for me at this point... But anyway, thanks for your hint ?? /christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 20. M?rz 2019 10:21 > To: Langer, Christoph ; Stuart Marks > > Cc: core-libs-dev > Subject: RE: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails > > Hi, > > if it is only about parsing floats, why not use > NumberFormat.getInstance().parse(value)? > > I did > 8205108: [testbug] Fix pattern matching in jstatd tests. > http://hg.openjdk.java.net/jdk- > updates/jdk11u/rev/1637a4e50fc9?revcount=80 > some while ago, because we had wrong float parsing on mac in our tests. > > ... just a hint to think about, you don't need to redo the change ... > > Best regards, > Goetz. > > > > -----Original Message----- > > From: core-libs-dev On Behalf > Of > > Langer, Christoph > > Sent: Mittwoch, 20. M?rz 2019 10:10 > > To: Stuart Marks > > Cc: core-libs-dev > > Subject: [CAUTION] RE: RFR(S): 8172695: (scanner) > > java/util/Scanner/ScanTest.java fails > > > > Hi Stuart, > > > > thanks for consulting with Naoto and providing the update. > > > > So I'll run the fix through jdk-submit and our test system at SAP with > Locale.US. > > Provided I don't see issues, I'll push it thereafter... > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Stuart Marks > > > Sent: Dienstag, 19. M?rz 2019 23:22 > > > To: Langer, Christoph > > > Cc: Brian Burkhalter ; core-libs-dev > > libs-dev at openjdk.java.net> > > > Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java > fails > > > > > > Hi Christoph, > > > > > > I spoke with Naoto Sato (internationalization) and he recommends using > > > Locale.US > > > instead of Locale.ROOT. (Sorry for having misdirected you.) > > > > > > The test case in question, parsing float strings, relies on the decimal > > > separator, which isn't defined in the ROOT locale. Of course it's "." in the > US > > > locale. Also, the US locale is the only one that's guaranteed to be > available; > > > see Locale::getAvailableLocales. > > > > > > So I think your current changeset will be fine if Locale.ROOT is replaced > with > > > Locale.US. Assuming it passes test runs. :-) > > > > > > s'marks > > > > > > > > > On 3/19/19 1:46 AM, Langer, Christoph wrote: > > > > Hi Stuart, > > > > > > > > thanks for your analysis of this. > > > > > > > > So you are suggesting to use Locale.ROOT for this test unconditionally? I > > > agree ?? > > > > > > > > The test coding as it is right now is not ready to support arbitrary locales, > as > > > the comment already suggests. Generally, the test probably needs some > > > overhaul. The scanned Strings should for instance use the Locale's > decimal > > > separators instead of hard coding ".". Maybe there are other > shortcomings. > > > But as long as this is not done, using Locale ROOT seems to be safe for all > > > possible scenarios. > > > > > > > > I've updated the webrev: > > > http://cr.openjdk.java.net/~clanger/webrevs/8172695.1/ > > > > > > > > Are you ok with that? Brian also? > > > > > > > > Thanks > > > > Christoph > > > > > > > > > > > >> -----Original Message----- > > > >> From: Stuart Marks > > > >> Sent: Dienstag, 19. M?rz 2019 00:44 > > > >> To: Langer, Christoph > > > >> Cc: Brian Burkhalter ; core-libs-dev > > > >> libs-dev at openjdk.java.net> > > > >> Subject: Re: RFR(S): 8172695: (scanner) > java/util/Scanner/ScanTest.java > > > fails > > > >> > > > >> Hi Christoph, > > > >> > > > >> After looking at this for a little bit I realized that it's not necessary to > > > >> have a system particular default locale in order to get the test case to > fail. > > > >> It's possible create a locale that causes test case to fail, like so: > > > >> > > > >> Locale.setDefault(new Locale("en", "DE")) > > > >> Scanner sc = new Scanner("\u0f23.\u0f27"); > > > >> sc.nextFloat(); > > > >> ^ throws InputMismatchException > > > >> > > > >> (This is because using "DE" as the locale's country causes texpects , > > > instead of > > > >> . as the decimal separator.) > > > >> > > > >> The test already saves the current default locale and attempts to find > a > > > >> known > > > >> good locale for running the tests. The difficulty seems to be finding a > > > "known > > > >> good" locale. The current check for the language of English doesn't > work if > > > >> the > > > >> default is en_DE. > > > >> > > > >> Instead, I'd suggest we use the root locale Locale.ROOT as the known > > > good > > > >> locale > > > >> for running the tests. We could then do something like this: > > > >> > > > >> Locale reservedLocale = Locale.getDefault(); > > > >> try { > > > >> Locale.setDefault(Locale.ROOT); > > > >> // run all the tests > > > >> } finally { > > > >> // restore the default locale > > > >> Locale.setDefault(reservedLocale); > > > >> } > > > >> > > > >> and dispense with the logic of searching the existing locales for one > that > > > we > > > >> think is suitable. > > > >> > > > >> (Actually, since the test is being run in /othervm mode, it's not clear to > me > > > >> that restoring the previous default locale is necessary. But that's kind > of a > > > >> separate discussion. I'm ok with leaving the save/restore in place.) > > > >> > > > >> s'marks > > > >> > > > >> On 3/18/19 10:57 AM, Brian Burkhalter wrote: > > > >>> Hi Christoph, > > > >>> > > > >>> Not a locale expert here so you probably need to hear from > someone > > > else, > > > >> but this looks like a reasonable approach to me. One minor comment > is to > > > >> perhaps use format() at lines 67-68 instead of println(). > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Brian > > > >>> > > > >>>> On Mar 18, 2019, at 7:51 AM, Langer, Christoph > > > >> wrote: > > > >>>> > > > >>>> please review a fix for 8172695, where > java/util/Scanner/ScanTest.java > > > >> fails. It reproducibly fails on one of our Mac servers, where the locale > is > > > set to > > > >> en_DE. > > > >>>> > > > >>>> The test in its current form checks if the test VM is run with a > > > supported > > > >> default Locale by just checking the language to be one of ?en?, ?zh?, > ?ko?, > > > >> ?ja?. But it turns out, that also the country part seems to be important. > I > > > >> suggest to change the test case to test whether the VM?s default > locale is > > > >> one of a restricted set of locales and if it isn?t, it shall try to run with > > > >> ?ENGLISH?. > > > >>>> > > > >>>> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to > > > work > > > >> on my machine. Before pushing, I?d run it through the submit repo. > > > >>>> > > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 > > > >> > > > >>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ > > > >> From aph at redhat.com Wed Mar 20 09:38:42 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Mar 2019 09:38:42 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: On 3/20/19 8:02 AM, Langer, Christoph wrote: > Hi Andrew, > >> Thanks. I get that, I'm just questioning the need to backport it to 11. >> No matter, I've approved it now. > > What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. No it doesn't. JDK-8212828 still had a jdk11u-fix-no, so I fixed that. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Mar 20 16:25:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 16:25:55 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> Message-ID: Hi Alan, I now found time to get back to the POSIX file permissions in zipfs. The goal would be to get it done for JDK13 ?? I went through your mail in details, please see my comments: > 1. By default, a zip file system will have no support for the "posix" > and "owner" views of file attributes, this means the following will fail > with UOE: > > ? PosixFileAttributes attrs = Files.readAttributes(file, > PosixFileAttributes.class); > > and the zip file system's supportedFileAttributView method will not > include "posix". Correct. > 2. Creating a zip file system with configuration parameter XXX set to > "true" will create the zip file system that supports > PosixFileAttributeView (and FileOwnerAttributeView). The current patch > names the configuration parameter "posix". That name might be misleading > as a configuration parameter as it conveys more than it actually does. > Something like "enablePosixFileAttributes" clear conveys that it enables > support for POSIX file attribute but might be a better wordy. OK. I've changed to "enablePosixFileAttributes" in my new webrev. > The value in the configuration map is documented as Boolean but I think > we are allowing it to be the string representation of a Boolean, meaning > it can be "true" or "false" like we have with the "create" parameter. I fixed the doc. > 3. The map of configurations parameters can optionally include the > parameters "defaultOwner", "defaultGroup", and "defaultPermissions" with > the default owner/group/permissions to return. These names seem okay to > me. > > For the owner/group, the parameter type can be > UserPrincipal/GroupPrincipal or strings. If the value is a String then > we need to decide if there is any validation. If I read the current > patch correctly then it doesn't do any validation - that might be okay > but minimally maybe we should disallow the empty string. I added checking for the empty string in my new webrev. > If the defaultXXX parameters aren't present then the zip file > owner/group would be a sensible default. If the zip file is on a file > store that supports FileOwnerAttributeView then we've got the owner. If > the file store supports PosixFileAttributeView then we have a group > owner. If PosixFileAttributeView is not supported then using the owner > as the group is okay. I see the current patch as a fallback to fallback > to "" but I'd prefer not have that because it will be > very confusing to diagnose if there are issues. Ok, but what shall we do then in the case of cases? That is, if the file store does not support the FileOwnerAttributeView or security permissions don't allow us to access them? Shall we fail, e.g. throw an IOException upon attempting to create a zipfs? > For defaultPermissions, the value is a Set or the > string representation. In the implementation, initPermissions can be > changed to use PosixFilePermissions.fromString as it does the > translation that we need. I don't see where it still needs to be changed. It's using PosixFilePermissions.fromString already. > 4. As an alternative to the type safe access that PosixFileAttributeView > provides, the proposal is to document the "zip" view of file attributes. > Initially, it will admit to one file attribute for the permissions. The > current patch uses the name "storedPermissions" but it might be simpler > to use "permissions" so that "zip:permissions" and "posix:permissions" > are the same when the zip entry has permissions. There's both, "storedPermissions" and "permissions. "storedPermissions" was chosen deliberately and has a different semantical meaning than "permissions". The former one will reflect the actual permission value on a zip entry, e.g. it can be null. The latter one will use the default, in case no permission information is associated with the zip entry. > With this support you can write code like this: > ??? Set perms = (Set) > Files.getAttribute(file, "zip:permissions"); > > The cast is ugly of course but that's the consequence of not exposing > ZipFileAttributes in the API so there is no type token to specify on the > RHS. That should work with the proposed patch. > Documenting the "zip" view brings up a few issues, e.g. will > Files.readAttributes(file, "zip:*") reveal more than "permissions". For > this API it is okay for the map to attributes beyond the specified list. I guess we should reveal all attributes of a zip view in the documentation. > 5. There will be no support for specifying as POSIX FileAttribute to > createFile or createDirectory to atomically set the permissions when > creating a new file/directory, UOE will thrown as is is now. Nope. It will work with the current state of the patch. Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.8/ What's next? Thanks Christoph From sergei.tsypanov at yandex.ru Wed Mar 20 18:35:53 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Wed, 20 Mar 2019 20:35:53 +0200 Subject: [PATCH] Some improvements for java.lang.Class In-Reply-To: <2796501552936166@myt6-add70abb4f02.qloud-c.yandex.net> References: <2796501552936166@myt6-add70abb4f02.qloud-c.yandex.net> Message-ID: <352521553106953@myt5-184376c2d7f8.qloud-c.yandex.net> I had a brief conversation with Brian Goetz which has left off the mailing list for some reason. Here's the text: --------------------------- Brian: These enhancements seem reasonable; these are exactly the cases that String::repeat was intended for. (This is a ?is this a reasonable idea? review, not a code review.). Have you looked for other places where similar transformations could be done? --------------------------- Me: Hello, after I had realized that looped StringBuilder::append calls can sometimes be replaced with String::repeat I requested corresponding inspection in IDEA issue tracker. Using the inspection I?ve found 129 similar warnings in jdk13 repo. Some of them are very promising, e.g. BigDecimal:: toPlainString where currently we have > int trailingZeros = checkScaleNonZero((-(long)scale)); > StringBuilder buf; > if(intCompact!=INFLATED) { > buf = new StringBuilder(20+trailingZeros); > buf.append(intCompact); > } else { > String str = intVal.toString(); > buf = new StringBuilder(str.length()+trailingZeros); > buf.append(str); > } > for (int i = 0; i < trailingZeros; i++) { > buf.append('0'); > } > return buf.toString(); which in fact can be simplified to > int trailingZeros = checkScaleNonZero((-(long)scale)); > if(intCompact!=INFLATED) { > return intCompact + "0".repeat(trailingZeros); > } else { > return intVal.toString() + "0".repeat(trailingZeros); > } The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. BTW, your reply to original message for some reason is missing from web-view. --------------------------- Brian: Cool. Note that replacing append() calls with repeat is not necessarily a win for anything other than code compactness; String::repeat will create a new string, which will then get appended to another StrinBuilder. So when used correctly (such as presized StringBuilders) appending in a loop is probably just as fast (look at the implementation of String::repeat.). > if(intCompact!=INFLATED) { > return intCompact + "0".repeat(trailingZeros); > } else { > return intVal.toString() + "0".repeat(trailingZeros); > } Which can be further simplified to > ((intCompact != INFLATED) ? intCompact : intVal.toString) + ?0?.repeat(trailingZeros); The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. I like short and simple. I am questioning the ?faster and memory saving.? That should be validated. --------------------------- Me: I think optimizations provided by JEP 280 allow compiler to optimize String concatenation executed with '+' by using StringBuilder of exact size (when the size of all components is known, like in our case). I've checked this with benchmark > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ConcatBenchmark { > > @Param({"1", "2", "5", "8"}) > private int trailingZeros; > > private final long intCompact = 1L; > > @Benchmark > public String stringBuilder() { > StringBuilder buf; > buf = new StringBuilder(20 + trailingZeros); > buf.append(intCompact); > for (int i = 0; i < trailingZeros; i++) { > buf.append('0'); > } > return buf.toString(); > } > @Benchmark > public String stringRepeat() { > return intCompact + "0".repeat(trailingZeros); > } > } Results: trailingZeros Mode Cnt Score Error Units stringBuilder 1 avgt 15 17,683 ? 0,664 ns/op stringRepeat 1 avgt 15 9,052 ? 0,042 ns/op stringBuilder 2 avgt 15 19,053 ? 1,206 ns/op stringRepeat 2 avgt 15 15,864 ? 1,331 ns/op stringBuilder 5 avgt 15 25,839 ? 2,256 ns/op stringRepeat 5 avgt 15 19,290 ? 1,685 ns/op stringBuilder 8 avgt 15 26,488 ? 0,371 ns/op stringRepeat 8 avgt 15 19,420 ? 1,593 ns/op stringBuilder:?gc.alloc.rate.norm 1 avgt 15 88,000 ? 0,001 B/op stringRepeat:?gc.alloc.rate.norm 1 avgt 15 48,000 ? 0,001 B/op stringBuilder:?gc.alloc.rate.norm 2 avgt 15 88,000 ? 0,001 B/op stringRepeat:?gc.alloc.rate.norm 2 avgt 15 72,000 ? 0,001 B/op stringBuilder:?gc.alloc.rate.norm 5 avgt 15 96,000 ? 0,001 B/op stringRepeat:?gc.alloc.rate.norm 5 avgt 15 72,000 ? 0,001 B/op stringBuilder:?gc.alloc.rate.norm 8 avgt 15 104,000 ? 0,001 B/op stringRepeat:?gc.alloc.rate.norm 8 avgt 15 80,000 ? 0,001 B/op I think this is a useful optimization, so we should use String::repeat where possible. --------------------------- Brian: My recommendation is to split your patch into two. The first is the straightforward ?replace loop with repeat? refactoring, which can be mechanically generated by the IDE. Here, you should examine each site to ensure that the transform seems sensible given the context. The second can then be additional hand-refactoring opportunities exposed by the first. The benefit of splitting it this way is that reviewing the first is far easier when you can say all the changes are mechanical. (Somehow this fell off the list; feel free to bring it back.) 18.03.2019, 21:13, "?????? ???????" : > Hi, > > I have an enhancement proposal for java.lang.Class.methodToString and java.lang.Class.getTypeName. > > First one is used when NoSuchMethodException is thrown from Class::getMethod which is in turn widely used in Spring Framework and often throws. > > In current implementation we have 2 major problems: > > - we create stream for the case when argTypes is not null but empty (which happens e. g. when Class::getMethod is called without vararg and throws) > - we have torn StringBuilder::append chain > > I?ve modified the method to skip creation of Stream for empty array and used separate StringBuilder for each case. Latter allowed to rid SB completely and use invokedynamic-based concatenation. > > I?ve compared both approaches for 2 cases: > > 1) argTypes is empty > 2) argTypes.length == 1 > > Benchmark Mode Cnt Score Error Units > > methodToString_noArgs avgt 25 170,986 ? 5,708 ns/op > methodToString_noArgs_patched avgt 25 26,883 ? 2,906 ns/op > > methodToString_1arg avgt 25 183,012 ? 0,701 ns/op > methodToString_1arg_patched avgt 25 112,784 ? 0,920 ns/op > > methodToString_noArgs:?gc.alloc.rate.norm avgt 25 881,600 ? 9,786 B/op > methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 25 128,000 ? 0,001 B/op > > methodToString_1arg:?gc.alloc.rate.norm avgt 25 960,000 ? 0,001 B/op > methodToString_1arg_patched:?gc.alloc.rate.norm avgt 25 552,000 ? 0,001 B/op > > We have the same problem regarding misusage of StringBuilder in Class:: getTypeName: > > StringBuilder sb = new StringBuilder(); > sb.append(cl.getName()); > for (int i = 0; i < dimensions; i++) { > ??? sb.append("[]"); > } > return sb.toString(); > > I suggest to use String::repeat instead of the loop: this again allows to get rid of StringBuilder and replace mentioned code with > > return cl.getName() + "[]".repeat(dimensions); > > Here are benchmark results executed for type Object[].class: > > ??????????????????????????????????????????Mode Cnt Score Error Units > getTypeName_patched avgt 25 16,037 ? 0,431 ns/op > getTypeName_patched:?gc.alloc.rate.norm avgt 25 64,000 ? 0,001 B/op > > getTypeName avgt 25 34,274 ? 1,432 ns/op > getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op > > Regards, > Sergei Tsypanov From fw at deneb.enyo.de Wed Mar 20 18:37:54 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 20 Mar 2019 19:37:54 +0100 Subject: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s) In-Reply-To: (Jason Mehrens's message of "Mon, 11 Mar 2019 16:24:33 +0000") References: <84b2fb20-2e6e-6307-afd8-8eafcfb311a5@gmail.com> Message-ID: <87wokttmrh.fsf@mid.deneb.enyo.de> * Jason Mehrens: > The initial implementation was only optimized to call into > String.compare if the arguments were string [1]. I proposed the > current code a general form to catch java.nio.CharBuffer and any new > JDK implementations of CharSequence + Comparable. > > Naively, I lean towards "- CharSequence interface specification > should be extended to require Comparable CharSeqeunces to implement > lexicographical ordering". There are natural lexicographical orderings, unfortunately. One is according to UCS-2 (currently implemented by String and specified by CharSequence.compare), and the other one according UTF-16, for compatibility with the lexicographical ordering according to Unicode codepoints (which is also compatible with lexicographical ordering of bytes after UTF-8 encoding). There must be implementations of CharSequence out there which implement UTF-16 ordering. From brent.christian at oracle.com Wed Mar 20 21:01:55 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 20 Mar 2019 14:01:55 -0700 Subject: RFR 8211941 : Enable checking/ignoring of non-conforming Class-Path entries Message-ID: <47453cb6-2ea2-7d86-0da1-91e70cad0aa4@oracle.com> Hi, JDK-8216401[1][2] added code to improve JAR spec conformance (WRT relative URLs in the Class-Path attribute), while maintaining some key compatibility aspects (entries using "file:" URLs are not relative, but are used by some libraries). This code was disabled by default, but we would now like to enable it. Bug: https://bugs.openjdk.java.net/browse/JDK-8211941 Webrev: http://cr.openjdk.java.net/~bchristi/8211941/webrev-06/ This change includes a new system property ("jdk.net.URLClassPath.showIgnoredClassPathEntries") that can be set to aid in debugging JAR Class-Paths by printing entries that are ignored. Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8216401 2. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html From jonathan.gibbons at oracle.com Wed Mar 20 21:50:52 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 Mar 2019 14:50:52 -0700 Subject: RFR: docs JDK-8220261: fix headings in java.base Message-ID: Please review a medium-sized but conceptually simple patch to fix most of the headings in the generated documentation for java.base, as described in [1]. This does not address the headings in java.util.concurrent which are reported separately, in JDK-8220248. The intent is to ensure that the headings in the generated pages are well-structured, with no gaps, and correct implicit nesting. Generally, the changes fall into three kinds: * Headings in doc-comments for modules, packages and types start at

              * Headings in doc comments for constructors, fields, methods and other members start at

              * Headings in package.html and doc-files/*.html start at

              The headings have been verified with the doccheck utility. We cannot re-enable doclint accessibility checking for java.base until JDK-8220248 has also been fixed. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8220261 Webrev: http://cr.openjdk.java.net/~jjg/8220261/webrev.00/index.html [1]: https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html From lance.andersen at oracle.com Wed Mar 20 22:16:56 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Mar 2019 18:16:56 -0400 Subject: RFR: docs JDK-8220261: fix headings in java.base In-Reply-To: References: Message-ID: Hi Jon, I went through the patch and it looks good (matches what i did for java.sql.rowset and java.naming :-) ) > On Mar 20, 2019, at 5:50 PM, Jonathan Gibbons wrote: > > JDK-8220248 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 jonathan.gibbons at oracle.com Wed Mar 20 22:32:39 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 Mar 2019 15:32:39 -0700 Subject: RFR: docs JDK-8220261: fix headings in java.base In-Reply-To: References: Message-ID: <5c3cc298-b35a-291f-a10b-e5334e433ca6@oracle.com> Thanks. -- Jon On 03/20/2019 03:16 PM, Lance Andersen wrote: > Hi Jon, > > I went through the patch and it looks good (matches what i did for > java.sql.rowset and java.naming :-) ) > >> On Mar 20, 2019, at 5:50 PM, Jonathan Gibbons >> > wrote: >> >> JDK-8220248 > > > > 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 Mar 20 22:39:18 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Mar 2019 15:39:18 -0700 Subject: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: <28d16e2a-25f6-d1b1-807a-aa1a973adbec@oracle.com> <352429d9-6bce-e5e4-e668-ceed17ae127e@oracle.com> Message-ID: <8e832310-d3aa-1a76-a4f6-c4cc277316c6@oracle.com> I agree, this is not a test of locale-sensitive number parsing, it's a test of Scanner. Thus I think it's reasonable to keep the focus on the Scanner methods. To step back a bit, this bug is about fixing the "intermittent" failure of this test. This isn't case where the test fails randomly 0.5% of the time. The failures are caused by a dependency on the JVM's default locale, which is a *hidden global variable*. It's possible to demonstrate a 100% failure rate the default locale is set to one for which the test is unprepared. Given this, setting the default locale to a known good locale is the right way to fix this test. (I'm reminded of tests and even production code that has a hidden dependency on the VM's default charset. Incorrect assumptions about the default charset can cause all kinds of hilarity.) s'marks On 3/20/19 2:23 AM, Langer, Christoph wrote: > Hi Goetz, > > this test is specifically for java.util.Scanner. > > Generally, it could probably be overhauled to make it run with any Locale. However, then the input data for scanning will need to be written in the Locale that the scanner uses. This is a bit out of scope for me at this point... > > But anyway, thanks for your hint ?? > > /christoph > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Mittwoch, 20. M?rz 2019 10:21 >> To: Langer, Christoph ; Stuart Marks >> >> Cc: core-libs-dev >> Subject: RE: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails >> >> Hi, >> >> if it is only about parsing floats, why not use >> NumberFormat.getInstance().parse(value)? >> >> I did >> 8205108: [testbug] Fix pattern matching in jstatd tests. >> http://hg.openjdk.java.net/jdk- >> updates/jdk11u/rev/1637a4e50fc9?revcount=80 >> some while ago, because we had wrong float parsing on mac in our tests. >> >> ... just a hint to think about, you don't need to redo the change ... >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: core-libs-dev On Behalf >> Of >>> Langer, Christoph >>> Sent: Mittwoch, 20. M?rz 2019 10:10 >>> To: Stuart Marks >>> Cc: core-libs-dev >>> Subject: [CAUTION] RE: RFR(S): 8172695: (scanner) >>> java/util/Scanner/ScanTest.java fails >>> >>> Hi Stuart, >>> >>> thanks for consulting with Naoto and providing the update. >>> >>> So I'll run the fix through jdk-submit and our test system at SAP with >> Locale.US. >>> Provided I don't see issues, I'll push it thereafter... >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Stuart Marks >>>> Sent: Dienstag, 19. M?rz 2019 23:22 >>>> To: Langer, Christoph >>>> Cc: Brian Burkhalter ; core-libs-dev >>> libs-dev at openjdk.java.net> >>>> Subject: Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java >> fails >>>> >>>> Hi Christoph, >>>> >>>> I spoke with Naoto Sato (internationalization) and he recommends using >>>> Locale.US >>>> instead of Locale.ROOT. (Sorry for having misdirected you.) >>>> >>>> The test case in question, parsing float strings, relies on the decimal >>>> separator, which isn't defined in the ROOT locale. Of course it's "." in the >> US >>>> locale. Also, the US locale is the only one that's guaranteed to be >> available; >>>> see Locale::getAvailableLocales. >>>> >>>> So I think your current changeset will be fine if Locale.ROOT is replaced >> with >>>> Locale.US. Assuming it passes test runs. :-) >>>> >>>> s'marks >>>> >>>> >>>> On 3/19/19 1:46 AM, Langer, Christoph wrote: >>>>> Hi Stuart, >>>>> >>>>> thanks for your analysis of this. >>>>> >>>>> So you are suggesting to use Locale.ROOT for this test unconditionally? I >>>> agree ?? >>>>> >>>>> The test coding as it is right now is not ready to support arbitrary locales, >> as >>>> the comment already suggests. Generally, the test probably needs some >>>> overhaul. The scanned Strings should for instance use the Locale's >> decimal >>>> separators instead of hard coding ".". Maybe there are other >> shortcomings. >>>> But as long as this is not done, using Locale ROOT seems to be safe for all >>>> possible scenarios. >>>>> >>>>> I've updated the webrev: >>>> http://cr.openjdk.java.net/~clanger/webrevs/8172695.1/ >>>>> >>>>> Are you ok with that? Brian also? >>>>> >>>>> Thanks >>>>> Christoph >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Stuart Marks >>>>>> Sent: Dienstag, 19. M?rz 2019 00:44 >>>>>> To: Langer, Christoph >>>>>> Cc: Brian Burkhalter ; core-libs-dev >> >>>>> libs-dev at openjdk.java.net> >>>>>> Subject: Re: RFR(S): 8172695: (scanner) >> java/util/Scanner/ScanTest.java >>>> fails >>>>>> >>>>>> Hi Christoph, >>>>>> >>>>>> After looking at this for a little bit I realized that it's not necessary to >>>>>> have a system particular default locale in order to get the test case to >> fail. >>>>>> It's possible create a locale that causes test case to fail, like so: >>>>>> >>>>>> Locale.setDefault(new Locale("en", "DE")) >>>>>> Scanner sc = new Scanner("\u0f23.\u0f27"); >>>>>> sc.nextFloat(); >>>>>> ^ throws InputMismatchException >>>>>> >>>>>> (This is because using "DE" as the locale's country causes texpects , >>>> instead of >>>>>> . as the decimal separator.) >>>>>> >>>>>> The test already saves the current default locale and attempts to find >> a >>>>>> known >>>>>> good locale for running the tests. The difficulty seems to be finding a >>>> "known >>>>>> good" locale. The current check for the language of English doesn't >> work if >>>>>> the >>>>>> default is en_DE. >>>>>> >>>>>> Instead, I'd suggest we use the root locale Locale.ROOT as the known >>>> good >>>>>> locale >>>>>> for running the tests. We could then do something like this: >>>>>> >>>>>> Locale reservedLocale = Locale.getDefault(); >>>>>> try { >>>>>> Locale.setDefault(Locale.ROOT); >>>>>> // run all the tests >>>>>> } finally { >>>>>> // restore the default locale >>>>>> Locale.setDefault(reservedLocale); >>>>>> } >>>>>> >>>>>> and dispense with the logic of searching the existing locales for one >> that >>>> we >>>>>> think is suitable. >>>>>> >>>>>> (Actually, since the test is being run in /othervm mode, it's not clear to >> me >>>>>> that restoring the previous default locale is necessary. But that's kind >> of a >>>>>> separate discussion. I'm ok with leaving the save/restore in place.) >>>>>> >>>>>> s'marks >>>>>> >>>>>> On 3/18/19 10:57 AM, Brian Burkhalter wrote: >>>>>>> Hi Christoph, >>>>>>> >>>>>>> Not a locale expert here so you probably need to hear from >> someone >>>> else, >>>>>> but this looks like a reasonable approach to me. One minor comment >> is to >>>>>> perhaps use format() at lines 67-68 instead of println(). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>>> On Mar 18, 2019, at 7:51 AM, Langer, Christoph >>>>>> wrote: >>>>>>>> >>>>>>>> please review a fix for 8172695, where >> java/util/Scanner/ScanTest.java >>>>>> fails. It reproducibly fails on one of our Mac servers, where the locale >> is >>>> set to >>>>>> en_DE. >>>>>>>> >>>>>>>> The test in its current form checks if the test VM is run with a >>>> supported >>>>>> default Locale by just checking the language to be one of ?en?, ?zh?, >> ?ko?, >>>>>> ?ja?. But it turns out, that also the country part seems to be important. >> I >>>>>> suggest to change the test case to test whether the VM?s default >> locale is >>>>>> one of a restricted set of locales and if it isn?t, it shall try to run with >>>>>> ?ENGLISH?. >>>>>>>> >>>>>>>> I tested the set of US, UK, CHINA, KOREA, JAPAN and GERMANY to >>>> work >>>>>> on my machine. Before pushing, I?d run it through the submit repo. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172695 >>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172695.0/ >>>>>> From peter.levart at gmail.com Wed Mar 20 22:56:37 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 20 Mar 2019 23:56:37 +0100 Subject: [PATCH] Some improvements for java.lang.Class In-Reply-To: <352521553106953@myt5-184376c2d7f8.qloud-c.yandex.net> References: <2796501552936166@myt6-add70abb4f02.qloud-c.yandex.net> <352521553106953@myt5-184376c2d7f8.qloud-c.yandex.net> Message-ID: <1a181b47-e392-c1f7-1ecc-2cf1ab5cd4d2@gmail.com> Hi Sergei, I don't know if you are aware that the new invokedynamic based translation of string concatenation expressions introduced in JDK 9 (http://openjdk.java.net/jeps/280) only applies to code outside java.base module. java.base module is still compiled with old-style StringBuilder based translation of string concatenation expressions because of bootstraping issues. If your benchmarks bellow are compiled with option -XDstringConcat=inline to disable JEP280 translation (as java.base module is), then it's OK. Else you are not benchmarking the right translation of the code as you intend to change the code in java.base module. Regards, Peter On 3/20/19 7:35 PM, ?????? ??????? wrote: > I had a brief conversation with Brian Goetz which has left off the mailing list for some reason. Here's the text: > --------------------------- > Brian: > > These enhancements seem reasonable; these are exactly the cases that String::repeat was intended for. (This is a ?is this a reasonable idea? review, not a code review.). > Have you looked for other places where similar transformations could be done? > > --------------------------- > Me: > > Hello, > after I had realized that looped StringBuilder::append calls can sometimes be replaced with String::repeat I requested corresponding inspection in IDEA issue tracker. > Using the inspection I?ve found 129 similar warnings in jdk13 repo. > Some of them are very promising, e.g. BigDecimal:: toPlainString where currently we have > >> int trailingZeros = checkScaleNonZero((-(long)scale)); >> StringBuilder buf; >> if(intCompact!=INFLATED) { >> buf = new StringBuilder(20+trailingZeros); >> buf.append(intCompact); >> } else { >> String str = intVal.toString(); >> buf = new StringBuilder(str.length()+trailingZeros); >> buf.append(str); >> } >> for (int i = 0; i < trailingZeros; i++) { >> buf.append('0'); >> } >> return buf.toString(); > which in fact can be simplified to > >> int trailingZeros = checkScaleNonZero((-(long)scale)); >> if(intCompact!=INFLATED) { >> return intCompact + "0".repeat(trailingZeros); >> } else { >> return intVal.toString() + "0".repeat(trailingZeros); >> } > The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. > BTW, your reply to original message for some reason is missing from web-view. > > --------------------------- > Brian: > > Cool. Note that replacing append() calls with repeat is not necessarily a win for anything other than code compactness; String::repeat will create a new string, which will then get appended to another StrinBuilder. So when used correctly (such as presized StringBuilders) appending in a loop is probably just as fast (look at the implementation of String::repeat.). > >> if(intCompact!=INFLATED) { >> return intCompact + "0".repeat(trailingZeros); >> } else { >> return intVal.toString() + "0".repeat(trailingZeros); >> } > Which can be further simplified to > >> ((intCompact != INFLATED) ? intCompact : intVal.toString) + ?0?.repeat(trailingZeros); > > The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. > I like short and simple. I am questioning the ?faster and memory saving.? That should be validated. > > --------------------------- > Me: > > I think optimizations provided by JEP 280 allow compiler to optimize String concatenation executed with '+' by using StringBuilder of exact size (when the size of all components is known, like in our case). > > I've checked this with benchmark > >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ConcatBenchmark { >> >> @Param({"1", "2", "5", "8"}) >> private int trailingZeros; >> >> private final long intCompact = 1L; >> >> @Benchmark >> public String stringBuilder() { >> StringBuilder buf; >> buf = new StringBuilder(20 + trailingZeros); >> buf.append(intCompact); >> for (int i = 0; i < trailingZeros; i++) { >> buf.append('0'); >> } >> return buf.toString(); >> } >> @Benchmark >> public String stringRepeat() { >> return intCompact + "0".repeat(trailingZeros); >> } >> } > Results: > trailingZeros Mode Cnt Score Error Units > stringBuilder 1 avgt 15 17,683 ? 0,664 ns/op > stringRepeat 1 avgt 15 9,052 ? 0,042 ns/op > > stringBuilder 2 avgt 15 19,053 ? 1,206 ns/op > stringRepeat 2 avgt 15 15,864 ? 1,331 ns/op > > stringBuilder 5 avgt 15 25,839 ? 2,256 ns/op > stringRepeat 5 avgt 15 19,290 ? 1,685 ns/op > > stringBuilder 8 avgt 15 26,488 ? 0,371 ns/op > stringRepeat 8 avgt 15 19,420 ? 1,593 ns/op > > stringBuilder:?gc.alloc.rate.norm 1 avgt 15 88,000 ? 0,001 B/op > stringRepeat:?gc.alloc.rate.norm 1 avgt 15 48,000 ? 0,001 B/op > > stringBuilder:?gc.alloc.rate.norm 2 avgt 15 88,000 ? 0,001 B/op > stringRepeat:?gc.alloc.rate.norm 2 avgt 15 72,000 ? 0,001 B/op > > stringBuilder:?gc.alloc.rate.norm 5 avgt 15 96,000 ? 0,001 B/op > stringRepeat:?gc.alloc.rate.norm 5 avgt 15 72,000 ? 0,001 B/op > > stringBuilder:?gc.alloc.rate.norm 8 avgt 15 104,000 ? 0,001 B/op > stringRepeat:?gc.alloc.rate.norm 8 avgt 15 80,000 ? 0,001 B/op > > > I think this is a useful optimization, so we should use String::repeat where possible. > > --------------------------- > Brian: > > My recommendation is to split your patch into two. The first is the straightforward ?replace loop with repeat? refactoring, which can be mechanically generated by the IDE. Here, you should examine each site to ensure that the transform seems sensible given the context. The second can then be additional hand-refactoring opportunities exposed by the first. The benefit of splitting it this way is that reviewing the first is far easier when you can say all the changes are mechanical. > > (Somehow this fell off the list; feel free to bring it back.) > > > 18.03.2019, 21:13, "?????? ???????" : >> Hi, >> >> I have an enhancement proposal for java.lang.Class.methodToString and java.lang.Class.getTypeName. >> >> First one is used when NoSuchMethodException is thrown from Class::getMethod which is in turn widely used in Spring Framework and often throws. >> >> In current implementation we have 2 major problems: >> >> - we create stream for the case when argTypes is not null but empty (which happens e. g. when Class::getMethod is called without vararg and throws) >> - we have torn StringBuilder::append chain >> >> I?ve modified the method to skip creation of Stream for empty array and used separate StringBuilder for each case. Latter allowed to rid SB completely and use invokedynamic-based concatenation. >> >> I?ve compared both approaches for 2 cases: >> >> 1) argTypes is empty >> 2) argTypes.length == 1 >> >> Benchmark Mode Cnt Score Error Units >> >> methodToString_noArgs avgt 25 170,986 ? 5,708 ns/op >> methodToString_noArgs_patched avgt 25 26,883 ? 2,906 ns/op >> >> methodToString_1arg avgt 25 183,012 ? 0,701 ns/op >> methodToString_1arg_patched avgt 25 112,784 ? 0,920 ns/op >> >> methodToString_noArgs:?gc.alloc.rate.norm avgt 25 881,600 ? 9,786 B/op >> methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 25 128,000 ? 0,001 B/op >> >> methodToString_1arg:?gc.alloc.rate.norm avgt 25 960,000 ? 0,001 B/op >> methodToString_1arg_patched:?gc.alloc.rate.norm avgt 25 552,000 ? 0,001 B/op >> >> We have the same problem regarding misusage of StringBuilder in Class:: getTypeName: >> >> StringBuilder sb = new StringBuilder(); >> sb.append(cl.getName()); >> for (int i = 0; i < dimensions; i++) { >> ??? sb.append("[]"); >> } >> return sb.toString(); >> >> I suggest to use String::repeat instead of the loop: this again allows to get rid of StringBuilder and replace mentioned code with >> >> return cl.getName() + "[]".repeat(dimensions); >> >> Here are benchmark results executed for type Object[].class: >> >> ??????????????????????????????????????????Mode Cnt Score Error Units >> getTypeName_patched avgt 25 16,037 ? 0,431 ns/op >> getTypeName_patched:?gc.alloc.rate.norm avgt 25 64,000 ? 0,001 B/op >> >> getTypeName avgt 25 34,274 ? 1,432 ns/op >> getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op >> >> Regards, >> Sergei Tsypanov From mandy.chung at oracle.com Wed Mar 20 23:20:32 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Mar 2019 16:20:32 -0700 Subject: RFR: docs JDK-8220261: fix headings in java.base In-Reply-To: References: Message-ID: I looked through the webrev and this looks fine to me. Mandy On 3/20/19 2:50 PM, Jonathan Gibbons wrote: > Please review a medium-sized but conceptually simple patch to fix most > of the headings in the generated documentation for java.base, as > described in [1]. This does not address the headings in > java.util.concurrent which are reported separately, in JDK-8220248. > > The intent is to ensure that the headings in the generated pages are > well-structured, with no gaps, and correct implicit nesting. > Generally, the changes fall into three kinds: > > ?* Headings in doc-comments for modules, packages and types start at

              > ?* Headings in doc comments for constructors, fields, methods and other > ?? members start at

              > ?* Headings in package.html and doc-files/*.html start at

              > > The headings have been verified with the doccheck utility. > > We cannot re-enable doclint accessibility checking for java.base until > JDK-8220248 has also been fixed. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220261 > Webrev: http://cr.openjdk.java.net/~jjg/8220261/webrev.00/index.html > > [1]: > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html > From alexander.matveev at oracle.com Thu Mar 21 00:05:37 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 20 Mar 2019 17:05:37 -0700 Subject: RFR: JDK-8215019: Allow --install-dir on windows Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Added support for --install-dir on Windows. It should be relative path to "Program Files" or "AppData". - If --install-dir is invalid we will use app name instead. - Added two new tests to validate --install-dir and related functionality. [1] https://bugs.openjdk.java.net/browse/JDK-8215019 [2] http://cr.openjdk.java.net/~almatvee/8215019/webrev.00/ Thanks, Alexander From mandy.chung at oracle.com Thu Mar 21 00:28:50 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Mar 2019 17:28:50 -0700 Subject: RFR 8211941 : Enable checking/ignoring of non-conforming Class-Path entries In-Reply-To: <47453cb6-2ea2-7d86-0da1-91e70cad0aa4@oracle.com> References: <47453cb6-2ea2-7d86-0da1-91e70cad0aa4@oracle.com> Message-ID: Hi Brent, The change looks fine. Can you file a JBS issue to follow up a place to document this JDK-specific property? thanks Mandy On 3/20/19 2:01 PM, Brent Christian wrote: > Hi, > > JDK-8216401[1][2] added code to improve JAR spec conformance (WRT > relative URLs in the Class-Path attribute), while maintaining some key > compatibility aspects (entries using "file:" URLs are not relative, > but are used by some libraries). > > This code was disabled by default, but we would now like to enable it. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211941 > Webrev: > http://cr.openjdk.java.net/~bchristi/8211941/webrev-06/ > > This change includes a new system property > ("jdk.net.URLClassPath.showIgnoredClassPathEntries") that can be set > to aid in debugging JAR Class-Paths by printing entries that are ignored. > > Thanks, > -Brent > > 1. https://bugs.openjdk.java.net/browse/JDK-8216401 > > 2. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html From mandy.chung at oracle.com Thu Mar 21 00:39:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Mar 2019 17:39:37 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <9140740e-a4db-71ee-2b2e-c4c9dc2aba84@oracle.com> Message-ID: <6667efa8-c892-d08e-70cd-b669ed11e758@oracle.com> On 3/20/19 1:54 AM, Lindenmaier, Goetz wrote: > Should I move the JEP to status 'submitted'? Per the Process states section? [1] Draft --- In circulation by the author for initial review and consensus-building I certainly don't want to be the bottleneck.?? Others can help do the initial review. Mandy [1] http://openjdk.java.net/jeps/1#Process-states From daniel.smith at oracle.com Thu Mar 21 04:03:04 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 20 Mar 2019 22:03:04 -0600 Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation Message-ID: http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ Please review this update to java.lang.invoke.LambdaMetafactory. Adds some argument validation with tests; improves documentation; renames some variables. JBS: https://bugs.openjdk.java.net/browse/JDK-8174222 ?Dan From mandy.chung at oracle.com Thu Mar 21 05:22:51 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Mar 2019 22:22:51 -0700 Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: References: Message-ID: On 3/20/19 9:03 PM, Dan Smith wrote: > http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ AbstractValidatingLambdaMetafactory.java + throw new LambdaConversionException("implementation is not direct or cannot be cracked"); It may help to print implementation method handle: throw new LambdaConversionException(implementation + " is not direct or cannot be cracked"); If you mind the formatting, the text descripting @param seems to be aligned with the first word in the description above it. I don't know if the webrev shows the whitespace properly you may want to check out line 90-93. Where does SecurityException get thrown? I think this needs a CSR. metafactory and altMetafactory @throws IAE, NPE and SecurityException. The class description of LambdaMetafactory also promotes @implNote to the spec. Otherwise looks good. Mandy From forax at univ-mlv.fr Thu Mar 21 13:17:11 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Mar 2019 14:17:11 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <1409f831-2153-997d-b23a-bccb02e2600a@oracle.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> <765913287.277879.1552952304666.JavaMail.zimbra@u-pem.fr> <1409f831-2153-997d-b23a-bccb02e2600a@oracle.com> Message-ID: <604470012.1583475.1553174231821.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Remi Forax" , "Stuart Marks" > Cc: "core-libs-dev" > Envoy?: Mardi 19 Mars 2019 00:58:04 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams >> My fear is more than we will want in the future to have one code for all kinds >> of Stream, but Stream will have to implement Iterable while >> Stream will not, this not something you can actually do with the current >> generics, we may be able to do that with the reified generics but some >> languages that already have reified generics like Swift are not able to do >> that. >> So by making Stream to have different set of supertypes than Stream, you >> are forcing the future reified generics implementation to work on this case >> because we will never introduce an implementation of reified generics that >> doesn't support the classe of java.util. > > This will work fine; Stream <: IterableOnce, and when we can > instantiate T=int in the first, we'll be able to do so in the second as > well.? (Having spent hundreds of hours banging my head against how we're > going to migrate collections and stream to specialization, this one is > not even on the list.) for some reason i was convinced that IntStream.iterator() was returning a PrimitiveIterator.OfInt and not an Iterator, so yes, it will work but i don't understand why it's not BaseStream instead of Stream that inherits from Iterable. And i still think that add IterableOnce is a very bad idea because it's the same trap as trying to introduce an interface UnmodifiableList as subtype of List. R?mi From matthias.baesken at sap.com Thu Mar 21 13:29:34 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 21 Mar 2019 13:29:34 +0000 Subject: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows Message-ID: Hi Alan + Christoph, coming back to https://bugs.openjdk.java.net/browse/JDK-8218547 . We wanted to check for the whole flow (in JLI_Open on Windows ) , e.g. checking whether only CreateFileW can be used instead of open. I think there is already a similar solution available in the codebase . See the os::open + create_unc_path functions in os_windows.cpp in the hotspot coding . There "simple" open is used for shorter paths ( < MAX_PATH) ; for larger paths an elp / unc path is constructed and _wopen is used on the elp/unc path : if (strlen(path) < MAX_PATH) { ret = ::open(pathbuf, oflag | O_BINARY | O_NOINHERIT, mode); } else { errno_t err = ERROR_SUCCESS; wchar_t* wpath = create_unc_path(pathbuf, err); .... ret = ::_wopen(wpath, oflag | O_BINARY | O_NOINHERIT, mode); I think we should do it the same way in JLI_Open . Is that fine with you? Unfortunately I think we cannot easily reuse the HS coding, so the have to take it over to jli . Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 6. Februar 2019 09:56 > To: Langer, Christoph > Cc: Chris Hegarty ; core-libs- > dev at openjdk.java.net; Alan Bateman (Alan.Bateman at oracle.com) > > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Christoph+Alan, I opened > > > https://bugs.openjdk.java.net/browse/JDK-8218547 > > JDK-8218547 : use CreateFile without open on Windows in jdk native code > > > To check for the usage of CreateFile (CreateFileW) without open . > > > Best regards, Matthias > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Dienstag, 29. Januar 2019 09:59 > > To: Baesken, Matthias > > Cc: Chris Hegarty ; core-libs- > > dev at openjdk.java.net > > Subject: RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hi Matthias, > > > > > > New webrev : > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > > > > > This is the one. Looks good ( and clean ). > > > > I agree, this version would be ok for me to be pushed. It would be good > > ,though, if there was a test for this (long paths on Windows). > > > > I also like Alan's suggestion to open a follow up bug to explore using > > CreateFile on Windows right away rather than trying open. Looking at > > libjava/libnet/libnio, it's all CreateFileW on Windows... > > > > Best regards > > Christoph > > From daniel.smith at oracle.com Thu Mar 21 13:39:05 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 21 Mar 2019 06:39:05 -0700 (PDT) Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: References: Message-ID: <8AD0071C-2CEF-4127-868C-238C1D8CD7F4@oracle.com> > On Mar 20, 2019, at 11:22 PM, Mandy Chung wrote: > > On 3/20/19 9:03 PM, Dan Smith wrote: >> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ > > AbstractValidatingLambdaMetafactory.java > + throw new LambdaConversionException("implementation is not direct or cannot be cracked"); > > It may help to print implementation method handle: > > throw new LambdaConversionException(implementation + " is not direct or cannot be cracked"); Not sure how useful the toString will be, but I suppose it's better than nothing. They seem to all start with "MethodHandle", so at least it will be clear what kind of object we're talking about. Done. > If you mind the formatting, the text descripting @param seems > to be aligned with the first word in the description above it. > I don't know if the webrev shows the whitespace properly > you may want to check out line 90-93. Yes, those need some extra indenting. Fixed. > Where does SecurityException get thrown? The call to 'revealDirect'. Added a comment. > I think this needs a CSR. metafactory and altMetafactory @throws > IAE, NPE and SecurityException. Yes, agreed. Created here: https://bugs.openjdk.java.net/browse/JDK-8221255 > The class description of LambdaMetafactory also promotes @implNote to the spec. Yep. Changed to an @apiNote, actually. It was wrong to treat it as an @implNote, because implementations don't get to decide which set of MethodHandles to support. > Otherwise looks good. Thanks! From peter.levart at gmail.com Thu Mar 21 14:54:21 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 21 Mar 2019 15:54:21 +0100 Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <604470012.1583475.1553174231821.JavaMail.zimbra@u-pem.fr> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <722720942.1092252.1551561588746.JavaMail.zimbra@u-pem.fr> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> <765913287.277879.1552952304666.JavaMail.zimbra@u-pem.fr> <1409f831-2153-997d-b23a-bccb02e2600a@oracle.com> <604470012.1583475.1553174231821.JavaMail.zimbra@u-pem.fr> Message-ID: <79542bf7-4f0b-e193-54c2-9d80f323ec00@gmail.com> On 3/21/19 2:17 PM, forax at univ-mlv.fr wrote: > for some reason i was convinced that IntStream.iterator() was returning a PrimitiveIterator.OfInt and not an Iterator, > so yes, it will work but i don't understand why it's not BaseStream instead of Stream that inherits from Iterable. I think it's the Iterable.forEach(Consumer) that would clash with IntStream.forEach(IntConsumer), LongStream.forEach(LongConsumer) and DoubleStream.forEach(DoubleConsumer) if Iterable was a supertype of BaseStream. ...unless IntConsumer was made to extend Consumer, LongConsumer was made to extend Consumer and DoubleConsumer was made to extend Consumer... I tried that and it (almost) compiles. The sole problem presents the following class: ??? public class LongSummaryStatistics implements LongConsumer, IntConsumer { ... So I had another idea. What if IntConsumer, LongConsumer and DoubleConsumer were all made to extend Consumer ? In that case LongSummaryStatistics would only have to override the method to disambiguate it. By doing that, the problem springs in java.util.stream.Sink hierarchy (Sink extends Consumer) where Sink.OfInt extends both Sink and IntConsumer... Perhaps this could be fixed (as it is internal non-public API), but the same problem could exist in 3rd party code... Regards, Peter From brian.goetz at oracle.com Thu Mar 21 14:58:37 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 21 Mar 2019 10:58:37 -0400 Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: References: Message-ID: <9dc49415-c28a-7e1a-3bd0-3b07b025fdf2@oracle.com> +1 from me. > http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ > > AbstractValidatingLMF --------------------- I see you renamed most of the fields and params.? Most of these are improvements, but it may be worth being more explicit in ambiguous cases.? For example, there are two method names, so perhaps instead of `methodName` it should be `interfaceMethodName` to make it clear this is the SAM method and not the implementation method. I presume the SecurityException is something that was always thrown, and we are just documenting it now.? Should that be wrapped in a LCE instead? (Similar for ICLMF) LMF --- Accidentally lost the {@code ...} surrounding MethodHandle in class description. From Alan.Bateman at oracle.com Thu Mar 21 15:20:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Mar 2019 15:20:46 +0000 Subject: RFR 8211941 : Enable checking/ignoring of non-conforming Class-Path entries In-Reply-To: <47453cb6-2ea2-7d86-0da1-91e70cad0aa4@oracle.com> References: <47453cb6-2ea2-7d86-0da1-91e70cad0aa4@oracle.com> Message-ID: On 20/03/2019 21:01, Brent Christian wrote: > Hi, > > JDK-8216401[1][2] added code to improve JAR spec conformance (WRT > relative URLs in the Class-Path attribute), while maintaining some key > compatibility aspects (entries using "file:" URLs are not relative, > but are used by some libraries). > > This code was disabled by default, but we would now like to enable it. This looks good to me too. -Alan. From forax at univ-mlv.fr Thu Mar 21 15:48:28 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Mar 2019 16:48:28 +0100 (CET) Subject: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams In-Reply-To: <79542bf7-4f0b-e193-54c2-9d80f323ec00@gmail.com> References: <663af988-f661-d2cd-b4ec-515e67c1e619@oracle.com> <3da5dd21-2f75-afc3-816f-af212234c4c8@oracle.com> <568990780.935538.1552550842423.JavaMail.zimbra@u-pem.fr> <4048ffa4-6b06-b561-a0f1-b12b3d3f4166@oracle.com> <765913287.277879.1552952304666.JavaMail.zimbra@u-pem.fr> <1409f831-2153-997d-b23a-bccb02e2600a@oracle.com> <604470012.1583475.1553174231821.JavaMail.zimbra@u-pem.fr> <79542bf7-4f0b-e193-54c2-9d80f323ec00@gmail.com> Message-ID: <427826997.1643061.1553183308723.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "Remi Forax" , "Brian Goetz" > Cc: "core-libs-dev" > Envoy?: Jeudi 21 Mars 2019 15:54:21 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > On 3/21/19 2:17 PM, forax at univ-mlv.fr wrote: >> for some reason i was convinced that IntStream.iterator() was returning a >> PrimitiveIterator.OfInt and not an Iterator, >> so yes, it will work but i don't understand why it's not BaseStream instead of >> Stream that inherits from Iterable. > > I think it's the Iterable.forEach(Consumer) that would clash > with IntStream.forEach(IntConsumer), LongStream.forEach(LongConsumer) > and DoubleStream.forEach(DoubleConsumer) if Iterable was a supertype of > BaseStream. > > ...unless IntConsumer was made to extend Consumer, LongConsumer > was made to extend Consumer and DoubleConsumer was made to extend > Consumer... > > I tried that and it (almost) compiles. The sole problem presents the > following class: > > ??? public class LongSummaryStatistics implements LongConsumer, > IntConsumer { ... > > So I had another idea. What if IntConsumer, LongConsumer and > DoubleConsumer were all made to extend Consumer ? > > In that case LongSummaryStatistics would only have to override the > method to disambiguate it. > > By doing that, the problem springs in java.util.stream.Sink hierarchy > (Sink extends Consumer) where Sink.OfInt extends both > Sink and IntConsumer... > > Perhaps this could be fixed (as it is internal non-public API), but the > same problem could exist in 3rd party code... having a class that implements 2 consumers like IntConsumer and LongConsumer is hard to retrofit if as you said IntConsumer is a subtype of Consumer and LongConsumer is a subtype of Consumer, it means that the bridge accept(Object) has to dispatch to accept(int) and accept(long) at the same time A code like Object o = ... Consumer c = new LongSummaryStatistics(...); c.accept(o); shows the issue. Having LongSummaryStatistics implementing IntConsumer was a mistake in retrospect. so thanks, i've my answer why BaseStream can not implement Iterable until at least we have reified generics. > > Regards, Peter regards, R?mi From adam.farley at uk.ibm.com Thu Mar 21 16:51:23 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 21 Mar 2019 16:51:23 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: Hi Mandy, Good spot. Have updated the webrev. http://cr.openjdk.java.net/~afarley/8216558/webrev/ Could you review the proposed change? Also, I ran the invoke tests as advised, and the only one that fails is "LFGarbageCollectedTest.java", which also fails in the same way when run against a non-patched java, so I think we're ok. Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 20/03/2019 05:08:37: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 20/03/2019 05:10 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > > I imported your patch but there is one test failure: > > test/jdk/java/lang/invoke/VarHandles/accessibility/ > TestFieldLookupAccessibility.java > > This test needs update of this change. Can you please send an updated > patch and run all test/jdk/java/lang/invoke tests. > > Mandy > > On 3/6/19 8:28 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > The webrev has been updated with the new test: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8216558_webrev_&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=O5CP6Q1HCaWGgNnRJQd_nB-y- > yzhE9tMJCTaqP-Sezo&s=2pU2OPf0uzVxxO95vYcq37aYknofgj2TKansTE2chyY&e= > > > > Note that I included a handful of small improvements, and that the final > > fields are all setAccessible by default, because (a) it seemed cleaner > > than adding a new control bit, and (b) nobody is meant to be changing > > final fields anyway. > > > > Open for review. > > > > 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 andy.herrick at oracle.com Thu Mar 21 17:08:53 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 21 Mar 2019 13:08:53 -0400 Subject: RFR: JDK-8215019: Allow --install-dir on windows In-Reply-To: References: Message-ID: <83569542-51ad-7d06-247b-274655fcbf51@oracle.com> I think you missed HelpResources_zh_CN.properties I think wording of help text: 'sub-path of the installation location of the application such as"Program Files" or "AppData"' is? misleading.? It reads like "Program files" or "AppDAta" are examples of the sub-path. The error message says: 'sub-path under default installation location" which is a little better. (though there should be a "the" before default). /Andy On 3/20/2019 8:05 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Added support for --install-dir on Windows. It should be relative > path to "Program Files" or "AppData". > - If --install-dir is invalid we will use app name instead. > - Added two new tests to validate --install-dir and related > functionality. > > [1] https://bugs.openjdk.java.net/browse/JDK-8215019 > > [2] http://cr.openjdk.java.net/~almatvee/8215019/webrev.00/ > > Thanks, > Alexander From bob.vandette at oracle.com Thu Mar 21 17:12:04 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 21 Mar 2019 13:12:04 -0400 Subject: RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs Message-ID: Please review this fix for a container test that fails on some Linux distributions. The test fails to see the Memory Fail count metric value increase. This is caused by the fact that we are allowing ergonomics to select the amount of Heap size. This size varies depending on the amount of free memory that?s available on different docker implementations. The fix is to force the VM to always set the heap size to the size of the containers memory. This change also stops allocating once it sees the fail count increase. This is needed to keep the container from getting killed by the out of memory killer. The fix has been verified by the submitter along with a local run of the container tests. BUG: https://bugs.openjdk.java.net/browse/JDK-8220674 WEBREV: http://cr.openjdk.java.net/~bobv/8220674/webrev/ Bob. From sgehwolf at redhat.com Thu Mar 21 17:54:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Mar 2019 18:54:50 +0100 Subject: RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs In-Reply-To: References: Message-ID: Hi Bob, On Thu, 2019-03-21 at 13:12 -0400, Bob Vandette wrote: > WEBREV: > > http://cr.openjdk.java.net/~bobv/8220674/webrev/ This looks good to me. Thanks for fixing it! I'm not a Reviewer, though. Cheers, Severin From brent.christian at oracle.com Thu Mar 21 17:59:53 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 21 Mar 2019 10:59:53 -0700 Subject: RFR 8211941 : Enable checking/ignoring of non-conforming Class-Path entries In-Reply-To: References: <47453cb6-2ea2-7d86-0da1-91e70cad0aa4@oracle.com> Message-ID: Done: 8221267[1] : Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8221267 On 3/20/19 5:28 PM, Mandy Chung wrote: > Hi Brent, > > The change looks fine. > > Can you file a JBS issue to follow up a place to document this > JDK-specific property? > > thanks > Mandy > > On 3/20/19 2:01 PM, Brent Christian wrote: >> Hi, >> >> JDK-8216401[1][2] added code to improve JAR spec conformance (WRT >> relative URLs in the Class-Path attribute), while maintaining some key >> compatibility aspects (entries using "file:" URLs are not relative, >> but are used by some libraries). >> >> This code was disabled by default, but we would now like to enable it. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8211941 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8211941/webrev-06/ >> >> This change includes a new system property >> ("jdk.net.URLClassPath.showIgnoredClassPathEntries") that can be set >> to aid in debugging JAR Class-Paths by printing entries that are ignored. >> >> Thanks, >> -Brent >> >> 1. https://bugs.openjdk.java.net/browse/JDK-8216401 >> >> 2. >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > From serguei.spitsyn at oracle.com Thu Mar 21 18:10:24 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Mar 2019 11:10:24 -0700 Subject: RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs In-Reply-To: References: Message-ID: <70f2d8c6-e3e6-7676-e4fb-6928588f0704@oracle.com> Hi Bob, It looks good to me. Thanks, Serguei On 3/21/19 10:12, Bob Vandette wrote: > Please review this fix for a container test that fails on some Linux distributions. > > The test fails to see the Memory Fail count metric value increase. This is caused by > the fact that we are allowing ergonomics to select the amount of Heap size. This > size varies depending on the amount of free memory that?s available on different > docker implementations. > > The fix is to force the VM to always set the heap size to the size of the containers > memory. This change also stops allocating once it sees the fail count increase. > This is needed to keep the container from getting killed by the out of memory > killer. > > The fix has been verified by the submitter along with a local run of the container tests. > > BUG: > > https://bugs.openjdk.java.net/browse/JDK-8220674 > > WEBREV: > > http://cr.openjdk.java.net/~bobv/8220674/webrev/ > > Bob. > > From brian.burkhalter at oracle.com Thu Mar 21 19:05:24 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Mar 2019 12:05:24 -0700 Subject: 8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off] Message-ID: <405DE107-3500-4BD8-AA34-2C4457DA73B1@oracle.com> Please review this trivial fix for [0]: @@ -237,7 +237,7 @@ * b[off+len-1] unaffected. * *

              In every case, elements b[0] through - * b[off] and elements b[off+len] through + * b[off-1] and elements b[off+len] through * b[b.length-1] are unaffected. * *

              The read(b, off, len) method Also, is a CSR needed for something this small? I assume so ... Thanks, Brian [0] https://bugs.openjdk.java.net/browse/JDK-8078860 From lance.andersen at oracle.com Thu Mar 21 19:23:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 21 Mar 2019 15:23:30 -0400 Subject: 8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off] In-Reply-To: <405DE107-3500-4BD8-AA34-2C4457DA73B1@oracle.com> References: <405DE107-3500-4BD8-AA34-2C4457DA73B1@oracle.com> Message-ID: +1 > On Mar 21, 2019, at 3:05 PM, Brian Burkhalter wrote: > > Please review this trivial fix for [0]: > > @@ -237,7 +237,7 @@ > * b[off+len-1] unaffected. > * > *

              In every case, elements b[0] through > - * b[off] and elements b[off+len] through > + * b[off-1] and elements b[off+len] through > * b[b.length-1] are unaffected. > * > *

              The read(b, off, len) method > > Also, is a CSR needed for something this small? I assume so ... > > Thanks, > > Brian > > [0] https://bugs.openjdk.java.net/browse/JDK-8078860 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 naoto.sato at oracle.com Thu Mar 21 20:54:50 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 21 Mar 2019 13:54:50 -0700 Subject: [13] RFR: 8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly. Message-ID: <6dba7fd4-3bc1-fe5f-8a6d-c00b6078a659@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8220224 Here is the CSR and proposed changeset: https://bugs.openjdk.java.net/browse/JDK-8220728 http://cr.openjdk.java.net/~naoto/8220224/webrev.01/ DecimalFormatSymbols assumes minus/percent/permille as a single character, which is not capable of supporting ones for BiDi languages that involve BiDi formatting characters. With this fix, DecimalFormatSymbols uses String variants of symbols from CLDR, and retains them for serialization. The above webrev contains tag cleanup which was suggested in the CSR. The following webrev only contains relevant changes to the issue (excluding those cleanup): http://cr.openjdk.java.net/~naoto/8220224/webrev.00/ Naoto From Roger.Riggs at oracle.com Thu Mar 21 20:54:28 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 21 Mar 2019 16:54:28 -0400 Subject: 8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off] In-Reply-To: References: <405DE107-3500-4BD8-AA34-2C4457DA73B1@oracle.com> Message-ID: <42ca058a-f89f-ad11-745f-5a5cfd9bc104@oracle.com> +1 And I don't think a CSR is warranted,? The text being modified does not change the behavior, it makes a statement about what the method does not do. (Which is pretty obvious). Roger On 03/21/2019 03:23 PM, Lance Andersen wrote: > +1 >> On Mar 21, 2019, at 3:05 PM, Brian Burkhalter wrote: >> >> Please review this trivial fix for [0]: >> >> @@ -237,7 +237,7 @@ >> * b[off+len-1] unaffected. >> * >> *

              In every case, elements b[0] through >> - * b[off] and elements b[off+len] through >> + * b[off-1] and elements b[off+len] through >> * b[b.length-1] are unaffected. >> * >> *

              The read(b, off, len) method >> >> Also, is a CSR needed for something this small? I assume so ... >> >> Thanks, >> >> Brian >> >> [0] https://bugs.openjdk.java.net/browse/JDK-8078860 > > > 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 joe.darcy at oracle.com Thu Mar 21 21:11:38 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 21 Mar 2019 14:11:38 -0700 Subject: [13] RFR: 8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly. In-Reply-To: <6dba7fd4-3bc1-fe5f-8a6d-c00b6078a659@oracle.com> References: <6dba7fd4-3bc1-fe5f-8a6d-c00b6078a659@oracle.com> Message-ID: <5C93FE0A.9040008@oracle.com> Hi Naoto, Looks okay. The serial-related declarations are still using ; I think it is fine to push what you have now, but what encourage a follow-up bug to replace foo with {@code foo} throughout the entire class. Thanks, -Joe On 3/21/2019 1:54 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8220224 > > Here is the CSR and proposed changeset: > > https://bugs.openjdk.java.net/browse/JDK-8220728 > http://cr.openjdk.java.net/~naoto/8220224/webrev.01/ > > DecimalFormatSymbols assumes minus/percent/permille as a single > character, which is not capable of supporting ones for BiDi languages > that involve BiDi formatting characters. With this fix, > DecimalFormatSymbols uses String variants of symbols from CLDR, and > retains them for serialization. > > The above webrev contains tag cleanup which was suggested in > the CSR. The following webrev only contains relevant changes to the > issue (excluding those cleanup): > > http://cr.openjdk.java.net/~naoto/8220224/webrev.00/ > > Naoto From joe.darcy at oracle.com Thu Mar 21 21:24:02 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 21 Mar 2019 14:24:02 -0700 Subject: [13] RFR: 8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly. In-Reply-To: <5C93FE0A.9040008@oracle.com> References: <6dba7fd4-3bc1-fe5f-8a6d-c00b6078a659@oracle.com> <5C93FE0A.9040008@oracle.com> Message-ID: <5C9400F2.1080209@oracle.com> PS Looking more closely, I see the the issue is addressed in the 01 version of the webrev; I was only looking at the 00 version before :-) Thanks, -Joe On 3/21/2019 2:11 PM, Joseph D. Darcy wrote: > Hi Naoto, > > Looks okay. The serial-related declarations are still using > ; I think it is fine to push what you have now, but what > encourage a follow-up bug to replace foo with {@code foo} > throughout the entire class. > > Thanks, > > -Joe > > On 3/21/2019 1:54 PM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8220224 >> >> Here is the CSR and proposed changeset: >> >> https://bugs.openjdk.java.net/browse/JDK-8220728 >> http://cr.openjdk.java.net/~naoto/8220224/webrev.01/ >> >> DecimalFormatSymbols assumes minus/percent/permille as a single >> character, which is not capable of supporting ones for BiDi languages >> that involve BiDi formatting characters. With this fix, >> DecimalFormatSymbols uses String variants of symbols from CLDR, and >> retains them for serialization. >> >> The above webrev contains tag cleanup which was suggested in >> the CSR. The following webrev only contains relevant changes to the >> issue (excluding those cleanup): >> >> http://cr.openjdk.java.net/~naoto/8220224/webrev.00/ >> >> Naoto > From mandy.chung at oracle.com Fri Mar 22 00:35:00 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Mar 2019 17:35:00 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> Message-ID: <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> 217 //If this is a USA test, then only the fraction of the expected failures will occur; those which are both static and final. 218 if (fl != FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE && actualFieldNames.stream().anyMatch(s->!(s.contains("static")&&(s.contains("final"))))) What is a USA test? Why the assertion becomes conditional? Have you considered another way doing it? Mandy On 3/21/19 9:51 AM, Adam Farley8 wrote: > Hi Mandy, > > Good spot. Have updated the webrev. > > http://cr.openjdk.java.net/~afarley/8216558/webrev/ > > Could you review the proposed change? > > Also, I ran the invoke tests as advised, and the only one that > fails is "LFGarbageCollectedTest.java", which also fails in the > same way when run against a non-patched java, so I think we're ok. > > Best Regards > > Adam Farley > IBM Runtimes From joe.darcy at oracle.com Fri Mar 22 01:42:43 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 21 Mar 2019 18:42:43 -0700 Subject: 8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off] In-Reply-To: <42ca058a-f89f-ad11-745f-5a5cfd9bc104@oracle.com> References: <405DE107-3500-4BD8-AA34-2C4457DA73B1@oracle.com> <42ca058a-f89f-ad11-745f-5a5cfd9bc104@oracle.com> Message-ID: <5C943D93.10500@oracle.com> Hello, I would say the text in question is a (slightly incorrect) attempt to provide some explicit informative implications of the preceding normative text of the spec, so a CSR is not required for this correction. (There are other cases where a small correction would require a CSR.) Thanks; HTH, -Joe On 3/21/2019 1:54 PM, Roger Riggs wrote: > +1 > > And I don't think a CSR is warranted, The text being modified > does not change the behavior, it makes a statement about what > the method does not do. (Which is pretty obvious). > > Roger > > On 03/21/2019 03:23 PM, Lance Andersen wrote: >> +1 >>> On Mar 21, 2019, at 3:05 PM, Brian Burkhalter >>> wrote: >>> >>> Please review this trivial fix for [0]: >>> >>> @@ -237,7 +237,7 @@ >>> * b[off+len-1] unaffected. >>> * >>> *

              In every case, elements b[0] through >>> - * b[off] and elements b[off+len] >>> through >>> + * b[off-1] and elements b[off+len] >>> through >>> * b[b.length-1] are unaffected. >>> * >>> *

              The read(b, off, >>> len) method >>> >>> Also, is a CSR needed for something this small? I assume so ... >>> >>> Thanks, >>> >>> Brian >>> >>> [0] https://bugs.openjdk.java.net/browse/JDK-8078860 >> >> >> >> 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 gary.adams at oracle.com Fri Mar 22 08:05:32 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 22 Mar 2019 04:05:32 -0400 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table Message-ID: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> Here's a proposed fix for the intermittent jstatd test failure. By moving the exported object from a local method variable to a static class variable a strong reference is held so the object will not be garbage collected prematurely. ? Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/ ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203026 The test is currently filed as a core-libs/java.rmi, but it probably should be core-svc/tools with label=jstatd. It is the callers responsibility to ensure the strong reference to prevent the premature garbage collection, so this is a test failure rather than a need to change the underlying rmi behavior. From christoph.langer at sap.com Fri Mar 22 08:37:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 22 Mar 2019 08:37:44 +0000 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes Message-ID: Hi, when contemplating over JDK-8211752, I found a few minor cleanups for the implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews? Bug: https://bugs.openjdk.java.net/browse/JDK-8221262 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/ Thanks Christoph From sgehwolf at redhat.com Fri Mar 22 10:43:47 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 22 Mar 2019 11:43:47 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support Message-ID: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Hi, Please review this change which improves container detection support tin the JVM. While docker container detection works quite well the results for systemd slices with memory limits are mixed and depend on the Linux kernel version in use. With newer kernel versions becoming more widely used we should improve JVMs memory limit detection support as well. This should be entirely backwards compatible as the hierarchical limit will only be used if everything else is unlimited. Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/04/webrev/ Testing: Manual testing of -XshowSettings and -Xlog:os+container=trace with systemd slices on affected Linux distributions: Fedora 29, recent Ubuntu (18-10). Existing docker tests pass. I'm currently also running this through jdk/submit. Thoughts? Thanks, Severin From christoph.dreis at freenet.de Fri Mar 22 11:30:11 2019 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 22 Mar 2019 12:30:11 +0100 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' Message-ID: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> Hi, I recently stumbled upon jdk.internal.module.Checks and was wondering if you could help me understanding if I face a bug. The mentioned class has a private static field containing a list of reserved keywords. When checking the list for completeness, I noticed that "var" seems to be missing here and I wonder if it should be added. I found two relevant links in the spec regarding that: The first one being the list of keywords: https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.html#jls-3.9 "var is not a keyword, but rather an identifier with special meaning as the type of a local variable declaration" And secondly the section about identifiers https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.html#jls-3.8 "Type identifiers are used in certain contexts involving the declaration or use of types. For example, the name of a class must be a TypeIdentifier, so it is illegal to declare a class named var." Especially the last one got me thinking. Imagine a call like the following: Checks.isClassName("var") This will currently return true, while it should return false, shouldn't it? I attached a patch for what I think should be implemented. And if my assumption turns out to be correct, I'd be more than happy if this is sponsored and earns a "contributed-by". If this is already known or an incorrect assumption, I'm very sorry for bothering you guys. Cheers, Christoph ========= PATCH ========== diff -r 96c45aa61056 src/java.base/share/classes/jdk/internal/module/Checks.java --- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar 22 13:42:45 2019 +0530 +++ b/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar 22 12:24:27 2019 +0100 @@ -242,6 +242,7 @@ "true", "false", "null", + "var", "_" ); } From adam.farley at uk.ibm.com Fri Mar 22 11:33:53 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 22 Mar 2019 11:33:53 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> Message-ID: Hi Mandy, Answers below. :) Mandy Chung wrote on 22/03/2019 00:35:00: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 22/03/2019 00:35 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > 217 //If this is a USA test, then only the fraction > of the expected failures will occur; those which are both static and final. > 218 if (fl != > FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE && > actualFieldNames.stream().anyMatch(s->!(s.contains("static")&& > (s.contains("final"))))) > > What is a USA test? UNREFLECT_SETTER_ACCESSIBLE. I was trying to be brief, and I lost readability. Will re-upload with the expanded name. > > Why the assertion becomes conditional? Because we only need this check if the test is USA. Previously, setting a variable as accessible gave us a setter without errors 100% of the time. The test expects this, and anticipates an empty list of variables which threw errors when passed to unreflectSetter. Since we now throw an exception when calling the unreflectSetter method, even when the variable is accessible, this check ensures that the only variables throwing an exception are the static final fields. > > Have you considered another way doing it? Yep, several. This seemed the simplest. Other options I considered were: -------------- 1) Changing the test to store a list of variables, rather than just their names, so the "isAccessible" method could be used instead. Discarded because it makes the array compare slower for every test. 2) Editing the array of anticipated excludeds during test execution, to remove the exceptions we don't expect to see. Discarded because the change seemed too bulky to accommodate a single test. 3) Make the "isAccessible" methods smarter, and rely on them exclusively to determine the list of anticipated exceptions. Ditto --------------------- Option 3 could work. I prefer the one-liner stream check. Thoughts? - Adam > > Mandy > > On 3/21/19 9:51 AM, Adam Farley8 wrote: > Hi Mandy, > > Good spot. Have updated the webrev. > > http://cr.openjdk.java.net/~afarley/8216558/webrev/ > > Could you review the proposed change? > > Also, I ran the invoke tests as advised, and the only one that > fails is "LFGarbageCollectedTest.java", which also fails in the > same way when run against a non-patched java, so I think we're ok. > > 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 christoph.dreis at freenet.de Fri Mar 22 11:59:53 2019 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 22 Mar 2019 12:59:53 +0100 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' In-Reply-To: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> References: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> Message-ID: <000101d4e0a6$c2eb23d0$48c16b70$@freenet.de> On a second thought, the patched posted is not safe as it is used for package name checks as well. And while var is not a type-identifier, it is still an identifier. So it should be possible to name your package "var" if I'm not mistaken. The question remains. Should we change anything here in the Checks class? > Hi, > > I recently stumbled upon jdk.internal.module.Checks and was wondering if > you could help me understanding if I face a bug. The mentioned class has a > private static field containing a list of reserved keywords. When checking the > list for completeness, I noticed that "var" seems to be missing here and I > wonder if it should be added. I found two relevant links in the spec regarding > that: > > The first one being the list of keywords: > https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.html#jls-3.9 > "var is not a keyword, but rather an identifier with special meaning as the > type of a local variable declaration" > > And secondly the section about identifiers > https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.html#jls-3.8 > "Type identifiers are used in certain contexts involving the declaration or > use of types. For example, the name of a class must be a TypeIdentifier, so it > is illegal to declare a class named var." > > Especially the last one got me thinking. Imagine a call like the following: > > Checks.isClassName("var") > > This will currently return true, while it should return false, shouldn't it? > > I attached a patch for what I think should be implemented. And if my > assumption turns out to be correct, I'd be more than happy if this is > sponsored and earns a "contributed-by". If this is already known or an > incorrect assumption, I'm very sorry for bothering you guys. > > Cheers, > Christoph > > ========= PATCH ========== > diff -r 96c45aa61056 > src/java.base/share/classes/jdk/internal/module/Checks.java > --- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri > Mar 22 13:42:45 2019 +0530 > +++ b/src/java.base/share/classes/jdk/internal/module/Checks.java Fri > Mar 22 12:24:27 2019 +0100 > @@ -242,6 +242,7 @@ > "true", > "false", > "null", > + "var", > "_" > ); > } From Alan.Bateman at oracle.com Fri Mar 22 12:36:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Mar 2019 12:36:22 +0000 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' In-Reply-To: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> References: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> Message-ID: <2021abea-f51a-fc88-f1fd-0c87ab1a6036@oracle.com> On 22/03/2019 11:30, Christoph Dreis wrote: > Hi, > > I recently stumbled upon jdk.internal.module.Checks and was wondering if you > could help me understanding if I face a bug. The mentioned class has a > private static field containing a list of reserved keywords. When checking > the list for completeness, I noticed that "var" seems to be missing here and > I wonder if it should be added. This class supports validation when building module descriptors with the API, e.g. ??????? var descriptor = ModuleDescriptor.newModule("var") ??????????????? .exports("var", Set.of("var")) ??????????????? .provides("var.var", List.of("var.var")) ??????????????? .mainClass("var.var") ??????????????? .build(); It is also used when deriving module descriptors for automatic modules. So I think you found an issue as the "provides" and "mainClass" builder methods should reject a class name named "var" (no issue with the module or packages names which is why it shouldn't be added to the RESERVED set). -Alan From christoph.dreis at freenet.de Fri Mar 22 12:53:32 2019 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 22 Mar 2019 13:53:32 +0100 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' In-Reply-To: <2021abea-f51a-fc88-f1fd-0c87ab1a6036@oracle.com> References: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> <2021abea-f51a-fc88-f1fd-0c87ab1a6036@oracle.com> Message-ID: <000401d4e0ae$41e07f30$c5a17d90$@freenet.de> Thanks Alan for your fast response. I'm "glad" the root issue remains even though the initial patch is wrong. I guess "uses" could be affected here as well, not just "mainClass" and "provides". How do we move on from now? Can I help in anyway? Christoph > On 22/03/2019 11:30, Christoph Dreis wrote: > > Hi, > > > > I recently stumbled upon jdk.internal.module.Checks and was wondering > > if you could help me understanding if I face a bug. The mentioned > > class has a private static field containing a list of reserved > > keywords. When checking the list for completeness, I noticed that > > "var" seems to be missing here and I wonder if it should be added. > This class supports validation when building module descriptors with the API, > e.g. > > var descriptor = ModuleDescriptor.newModule("var") > .exports("var", Set.of("var")) > .provides("var.var", List.of("var.var")) > .mainClass("var.var") > .build(); > > It is also used when deriving module descriptors for automatic modules. > > So I think you found an issue as the "provides" and "mainClass" builder > methods should reject a class name named "var" (no issue with the module > or packages names which is why it shouldn't be added to the RESERVED set). > > -Alan From Alan.Bateman at oracle.com Fri Mar 22 13:34:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Mar 2019 13:34:47 +0000 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes In-Reply-To: References: Message-ID: <718fd510-99e4-66ea-2206-f9da81eaf527@oracle.com> On 22/03/2019 08:37, Langer, Christoph wrote: > Hi, > > when contemplating over JDK-8211752, I found a few minor cleanups for the implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221262 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/ This looks okay to me. -Alan From christoph.dreis at freenet.de Fri Mar 22 13:31:17 2019 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 22 Mar 2019 14:31:17 +0100 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' In-Reply-To: <000401d4e0ae$41e07f30$c5a17d90$@freenet.de> References: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> <2021abea-f51a-fc88-f1fd-0c87ab1a6036@oracle.com> <000401d4e0ae$41e07f30$c5a17d90$@freenet.de> Message-ID: <000501d4e0b3$88031c20$98095460$@freenet.de> I wonder if this should do the trick. What do you think, Alan? ============ PATCH ============ diff -r 96c45aa61056 src/java.base/share/classes/jdk/internal/module/Checks.java --- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar 22 13:42:45 2019 +0530 +++ b/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar 22 14:30:03 2019 +0100 @@ -111,6 +111,11 @@ if (name.indexOf('.') == -1) throw new IllegalArgumentException(name + ": is not a qualified name of" + " a Java class in a named package"); + String unqualifiedName = getUnqualifiedClassName(name); + if (!"var".equals(unqualifiedName)) { + throw new IllegalArgumentException(name + ": Invalid " + what + + ": 'var' is not a valid Java class name"); + } return name; } @@ -118,7 +123,16 @@ * Returns {@code true} if the given name is a legal class name. */ public static boolean isClassName(String name) { - return isTypeName(name); + if (!isTypeName(name)) { + return false; + } + String unqualifiedName = getUnqualifiedClassName(name); + return !"var".equals(unqualifiedName); + } + + private static String getUnqualifiedClassName(String name) { + int index = name.lastIndexOf('.'); + return index != -1 ? name.substring(index) : name; } > Thanks Alan for your fast response. > > I'm "glad" the root issue remains even though the initial patch is wrong. > > I guess "uses" could be affected here as well, not just "mainClass" and > "provides". > How do we move on from now? Can I help in anyway? > > Christoph > > > On 22/03/2019 11:30, Christoph Dreis wrote: > > > Hi, > > > > > > I recently stumbled upon jdk.internal.module.Checks and was > > > wondering if you could help me understanding if I face a bug. The > > > mentioned class has a private static field containing a list of > > > reserved keywords. When checking the list for completeness, I > > > noticed that "var" seems to be missing here and I wonder if it should be > added. > > This class supports validation when building module descriptors with > > the API, e.g. > > > > var descriptor = ModuleDescriptor.newModule("var") > > .exports("var", Set.of("var")) > > .provides("var.var", List.of("var.var")) > > .mainClass("var.var") > > .build(); > > > > It is also used when deriving module descriptors for automatic modules. > > > > So I think you found an issue as the "provides" and "mainClass" > > builder methods should reject a class name named "var" (no issue with > > the module or packages names which is why it shouldn't be added to the > RESERVED set). > > > > -Alan From Roger.Riggs at oracle.com Fri Mar 22 13:56:21 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Mar 2019 09:56:21 -0400 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table In-Reply-To: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> References: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> Message-ID: <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> Hi Gary, Holding a static reference to the implementation solves the problem. But I noticed that the object that is bound in the registry is the RemoteHostImpl and it should be the RemoteHost stub. Line 145: should be: bind(name.toString(), stub); That is likely to solve the problem as well, because the distributed garbage collector will correctly cause a hard reference to be retained to the implementation. Roger On 03/22/2019 04:05 AM, gary.adams at oracle.com wrote: > Here's a proposed fix for the intermittent jstatd test failure. > By moving the exported object from a local method variable to a > static class variable a strong reference is held so the object > will not be garbage collected prematurely. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203026 > > The test is currently filed as a core-libs/java.rmi, but it probably > should be core-svc/tools with label=jstatd. It is the callers > responsibility to ensure the strong reference to prevent > the premature garbage collection, so this is a test failure > rather than a need to change the underlying rmi behavior. From matthias.baesken at sap.com Fri Mar 22 14:37:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 22 Mar 2019 14:37:20 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows Message-ID: Hello, here is the new webrev . I took over and adjusted coding from os::open + create_unc_path functions in os_windows.cpp in hotspot : http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/ Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Donnerstag, 21. M?rz 2019 14:30 > To: Langer, Christoph ; Alan Bateman > (Alan.Bateman at oracle.com) > Cc: 'Chris Hegarty' ; 'core-libs- > dev at openjdk.java.net' > Subject: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : > RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on > windows > > Hi Alan + Christoph, coming back to > https://bugs.openjdk.java.net/browse/JDK-8218547 . > > We wanted to check for the whole flow (in JLI_Open on Windows ) , e.g. > checking whether only CreateFileW can be used instead of open. > > I think there is already a similar solution available in the codebase . > > See the os::open + create_unc_path functions in os_windows.cpp in > the hotspot coding . > > There "simple" open is used for shorter paths ( < MAX_PATH) ; for larger > paths an elp / unc path is constructed and _wopen is used on the elp/unc > path : > > > if (strlen(path) < MAX_PATH) { > ret = ::open(pathbuf, oflag | O_BINARY | O_NOINHERIT, mode); > } else { > errno_t err = ERROR_SUCCESS; > wchar_t* wpath = create_unc_path(pathbuf, err); > .... > ret = ::_wopen(wpath, oflag | O_BINARY | O_NOINHERIT, mode); > > > I think we should do it the same way in JLI_Open . Is that fine with you? > Unfortunately I think we cannot easily reuse the HS coding, so the have to > take it over to jli . > > Best regards, Matthias > > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Mittwoch, 6. Februar 2019 09:56 > > To: Langer, Christoph > > Cc: Chris Hegarty ; core-libs- > > dev at openjdk.java.net; Alan Bateman (Alan.Bateman at oracle.com) > > > > Subject: RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hi Christoph+Alan, I opened > > > > > > https://bugs.openjdk.java.net/browse/JDK-8218547 > > > > JDK-8218547 : use CreateFile without open on Windows in jdk native code > > > > > > To check for the usage of CreateFile (CreateFileW) without open . > > > > > > Best regards, Matthias > > From christoph.dreis at freenet.de Fri Mar 22 14:36:54 2019 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 22 Mar 2019 15:36:54 +0100 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' In-Reply-To: <000501d4e0b3$88031c20$98095460$@freenet.de> References: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> <2021abea-f51a-fc88-f1fd-0c87ab1a6036@oracle.com> <000401d4e0ae$41e07f30$c5a17d90$@freenet.de> <000501d4e0b3$88031c20$98095460$@freenet.de> Message-ID: <000601d4e0bc$b37eeba0$1a7cc2e0$@freenet.de> I'm sorry. Another correction. > > I wonder if this should do the trick. > > What do you think, Alan? > > ============ PATCH ============ > diff -r 96c45aa61056 > src/java.base/share/classes/jdk/internal/module/Checks.java > --- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri > Mar 22 13:42:45 2019 +0530 > +++ b/src/java.base/share/classes/jdk/internal/module/Checks.java Fri > Mar 22 14:30:03 2019 +0100 > @@ -111,6 +111,11 @@ > if (name.indexOf('.') == -1) > throw new IllegalArgumentException(name + ": is not a qualified name > of" > + " a Java class in a named package"); > + String unqualifiedName = getUnqualifiedClassName(name); > + if (!"var".equals(unqualifiedName)) { > + throw new IllegalArgumentException(name + ": Invalid " + what > + + ": 'var' is not a valid Java class name"); > + } > return name; > } > Today is not my day. This needs to be of course if ("var".equals(unqualifiedName)). Cheers, Christoph From joe.darcy at oracle.com Fri Mar 22 15:40:15 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Mar 2019 08:40:15 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> Message-ID: <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> A quick comment below... On 3/22/2019 4:33 AM, Adam Farley8 wrote: > Hi Mandy, > > Answers below. :) > > Mandy Chung wrote on 22/03/2019 00:35:00: > >> From: Mandy Chung >> To: Adam Farley8 >> Cc: core-libs-dev >> Date: 22/03/2019 00:35 >> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails >> to throw IllegalAccessException for final fields >> >> 217 //If this is a USA test, then only the fraction >> of the expected failures will occur; those which are both static and > final. >> 218 if (fl != >> FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE && >> actualFieldNames.stream().anyMatch(s->!(s.contains("static")&& >> (s.contains("final"))))) >> >> What is a USA test? > UNREFLECT_SETTER_ACCESSIBLE. > > I was trying to be brief, and I lost readability. > > Will re-upload with the expanded name. Please update distinct versions of a webrev (e.g. distinguished with .1, .2 directory names) rather than overwriting a single one. This make it easier for those coming to the review thread later to see the evolution of the changes over time. Cheers, -Joe From deepak.kejriwal at oracle.com Fri Mar 22 15:51:44 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 22 Mar 2019 08:51:44 -0700 (PDT) Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 Message-ID: <627764ae-9c68-4113-920b-f1010086e8c7@default> Hi All, Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:- JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 https://bugs.openjdk.java.net/browse/JDK-8210633 Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ Master bug change set: http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 Summary: The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 (from 12u) are not clean backport. Changes for file "DateTimeFormatterBuilder.java" are manually merged. Since, test file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only test cases modified as part for JDK-8042131 and JDK-8210633 are added. All tests are run against the changes and found to be passing. Regards, Deepak From christoph.dreis at freenet.de Fri Mar 22 16:06:49 2019 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 22 Mar 2019 17:06:49 +0100 Subject: [NEW BUG] jdk.internal.module.Checks seems to miss a check for 'var' In-Reply-To: <000601d4e0bc$b37eeba0$1a7cc2e0$@freenet.de> References: <000001d4e0a2$9c89b020$d59d1060$@freenet.de> <2021abea-f51a-fc88-f1fd-0c87ab1a6036@oracle.com> <000401d4e0ae$41e07f30$c5a17d90$@freenet.de> <000501d4e0b3$88031c20$98095460$@freenet.de> <000601d4e0bc$b37eeba0$1a7cc2e0$@freenet.de> Message-ID: <000701d4e0c9$41c73690$c555a3b0$@freenet.de> For completeness reasons, here is the corrected version of the complete patch I'm proposing. ============= PATCH ============= diff -r 96c45aa61056 src/java.base/share/classes/jdk/internal/module/Checks.java --- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar 22 13:42:45 2019 +0530 +++ b/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar 22 17:04:38 2019 +0100 @@ -111,6 +111,11 @@ if (name.indexOf('.') == -1) throw new IllegalArgumentException(name + ": is not a qualified name of" + " a Java class in a named package"); + String unqualifiedName = getUnqualifiedClassName(name); + if ("var".equals(unqualifiedName)) { + throw new IllegalArgumentException(name + ": Invalid " + what + + ": 'var' is not a valid Java class name"); + } return name; } @@ -118,7 +123,19 @@ * Returns {@code true} if the given name is a legal class name. */ public static boolean isClassName(String name) { - return isTypeName(name); + if (!isTypeName(name)) { + return false; + } + String unqualifiedName = getUnqualifiedClassName(name); + return !"var".equals(unqualifiedName); + } + + /** + * Returns the unqualified name of the given class name. + */ + private static String getUnqualifiedClassName(String name) { + int index = name.lastIndexOf('.'); + return index != -1 ? name.substring(index + 1) : name; } > I'm sorry. Another correction. > > > > > I wonder if this should do the trick. > > > > What do you think, Alan? > > > > ============ PATCH ============ > > diff -r 96c45aa61056 > > src/java.base/share/classes/jdk/internal/module/Checks.java > > --- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri > > Mar 22 13:42:45 2019 +0530 > > +++ b/src/java.base/share/classes/jdk/internal/module/Checks.java Fri > > Mar 22 14:30:03 2019 +0100 > > @@ -111,6 +111,11 @@ > > if (name.indexOf('.') == -1) > > throw new IllegalArgumentException(name + ": is not a > > qualified name of" > > + " a Java class in a > > named package"); > > + String unqualifiedName = getUnqualifiedClassName(name); > > + if (!"var".equals(unqualifiedName)) { > > + throw new IllegalArgumentException(name + ": Invalid " + what > > + + ": 'var' is not a valid Java class name"); > > + } > > return name; > > } > > > > Today is not my day. This needs to be of course if > ("var".equals(unqualifiedName)). > > Cheers, > Christoph From adam.farley at uk.ibm.com Fri Mar 22 16:14:58 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 22 Mar 2019 16:14:58 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> References: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> Message-ID: Hi Joe, I was aware that webrevs should be versioned, though I didn't see the value for small change sets like this one. You seem to think there is a value. Can you explain it to me? Best Regards Adam Farley IBM Runtimes Joe Darcy wrote on 22/03/2019 15:40:15: > From: Joe Darcy > To: Adam Farley8 , Mandy Chung > > Cc: core-libs-dev > Date: 22/03/2019 15:42 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > A quick comment below... > > On 3/22/2019 4:33 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > Answers below. :) > > > > Mandy Chung wrote on 22/03/2019 00:35:00: > > > >> From: Mandy Chung > >> To: Adam Farley8 > >> Cc: core-libs-dev > >> Date: 22/03/2019 00:35 > >> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > >> to throw IllegalAccessException for final fields > >> > >> 217 //If this is a USA test, then only the fraction > >> of the expected failures will occur; those which are both static and > > final. > >> 218 if (fl != > >> FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE && > >> actualFieldNames.stream().anyMatch(s->!(s.contains("static")&& > >> (s.contains("final"))))) > >> > >> What is a USA test? > > UNREFLECT_SETTER_ACCESSIBLE. > > > > I was trying to be brief, and I lost readability. > > > > Will re-upload with the expanded name. > > Please update distinct versions of a webrev (e.g. distinguished with .1, > .2 directory names) rather than overwriting a single one. This make it > easier for those coming to the review thread later to see the evolution > of the changes over time. > > Cheers, > > -Joe > 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 Fri Mar 22 16:56:12 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Mar 2019 09:56:12 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> Message-ID: Hi Adam, On 3/22/19 8:40 AM, Joe Darcy wrote: > > Please update distinct versions of a webrev (e.g. distinguished with > .1, .2 directory names) rather than overwriting a single one. This > make it easier for those coming to the review thread later to see the > evolution of the changes over time. > +1 I had requested new test in the webrev during my review. That really helps me, a reviewer, to keep track what has been changed easily. It will also give you an idea how many revisions this review involves when you started for a code review (as opposed to asking for "how to fix this issue"). I was asked to read the regression test that is attached to JBS issue [1] I was asked to review a diff (cut-n-paste) on the mail when I requested a webrev to include a regression test. [2] On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer guide and I was hoping you read the guideline and be familiar with it which should help you contributing to the OpenJDK. I was disappointed to get your conclusion: > Historically, the bigger the change I propose, the more months it takes > the OpenJDK community to approve. I had helped as much as I can to sponsor this patch even if you refused what I requested to help my review easier. I expected that you ran JDK regression tests on local machine rather than I caught it for you.? Is that what you expected a reviewer to do it for you??? Won't you consider this a new revision to your patch?? You can do anything you like and tells a reviewer that I should be smart enough to identify the diff in the previous patch. I am not an educator and excuse me if my response is not what you are looking for. Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058320.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058544.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058350.html [4] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058784.html From joe.darcy at oracle.com Fri Mar 22 17:05:33 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Mar 2019 10:05:33 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> Message-ID: <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Hi Adam, On 3/22/2019 9:14 AM, Adam Farley8 wrote: > Hi Joe, > > I was aware that webrevs should be versioned, though I didn't see the > value for small change sets like this one. > > You seem to think there is a value. Can you explain it to me? > The time of reviewers is valuable and should not be dissipated in unnecessary attempts to determine what aspects of feedback have been acted upon. -Joe From joe.darcy at oracle.com Fri Mar 22 17:06:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Mar 2019 10:06:38 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> Message-ID: On 3/22/2019 9:56 AM, Mandy Chung wrote: > Hi Adam, > > On 3/22/19 8:40 AM, Joe Darcy wrote: >> >> Please update distinct versions of a webrev (e.g. distinguished with >> .1, .2 directory names) rather than overwriting a single one. This >> make it easier for those coming to the review thread later to see the >> evolution of the changes over time. >> > > +1 > > I had requested new test in the webrev during my review. That really > helps me, a reviewer, to keep track what has been changed easily.? It > will also give you an idea how many revisions this review involves > when you started for a code review (as opposed to asking for "how to > fix this issue"). > > I was asked to read the regression test that is attached to JBS issue [1] > I was asked to review a diff (cut-n-paste) on the mail when I > requested a webrev to include a regression test. [2] > > On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer guide > and I was hoping you read the guideline and be familiar with it which > should help you contributing to the OpenJDK. > > I was disappointed to get your conclusion: >> Historically, the bigger the change I propose, the more months it takes >> the OpenJDK community to approve. > OpenJDK is a community one participates in, not a service one sits in judgement over. -Joe From naoto.sato at oracle.com Fri Mar 22 17:29:26 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 22 Mar 2019 10:29:26 -0700 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: <627764ae-9c68-4113-920b-f1010086e8c7@default> References: <627764ae-9c68-4113-920b-f1010086e8c7@default> Message-ID: <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> Hi Deepak, Please modify the copyright year accordingly. Otherwise it looks good to me. Naoto On 3/22/19 8:51 AM, Deepak Kejriwal wrote: > Hi All, > > > > Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:- > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 > > https://bugs.openjdk.java.net/browse/JDK-8210633 > > > > Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ > > > > Master bug change set: http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > Summary: > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 (from 12u) are not clean backport. Changes for file "DateTimeFormatterBuilder.java" are manually merged. Since, test file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only test cases modified as part for JDK-8042131 and JDK-8210633 are added. > > All tests are run against the changes and found to be passing. > > Regards, > > Deepak > > > From bob.vandette at oracle.com Fri Mar 22 18:25:50 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 22 Mar 2019 14:25:50 -0400 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Message-ID: Is there ever a situation where the memory.limit_in_bytes could be unlimited but the hierarchical_memory_limit is not? Could you maybe combine subsystem_file_contents with subsystem_file_line_contents by adding an additional argument? BTW: I found another problem with the mountinfo/cgroup parsing that impacts the container tests. I don?t know why it only caused a failure on one of my systems. I?m going to file another bug. You might want to test with these changes to make sure your looking at the correct subsystem files. diff --git a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java --- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java +++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java @@ -60,7 +60,7 @@ path = mountPoint; } else { - if (root.indexOf(cgroupPath) == 0) { + if (cgroupPath.indexOf(root) == 0) { if (cgroupPath.length() > root.length()) { String cgroupSubstr = cgroupPath.substring(root.length()); path = mountPoint + cgroupSubstr; diff --git a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java --- a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java +++ b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java @@ -85,7 +85,7 @@ String mountPoint = paths[1]; if (root != null && cgroupPath != null) { if (root.equals("/")) { - if (cgroupPath.equals("/")) { + if (!cgroupPath.equals("/")) { finalPath = mountPoint + cgroupPath; } else { finalPath = mountPoint; @@ -94,7 +94,7 @@ if (root.equals(cgroupPath)) { finalPath = mountPoint; } else { - if (root.indexOf(cgroupPath) == 0) { + if (cgroupPath.indexOf(root) == 0) { if (cgroupPath.length() > root.length()) { String cgroupSubstr = cgroupPath.substring(root.length()); finalPath = mountPoint + cgroupSubstr; @@ -103,7 +103,7 @@ } } } - subSystemPaths.put(subSystem, new String[]{finalPath}); + subSystemPaths.put(subSystem, new String[]{finalPath, mountPoint}); } } } Bob. > On Mar 22, 2019, at 6:43 AM, Severin Gehwolf wrote: > > Hi, > > Please review this change which improves container detection support > tin the JVM. While docker container detection works quite well the > results for systemd slices with memory limits are mixed and depend on > the Linux kernel version in use. With newer kernel versions becoming > more widely used we should improve JVMs memory limit detection support > as well. This should be entirely backwards compatible as the > hierarchical limit will only be used if everything else is unlimited. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/04/webrev/ > > Testing: Manual testing of -XshowSettings and -Xlog:os+container=trace > with systemd slices on affected Linux distributions: Fedora 29, > recent Ubuntu (18-10). Existing docker tests pass. I'm currently also > running this through jdk/submit. > > Thoughts? > > Thanks, > Severin > From ecki at zusammenkunft.net Fri Mar 22 19:04:13 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 22 Mar 2019 19:04:13 +0000 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes In-Reply-To: <718fd510-99e4-66ea-2206-f9da81eaf527@oracle.com> References: , <718fd510-99e4-66ea-2206-f9da81eaf527@oracle.com> Message-ID: Instead of removing the file path, would it be possible to add it to all implementations guarded by jdk.includeInExceptions=filename? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alan Bateman Gesendet: Freitag, M?rz 22, 2019 5:35 PM An: Langer, Christoph; Java Core Libs Betreff: Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes On 22/03/2019 08:37, Langer, Christoph wrote: > Hi, > > when contemplating over JDK-8211752, I found a few minor cleanups for the implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221262 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/ This looks okay to me. -Alan From Alan.Bateman at oracle.com Fri Mar 22 19:36:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Mar 2019 19:36:33 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: Message-ID: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> On 22/03/2019 14:37, Baesken, Matthias wrote: > Hello, here is the new webrev . > > I took over and adjusted coding from os::open + create_unc_path functions in os_windows.cpp in hotspot : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/ > This looks quite good. For the comment then it might be better to drop the mention of os_windows.cpp, also maybe mention that the memory should be freed with JLI_MemFree rather than free. -Alan From ivan.gerasimov at oracle.com Fri Mar 22 20:28:44 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 22 Mar 2019 13:28:44 -0700 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes In-Reply-To: References: Message-ID: <8d492e5d-0b95-bf6a-3a3b-a65d322778e8@oracle.com> Hi Christoph! UnixFileSystem_md.c: Should the second error message be "Could not *close* file"? UnixFileSystem.java: Line spacing looks inconsistent. Please leave an empty line before @Override at lines 267, 269, 271, 273, etc. With kind regards, Ivan On 3/22/19 1:37 AM, Langer, Christoph wrote: > Hi, > > when contemplating over JDK-8211752, I found a few minor cleanups for the implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221262 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/ > > Thanks > Christoph > > -- With kind regards, Ivan Gerasimov From brian.burkhalter at oracle.com Fri Mar 22 20:46:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Mar 2019 13:46:30 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> Message-ID: <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> > On Mar 18, 2019, at 1:03 PM, Martin Buchholz wrote: > > Below is another attempt at micro-optimization (might be too tricky!), BUT: I like this version better and have updated the CR accordingly: http://cr.openjdk.java.net/~bpb/8219196/webrev.02/ I refrained from doing a global replace of => {@code } and @exception => @throws although it was tempting. > - consider documenting the UTFDataFormatException and the 64k length limit Done; will require a CSR. > - error message would actually be more useful if it contained a few chars > from head and tail instead of length Done. I also changed the calculation of the length to use Integer.toUnsignedLong(). > On Mar 18, 2019, at 11:35 AM, Roger Riggs wrote: > > The test only needs enough memory to create the input string (MAXINT/3+1) > and a bit more for the default sized ByteArrayOutputStream. > So it should run in 2G configurations. Fixed. Thanks, Brian From martinrb at google.com Fri Mar 22 22:31:36 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Mar 2019 15:31:36 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> Message-ID: No need to check for short strings in tooLongMsg. Getting the actual length calculation 100% is not very important, but THIS IS JAVA so here's an attempt that looks correct even for maximal length input (untested - you could check that the exception detail gets the 3x expansion right): private static String tooLongMsg(String s, int bits32) { int slen = s.length(); String head = s.substring(0, 8); String tail = s.substring(slen - 8, slen); // handle int overflow with max 3x expansion long actualLength = (long)slen + Integer.toUnsignedLong(bits32 - slen); return "encoded string (" + head + "..." + tail + ") too long: " + actualLength + " bytes"; } Otherwise looks good to me. On Fri, Mar 22, 2019 at 1:46 PM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > > On Mar 18, 2019, at 1:03 PM, Martin Buchholz wrote: > > Below is another attempt at micro-optimization (might be too tricky!), BUT: > > > I like this version better and have updated the CR accordingly: > > http://cr.openjdk.java.net/~bpb/8219196/webrev.02/ > > I refrained from doing a global replace of => {@code } and > @exception => @throws although it was tempting. > > - consider documenting the UTFDataFormatException and the 64k length limit > > > Done; will require a CSR. > > - error message would actually be more useful if it contained a few chars > from head and tail instead of length > > > Done. I also changed the calculation of the length to use > Integer.toUnsignedLong(). > > On Mar 18, 2019, at 11:35 AM, Roger Riggs wrote: > > The test only needs enough memory to create the input string (MAXINT/3+1) > and a bit more for the default sized ByteArrayOutputStream. > So it should run in 2G configurations. > > > Fixed. > > Thanks, > > Brian > From brian.burkhalter at oracle.com Fri Mar 22 23:32:57 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Mar 2019 16:32:57 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> Message-ID: <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> > On Mar 22, 2019, at 3:31 PM, Martin Buchholz wrote: > > No need to check for short strings in tooLongMsg. Yeah that was stupid on my part. > Getting the actual length calculation 100% is not very important, but THIS IS JAVA so here's an attempt that looks correct even for maximal length input (untested - you could check that the exception detail gets the 3x expansion right): > > private static String tooLongMsg(String s, int bits32) { > int slen = s.length(); > String head = s.substring(0, 8); > String tail = s.substring(slen - 8, slen); > // handle int overflow with max 3x expansion > long actualLength = (long)slen + Integer.toUnsignedLong(bits32 - slen); > return "encoded string (" + head + "..." + tail + ") too long: " > + actualLength + " bytes"; > } Ran the test without suppressing the exceptions and the messages look fine. > Otherwise looks good to me. Patch updated for the sake of formality. Don?t want to check it into the CI system until Monday. Thanks ... From brian.burkhalter at oracle.com Fri Mar 22 23:41:29 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Mar 2019 16:41:29 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> Message-ID: Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/ > On Mar 22, 2019, at 4:32 PM, Brian Burkhalter wrote: > > Patch updated for the sake of formality. From martinrb at google.com Fri Mar 22 23:48:55 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Mar 2019 16:48:55 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> Message-ID: Looks good! (and I should have remembered about toUnsignedLong) On Fri, Mar 22, 2019 at 4:41 PM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/ > > On Mar 22, 2019, at 4:32 PM, Brian Burkhalter > wrote: > > Patch updated for the sake of formality. > > > From alexander.matveev at oracle.com Sat Mar 23 00:54:09 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 22 Mar 2019 17:54:09 -0700 Subject: RFR: JDK-8221101: Update JNLPConverter to support latest jpackage CLI changes Message-ID: <00d4d597-3018-c886-b950-580d33d5ffef@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Updated JNLPConverter to support latest CLI changes and bug fixes. - Added getMessage() to exceptions, otherwise null was printed. - Restored characters() in XMLParser.java, otherwise some JNLP files were not parsed correctly. This function was deleted during code cleanup. [1] https://bugs.openjdk.java.net/browse/JDK-8221101 [2] http://cr.openjdk.java.net/~almatvee/8221101/webrev.00/ Thanks, Alexander From forax at univ-mlv.fr Sat Mar 23 12:36:15 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 23 Mar 2019 13:36:15 +0100 (CET) Subject: When executing in module mode, the java command doesn't show the verifyError message details Message-ID: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> Hi all, When you run a main class which contains an invalid bytecode sequence using the class-path you get: /usr/jdk/jdk-13/bin/java --enable-preview --class-path target/main/artifact/fr.umlv.lazystaticfinal-1.0.jar fr.umlv.lazystaticfinal.Main Error: Unable to initialize main class fr.umlv.lazystaticfinal.Main Caused by: java.lang.VerifyError: Method expects a return value Exception Details: Location: fr/umlv/lazystaticfinal/Main.HOME_lazy()Ljava/nio/file/Path; @2: return Reason: Error exists in the bytecode Bytecode: 0000000: 1241 b1 if you run the same code using the module-path, you get /usr/jdk/jdk-13/bin/java --enable-preview --module-path target/main/artifact -m fr.umlv.lazystaticfinal Error occurred during initialization of boot layer java.lang.module.FindException: Module org.objectweb.asm.util not found, required by fr.umlv.lazystaticfinal the exception details corresponding to the VerifyError are not printed making the issue hard to debug. regards, R?mi From Alan.Bateman at oracle.com Sat Mar 23 13:09:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Mar 2019 13:09:10 +0000 Subject: When executing in module mode, the java command doesn't show the verifyError message details In-Reply-To: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> References: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> Message-ID: <56f51c99-1640-d811-c4b3-36b8917ee845@oracle.com> On 23/03/2019 12:36, Remi Forax wrote: > : > > /usr/jdk/jdk-13/bin/java --enable-preview --module-path target/main/artifact -m fr.umlv.lazystaticfinal > Error occurred during initialization of boot layer > java.lang.module.FindException: Module org.objectweb.asm.util not found, required by fr.umlv.lazystaticfinal > > the exception details corresponding to the VerifyError are not printed making the issue hard to debug. > Can you run with -Xlog:init=debug to see if it reveals stack trace you are looking for? -Alan From forax at univ-mlv.fr Sat Mar 23 13:17:53 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 23 Mar 2019 14:17:53 +0100 (CET) Subject: When executing in module mode, the java command doesn't show the verifyError message details In-Reply-To: <56f51c99-1640-d811-c4b3-36b8917ee845@oracle.com> References: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> <56f51c99-1640-d811-c4b3-36b8917ee845@oracle.com> Message-ID: <1997517048.42091.1553347073228.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "core-libs-dev" > Envoy?: Samedi 23 Mars 2019 14:09:10 > Objet: Re: When executing in module mode, the java command doesn't show the verifyError message details > On 23/03/2019 12:36, Remi Forax wrote: >> : >> >> /usr/jdk/jdk-13/bin/java --enable-preview --module-path target/main/artifact -m >> fr.umlv.lazystaticfinal >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Module org.objectweb.asm.util not found, >> required by fr.umlv.lazystaticfinal >> >> the exception details corresponding to the VerifyError are not printed making >> the issue hard to debug. >> > Can you run with -Xlog:init=debug to see if it reveals stack trace you > are looking for? it doesn't :( /usr/jdk/jdk-13/bin/java -Xlog:init=debug --enable-preview --module-path target/main/artifact:deps -m fr.umlv.lazystaticfinal Error: Unable to initialize main class fr.umlv.lazystaticfinal.Main in module module fr.umlv.lazystaticfinal Caused by: module fr.umlv.lazystaticfinal: java.lang.VerifyError > > -Alan R?mi From Alan.Bateman at oracle.com Sat Mar 23 15:09:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Mar 2019 15:09:07 +0000 Subject: When executing in module mode, the java command doesn't show the verifyError message details In-Reply-To: <1997517048.42091.1553347073228.JavaMail.zimbra@u-pem.fr> References: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> <56f51c99-1640-d811-c4b3-36b8917ee845@oracle.com> <1997517048.42091.1553347073228.JavaMail.zimbra@u-pem.fr> Message-ID: On 23/03/2019 13:17, forax at univ-mlv.fr wrote: > : > > /usr/jdk/jdk-13/bin/java -Xlog:init=debug --enable-preview --module-path target/main/artifact:deps -m fr.umlv.lazystaticfinal > Error: Unable to initialize main class fr.umlv.lazystaticfinal.Main in module module fr.umlv.lazystaticfinal > Caused by: module fr.umlv.lazystaticfinal: java.lang.VerifyError > You first mail had: Error occurred during initialization of boot layer java.lang.module.FindException: Module org.objectweb.asm.util not found, required by fr.umlv.lazystaticfinal which suggests that org.objectweb.asm.util wasn't observable. Running -Xlog:init-debug should have reveal more for that case. It looks like you've got past that now and are hitting the same VerifyError. In the launcher, the resources corresponding to the two cases are java.launcher.cls.error7 and java.launcher.module.error5 so I would expect the exception message from the VerifyError to be printed in both. I suspect you'll need to run with -verbose and look at the class loading order to give some hint as to whether the message may be getting lost. -Alan From daniel.smith at oracle.com Sat Mar 23 15:13:29 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Sat, 23 Mar 2019 09:13:29 -0600 Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: <9dc49415-c28a-7e1a-3bd0-3b07b025fdf2@oracle.com> References: <9dc49415-c28a-7e1a-3bd0-3b07b025fdf2@oracle.com> Message-ID: <4681047C-6668-4181-A48B-C63DE3EA8076@oracle.com> > On Mar 21, 2019, at 8:58 AM, Brian Goetz wrote: > > +1 from me. > > >> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ >> >> > > AbstractValidatingLMF > --------------------- > > I see you renamed most of the fields and params. Most of these are improvements, but it may be worth being more explicit in ambiguous cases. For example, there are two method names, so perhaps instead of `methodName` it should be `interfaceMethodName` to make it clear this is the SAM method and not the implementation method. Good idea, done. > I presume the SecurityException is something that was always thrown, and we are just documenting it now. Should that be wrapped in a LCE instead? Yep, it's inherent in trying to crack MethodHandles. It's unusual enough that it seems like it's worth passing through?it's sort of a configuration problem for users? Worth thinking about how that limitation impacts the language. I didn't try to test it, because I don't totally get how to trigger it, but it seems like you could write a valid Java program with a method reference and end up triggering the exception at runtime? Is that bad? > Accidentally lost the {@code ...} surrounding MethodHandle in class description. Fixed. From forax at univ-mlv.fr Sat Mar 23 15:49:53 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 23 Mar 2019 16:49:53 +0100 (CET) Subject: When executing in module mode, the java command doesn't show the verifyError message details In-Reply-To: References: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> <56f51c99-1640-d811-c4b3-36b8917ee845@oracle.com> <1997517048.42091.1553347073228.JavaMail.zimbra@u-pem.fr> Message-ID: <1214581477.63149.1553356193197.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Samedi 23 Mars 2019 16:09:07 > Objet: Re: When executing in module mode, the java command doesn't show the verifyError message details > On 23/03/2019 13:17, forax at univ-mlv.fr wrote: >> : >> >> /usr/jdk/jdk-13/bin/java -Xlog:init=debug --enable-preview --module-path >> target/main/artifact:deps -m fr.umlv.lazystaticfinal >> Error: Unable to initialize main class fr.umlv.lazystaticfinal.Main in module >> module fr.umlv.lazystaticfinal >> Caused by: module fr.umlv.lazystaticfinal: java.lang.VerifyError >> > You first mail had: > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module org.objectweb.asm.util not found, > required by fr.umlv.lazystaticfinal > > which suggests that org.objectweb.asm.util wasn't observable. Running > -Xlog:init-debug should have reveal more for that case. > > It looks like you've got past that now and are hitting the same > VerifyError. in my original email, i've cut and paste the wrong lines, at that point i had already resolved the FindException (the dependency modules in folder deps were not in the module path) > In the launcher, the resources corresponding to the two > cases are java.launcher.cls.error7 and java.launcher.module.error5 so I > would expect the exception message from the VerifyError to be printed in > both. I suspect you'll need to run with -verbose and look at the class > loading order to give some hint as to whether the message may be getting > lost. found the issue, it's more simple :) If you take a look to the error message, the module name is printed twice: Error: Unable to initialize main class fr.umlv.lazystaticfinal.Main in module module fr.umlv.lazystaticfinal Caused by: module fr.umlv.lazystaticfinal: java.lang.VerifyError so the issue is here http://hg.openjdk.java.net/jdk/jdk/file/c81fbf340ceb/src/java.base/share/classes/sun/launcher/resources/launcher.properties#l245 it should be Caused by: {2}: {3} instead of Caused by: {1}: {2} because {1} is the name of the module, not the name of the exception. > > -Alan R?mi From forax at univ-mlv.fr Sat Mar 23 16:04:15 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 23 Mar 2019 17:04:15 +0100 (CET) Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: <4681047C-6668-4181-A48B-C63DE3EA8076@oracle.com> References: <9dc49415-c28a-7e1a-3bd0-3b07b025fdf2@oracle.com> <4681047C-6668-4181-A48B-C63DE3EA8076@oracle.com> Message-ID: <1336121952.63814.1553357055712.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "daniel smith" > ?: "Brian Goetz" > Cc: "core-libs-dev" > Envoy?: Samedi 23 Mars 2019 16:13:29 > Objet: Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation >> On Mar 21, 2019, at 8:58 AM, Brian Goetz wrote: >> >> +1 from me. >> >> >>> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ >>> >>> >> >> AbstractValidatingLMF >> --------------------- >> >> I see you renamed most of the fields and params. Most of these are >> improvements, but it may be worth being more explicit in ambiguous cases. For >> example, there are two method names, so perhaps instead of `methodName` it >> should be `interfaceMethodName` to make it clear this is the SAM method and not >> the implementation method. > > Good idea, done. > >> I presume the SecurityException is something that was always thrown, and we are >> just documenting it now. Should that be wrapped in a LCE instead? > > Yep, it's inherent in trying to crack MethodHandles. It's unusual enough that it > seems like it's worth passing through?it's sort of a configuration problem for > users? > > Worth thinking about how that limitation impacts the language. I didn't try to > test it, because I don't totally get how to trigger it, but it seems like you > could write a valid Java program with a method reference and end up triggering > the exception at runtime? Is that bad? Hi Dan, i don't think you can trigger the SecurityException by written an invokedynamic in the bytecode because by construction the Lookup object and the MethodHandle will use the same classloader, see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#secmgr But you can trigger it by calling the bootstrap method directly from Java with a a security manager installed and a Lookup and a MethodHandle that come from two different classloaders. [I've added John in CC, just to be sure i'm not saying something stupid] > >> Accidentally lost the {@code ...} surrounding MethodHandle in class description. > > Fixed. R?mi From Alan.Bateman at oracle.com Sat Mar 23 17:48:01 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Mar 2019 17:48:01 +0000 Subject: When executing in module mode, the java command doesn't show the verifyError message details In-Reply-To: <1214581477.63149.1553356193197.JavaMail.zimbra@u-pem.fr> References: <492371678.35260.1553344575695.JavaMail.zimbra@u-pem.fr> <56f51c99-1640-d811-c4b3-36b8917ee845@oracle.com> <1997517048.42091.1553347073228.JavaMail.zimbra@u-pem.fr> <1214581477.63149.1553356193197.JavaMail.zimbra@u-pem.fr> Message-ID: On 23/03/2019 15:49, forax at univ-mlv.fr wrote: > : > found the issue, it's more simple :) > > If you take a look to the error message, the module name is printed twice: > Error: Unable to initialize main class fr.umlv.lazystaticfinal.Main in module module fr.umlv.lazystaticfinal > Caused by: module fr.umlv.lazystaticfinal: java.lang.VerifyError > > so the issue is here > http://hg.openjdk.java.net/jdk/jdk/file/c81fbf340ceb/src/java.base/share/classes/sun/launcher/resources/launcher.properties#l245 > it should be > Caused by: {2}: {3} > instead of > Caused by: {1}: {2} > because {1} is the name of the module, not the name of the exception. > Good sleuthing, I've created JDK-8221368 to track this. -Alan From christoph.langer at sap.com Sun Mar 24 06:14:24 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 24 Mar 2019 06:14:24 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hi Matthias, yes, I think this is generally a good way to go. In JLI_Open(const char* name, int flags), you should remove ret and only use fd, I think. (Currently it would return 0 in the _wopen case). Furthermore, I think it would be a good time to introduce a test now that exercises paths to libjvm of different lengths... Thanks for your work here! Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Freitag, 22. M?rz 2019 20:37 > To: Baesken, Matthias ; Langer, Christoph > > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > On 22/03/2019 14:37, Baesken, Matthias wrote: > > Hello, here is the new webrev . > > > > I took over and adjusted coding from os::open + create_unc_path > functions in os_windows.cpp in hotspot : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/ > > > This looks quite good. For the comment then it might be better to drop > the mention of os_windows.cpp, also maybe mention that the memory > should > be freed with JLI_MemFree rather than free. > > -Alan From christoph.langer at sap.com Sun Mar 24 20:26:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 24 Mar 2019 20:26:14 +0000 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes In-Reply-To: <8d492e5d-0b95-bf6a-3a3b-a65d322778e8@oracle.com> References: <8d492e5d-0b95-bf6a-3a3b-a65d322778e8@oracle.com> Message-ID: Hi Ivan, thanks for looking closely. > UnixFileSystem_md.c: > Should the second error message be "Could not close file"? Yes, maybe that's better. Though it's really just the fallback, one could at least distinguish the two possibilities of IOException in this method... > UnixFileSystem.java: > Line spacing looks inconsistent.? Please leave an empty line before > @Override at lines 267, 269, 271, 273, etc. Good point, I compared to WinNTFileSystem.java and aligned the line spacing. Please find the updated webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8221262.1/ Best regards Christoph From christoph.langer at sap.com Sun Mar 24 20:32:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 24 Mar 2019 20:32:41 +0000 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes In-Reply-To: References: , <718fd510-99e4-66ea-2206-f9da81eaf527@oracle.com> Message-ID: Hi Bernd, we had that discussion about JDK-8211752: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057370.html There were objections against making this addition to jdk.includeInExceptions and the patch that Matthias proposed was also considered incomplete (e.g. not all possible native IOException would add a file path). So we withdrew the proposal. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Bernd Eckenfels > Sent: Freitag, 22. M?rz 2019 20:04 > To: Java Core Libs > Subject: Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem > implementation classes > > Instead of removing the file path, would it be possible to add it to all > implementations guarded by jdk.includeInExceptions=filename? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ________________________________ > Von: core-libs-dev im Auftrag > von Alan Bateman > Gesendet: Freitag, M?rz 22, 2019 5:35 PM > An: Langer, Christoph; Java Core Libs > Betreff: Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem > implementation classes > > On 22/03/2019 08:37, Langer, Christoph wrote: > > Hi, > > > > when contemplating over JDK-8211752, I found a few minor cleanups for > the implementations of UnixFileSystem/WinNTFileSystem. Can I please get > reviews? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221262 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/ > This looks okay to me. > > -Alan From thomas.stuefe at gmail.com Sun Mar 24 20:58:44 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 24 Mar 2019 21:58:44 +0100 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken Message-ID: Hi all, After a long time I tried to build a Windows 32bit VM (VS2017) and failed; multiple errors and warnings. Lets reverse the bitrot: cr: http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 Most of the fixes are trivial: Calling convention mismatches (awt DTRACE callbacks), printf specifiers etc. Had to supress a warning in os_windows_x86.cpp - I was surprised by this since this did not look 32bit specifc, do we disable warnings on Windows 64bit builds? The error I had in vmStructs.cpp was a bit weird: compiler complained about an assignment of an enum value defined like this: hash_mask_in_place = (address_word)hash_mask << hash_shift to an uint64_t variable, complaining about narrowing. I did not find out what his problem was. In the end, I decided to add an explicit cast to GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). With this patch we can build with warnings enabled on 32bit and 64bit windows. Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev and core-libs-dev. Thanks, Thomas From david.holmes at oracle.com Mon Mar 25 00:33:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 10:33:50 +1000 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: Message-ID: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Hi Thomas, A few queries, comments and concerns ... On 25/03/2019 6:58 am, Thomas St?fe wrote: > Hi all, > > After a long time I tried to build a Windows 32bit VM (VS2017) and failed; I'm somewhat surprised as I thought someone was actively doing Windows 32-bit builds out there, plus there are shared code changes that should also have been caught by non-Windows 32-bit builds. :( > multiple errors and warnings. Lets reverse the bitrot: > > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 > > Most of the fixes are trivial: Calling convention mismatches (awt DTRACE > callbacks), printf specifiers etc. > > Had to supress a warning in os_windows_x86.cpp - I was surprised by this > since this did not look 32bit specifc, do we disable warnings on Windows > 64bit builds? What version of VS2017? We use VS2017 15.9.6 and we don't disable warnings. > The error I had in vmStructs.cpp was a bit weird: compiler complained about > an assignment of an enum value defined like this: > > hash_mask_in_place = (address_word)hash_mask << hash_shift > > to an uint64_t variable, complaining about narrowing. I did not find out > what his problem was. In the end, I decided to add an explicit cast to > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). Not at all sure that's the right fix. In markOop.hpp we see that value gets special treatment on Windows-x64: #ifndef _WIN64 ,hash_mask = right_n_bits(hash_bits), hash_mask_in_place = (address_word)hash_mask << hash_shift #endif }; // Alignment of JavaThread pointers encoded in object header required by biased locking enum { biased_lock_alignment = 2 << (epoch_shift + epoch_bits) }; #ifdef _WIN64 // These values are too big for Win64 const static uintptr_t hash_mask = right_n_bits(hash_bits); const static uintptr_t hash_mask_in_place = (address_word)hash_mask << hash_shift; #endif perhaps something special is needed for Windows-x86. I'm unclear how the values can be "too big" ?? > > With this patch we can build with warnings enabled on 32bit and 64bit > windows. > > Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev and > core-libs-dev. Don't see anything that actually comes under core-libs-dev. Looks like one net-dev, one awt-dev and one security-dev. Sorry. Cheers, David ----- > Thanks, Thomas > From deepak.kejriwal at oracle.com Mon Mar 25 04:41:22 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Sun, 24 Mar 2019 21:41:22 -0700 (PDT) Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> Message-ID: Hi Naoto, Thanks for review. I will update the copyright information and push the changes. Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Friday, March 22, 2019 10:59 PM To: Deepak Kejriwal ; core-libs-dev ; jdk8u-dev at openjdk.java.net Subject: Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 Hi Deepak, Please modify the copyright year accordingly. Otherwise it looks good to me. Naoto On 3/22/19 8:51 AM, Deepak Kejriwal wrote: > Hi All, > > > > Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:- > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 > > https://bugs.openjdk.java.net/browse/JDK-8210633 > > > > Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ > > > > Master bug change set: http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > Summary: > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 (from 12u) are not clean backport. Changes for file "DateTimeFormatterBuilder.java" are manually merged. Since, test file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only test cases modified as part for JDK-8042131 and JDK-8210633 are added. > > All tests are run against the changes and found to be passing. > > Regards, > > Deepak > > > From ramanand.patil at oracle.com Mon Mar 25 06:37:40 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Sun, 24 Mar 2019 23:37:40 -0700 (PDT) Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> Message-ID: <7afc386a-11ac-403c-a6ec-0d7988604818@default> Hi Deepak, In particular, the test TestDateTimeFormatterBuilderWithLocale.java should have only one copyright year i.e. 2019, since this is a new file in jdk8u-dev repos. Also I think, you can omit the second copyright info(from line no. 24) for the same reason. Note: I am not a reviewer for JDK 8 Updates Project. Regards, Ramanand. > -----Original Message----- > From: Deepak Kejriwal > Sent: Monday, March 25, 2019 10:11 AM > To: Naoto Sato ; core-libs-dev dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > Hi Naoto, > > Thanks for review. I will update the copyright information and push the > changes. > > Regards, > Deepak > > > -----Original Message----- > From: Naoto Sato > Sent: Friday, March 22, 2019 10:59 PM > To: Deepak Kejriwal ; core-libs-dev libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > Hi Deepak, > > Please modify the copyright year accordingly. Otherwise it looks good to me. > > Naoto > > On 3/22/19 8:51 AM, Deepak Kejriwal wrote: > > Hi All, > > > > > > > > Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u- > dev:- > > > > > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 > > > > https://bugs.openjdk.java.net/browse/JDK-8210633 > > > > > > > > Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ > > > > > > > > Master bug change set: > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 > > > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > > > Summary: > > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 > (from 12u) are not clean backport. Changes for file > "DateTimeFormatterBuilder.java" are manually merged. Since, test file > "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only > test cases modified as part for JDK-8042131 and JDK-8210633 are added. > > > > All tests are run against the changes and found to be passing. > > > > Regards, > > > > Deepak > > > > > > From christoph.langer at sap.com Mon Mar 25 07:12:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Mar 2019 07:12:12 +0000 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: <7afc386a-11ac-403c-a6ec-0d7988604818@default> References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> Message-ID: Hi there, since this is a downport for jdk/jdk, I think the copyright headers should be the same as upstream. So, for src/share/classes/java/time/format/DateTimeFormatterBuilder.java, you should take 2018 as copyright year. For the test the headers look correct. As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle 8 updates. For the former, you'll have to request downport by setting the jdk8u-fix-request label in the bugs. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Ramanand Patil > Sent: Montag, 25. M?rz 2019 07:38 > To: Deepak Kejriwal ; Naoto Sato > ; core-libs-dev ; > jdk8u-dev at openjdk.java.net > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > Hi Deepak, > > In particular, the test TestDateTimeFormatterBuilderWithLocale.java should > have only one copyright year i.e. 2019, since this is a new file in jdk8u-dev > repos. Also I think, you can omit the second copyright info(from line no. 24) > for the same reason. > > > Note: I am not a reviewer for JDK 8 Updates Project. > > Regards, > Ramanand. > > > -----Original Message----- > > From: Deepak Kejriwal > > Sent: Monday, March 25, 2019 10:11 AM > > To: Naoto Sato ; core-libs-dev > dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > Hi Naoto, > > > > Thanks for review. I will update the copyright information and push the > > changes. > > > > Regards, > > Deepak > > > > > > -----Original Message----- > > From: Naoto Sato > > Sent: Friday, March 22, 2019 10:59 PM > > To: Deepak Kejriwal ; core-libs-dev > libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net > > Subject: Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > Hi Deepak, > > > > Please modify the copyright year accordingly. Otherwise it looks good to > me. > > > > Naoto > > > > On 3/22/19 8:51 AM, Deepak Kejriwal wrote: > > > Hi All, > > > > > > > > > > > > Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u- > > dev:- > > > > > > > > > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 > > > > > > https://bugs.openjdk.java.net/browse/JDK-8210633 > > > > > > > > > > > > Webrev: > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ > > > > > > > > > > > > Master bug change set: > > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > > > > > Summary: > > > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK- > 8210633 > > (from 12u) are not clean backport. Changes for file > > "DateTimeFormatterBuilder.java" are manually merged. Since, test file > > "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only > > test cases modified as part for JDK-8042131 and JDK-8210633 are added. > > > > > > All tests are run against the changes and found to be passing. > > > > > > Regards, > > > > > > Deepak > > > > > > > > > From matthias.baesken at sap.com Mon Mar 25 09:48:12 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 25 Mar 2019 09:48:12 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hi Christoph / Alan, thanks for the reviews. Btw what do you think about the longPathAware setting in the manifest ? https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/ This might be an option for Windows 10 / Windows server 2016 to enable long path awareness for all open calls. ( however for older Windows versions I think we still need the ELP/UNC path coding) Thanks, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Sonntag, 24. M?rz 2019 07:14 > To: Baesken, Matthias > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > yes, I think this is generally a good way to go. > > In JLI_Open(const char* name, int flags), you should remove ret and only > use fd, I think. (Currently it would return 0 in the _wopen case). > > Furthermore, I think it would be a good time to introduce a test now that > exercises paths to libjvm of different lengths... > > Thanks for your work here! > > Best regards > Christoph > > > > -----Original Message----- > > From: Alan Bateman > > Sent: Freitag, 22. M?rz 2019 20:37 > > To: Baesken, Matthias ; Langer, Christoph > > > > Cc: core-libs-dev at openjdk.java.net > > Subject: Re: RFR: 8218547: Simplify JLI_Open on Windows in native code > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > On 22/03/2019 14:37, Baesken, Matthias wrote: > > > Hello, here is the new webrev . > > > > > > I took over and adjusted coding from os::open + create_unc_path > > functions in os_windows.cpp in hotspot : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/ > > > > > This looks quite good. For the comment then it might be better to drop > > the mention of os_windows.cpp, also maybe mention that the memory > > should > > be freed with JLI_MemFree rather than free. > > > > -Alan From ramanand.patil at oracle.com Mon Mar 25 10:23:33 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 25 Mar 2019 03:23:33 -0700 (PDT) Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> Message-ID: <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Hi Christoph, I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same. Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it. Regards, Ramanand. > -----Original Message----- > From: Langer, Christoph > Sent: Monday, March 25, 2019 12:42 PM > To: Deepak Kejriwal > Cc: Ramanand Patil ; Naoto Sato > ; core-libs-dev ; > jdk8u-dev at openjdk.java.net > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > Hi there, > > since this is a downport for jdk/jdk, I think the copyright headers should be > the same as upstream. > > So, for src/share/classes/java/time/format/DateTimeFormatterBuilder.java, > you should take 2018 as copyright year. For the test the headers look correct. > > As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle 8 > updates. For the former, you'll have to request downport by setting the > jdk8u-fix-request label in the bugs. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk8u-dev On Behalf Of > > Ramanand Patil > > Sent: Montag, 25. M?rz 2019 07:38 > > To: Deepak Kejriwal ; Naoto Sato > > ; core-libs-dev > > ; jdk8u-dev at openjdk.java.net > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > Hi Deepak, > > > > In particular, the test TestDateTimeFormatterBuilderWithLocale.java > > should have only one copyright year i.e. 2019, since this is a new > > file in jdk8u-dev repos. Also I think, you can omit the second > > copyright info(from line no. 24) for the same reason. > > > > > > Note: I am not a reviewer for JDK 8 Updates Project. > > > > Regards, > > Ramanand. > > > > > -----Original Message----- > > > From: Deepak Kejriwal > > > Sent: Monday, March 25, 2019 10:11 AM > > > To: Naoto Sato ; core-libs-dev > > dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net > > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > > > Hi Naoto, > > > > > > Thanks for review. I will update the copyright information and push > > > the changes. > > > > > > Regards, > > > Deepak > > > > > > > > > -----Original Message----- > > > From: Naoto Sato > > > Sent: Friday, March 22, 2019 10:59 PM > > > To: Deepak Kejriwal ; core-libs-dev > > > ; jdk8u-dev at openjdk.java.net > > > Subject: Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > > > Hi Deepak, > > > > > > Please modify the copyright year accordingly. Otherwise it looks > > > good to > > me. > > > > > > Naoto > > > > > > On 3/22/19 8:51 AM, Deepak Kejriwal wrote: > > > > Hi All, > > > > > > > > > > > > > > > > Please review the back port of fix for JDK-8042131 and JDK-8210633 > > > > to 8u- > > > dev:- > > > > > > > > > > > > > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8210633 > > > > > > > > > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ > > > > > > > > > > > > > > > > Master bug change set: > > > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 > > > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > > > > > > > Summary: > > > > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK- > > 8210633 > > > (from 12u) are not clean backport. Changes for file > > > "DateTimeFormatterBuilder.java" are manually merged. Since, test > > > file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u > > > release only test cases modified as part for JDK-8042131 and JDK-8210633 > are added. > > > > > > > > All tests are run against the changes and found to be passing. > > > > > > > > Regards, > > > > > > > > Deepak > > > > > > > > > > > > From adam.farley at uk.ibm.com Mon Mar 25 11:41:13 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 25 Mar 2019 11:41:13 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> Message-ID: Hi Mandy, Mandy Chung wrote on 22/03/2019 16:56:12: > From: Mandy Chung > To: Joe Darcy , Adam Farley8 > Cc: core-libs-dev > Date: 22/03/2019 16:58 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > On 3/22/19 8:40 AM, Joe Darcy wrote: > > Please update distinct versions of a webrev (e.g. distinguished with > .1, .2 directory names) rather than overwriting a single one. This > make it easier for those coming to the review thread later to see > the evolution of the changes over time. > > +1 > > I had requested new test in the webrev during my review. That really > helps me, a reviewer, to keep track what has been changed easily. > It will also give you an idea how many revisions this review > involves when you started for a code review (as opposed to asking > for "how to fix this issue"). Ah, that makes sense. Thanks for explaining. :) > > I was asked to read the regression test that is attached to JBS issue [1] > I was asked to review a diff (cut-n-paste) on the mail when I > requested a webrev to include a regression test. [2] > > On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer > guide and I was hoping you read the guideline and be familiar with > it which should help you contributing to the OpenJDK. I completely forgot about that. I appreciate the reminder, will review the guide now so I don't forget again. > > I was disappointed to get your conclusion: > Historically, the bigger the change I propose, the more months it takes > the OpenJDK community to approve. Perhaps I misspoke. The only changes I've been able to get into OpenJDK have taken months apiece, with the exception of typos and pure comment tweaks. My *hope* is that small change sets will reduce the amount of debate (in general, this is not aimed at you personally), and result in a faster turnaround. > > I had helped as much as I can to sponsor this patch even if you > refused what I requested to help my review easier. Refused? I don't recall refusing your help. I appreciate your help, and I believe I have done everything you have asked, because I can see that you are working hard to help me get this changeset in. The only times I have not done as asked is when I have questions first, to help me understand, or because I have legitimately forgotten. > > I expected that you ran JDK regression tests on local machine rather > than I caught it for you. Is that what you expected a reviewer to > do it for you? Won't you consider this a new revision to your > patch? You can do anything you like and tells a reviewer that I > should be smart enough to identify the diff in the previous patch. > I am not an educator and excuse me if my response is not what you > are looking for. > > Mandy Do I expect reviewers to run tests for me? No. I made a mistake by assuming this code change was so small that a test run beyond MethodHandlesGeneralTest was unnecessary. This was a learning experience, and you did the right thing by double-checking, and finding my mistake. Now I know better. As for a new revision to my patch, I think you are referring to the versioning mentioned above. Now you have kindly explained the value of this to me, I am happy to include the versioning for future changes. Past changes may be tricky, as I don't have them. Illustrates the benefits of versioning quite well, hehe. As for your "educator" comment, you don't need to worry. Your response was quite clear. Best Regards Adam Farley > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > January/058320.html > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > February/058544.html > [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > January/058350.html > [4] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > March/058784.html 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 adam.farley at uk.ibm.com Mon Mar 25 11:48:45 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 25 Mar 2019 11:48:45 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> Message-ID: Hiya Joe, Responses below. Joe Darcy wrote on 22/03/2019 17:06:38: > From: Joe Darcy > To: Mandy Chung , Adam Farley8 > > Cc: core-libs-dev > Date: 22/03/2019 17:07 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > On 3/22/2019 9:56 AM, Mandy Chung wrote: > Hi Adam, > On 3/22/19 8:40 AM, Joe Darcy wrote: > > Please update distinct versions of a webrev (e.g. distinguished with > .1, .2 directory names) rather than overwriting a single one. This > make it easier for those coming to the review thread later to see > the evolution of the changes over time. > > +1 > > I had requested new test in the webrev during my review. That really > helps me, a reviewer, to keep track what has been changed easily. > It will also give you an idea how many revisions this review > involves when you started for a code review (as opposed to asking > for "how to fix this issue"). > > I was asked to read the regression test that is attached to JBS issue [1] > I was asked to review a diff (cut-n-paste) on the mail when I > requested a webrev to include a regression test. [2] > > On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer > guide and I was hoping you read the guideline and be familiar with > it which should help you contributing to the OpenJDK. > > I was disappointed to get your conclusion: > Historically, the bigger the change I propose, the more months it takes > the OpenJDK community to approve. > > OpenJDK is a community one participates in, not a service one sits > in judgement over. > -Joe No judgement was implied in my original comment. I was attempting to explain why I'd favoured a smaller code change over a large code change, and you're telling me I was unclear. Code changes can take a while to gain community approval, and it makes sense to me that I would notice that and attempt to make my code changes as small and simple as possible, to avoid delays, and make things easier for everyone. It seems that didn't get across this time, so I apologise. I will try to be more explicit in the future. Best Regards Adam Farley 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 adam.farley at uk.ibm.com Mon Mar 25 11:50:48 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 25 Mar 2019 11:50:48 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> References: <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: Hiya Joe, Response below, Joe Darcy wrote on 22/03/2019 17:05:33: > From: Joe Darcy > To: Adam Farley8 > Cc: core-libs-dev , Mandy Chung > > Date: 22/03/2019 17:06 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > On 3/22/2019 9:14 AM, Adam Farley8 wrote: > Hi Joe, > > I was aware that webrevs should be versioned, though I didn't see > the value for small change sets like this one. > > You seem to think there is a value. Can you explain it to me? > > The time of reviewers is valuable and should not be dissipated in > unnecessary attempts to determine what aspects of feedback have been > acted upon. > -Joe Ah, that makes sense. If I supplied a diff-of-diffs, would that help? To show the difference between two diffs, I mean, so it's clear what I changed. 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 gary.adams at oracle.com Mon Mar 25 00:10:50 2019 From: gary.adams at oracle.com (Gary Adams) Date: Sun, 24 Mar 2019 20:10:50 -0400 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table In-Reply-To: <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> References: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> Message-ID: <5C981C8A.3060101@oracle.com> Here's an updated webrev that includes the change to bind to the stub. The jstatd tests continue to pass after this change. Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.01/ It would be good to have a second reviewer from the serviceability team. Longer term it would be good to replace the rmi dependency, which does not appear to be central to the functionality provided here. On 3/22/19, 9:56 AM, Roger Riggs wrote: > Hi Gary, > > Holding a static reference to the implementation solves the problem. > > But I noticed that the object that is bound in the registry is the > RemoteHostImpl > and it should be the RemoteHost stub. > > Line 145: should be: > > bind(name.toString(), stub); > > That is likely to solve the problem as well, because the distributed > garbage > collector will correctly cause a hard reference to be retained to the > implementation. > > Roger > > > On 03/22/2019 04:05 AM, gary.adams at oracle.com wrote: >> Here's a proposed fix for the intermittent jstatd test failure. >> By moving the exported object from a local method variable to a >> static class variable a strong reference is held so the object >> will not be garbage collected prematurely. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8203026 >> >> The test is currently filed as a core-libs/java.rmi, but it probably >> should be core-svc/tools with label=jstatd. It is the callers >> responsibility to ensure the strong reference to prevent >> the premature garbage collection, so this is a test failure >> rather than a need to change the underlying rmi behavior. > From fw at deneb.enyo.de Mon Mar 25 12:24:37 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 25 Mar 2019 13:24:37 +0100 Subject: Formatting rules for exception messages Message-ID: <87o95zm9a2.fsf@mid.deneb.enyo.de> Are there any guidelines for formatting exception messages? In particular, I'm interested in the case when the exception message is a (clipped) sentence. Is it supposed to start with a capital letter? If the message refers to a parameter name, the spelling should reflect the name exactly, of course. There seems to be a slight bias towards capitalization, based on a few greps. Consider this: $ LC_ALL=C grep -r 'Exception("[A-Z][^" ]*ing ' src/*/share/classes/ | wc -l 159 $ LC_ALL=C grep -r 'Exception("[a-z][^" ]*ing ' src/*/share/classes/ | wc -l 73 From sgehwolf at redhat.com Mon Mar 25 13:01:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 Mar 2019 14:01:51 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Message-ID: <9f743d16db44bc87ddb0a4aa275538ba3260fe9c.camel@redhat.com> On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > Is there ever a situation where the memory.limit_in_bytes could be unlimited but the > hierarchical_memory_limit is not? Yes. This is the very bug. Under a systemd slice with newer kernels the memory.limit_in_bytes file OpenJDK looks at has unlimited, but memory.stat on the same hierarchy has the correct setting. Patched JDK with -Xlog:os+container=trace [0.051s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.limit_in_bytes [0.051s][trace][os,container] Memory Limit is: 9223372036854771712 [0.051s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited [0.051s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.stat [0.051s][trace][os,container] Hierarchical Memory Limit is: 10485760 $ cat /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.limit_in_bytes 9223372036854771712 $ cat /sys/fs/cgroup/memory/user.slice/user-cg.slice/memory.limit_in_bytes 10485760 $ grep hierarchical /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.stat hierarchical_memory_limit 10485760 hierarchical_memsw_limit 9223372036854771712 This was mentioned in the bug comments as well. > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > by adding an additional argument? Sure, I could look into that. I'll post an updated webrev soon. Thanks for the review! Cheers, Severin > BTW: I found another problem with the mountinfo/cgroup parsing that impacts the > container tests. > > I don?t know why it only caused a failure on one of my systems. I?m going to > file another bug. You might want to test with these changes to make sure > your looking at the correct subsystem files. OK. Thanks for the heads-up. It looks unrelated, though. > > diff --git a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java > --- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java > +++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java > @@ -60,7 +60,7 @@ > path = mountPoint; > } > else { > - if (root.indexOf(cgroupPath) == 0) { > + if (cgroupPath.indexOf(root) == 0) { > if (cgroupPath.length() > root.length()) { > String cgroupSubstr = cgroupPath.substring(root.length()); > path = mountPoint + cgroupSubstr; > diff --git a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java > --- a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java > +++ b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java > @@ -85,7 +85,7 @@ > String mountPoint = paths[1]; > if (root != null && cgroupPath != null) { > if (root.equals("/")) { > - if (cgroupPath.equals("/")) { > + if (!cgroupPath.equals("/")) { > finalPath = mountPoint + cgroupPath; > } else { > finalPath = mountPoint; > @@ -94,7 +94,7 @@ > if (root.equals(cgroupPath)) { > finalPath = mountPoint; > } else { > - if (root.indexOf(cgroupPath) == 0) { > + if (cgroupPath.indexOf(root) == 0) { > if (cgroupPath.length() > root.length()) { > String cgroupSubstr = cgroupPath.substring(root.length()); > finalPath = mountPoint + cgroupSubstr; > @@ -103,7 +103,7 @@ > } > } > } > - subSystemPaths.put(subSystem, new String[]{finalPath}); > + subSystemPaths.put(subSystem, new String[]{finalPath, mountPoint}); > } > } > } > > > Bob. > > > > > On Mar 22, 2019, at 6:43 AM, Severin Gehwolf wrote: > > > > Hi, > > > > Please review this change which improves container detection support > > tin the JVM. While docker container detection works quite well the > > results for systemd slices with memory limits are mixed and depend on > > the Linux kernel version in use. With newer kernel versions becoming > > more widely used we should improve JVMs memory limit detection support > > as well. This should be entirely backwards compatible as the > > hierarchical limit will only be used if everything else is unlimited. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/04/webrev/ > > > > Testing: Manual testing of -XshowSettings and -Xlog:os+container=trace > > with systemd slices on affected Linux distributions: Fedora 29, > > recent Ubuntu (18-10). Existing docker tests pass. I'm currently also > > running this through jdk/submit. > > > > Thoughts? > > > > Thanks, > > Severin > > From deepak.kejriwal at oracle.com Mon Mar 25 13:53:45 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 25 Mar 2019 06:53:45 -0700 (PDT) Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Message-ID: Hi Ramanand / Christoph, Thanks for review. I think Naoto and Ramanand are right, we do update the copyright year when it is not a clean backport. Please find the updated version of webrev. http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ Regards, Deepak -----Original Message----- From: Ramanand Patil Sent: Monday, March 25, 2019 3:54 PM To: Langer, Christoph ; Deepak Kejriwal Cc: Naoto Sato ; core-libs-dev ; jdk8u-dev at openjdk.java.net Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 Hi Christoph, I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same. Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it. Regards, Ramanand. > -----Original Message----- > From: Langer, Christoph > Sent: Monday, March 25, 2019 12:42 PM > To: Deepak Kejriwal > Cc: Ramanand Patil ; Naoto Sato > ; core-libs-dev > ; jdk8u-dev at openjdk.java.net > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > Hi there, > > since this is a downport for jdk/jdk, I think the copyright headers > should be the same as upstream. > > So, for > src/share/classes/java/time/format/DateTimeFormatterBuilder.java, > you should take 2018 as copyright year. For the test the headers look correct. > > As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle > 8 updates. For the former, you'll have to request downport by setting > the jdk8u-fix-request label in the bugs. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk8u-dev On Behalf Of > > Ramanand Patil > > Sent: Montag, 25. M?rz 2019 07:38 > > To: Deepak Kejriwal ; Naoto Sato > > ; core-libs-dev > > ; jdk8u-dev at openjdk.java.net > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > Hi Deepak, > > > > In particular, the test TestDateTimeFormatterBuilderWithLocale.java > > should have only one copyright year i.e. 2019, since this is a new > > file in jdk8u-dev repos. Also I think, you can omit the second > > copyright info(from line no. 24) for the same reason. > > > > > > Note: I am not a reviewer for JDK 8 Updates Project. > > > > Regards, > > Ramanand. > > > > > -----Original Message----- > > > From: Deepak Kejriwal > > > Sent: Monday, March 25, 2019 10:11 AM > > > To: Naoto Sato ; core-libs-dev > > dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net > > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > > > Hi Naoto, > > > > > > Thanks for review. I will update the copyright information and > > > push the changes. > > > > > > Regards, > > > Deepak > > > > > > > > > -----Original Message----- > > > From: Naoto Sato > > > Sent: Friday, March 22, 2019 10:59 PM > > > To: Deepak Kejriwal ; core-libs-dev > > > ; jdk8u-dev at openjdk.java.net > > > Subject: Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > > > > > Hi Deepak, > > > > > > Please modify the copyright year accordingly. Otherwise it looks > > > good to > > me. > > > > > > Naoto > > > > > > On 3/22/19 8:51 AM, Deepak Kejriwal wrote: > > > > Hi All, > > > > > > > > > > > > > > > > Please review the back port of fix for JDK-8042131 and > > > > JDK-8210633 to 8u- > > > dev:- > > > > > > > > > > > > > > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8210633 > > > > > > > > > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ > > > > > > > > > > > > > > > > Master bug change set: > > > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 > > > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > > > > > > > Summary: > > > > The backport of fix for both bugs JDK-8042131 (from 11u) and > > > > JDK- > > 8210633 > > > (from 12u) are not clean backport. Changes for file > > > "DateTimeFormatterBuilder.java" are manually merged. Since, test > > > file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u > > > release only test cases modified as part for JDK-8042131 and > > > JDK-8210633 > are added. > > > > > > > > All tests are run against the changes and found to be passing. > > > > > > > > Regards, > > > > > > > > Deepak > > > > > > > > > > > > From Roger.Riggs at oracle.com Mon Mar 25 14:16:39 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 25 Mar 2019 10:16:39 -0400 Subject: Formatting rules for exception messages In-Reply-To: <87o95zm9a2.fsf@mid.deneb.enyo.de> References: <87o95zm9a2.fsf@mid.deneb.enyo.de> Message-ID: <8cf1738d-b898-d6f8-26e7-98f07efbea43@oracle.com> Hi Florian, Appropriate message composition also varies depending on the level of the library or application.? Since you are asking here I'm assuming this is about OpenJDK exception messages. Exception messages are very context dependent both on the exception being thrown and class/method from which they are thrown. Even though the exception class and the message are propagated and may be logged or display in another context than they are thrown the message should tend toward brevity, supplying enough specific information to identify the cause.? It should avoid explaining. Exceptions are for programmers and operations, not end users. If an exception text is a full sentence, (noun, verb, direct object, etc.) it should follow correct grammar and punctuation. But it would rare that a sentence is appropriate for a Openjdk class exception. $.02, Roger On 03/25/2019 08:24 AM, Florian Weimer wrote: > Are there any guidelines for formatting exception messages? > > In particular, I'm interested in the case when the exception message > is a (clipped) sentence. Is it supposed to start with a capital > letter? > > If the message refers to a parameter name, the spelling should reflect > the name exactly, of course. There seems to be a slight bias towards > capitalization, based on a few greps. Consider this: > > $ LC_ALL=C grep -r 'Exception("[A-Z][^" ]*ing ' src/*/share/classes/ | wc -l > 159 > $ LC_ALL=C grep -r 'Exception("[a-z][^" ]*ing ' src/*/share/classes/ | wc -l > 73 From shade at redhat.com Mon Mar 25 14:32:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Mar 2019 15:32:02 +0100 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap Message-ID: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8221400 My major concern is to make tier1 passing on x86_32. This is one of the tests that fail. It seems the test can just use smaller heap size. Fix: diff -r d25b24c70126 test/jdk/java/lang/String/StringRepeat.java --- a/test/jdk/java/lang/String/StringRepeat.java Mon Mar 25 00:57:03 2019 -0400 +++ b/test/jdk/java/lang/String/StringRepeat.java Mon Mar 25 12:24:08 2019 +0100 @@ -22,11 +22,11 @@ */ /* * @test * @summary This exercises String#repeat patterns and limits. - * @run main/othervm -Xmx4G StringRepeat + * @run main/othervm -Xmx2g StringRepeat */ import java.nio.CharBuffer; Testing: Linux {x86_64, x86_32} fastdebug build and test, jdk-submit Thanks, -Aleksey From shade at redhat.com Mon Mar 25 14:33:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Mar 2019 15:33:47 +0100 Subject: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8221401 My major concern is to make tier1 passing on x86_32. This is one of the tests that fail. Smaller heap size does not fit this test case, unfortunately. So, we have to disable it for 32-bit builds. In fact, somebody did it already for 8u backport, but not upstream! Fix: diff -r 59816a32df2c test/jdk/java/math/BigInteger/LargeValueExceptions.java --- a/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar 25 13:12:37 2019 +0100 +++ b/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar 25 15:29:16 2019 +0100 @@ -23,11 +23,11 @@ /* * @test * @bug 8200698 * @summary Tests that exceptions are thrown for ops which would overflow - * @requires os.maxMemory >= 4g + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g) * @run testng/othervm -Xmx4g LargeValueExceptions */ import java.math.BigInteger; import static java.math.BigInteger.ONE; import org.testng.annotations.Test; Testing: Linux {x86_64, x86_32} fastdebug build and test, jdk-submit (running) Thanks, -Aleksey From thomas.stuefe at gmail.com Mon Mar 25 13:40:01 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 14:40:01 +0100 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> Message-ID: Looks fine and trivial. Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I just built) is 1400m. Cheers, Thomas On Mon, Mar 25, 2019 at 3:33 PM Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221400 > > My major concern is to make tier1 passing on x86_32. This is one of the > tests that fail. It seems > the test can just use smaller heap size. > > Fix: > > diff -r d25b24c70126 test/jdk/java/lang/String/StringRepeat.java > --- a/test/jdk/java/lang/String/StringRepeat.java Mon Mar 25 00:57:03 2019 > -0400 > +++ b/test/jdk/java/lang/String/StringRepeat.java Mon Mar 25 12:24:08 2019 > +0100 > @@ -22,11 +22,11 @@ > */ > > /* > * @test > * @summary This exercises String#repeat patterns and limits. > - * @run main/othervm -Xmx4G StringRepeat > + * @run main/othervm -Xmx2g StringRepeat > */ > > import java.nio.CharBuffer; > > > Testing: Linux {x86_64, x86_32} fastdebug build and test, jdk-submit > > Thanks, > -Aleksey > > From shade at redhat.com Mon Mar 25 14:47:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Mar 2019 15:47:14 +0100 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> Message-ID: <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> On 3/25/19 2:40 PM, Thomas St?fe wrote: > Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I > just built) is 1400m. That probably means something else is mapped into process memory that prevents continuous heap alloc. Does -Xmx2g work with fastdebug on your win32? We can adjust it later. -Aleksey From thomas.stuefe at gmail.com Mon Mar 25 14:54:36 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 15:54:36 +0100 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> Message-ID: On Mon, Mar 25, 2019 at 3:47 PM Aleksey Shipilev wrote: > On 3/25/19 2:40 PM, Thomas St?fe wrote: > > Note that this may not be enough for windows 32bit. Highest I can go > there (win32 slowdebug build I > > just built) is 1400m. > > That probably means something else is mapped into process memory that > prevents continuous heap > alloc. Does -Xmx2g work with fastdebug on your win32? We can adjust it > later. > > Can check tonight but actually I doubt it. I do not know of any differences of that kind (additionally loaded dlls or memory mappings) on slowdebug which would not be there on fastdebug. But since win32 is not officially supported anyway, I would be fine with the patch as it is. ..Thomas > -Aleksey > > From Roger.Riggs at oracle.com Mon Mar 25 14:56:44 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 25 Mar 2019 10:56:44 -0400 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> Message-ID: <1fbbace9-7b29-725a-147e-2dee9976b1b2@oracle.com> +1 On 03/22/2019 07:41 PM, Brian Burkhalter wrote: > Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/ > >> On Mar 22, 2019, at 4:32 PM, Brian Burkhalter wrote: >> >> Patch updated for the sake of formality. From Alan.Bateman at oracle.com Mon Mar 25 15:10:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Mar 2019 15:10:37 +0000 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> Message-ID: <5780df56-67ac-bfcd-04fd-cbd2941375b8@oracle.com> On 25/03/2019 14:47, Aleksey Shipilev wrote: > On 3/25/19 2:40 PM, Thomas St?fe wrote: >> Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I >> just built) is 1400m. > That probably means something else is mapped into process memory that prevents continuous heap > alloc. Does -Xmx2g work with fastdebug on your win32? We can adjust it later. Sometimes -Xshare:off can help a bit on Windows 32-bit. -Alan. From matthias.baesken at sap.com Mon Mar 25 17:05:12 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 25 Mar 2019 17:05:12 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hello here is an updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > In JLI_Open(const char* name, int flags), you should remove ret and only > > use fd, I think. I removed ret and adjusted some comments. Additionally I added a test that uses (on Windows) JLI_Open on a jar file with a "long" path (> 260 chars). [ JLI_Open is currently called from parse_manifest.c with jarfile as parameter ] Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 25. M?rz 2019 10:48 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Christoph / Alan, thanks for the reviews. > > > Btw what do you think about the longPathAware setting in the manifest > ? > > https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file > > https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and- > long-paths-on-windows-10/ > > This might be an option for Windows 10 / Windows server 2016 to enable > long path awareness for all open calls. > ( however for older Windows versions I think we still need the ELP/UNC path > coding) > > > Thanks, Matthias > > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Sonntag, 24. M?rz 2019 07:14 > > To: Baesken, Matthias > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hi Matthias, > > > > yes, I think this is generally a good way to go. > > > > In JLI_Open(const char* name, int flags), you should remove ret and only > > use fd, I think. (Currently it would return 0 in the _wopen case). > > > > Furthermore, I think it would be a good time to introduce a test now that > > exercises paths to libjvm of different lengths... > > > > Thanks for your work here! > > > > Best regards > > Christoph > > > > > > > -----Original Message----- > > > From: Alan Bateman > > > Sent: Freitag, 22. M?rz 2019 20:37 > > > To: Baesken, Matthias ; Langer, Christoph > > > > > > Cc: core-libs-dev at openjdk.java.net > > > Subject: Re: RFR: 8218547: Simplify JLI_Open on Windows in native code > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > parse_manifest.c on windows > > > > > > On 22/03/2019 14:37, Baesken, Matthias wrote: > > > > Hello, here is the new webrev . > > > > > > > > I took over and adjusted coding from os::open + create_unc_path > > > functions in os_windows.cpp in hotspot : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/ > > > > > > > This looks quite good. For the comment then it might be better to drop > > > the mention of os_windows.cpp, also maybe mention that the memory > > > should > > > be freed with JLI_MemFree rather than free. > > > > > > -Alan From ivan.gerasimov at oracle.com Mon Mar 25 17:29:35 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 25 Mar 2019 10:29:35 -0700 Subject: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes In-Reply-To: References: <8d492e5d-0b95-bf6a-3a3b-a65d322778e8@oracle.com> Message-ID: <11a147b2-322e-5532-9574-7993d07c8e71@oracle.com> Looks good, thank you! With kind regards, Ivan On 3/24/19 1:26 PM, Langer, Christoph wrote: > Hi Ivan, > > thanks for looking closely. > >> UnixFileSystem_md.c: >> Should the second error message be "Could not close file"? > Yes, maybe that's better. Though it's really just the fallback, one could at least distinguish the two possibilities of IOException in this method... > >> UnixFileSystem.java: >> Line spacing looks inconsistent. Please leave an empty line before >> @Override at lines 267, 269, 271, 273, etc. > Good point, I compared to WinNTFileSystem.java and aligned the line spacing. > > Please find the updated webrev here: > http://cr.openjdk.java.net/~clanger/webrevs/8221262.1/ > > Best regards > Christoph > > -- With kind regards, Ivan Gerasimov From sgehwolf at redhat.com Mon Mar 25 17:30:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 Mar 2019 18:30:48 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Message-ID: <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > by adding an additional argument? Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ Thanks, Severin From joe.darcy at oracle.com Mon Mar 25 17:34:42 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 25 Mar 2019 10:34:42 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: On 3/25/2019 4:50 AM, Adam Farley8 wrote: > Hiya Joe, > > Response below, > > Joe Darcy wrote on 22/03/2019 17:05:33: > > > From: Joe Darcy > > To: Adam Farley8 > > Cc: core-libs-dev , Mandy Chung > > > > Date: 22/03/2019 17:06 > > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > > to throw IllegalAccessException for final fields > > > > Hi Adam, > > On 3/22/2019 9:14 AM, Adam Farley8 wrote: > > Hi Joe, > > > > I was aware that webrevs should be versioned, though I didn't see > > the value for small change sets like this one. > > > > You seem to think there is a value. Can you explain it to me? > > > > > The time of reviewers is valuable and should not be dissipated in > > unnecessary attempts to determine what aspects of feedback have been > > acted upon. > > -Joe > > Ah, that makes sense. > > If I supplied a diff-of-diffs, would that help? > > To show the difference between two diffs, I mean, so it's clear what I > changed. > How about when multiple senior reviewers in OpenJDK ask you to follow common project conventions on versioned reviews, conventions they follow themselves (http://cr.openjdk.java.net/~darcy/), your opening position is comply with the request (perhaps asking for a rationale or offering additional alternatives) rather asking for a personal justification or exception? -Joe From adam.farley at uk.ibm.com Mon Mar 25 18:04:06 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 25 Mar 2019 18:04:06 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: Hi Joe, I've read your reply, and I apologise for any offence my inquiry has caused. My intent was only to ask for information. I would now like to refocus on the bug at hand. Do you, or Mandy, have a position in regards to the response I sent a few days ago? https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059191.html Also, I have read the guide (finally), and I see the tests should have a bug tag. I'll add that now, in a versioned webrev. Best Regards Adam Farley IBM Runtimes Joe Darcy wrote on 25/03/2019 17:34:42: > From: Joe Darcy > To: Adam Farley8 > Cc: core-libs-dev , Mandy Chung > > Date: 25/03/2019 17:35 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > On 3/25/2019 4:50 AM, Adam Farley8 wrote: > Hiya Joe, > > Response below, > > Joe Darcy wrote on 22/03/2019 17:05:33: > > > From: Joe Darcy > > To: Adam Farley8 > > Cc: core-libs-dev , Mandy Chung > > > > Date: 22/03/2019 17:06 > > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > > to throw IllegalAccessException for final fields > > > > Hi Adam, > > On 3/22/2019 9:14 AM, Adam Farley8 wrote: > > Hi Joe, > > > > I was aware that webrevs should be versioned, though I didn't see > > the value for small change sets like this one. > > > > You seem to think there is a value. Can you explain it to me? > > > > > The time of reviewers is valuable and should not be dissipated in > > unnecessary attempts to determine what aspects of feedback have been > > acted upon. > > -Joe > > Ah, that makes sense. > > If I supplied a diff-of-diffs, would that help? > > To show the difference between two diffs, I mean, so it's clear whatI changed. > > How about when multiple senior reviewers in OpenJDK ask you to > follow common project conventions on versioned reviews, conventions > they follow themselves (http://cr.openjdk.java.net/~darcy/), your > opening position is comply with the request (perhaps asking for a > rationale or offering additional alternatives) rather asking for a > personal justification or exception? > -Joe 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 adam.farley at uk.ibm.com Mon Mar 25 18:36:08 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 25 Mar 2019 18:36:08 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: Addendum: URL for new webrev: http://cr.openjdk.java.net/~afarley/8216558.1/webrev/ Adam Farley8/UK/IBM wrote on 25/03/2019 18:04:05: > From: Adam Farley8/UK/IBM > To: Joe Darcy > Cc: core-libs-dev , Mandy Chung > > Date: 25/03/2019 18:04 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Joe, > > I've read your reply, and I apologise for any offence my inquiry has caused. > > My intent was only to ask for information. > > I would now like to refocus on the bug at hand. > > Do you, or Mandy, have a position in regards to the response I sent > a few days ago? > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059191.html > > Also, I have read the guide (finally), and I see the tests should > have a bug tag. I'll add that now, in a versioned webrev. > > Best Regards > > Adam Farley > IBM Runtimes > > Joe Darcy wrote on 25/03/2019 17:34:42: > > > From: Joe Darcy > > To: Adam Farley8 > > Cc: core-libs-dev , Mandy Chung > > > > Date: 25/03/2019 17:35 > > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > > to throw IllegalAccessException for final fields > > > > On 3/25/2019 4:50 AM, Adam Farley8 wrote: > > Hiya Joe, > > > > Response below, > > > > Joe Darcy wrote on 22/03/2019 17:05:33: > > > > > From: Joe Darcy > > > To: Adam Farley8 > > > Cc: core-libs-dev , Mandy Chung > > > > > > Date: 22/03/2019 17:06 > > > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > > > to throw IllegalAccessException for final fields > > > > > > Hi Adam, > > > On 3/22/2019 9:14 AM, Adam Farley8 wrote: > > > Hi Joe, > > > > > > I was aware that webrevs should be versioned, though I didn't see > > > the value for small change sets like this one. > > > > > > You seem to think there is a value. Can you explain it to me? > > > > > > > > The time of reviewers is valuable and should not be dissipated in > > > unnecessary attempts to determine what aspects of feedback have been > > > acted upon. > > > -Joe > > > > Ah, that makes sense. > > > > If I supplied a diff-of-diffs, would that help? > > > > To show the difference between two diffs, I mean, so it's clear > whatI changed. > > > > How about when multiple senior reviewers in OpenJDK ask you to > > follow common project conventions on versioned reviews, conventions > > they follow themselves (http://cr.openjdk.java.net/~darcy/), your > > opening position is comply with the request (perhaps asking for a > > rationale or offering additional alternatives) rather asking for a > > personal justification or exception? > > -Joe > 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 joe.darcy at oracle.com Mon Mar 25 19:07:50 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 25 Mar 2019 12:07:50 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> Message-ID: <9bdcc0ee-2339-a28a-fccd-7f60c1a9a7a4@oracle.com> On 3/25/2019 4:48 AM, Adam Farley8 wrote: > Hiya Joe, > > Responses below. > > Joe Darcy wrote on 22/03/2019 17:06:38: > > > From: Joe Darcy > > To: Mandy Chung , Adam Farley8 > > > > Cc: core-libs-dev > > Date: 22/03/2019 17:07 > > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > > to throw IllegalAccessException for final fields > > > > On 3/22/2019 9:56 AM, Mandy Chung wrote: > > Hi Adam, > > > On 3/22/19 8:40 AM, Joe Darcy wrote: > > > > Please update distinct versions of a webrev (e.g. distinguished with > > .1, .2 directory names) rather than overwriting a single one. This > > make it easier for those coming to the review thread later to see > > the evolution of the changes over time. > > > > > +1 > > > > I had requested new test in the webrev during my review. That really > > helps me, a reviewer, to keep track what has been changed easily. > > It will also give you an idea how many revisions this review > > involves when you started for a code review (as opposed to asking > > for "how to fix this issue"). > > > > I was asked to read the regression test that is attached to JBS > issue [1] > > I was asked to review a diff (cut-n-paste) on the mail when I > > requested a webrev to include a regression test. [2] > > > > On Jan 31, 2019 [3], I includeed a link to the OpenJDK developer > > guide and I was hoping you read the guideline and be familiar with > > it which should help you contributing to the OpenJDK. > > > > I was disappointed to get your conclusion: > > Historically, the bigger the change I propose, the more months it takes > > the OpenJDK community to approve. > > > > OpenJDK is a community one participates in, not a service one sits > > in judgement over. > > -Joe > > No judgement was implied in my original comment. I was attempting to > explain why I'd favoured a smaller code change over a large code change, > and you're telling me I was unclear. > > Code changes can take a while to gain community approval, and it makes > sense to me that I would notice that and attempt to make my code > changes as small and simple as possible, to avoid delays, and make > things easier for everyone. > There is a difference between asking "What can I do to reduce the review time on on my patches?" and simply stating in what would reasonably be interpreted in an accusatory tone "it takes months for the OpenJDK community to review my patches." Answers to that question include, but are not limited to, following long-established project conventions around, for example, writing new tests, running regression tests oneself, accepting and acting on feedback from senior reviewers, etc. Assuming a multi-month latency for getting patches in is longer than average, there is a large space of possible explanations for that. One set of explanations includes deficiencies in the reviewers or review process. Another set of explanations includes deficiencies in the patch or its author, such as argumentativeness or other cause requiring excessive involvement of and corrective action from the reviewers to get the patch to conform to the conventions and quality standards of the project. In this project at least, the burden of proof is on the person advocating to get the patch in; the burden of proof is not on the reviewers for why the patch should be kept out. -Joe From naoto.sato at oracle.com Mon Mar 25 19:39:24 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 25 Mar 2019 12:39:24 -0700 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Message-ID: <9a025359-2f31-6f73-59b5-cc3d6ed9ea34@oracle.com> Looks good. Naoto On 3/25/19 6:53 AM, Deepak Kejriwal wrote: > Hi Ramanand / Christoph, > > Thanks for review. I think Naoto and Ramanand are right, we do update the copyright year when it is not a clean backport. Please find the updated version of webrev. > > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Ramanand Patil > Sent: Monday, March 25, 2019 3:54 PM > To: Langer, Christoph ; Deepak Kejriwal > Cc: Naoto Sato ; core-libs-dev ; jdk8u-dev at openjdk.java.net > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 > > Hi Christoph, > I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same. > > Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it. > > Regards, > Ramanand. > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Monday, March 25, 2019 12:42 PM >> To: Deepak Kejriwal >> Cc: Ramanand Patil ; Naoto Sato >> ; core-libs-dev >> ; jdk8u-dev at openjdk.java.net >> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 >> >> Hi there, >> >> since this is a downport for jdk/jdk, I think the copyright headers >> should be the same as upstream. >> >> So, for >> src/share/classes/java/time/format/DateTimeFormatterBuilder.java, >> you should take 2018 as copyright year. For the test the headers look correct. >> >> As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle >> 8 updates. For the former, you'll have to request downport by setting >> the jdk8u-fix-request label in the bugs. >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: jdk8u-dev On Behalf Of >>> Ramanand Patil >>> Sent: Montag, 25. M?rz 2019 07:38 >>> To: Deepak Kejriwal ; Naoto Sato >>> ; core-libs-dev >>> ; jdk8u-dev at openjdk.java.net >>> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 >>> >>> Hi Deepak, >>> >>> In particular, the test TestDateTimeFormatterBuilderWithLocale.java >>> should have only one copyright year i.e. 2019, since this is a new >>> file in jdk8u-dev repos. Also I think, you can omit the second >>> copyright info(from line no. 24) for the same reason. >>> >>> >>> Note: I am not a reviewer for JDK 8 Updates Project. >>> >>> Regards, >>> Ramanand. >>> >>>> -----Original Message----- >>>> From: Deepak Kejriwal >>>> Sent: Monday, March 25, 2019 10:11 AM >>>> To: Naoto Sato ; core-libs-dev >>> dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net >>>> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 >>>> >>>> Hi Naoto, >>>> >>>> Thanks for review. I will update the copyright information and >>>> push the changes. >>>> >>>> Regards, >>>> Deepak >>>> >>>> >>>> -----Original Message----- >>>> From: Naoto Sato >>>> Sent: Friday, March 22, 2019 10:59 PM >>>> To: Deepak Kejriwal ; core-libs-dev >>>> ; jdk8u-dev at openjdk.java.net >>>> Subject: Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 >>>> >>>> Hi Deepak, >>>> >>>> Please modify the copyright year accordingly. Otherwise it looks >>>> good to >>> me. >>>> >>>> Naoto >>>> >>>> On 3/22/19 8:51 AM, Deepak Kejriwal wrote: >>>>> Hi All, >>>>> >>>>> >>>>> >>>>> Please review the back port of fix for JDK-8042131 and >>>>> JDK-8210633 to 8u- >>>> dev:- >>>>> >>>>> >>>>> >>>>> JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131 >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8210633 >>>>> >>>>> >>>>> >>>>> Webrev: >>> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/ >>>>> >>>>> >>>>> >>>>> Master bug change set: >>>> http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2 >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 >>>>> >>>>> Summary: >>>>> The backport of fix for both bugs JDK-8042131 (from 11u) and >>>>> JDK- >>> 8210633 >>>> (from 12u) are not clean backport. Changes for file >>>> "DateTimeFormatterBuilder.java" are manually merged. Since, test >>>> file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u >>>> release only test cases modified as part for JDK-8042131 and >>>> JDK-8210633 >> are added. >>>>> >>>>> All tests are run against the changes and found to be passing. >>>>> >>>>> Regards, >>>>> >>>>> Deepak >>>>> >>>>> >>>>> From andrew_m_leonard at uk.ibm.com Mon Mar 25 19:45:06 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 25 Mar 2019 19:45:06 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Message-ID: Hi, Please can I request a sponsor for this fix to a JDK-13 regression? Patch with jtreg testcase here: http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8221430 Many 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 kim.barrett at oracle.com Mon Mar 25 21:25:36 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 25 Mar 2019 17:25:36 -0400 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: Message-ID: <121ECA5D-7D83-4072-A4C7-C9DFA398874B@oracle.com> > On Mar 24, 2019, at 4:58 PM, Thomas St?fe wrote: > > Hi all, > > After a long time I tried to build a Windows 32bit VM (VS2017) and failed; > multiple errors and warnings. Lets reverse the bitrot: > > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 > > Most of the fixes are trivial: Calling convention mismatches (awt DTRACE > callbacks), printf specifiers etc. > > Had to supress a warning in os_windows_x86.cpp - I was surprised by this > since this did not look 32bit specifc, do we disable warnings on Windows > 64bit builds? > > The error I had in vmStructs.cpp was a bit weird: compiler complained about > an assignment of an enum value defined like this: > > hash_mask_in_place = (address_word)hash_mask << hash_shift > > to an uint64_t variable, complaining about narrowing. I did not find out > what his problem was. In the end, I decided to add an explicit cast to > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). > > With this patch we can build with warnings enabled on 32bit and 64bit > windows. > > Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev and > core-libs-dev. > > Thanks, Thomas I started looking at the HotSpot parts before you retracted with the intent of opening separate issues. I?ll give you my comments now, in case I miss some of those new issues and might be able to affect the associated changes. ------------------------------------------------------------------------------ src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp 468 #pragma warning(push) 469 // Ignore "C4172: returning address of local variable or temporary" 470 #pragma warning(disable : 4172) Although this is Windows-specific code, consider using PRAGMA_DIAG_PUSH/POP and PRAGMA_DISABLE_MSVC_WARNING. ------------------------------------------------------------------------------ src/hotspot/share/classfile/classFileParser.cpp 315 utf8_length = (u2) strlen(str); This looked really familiar; I remember DavidH and I looking at this before and being puzzled because the warning only showed up in 32bit builds, even though the exact same issue applies to 64bit builds. Unfortunately, the person who reported it (in an internal channel) doesn't seem to have followed up with a patch or even a bug report. So thanks for this. ------------------------------------------------------------------------------ src/hotspot/share/oops/markOop.hpp 29 #include "utilities/globalDefinitions.hpp" I don't object to this change, but I'm surprised this is needed in order to build. oops/oop.hpp indirectly includes globalDefinitions.hpp. ------------------------------------------------------------------------------ src/hotspot/share/runtime/vmStructs.hpp 275 { QUOTE(name), (uint64_t)name }, I'd like to get a better understanding of this change, as it doesn't make sense to me. Can you provide the exact error message? I can't see why there would be a problem here. If I haven't messed up, the case you mentioned should be 64bit hash_mask_in_place = (uintptr_t)((intptr_t(1) << 31) - 1) << 8 32bit hash_mask_in_place = (uintptr_t)((intptr_t(1) << (31 - 7)) - 1) << 7 and I don't see anything problematic about either of those. ------------------------------------------------------------------------------ From andy.herrick at oracle.com Mon Mar 25 21:32:20 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 25 Mar 2019 17:32:20 -0400 Subject: New JBS component/sub-component for jpackage Message-ID: For all those interested in the proposed jpackage tool: As described in INFRA-15257 , the component/subcomponent for jpackage bug in JBS has been changed from deploy/packager to tools/jpackage. Existing bugs and enhancements in jpackage have been moved to the new component/subcomponent, and only bugs specifically for the javafxpackager in 8u will be left in the deploy component. We will continue to monitor any bugs filed as deploy/packager and move them overe as appropriate. /Andy From martijnverburg at gmail.com Mon Mar 25 21:49:24 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 25 Mar 2019 21:49:24 +0000 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: Hi all, Snipping much, but commenting on one statement inline below. On Mon, 25 Mar 2019 at 01:58, David Holmes wrote: > Hi Thomas, > > A few queries, comments and concerns ... > > On 25/03/2019 6:58 am, Thomas St?fe wrote: > > Hi all, > > > > After a long time I tried to build a Windows 32bit VM (VS2017) and > failed; > > I'm somewhat surprised as I thought someone was actively doing Windows > 32-bit builds out there, plus there are shared code changes that should > also have been caught by non-Windows 32-bit builds. :( > AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 to do so and have hit the same issues (Thomas beat us to reporting!). Hopefully, we'll have that nightly warning system in place for you going forward soon. Cheers, Martijn From ivan.gerasimov at oracle.com Mon Mar 25 22:20:44 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 25 Mar 2019 15:20:44 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: Message-ID: Hi Andrew! Thanks for finding this bug! Your fix solves the problem. However, I think the main issue is that the constructor AbstractStringBuilder(byte,int,int) is now broken: as you discovered, it allows to create a string buffer with the coder LATIN1 when COMPACT_STRINGS is false. Wouldn't it make sense to rename the argument of the constructor to, say, coderHint, and then either use it as the coder if COMPACT_STRINGS==true, or discard it otherwise. What do you think? With kind regards, Ivan On 3/25/19 12:45 PM, Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to a JDK-13 regression? > > Patch with jtreg testcase here: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > > Many 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 > -- With kind regards, Ivan Gerasimov From alexander.matveev at oracle.com Mon Mar 25 22:35:44 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 25 Mar 2019 15:35:44 -0700 Subject: RFR: JDK-8215019: Allow --install-dir on windows In-Reply-To: <83569542-51ad-7d06-247b-274655fcbf51@oracle.com> References: <83569542-51ad-7d06-247b-274655fcbf51@oracle.com> Message-ID: <5559cac3-1685-d149-d816-bd45e4ad8f3c@oracle.com> Hi Andy, http://cr.openjdk.java.net/~almatvee/8215019/webrev.01/ Updated webrev with added missing message in HelpResources_zh_CN.properties and updated messages below: MSG_Help_win_install_dir=\ \Relative sub-path under the default installation location\n\ message.invalid.install.dir=Warning: Invalid install directory {0}. Install directory should be a relative sub-path under the default installation location such as "Program Files". Defaulting to application name "{1}". Thanks, Alexander On 3/21/2019 10:08 AM, Andy Herrick wrote: > I think you missed HelpResources_zh_CN.properties > > I think wording of help text: 'sub-path of the installation location > of the application such as"Program Files" or "AppData"' is? > misleading.? It reads like "Program files" or "AppDAta" are examples > of the sub-path. > > The error message says: 'sub-path under default installation location" > which is a little better. (though there should be a "the" before > default). > > /Andy > > > On 3/20/2019 8:05 PM, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Added support for --install-dir on Windows. It should be relative >> path to "Program Files" or "AppData". >> - If --install-dir is invalid we will use app name instead. >> - Added two new tests to validate --install-dir and related >> functionality. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8215019 >> >> [2] http://cr.openjdk.java.net/~almatvee/8215019/webrev.00/ >> >> Thanks, >> Alexander > From andrew_m_leonard at uk.ibm.com Mon Mar 25 22:45:44 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 25 Mar 2019 22:45:44 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: Message-ID: Hi Ivan, I think I see what you're saying, you mean we also need to correct this line in AbstractStringBuilder constructor: value = (coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); to be maybe: value = (COMPACT_STRINGS && coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); The passed in coder stills need to be correct, since with COMPACT_STRINGS a string could be UTF16 if it cannot be compacted, so it's more than just a hint isn't it? 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 From: Ivan Gerasimov To: Andrew Leonard , core-libs-dev at openjdk.java.net Date: 25/03/2019 22:20 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew! Thanks for finding this bug! Your fix solves the problem. However, I think the main issue is that the constructor AbstractStringBuilder(byte,int,int) is now broken: as you discovered, it allows to create a string buffer with the coder LATIN1 when COMPACT_STRINGS is false. Wouldn't it make sense to rename the argument of the constructor to, say, coderHint, and then either use it as the coder if COMPACT_STRINGS==true, or discard it otherwise. What do you think? With kind regards, Ivan On 3/25/19 12:45 PM, Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to a JDK-13 regression? > > Patch with jtreg testcase here: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=dSyZ3Lfm50uqPEMhbRsyUW8TP_-2bGVkewnWt3wUJUE&s=bUl6dk1cPu349mQ06PdWcF-OC50wYFkmMSC6W3HNvl4&e= > > bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221430&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=dSyZ3Lfm50uqPEMhbRsyUW8TP_-2bGVkewnWt3wUJUE&s=JZXGlJ2wpJFaZb3MKCiTM7xzJGzqXDWRE14oRo5Mhgw&e= > > Many 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 > -- With kind regards, Ivan Gerasimov 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 ivan.gerasimov at oracle.com Mon Mar 25 22:55:27 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 25 Mar 2019 15:55:27 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: Message-ID: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> I was thinking of organizing code similar to what is done in AbstractStringBuilder(int): if (COMPACT_STRINGS && coderHint == LATIN1) { value = new byte[capacity]; coder = LATIN1; } else { value = StringUTF16.newBytesFor(capacity); coder = UTF16; } With kind regards, Ivan On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct > this line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > > Hi, > > Please can I request a sponsor for this fix to a JDK-13 regression? > > > > Patch with jtreg testcase here: > > http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > > > > Many 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 > > > > -- > With kind regards, > Ivan Gerasimov > > > > > > 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 -- With kind regards, Ivan Gerasimov From andrew_m_leonard at uk.ibm.com Mon Mar 25 23:07:23 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 25 Mar 2019 23:07:23 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> Message-ID: Yes, I think organizing it the same as the (int) constructor would be good for consistency. I will update my patch with that, Thanks Ivan 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: Ivan Gerasimov To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 25/03/2019 22:55 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified I was thinking of organizing code similar to what is done in AbstractStringBuilder(int): if (COMPACT_STRINGS && coderHint == LATIN1) { value = new byte[capacity]; coder = LATIN1; } else { value = StringUTF16.newBytesFor(capacity); coder = UTF16; } With kind regards, Ivan On 3/25/19 3:45 PM, Andrew Leonard wrote: Hi Ivan, I think I see what you're saying, you mean we also need to correct this line in AbstractStringBuilder constructor: value = (coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); to be maybe: value = (COMPACT_STRINGS && coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); The passed in coder stills need to be correct, since with COMPACT_STRINGS a string could be UTF16 if it cannot be compacted, so it's more than just a hint isn't it? 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 From: Ivan Gerasimov To: Andrew Leonard , core-libs-dev at openjdk.java.net Date: 25/03/2019 22:20 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew! Thanks for finding this bug! Your fix solves the problem. However, I think the main issue is that the constructor AbstractStringBuilder(byte,int,int) is now broken: as you discovered, it allows to create a string buffer with the coder LATIN1 when COMPACT_STRINGS is false. Wouldn't it make sense to rename the argument of the constructor to, say, coderHint, and then either use it as the coder if COMPACT_STRINGS==true, or discard it otherwise. What do you think? With kind regards, Ivan On 3/25/19 12:45 PM, Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to a JDK-13 regression? > > Patch with jtreg testcase here: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > > Many 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 > -- With kind regards, Ivan Gerasimov 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 -- With kind regards, Ivan Gerasimov 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 andrew_m_leonard at uk.ibm.com Tue Mar 26 00:00:08 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 00:00:08 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> Message-ID: Hi Ivan, Here is my updated webrev: http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ 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 From: Ivan Gerasimov To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 25/03/2019 22:55 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified I was thinking of organizing code similar to what is done in AbstractStringBuilder(int): if (COMPACT_STRINGS && coderHint == LATIN1) { value = new byte[capacity]; coder = LATIN1; } else { value = StringUTF16.newBytesFor(capacity); coder = UTF16; } With kind regards, Ivan On 3/25/19 3:45 PM, Andrew Leonard wrote: Hi Ivan, I think I see what you're saying, you mean we also need to correct this line in AbstractStringBuilder constructor: value = (coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); to be maybe: value = (COMPACT_STRINGS && coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); The passed in coder stills need to be correct, since with COMPACT_STRINGS a string could be UTF16 if it cannot be compacted, so it's more than just a hint isn't it? 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 From: Ivan Gerasimov To: Andrew Leonard , core-libs-dev at openjdk.java.net Date: 25/03/2019 22:20 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew! Thanks for finding this bug! Your fix solves the problem. However, I think the main issue is that the constructor AbstractStringBuilder(byte,int,int) is now broken: as you discovered, it allows to create a string buffer with the coder LATIN1 when COMPACT_STRINGS is false. Wouldn't it make sense to rename the argument of the constructor to, say, coderHint, and then either use it as the coder if COMPACT_STRINGS==true, or discard it otherwise. What do you think? With kind regards, Ivan On 3/25/19 12:45 PM, Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to a JDK-13 regression? > > Patch with jtreg testcase here: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > > Many 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 > -- With kind regards, Ivan Gerasimov 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 -- With kind regards, Ivan Gerasimov 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 ivan.gerasimov at oracle.com Tue Mar 26 01:18:47 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 25 Mar 2019 18:18:47 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> Message-ID: Thanks Andrew! Introducing getCharSequenceCoder() is actually an enhancement, which may improve pre-allocation in certain cases. It's not actually required to restore correctness of StringBuilder/Buffer constructors. I recommend to separate it from this bug fix, so it can be discussed separately, and determined if this is the best approach to this enhancement. If you agree, I can adjust your latest patch accordingly, run it through the Mach5 test systems and push it on your behalf. With kind regards, Ivan On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct > this line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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_ > > > > > > From: Ivan Gerasimov __ > > To: Andrew Leonard __ > , _core-libs-dev at openjdk.java.net_ > > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > > Hi, > > Please can I request a sponsor for this fix to a JDK-13 regression? > > > > Patch with jtreg testcase here: > > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ > > > > > bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ > > > > Many 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 > > > > -- > With kind regards, > Ivan Gerasimov > > > > > > 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 > > -- > With kind regards, > Ivan Gerasimov > > > 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 -- With kind regards, Ivan Gerasimov From seth.lytle at gmail.com Tue Mar 26 01:22:23 2019 From: seth.lytle at gmail.com (seth lytle) Date: Mon, 25 Mar 2019 21:22:23 -0400 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader Message-ID: if a lambda is a field and captures `this`, and it's deserialized into a new class loader, it throws a ClassCastException. i came across this bug independently while writing a test, but then found an old openjdk bug with a similar issue and tweaked the test case (source below). my version differs only in 1. moved the lambda to a field 2. reference `this` in it 3. uses readAllBytes instead of the internal method 4. formatting running with java 11 or 12 (or java 8 using a substitute for readAllBytes) results in: this: test.SerializedLambdaTest$MyCode at 8efb846 deSerializedThis: test.SerializedLambdaTest$MyCode at 2b71fc7e runnable: test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 Exception in thread "main" java.lang.ClassCastException: cannot assign instance of java.lang.invoke.SerializedLambda to field test.SerializedLambdaTest$MyCode.runnable2 of type test.SerializedLambdaTest$SerializableRunnable in instance of test.SerializedLambdaTest$MyCode at java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) at java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) at java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) at java.base/java.io.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1594) at java.base/java.io.ObjectInputStream.readArray(ObjectInputStream.java:1993) at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1588) at java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1594) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:430) at test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) at test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) at test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) https://bugs.openjdk.java.net/browse/JDK-8008770 package test; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; // from: https://bugs.openjdk.java.net/browse/JDK-8008770 public class SerializedLambdaTest { public interface SerializableRunnable extends Runnable,Serializable { } public static class MyCode implements SerializableRunnable { SerializableRunnable runnable2 = () -> { System.out.println("HELLO"+this.getClass()); }; private byte[] serialize(Object o) { ByteArrayOutputStream baos; try ( ObjectOutputStream oos = new ObjectOutputStream(baos = new ByteArrayOutputStream())) { oos.writeObject(o); } catch (IOException e) { throw new RuntimeException(e); } return baos.toByteArray(); } private T deserialize(byte[] bytes) { try ( ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bytes))) { return (T) ois.readObject(); } catch (IOException|ClassNotFoundException e) { throw new RuntimeException(e); } } @Override public void run() { System.out.println(" this: "+this); SerializableRunnable deSerializedThis = deserialize(serialize(this)); System.out.println(" deSerializedThis: " +deSerializedThis); SerializableRunnable runnable = runnable2; System.out.println(" runnable: "+runnable); SerializableRunnable deSerializedRunnable = deserialize(serialize(runnable)); System.out.println("deSerializedRunnable: " +deSerializedRunnable); } } public static void main(String[] args) throws Exception { ClassLoader myCl = new MyClassLoader( SerializedLambdaTest.class.getClassLoader() ); Class myCodeClass = Class.forName( SerializedLambdaTest.class.getName()+"$MyCode", true, myCl ); Runnable myCode = (Runnable) myCodeClass.newInstance(); myCode.run(); } static class MyClassLoader extends ClassLoader { MyClassLoader(ClassLoader parent) { super(parent); } @Override protected Class loadClass(String name,boolean resolve) throws ClassNotFoundException { if (name.startsWith("test.")) synchronized (getClassLoadingLock(name)) { Class c = findLoadedClass(name); if (c==null) c = findClass(name); if (resolve) resolveClass(c); return c; } else return super.loadClass(name,resolve); } @Override protected Class findClass(String name) throws ClassNotFoundException { String path = name.replace('.','/').concat(".class"); try ( InputStream is = getResourceAsStream(path)) { if (is!=null) { byte[] bytes = is.readAllBytes(); return defineClass(name,bytes,0,bytes.length); } else throw new ClassNotFoundException(name); } catch (IOException e) { throw new ClassNotFoundException(name,e); } } } } From david.holmes at oracle.com Tue Mar 26 01:34:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 11:34:23 +1000 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: Message-ID: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> Hi Seth, On 26/03/2019 11:22 am, seth lytle wrote: > if a lambda is a field and captures `this`, and it's deserialized into a > new class loader, it throws a ClassCastException. Not sure I follow. If you load a class into a different classloader then you get a different type. It might appear the same to you but it is a distinct type, so you can't assign across different instances loaded by different classloaders. Cheers, David ----- > i came across this bug > independently while writing a test, but then found an old openjdk bug with > a similar issue and tweaked the test case (source below). my version > differs only in > 1. moved the lambda to a field > 2. reference `this` in it > 3. uses readAllBytes instead of the internal method > 4. formatting > > running with java 11 or 12 (or java 8 using a substitute for readAllBytes) > results in: > this: test.SerializedLambdaTest$MyCode at 8efb846 > deSerializedThis: test.SerializedLambdaTest$MyCode at 2b71fc7e > runnable: > test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > Exception in thread "main" java.lang.ClassCastException: cannot assign > instance of java.lang.invoke.SerializedLambda to field > test.SerializedLambdaTest$MyCode.runnable2 of type > test.SerializedLambdaTest$SerializableRunnable in instance of > test.SerializedLambdaTest$MyCode > at > java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > at > java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > at > java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > at > java.base/java.io.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > at > java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > at > java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > at > java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > at > java.base/java.io.ObjectInputStream.readArray(ObjectInputStream.java:1993) > at > java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1588) > at > java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > at > java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > at > java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > at > java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > at > java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:430) > at > test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > at test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > at test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > > > > https://bugs.openjdk.java.net/browse/JDK-8008770 > > > package test; > > import java.io.ByteArrayInputStream; > import java.io.ByteArrayOutputStream; > import java.io.IOException; > import java.io.InputStream; > import java.io.ObjectInputStream; > import java.io.ObjectOutputStream; > import java.io.Serializable; > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > public class SerializedLambdaTest { > public interface SerializableRunnable extends Runnable,Serializable { > } > public static class MyCode implements SerializableRunnable { > SerializableRunnable runnable2 = () > -> { > System.out.println("HELLO"+this.getClass()); > }; > private byte[] serialize(Object o) { > ByteArrayOutputStream baos; > try ( > ObjectOutputStream oos > = new ObjectOutputStream(baos = new > ByteArrayOutputStream())) { > oos.writeObject(o); > } catch (IOException e) { > throw new RuntimeException(e); > } > return baos.toByteArray(); > } > private T deserialize(byte[] bytes) { > try ( > ObjectInputStream ois > = new ObjectInputStream(new > ByteArrayInputStream(bytes))) { > return (T) ois.readObject(); > } catch (IOException|ClassNotFoundException e) { > throw new RuntimeException(e); > } > } > @Override > public void run() { > System.out.println(" this: "+this); > SerializableRunnable deSerializedThis > = deserialize(serialize(this)); > System.out.println(" deSerializedThis: " > +deSerializedThis); > > SerializableRunnable runnable = runnable2; > System.out.println(" runnable: "+runnable); > SerializableRunnable deSerializedRunnable > = deserialize(serialize(runnable)); > System.out.println("deSerializedRunnable: " > +deSerializedRunnable); > } > } > public static void main(String[] args) throws Exception { > ClassLoader myCl = new MyClassLoader( > SerializedLambdaTest.class.getClassLoader() > ); > Class myCodeClass = Class.forName( > SerializedLambdaTest.class.getName()+"$MyCode", > true, > myCl > ); > Runnable myCode = (Runnable) myCodeClass.newInstance(); > myCode.run(); > } > static class MyClassLoader extends ClassLoader { > MyClassLoader(ClassLoader parent) { > super(parent); > } > @Override > protected Class loadClass(String name,boolean resolve) > throws ClassNotFoundException { > if (name.startsWith("test.")) > synchronized (getClassLoadingLock(name)) { > Class c = findLoadedClass(name); > if (c==null) > c = findClass(name); > if (resolve) > resolveClass(c); > return c; > } > else > return super.loadClass(name,resolve); > } > @Override > protected Class findClass(String name) throws > ClassNotFoundException { > String path = name.replace('.','/').concat(".class"); > try ( InputStream is = getResourceAsStream(path)) { > if (is!=null) { > byte[] bytes = is.readAllBytes(); > return defineClass(name,bytes,0,bytes.length); > } else > throw new ClassNotFoundException(name); > } catch (IOException e) { > throw new ClassNotFoundException(name,e); > } > } > } > } > From seth.lytle at gmail.com Tue Mar 26 02:16:43 2019 From: seth.lytle at gmail.com (seth lytle) Date: Mon, 25 Mar 2019 22:16:43 -0400 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> Message-ID: i haven't changed the assignment from the original test case (which was accepted as valid at the time). i haven't gone through it in depth, but assume that it's ok and used it since people are already familiar with it. it appears to me that that example uses reflection to allocate an instance using a definitive class loader and then uses a runnable for the serialization/deserialization cycle the class cast exception happens not at the example level, but deep inside `readObject` when it's doing an internal assignment perhaps my choice of words "into a new classloader" was insufficient or misleading. in both examples that i've come up with so far, the class loader calls defineClass directly without first delegating to super (for a subset of the classes). so "into a definitive classloader" might have been a better choice On Mon, Mar 25, 2019 at 9:34 PM David Holmes wrote: > Hi Seth, > > On 26/03/2019 11:22 am, seth lytle wrote: > > if a lambda is a field and captures `this`, and it's deserialized into a > > new class loader, it throws a ClassCastException. > > Not sure I follow. If you load a class into a different classloader then > you get a different type. It might appear the same to you but it is a > distinct type, so you can't assign across different instances loaded by > different classloaders. > > Cheers, > David > ----- > > > i came across this bug > > independently while writing a test, but then found an old openjdk bug > with > > a similar issue and tweaked the test case (source below). my version > > differs only in > > 1. moved the lambda to a field > > 2. reference `this` in it > > 3. uses readAllBytes instead of the internal method > > 4. formatting > > > > running with java 11 or 12 (or java 8 using a substitute for > readAllBytes) > > results in: > > this: test.SerializedLambdaTest$MyCode at 8efb846 > > deSerializedThis: test.SerializedLambdaTest$MyCode at 2b71fc7e > > runnable: > > test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > > Exception in thread "main" java.lang.ClassCastException: cannot assign > > instance of java.lang.invoke.SerializedLambda to field > > test.SerializedLambdaTest$MyCode.runnable2 of type > > test.SerializedLambdaTest$SerializableRunnable in instance of > > test.SerializedLambdaTest$MyCode > > at > > java.base/java.io > .ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > > at > > java.base/java.io > .ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > > at > > java.base/java.io > .ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > > at > > java.base/java.io > .ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > > at > > java.base/java.io > .ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > > at > > java.base/java.io > .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > at > > java.base/java.io > .ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > at > > java.base/java.io > .ObjectInputStream.readArray(ObjectInputStream.java:1993) > > at > > java.base/java.io > .ObjectInputStream.readObject0(ObjectInputStream.java:1588) > > at > > java.base/java.io > .ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > > at > > java.base/java.io > .ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > > at > > java.base/java.io > .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > at > > java.base/java.io > .ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > at > > java.base/java.io > .ObjectInputStream.readObject(ObjectInputStream.java:430) > > at > > > test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > > at test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > > at test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8008770 > > > > > > package test; > > > > import java.io.ByteArrayInputStream; > > import java.io.ByteArrayOutputStream; > > import java.io.IOException; > > import java.io.InputStream; > > import java.io.ObjectInputStream; > > import java.io.ObjectOutputStream; > > import java.io.Serializable; > > > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > > public class SerializedLambdaTest { > > public interface SerializableRunnable extends Runnable,Serializable > { > > } > > public static class MyCode implements SerializableRunnable { > > SerializableRunnable runnable2 = () > > -> { > > System.out.println("HELLO"+this.getClass()); > > }; > > private byte[] serialize(Object o) { > > ByteArrayOutputStream baos; > > try ( > > ObjectOutputStream oos > > = new ObjectOutputStream(baos = new > > ByteArrayOutputStream())) { > > oos.writeObject(o); > > } catch (IOException e) { > > throw new RuntimeException(e); > > } > > return baos.toByteArray(); > > } > > private T deserialize(byte[] bytes) { > > try ( > > ObjectInputStream ois > > = new ObjectInputStream(new > > ByteArrayInputStream(bytes))) { > > return (T) ois.readObject(); > > } catch (IOException|ClassNotFoundException e) { > > throw new RuntimeException(e); > > } > > } > > @Override > > public void run() { > > System.out.println(" this: "+this); > > SerializableRunnable deSerializedThis > > = deserialize(serialize(this)); > > System.out.println(" deSerializedThis: " > > +deSerializedThis); > > > > SerializableRunnable runnable = runnable2; > > System.out.println(" runnable: "+runnable); > > SerializableRunnable deSerializedRunnable > > = deserialize(serialize(runnable)); > > System.out.println("deSerializedRunnable: " > > +deSerializedRunnable); > > } > > } > > public static void main(String[] args) throws Exception { > > ClassLoader myCl = new MyClassLoader( > > SerializedLambdaTest.class.getClassLoader() > > ); > > Class myCodeClass = Class.forName( > > SerializedLambdaTest.class.getName()+"$MyCode", > > true, > > myCl > > ); > > Runnable myCode = (Runnable) myCodeClass.newInstance(); > > myCode.run(); > > } > > static class MyClassLoader extends ClassLoader { > > MyClassLoader(ClassLoader parent) { > > super(parent); > > } > > @Override > > protected Class loadClass(String name,boolean resolve) > > throws ClassNotFoundException { > > if (name.startsWith("test.")) > > synchronized (getClassLoadingLock(name)) { > > Class c = findLoadedClass(name); > > if (c==null) > > c = findClass(name); > > if (resolve) > > resolveClass(c); > > return c; > > } > > else > > return super.loadClass(name,resolve); > > } > > @Override > > protected Class findClass(String name) throws > > ClassNotFoundException { > > String path = name.replace('.','/').concat(".class"); > > try ( InputStream is = getResourceAsStream(path)) { > > if (is!=null) { > > byte[] bytes = is.readAllBytes(); > > return defineClass(name,bytes,0,bytes.length); > > } else > > throw new ClassNotFoundException(name); > > } catch (IOException e) { > > throw new ClassNotFoundException(name,e); > > } > > } > > } > > } > > > From david.holmes at oracle.com Tue Mar 26 02:34:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 12:34:10 +1000 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> Message-ID: <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Hi Seth, On 26/03/2019 12:16 pm, seth lytle wrote: > i haven't changed the assignment from the original test case (which was > accepted as valid at the time). i haven't gone through it in depth, but > assume that it's ok and used it since people are already familiar with > it. it appears to me that that example uses reflection to allocate an > instance using a definitive class loader and then uses a runnable for > the serialization/deserialization cycle > > the class cast exception happens not at the example level, but deep > inside `readObject` when it's doing an internal assignment > > perhaps my choice of words "into a new classloader" was insufficient or > misleading. in both examples that i've come up with so far, the class > loader calls defineClass directly without first delegating to super (for > a subset of the classes). so "into a definitive classloader" might have > been a better choice I think the basic problem is that this test loads a nested type into a different classloader to its enclosing type. I can easily imagine this messing up the code that gets generated to implement the lambda expression - but I'd need to examine that code in detail to see exactly why (others may know this more readily than I do). It's unclear to me whether this would be considered a bug or a "don't do that" situation. As of JDK 11, nested types define "nests" at the VM level (see JEP-181) and it is a requirement that all nest members be defined in the same package - which implies the same classloader. David > > > > > > On Mon, Mar 25, 2019 at 9:34 PM David Holmes > wrote: > > Hi Seth, > > On 26/03/2019 11:22 am, seth lytle wrote: > > if a lambda is a field and captures `this`, and it's deserialized > into a > > new class loader, it throws a ClassCastException. > > Not sure I follow. If you load a class into a different classloader > then > you get a different type. It might appear the same to you but it is a > distinct type, so you can't assign across different instances loaded by > different classloaders. > > Cheers, > David > ----- > > > i came across this bug > > independently while writing a test, but then found an old openjdk > bug with > > a similar issue and tweaked the test case (source below). my version > > differs only in > > 1. moved the lambda to a field > > 2. reference `this` in it > > 3. uses readAllBytes instead of the internal method > > 4. formatting > > > > running with java 11 or 12 (or java 8 using a substitute for > readAllBytes) > > results in: > >? ? ? ? ? ? ? ? ? this: test.SerializedLambdaTest$MyCode at 8efb846 > >? ? ? deSerializedThis: test.SerializedLambdaTest$MyCode at 2b71fc7e > >? ? ? ? ? ? ? runnable: > > > test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > > Exception in thread "main" java.lang.ClassCastException: cannot > assign > > instance of java.lang.invoke.SerializedLambda to field > > test.SerializedLambdaTest$MyCode.runnable2 of type > > test.SerializedLambdaTest$SerializableRunnable in instance of > > test.SerializedLambdaTest$MyCode > > at > > java.base/java.io > .ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > > at > > java.base/java.io > .ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > > at > > java.base/java.io > .ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > > at > > java.base/java.io > .ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > > at > > java.base/java.io > .ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > > at > > java.base/java.io > .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > at > > java.base/java.io > .ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > at > > java.base/java.io > .ObjectInputStream.readArray(ObjectInputStream.java:1993) > > at > > java.base/java.io > .ObjectInputStream.readObject0(ObjectInputStream.java:1588) > > at > > java.base/java.io > .ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > > at > > java.base/java.io > .ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > > at > > java.base/java.io > .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > at > > java.base/java.io > .ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > at > > java.base/java.io > .ObjectInputStream.readObject(ObjectInputStream.java:430) > > at > > > test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > > at test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > > at test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8008770 > > > > > > package test; > > > > import java.io.ByteArrayInputStream; > > import java.io.ByteArrayOutputStream; > > import java.io.IOException; > > import java.io.InputStream; > > import java.io.ObjectInputStream; > > import java.io.ObjectOutputStream; > > import java.io.Serializable; > > > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > > public class SerializedLambdaTest { > >? ? ? public interface SerializableRunnable extends > Runnable,Serializable { > >? ? ? } > >? ? ? public static class MyCode implements SerializableRunnable { > >? ? ? ? ? SerializableRunnable runnable2 = () > >? ? ? ? ? ? ? ? ? -> { > >? ? ? ? ? ? ? System.out.println("HELLO"+this.getClass()); > >? ? ? ? ? }; > >? ? ? ? ? private byte[] serialize(Object o) { > >? ? ? ? ? ? ? ByteArrayOutputStream baos; > >? ? ? ? ? ? ? try ( > >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos > >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos = new > > ByteArrayOutputStream())) { > >? ? ? ? ? ? ? ? ? oos.writeObject(o); > >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? ? ? ? ? } > >? ? ? ? ? ? ? return baos.toByteArray(); > >? ? ? ? ? } > >? ? ? ? ? private T deserialize(byte[] bytes) { > >? ? ? ? ? ? ? try ( > >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois > >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new > > ByteArrayInputStream(bytes))) { > >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); > >? ? ? ? ? ? ? } catch (IOException|ClassNotFoundException e) { > >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? ? ? ? ? } > >? ? ? ? ? } > >? ? ? ? ? @Override > >? ? ? ? ? public void run() { > >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? ? ? this: "+this); > >? ? ? ? ? ? ? SerializableRunnable deSerializedThis > >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); > >? ? ? ? ? ? ? System.out.println("? ? deSerializedThis: " > >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); > > > >? ? ? ? ? ? ? SerializableRunnable runnable = runnable2; > >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? runnable: "+runnable); > >? ? ? ? ? ? ? SerializableRunnable deSerializedRunnable > >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(runnable)); > >? ? ? ? ? ? ? System.out.println("deSerializedRunnable: " > >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); > >? ? ? ? ? } > >? ? ? } > >? ? ? public static void main(String[] args) throws Exception { > >? ? ? ? ? ClassLoader myCl = new MyClassLoader( > >? ? ? ? ? ? ? ? ? SerializedLambdaTest.class.getClassLoader() > >? ? ? ? ? ); > >? ? ? ? ? Class myCodeClass = Class.forName( > >? ? ? ? ? ? ? ? ? SerializedLambdaTest.class.getName()+"$MyCode", > >? ? ? ? ? ? ? ? ? true, > >? ? ? ? ? ? ? ? ? myCl > >? ? ? ? ? ); > >? ? ? ? ? Runnable myCode = (Runnable) myCodeClass.newInstance(); > >? ? ? ? ? myCode.run(); > >? ? ? } > >? ? ? static class MyClassLoader extends ClassLoader { > >? ? ? ? ? MyClassLoader(ClassLoader parent) { > >? ? ? ? ? ? ? super(parent); > >? ? ? ? ? } > >? ? ? ? ? @Override > >? ? ? ? ? protected Class loadClass(String name,boolean resolve) > >? ? ? ? ? ? ? ? ? throws ClassNotFoundException { > >? ? ? ? ? ? ? if (name.startsWith("test.")) > >? ? ? ? ? ? ? ? ? synchronized (getClassLoadingLock(name)) { > >? ? ? ? ? ? ? ? ? ? ? Class c = findLoadedClass(name); > >? ? ? ? ? ? ? ? ? ? ? if (c==null) > >? ? ? ? ? ? ? ? ? ? ? ? ? c = findClass(name); > >? ? ? ? ? ? ? ? ? ? ? if (resolve) > >? ? ? ? ? ? ? ? ? ? ? ? ? resolveClass(c); > >? ? ? ? ? ? ? ? ? ? ? return c; > >? ? ? ? ? ? ? ? ? } > >? ? ? ? ? ? ? else > >? ? ? ? ? ? ? ? ? return super.loadClass(name,resolve); > >? ? ? ? ? } > >? ? ? ? ? @Override > >? ? ? ? ? protected Class findClass(String name) throws > >? ? ? ? ? ? ? ? ? ClassNotFoundException { > >? ? ? ? ? ? ? String path = name.replace('.','/').concat(".class"); > >? ? ? ? ? ? ? try ( InputStream is = getResourceAsStream(path)) { > >? ? ? ? ? ? ? ? ? if (is!=null) { > >? ? ? ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); > >? ? ? ? ? ? ? ? ? ? ? return defineClass(name,bytes,0,bytes.length); > >? ? ? ? ? ? ? ? ? } else > >? ? ? ? ? ? ? ? ? ? ? throw new ClassNotFoundException(name); > >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? ? ? ? ? ? ? throw new ClassNotFoundException(name,e); > >? ? ? ? ? ? ? } > >? ? ? ? ? } > >? ? ? } > > } > > > From mandy.chung at oracle.com Tue Mar 26 02:48:21 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Mar 2019 19:48:21 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> Message-ID: <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> Hi Goetz, On 3/15/19 3:55 AM, Lindenmaier, Goetz wrote: > I followed your advice and created a JEP: > https://bugs.openjdk.java.net/browse/JDK-8220715 This is a good start.?? I include my comments as a reader who does not read TrackingStackCreator and other C++ code. In the "Basic algorithm to compute the message" section: "This dataflow analysis walks the bytecodes forward simulating the execution stack." Please elaborate it.? Given a stack trace, it starts with the most recently executed method and bytecode index, I assume it simulates the method from the beginning of the method until it hits the instruction with the matching BCI. Please describe it and also the cases when it requires to look at its caller frame. "Computing either part of these messages can fail due to insufficient information." What are the cases that it fails to obtain the information? It'd be useful to list some examples if not all. The "Different bytecode variants of a method" section This section raises the case when a method representing an execution stack frame throwing NPE becomes obsolete, it does not have the information to compute the message lazily.? So this falls into the "insufficient information" category and no improved NPE message can be generated. The "computation overhead" section I agree with the requirement to have minimal performance overhead to the NPE construction cost. "NullPointerExceptions are thrown frequently." "Fortunately, most Exceptions are discarded without looking at the message." This is interesting.? Do you have any statistic on the number of NPE thrown and swallowed on certain application/environment that you have gathered? "If the message is printed based on the backtrace, it must be omitted ?if the top frame was dropped from the backtrace." If NPE includes the hidden frames, `Throwable::getStackTrace` and `Throwable::toString` and the VM printing of NPE stack trace needs to filter the hidden frames.? I think it's appropriate for this JEP to cover rather than in a separate JBS issue. The "Message persistance" section I read this section like an implementation details.? I think this section intends to call out that the message of NPE if constructed by user code i.e. via public constructor, should not be altered including no-arg constructor or pass a null message to 1-arg constructor.? The enhanced NPE message is proposed only when NPE is thrown due to null dereference when executing bytecode. I don't understand what you tried to say about "npe.getMessage() == npe.getMessage()". Throwable::getMessage does not guarantee to return same String object for each invocation. When deserializing the class bytes may be of a different version, so StackTraceElements are serialized with its string form.? Serializing NPE with a computed message seems to be the only viable solution. The "Message content" section I think this section can break down into clear scenarios 1. debug information is present 2. debug information is absent 3. the matching version of bytecode is not available I agree that the message should be easy for Java developers including the beginners to understand the error. You bring up a good question about the exception message format e.g. whether with quotation (none vs single quote vs double quote).? It's good to have a guideline on that while this is out of scope of this JEP.? IAE was updated to include module name, loader name and improve the error message for the developers to understand the exception which is a good improvement. "Alternatives" section "The current proposal is to implement this in the Java runtime in C++ accessing ?directly the available datastructures in the metaspace." "Also, ASM and StackWalker do not support the full functionality needed. StackWalker must be called in the NullPointerException constructor." This is not true as you wrote in the subsequent sentence.? If we choose the implementation to Java, StackWalker will need to be extended to read Throwable's backtrace.? Such specialized form can provide the ability to fetch the bytecode in Method* if appropriate.? This is the implementation details.? As discussed in the email thread, another implementation choice could be a hybrid of native in the VM and Java to accomplish this task (for example fetching the bytecode of the current version could be done in the VM if we agree supporting the redefinition case). For logic that is not strictly needed to be done in the VM, doing it in Java and library is a good option to consider (putting aside the amount of new code you have to write).?? Looks like you can't evaluate the alternatives since existing library code requires work in order to prototype this in Java.? So I'd say more investigation needs to be done to decide on alternative implementation approaches. "Testing" section "The basic implementation is in use in SAP's internal Java virtual machine since 2006." This is good information.? This assumes if the same implementation goes into JDK. So this is subject to the discussion and code review.?? I think it's adequate to say unit tests will need to be developed.? I think this feature should not impact much of the existing VM code and so running existing jtreg tests, jck tests and other existing test suites should provide adequate coverage. I found [1] is quite useful to understand the scenarios this JEP considers.? I think it would be useful to include them in the JEP perhaps as examples when describing the data flow analysis.? [1] can be grouped into several categories and the JEP can just talk about the worthnoting groups and does not need to list all messages such as dereference a null receive on getfield, null array element vs null array This JEP includes a few links to the C++ functions in the current webrev.? I appreciate that and I assume they will be taken out at some point. Mandy From seth.lytle at gmail.com Tue Mar 26 03:06:28 2019 From: seth.lytle at gmail.com (seth lytle) Date: Mon, 25 Mar 2019 23:06:28 -0400 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Message-ID: i still get the same stack trace after breaking the example out into two files. does that sufficiently address the nesting issue ? file: SerializedLambdaTest package test; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; // from: https://bugs.openjdk.java.net/browse/JDK-8008770 public class SerializedLambdaTest implements Runnable { public void run() { new MyCode().run(); } public interface SerializableRunnable extends Runnable,Serializable { } public static class MyCode implements SerializableRunnable { SerializableRunnable runnable2 = () -> { System.out.println("HELLO"+this.getClass()); }; private byte[] serialize(Object o) { ByteArrayOutputStream baos; try ( ObjectOutputStream oos = new ObjectOutputStream(baos = new ByteArrayOutputStream())) { oos.writeObject(o); } catch (IOException e) { throw new RuntimeException(e); } return baos.toByteArray(); } private T deserialize(byte[] bytes) { try ( ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bytes))) { return (T) ois.readObject(); } catch (IOException|ClassNotFoundException e) { throw new RuntimeException(e); } } @Override public void run() { System.out.println(" this: "+this); SerializableRunnable deSerializedThis = deserialize(serialize(this)); System.out.println(" deSerializedThis: " +deSerializedThis); SerializableRunnable runnable = runnable2; System.out.println(" runnable: "+runnable); SerializableRunnable deSerializedRunnable = deserialize(serialize(runnable)); System.out.println("deSerializedRunnable: " +deSerializedRunnable); } } } file: MyClassLoader package test; import java.io.IOException; import java.io.InputStream; class MyClassLoader extends ClassLoader { MyClassLoader(ClassLoader parent) { super(parent); } @Override protected Class loadClass(String name,boolean resolve) throws ClassNotFoundException { if (name.startsWith("test.")) synchronized (getClassLoadingLock(name)) { Class c = findLoadedClass(name); if (c==null) c = findClass(name); if (resolve) resolveClass(c); return c; } else return super.loadClass(name,resolve); } @Override protected Class findClass(String name) throws ClassNotFoundException { String path = name.replace('.','/').concat(".class"); try (final InputStream is = getResourceAsStream(path)) { if (is!=null) { byte[] bytes = is.readAllBytes(); return defineClass(name,bytes,0,bytes.length); } else throw new ClassNotFoundException(name); } catch (IOException e) { throw new ClassNotFoundException(name,e); } } public static void main(String[] args) throws Exception { ClassLoader myCl = new MyClassLoader( MyClassLoader.class.getClassLoader() ); Class myCodeClass = Class.forName( "test.SerializedLambdaTest", true, myCl ); Runnable myCode = (Runnable) myCodeClass.newInstance(); myCode.run(); } } On Mon, Mar 25, 2019 at 10:34 PM David Holmes wrote: > Hi Seth, > > On 26/03/2019 12:16 pm, seth lytle wrote: > > i haven't changed the assignment from the original test case (which was > > accepted as valid at the time). i haven't gone through it in depth, but > > assume that it's ok and used it since people are already familiar with > > it. it appears to me that that example uses reflection to allocate an > > instance using a definitive class loader and then uses a runnable for > > the serialization/deserialization cycle > > > > the class cast exception happens not at the example level, but deep > > inside `readObject` when it's doing an internal assignment > > > > perhaps my choice of words "into a new classloader" was insufficient or > > misleading. in both examples that i've come up with so far, the class > > loader calls defineClass directly without first delegating to super (for > > a subset of the classes). so "into a definitive classloader" might have > > been a better choice > > I think the basic problem is that this test loads a nested type into a > different classloader to its enclosing type. I can easily imagine this > messing up the code that gets generated to implement the lambda > expression - but I'd need to examine that code in detail to see exactly > why (others may know this more readily than I do). It's unclear to me > whether this would be considered a bug or a "don't do that" situation. > As of JDK 11, nested types define "nests" at the VM level (see JEP-181) > and it is a requirement that all nest members be defined in the same > package - which implies the same classloader. > > David > > > > > > > > > > > > > On Mon, Mar 25, 2019 at 9:34 PM David Holmes > > wrote: > > > > Hi Seth, > > > > On 26/03/2019 11:22 am, seth lytle wrote: > > > if a lambda is a field and captures `this`, and it's deserialized > > into a > > > new class loader, it throws a ClassCastException. > > > > Not sure I follow. If you load a class into a different classloader > > then > > you get a different type. It might appear the same to you but it is a > > distinct type, so you can't assign across different instances loaded > by > > different classloaders. > > > > Cheers, > > David > > ----- > > > > > i came across this bug > > > independently while writing a test, but then found an old openjdk > > bug with > > > a similar issue and tweaked the test case (source below). my > version > > > differs only in > > > 1. moved the lambda to a field > > > 2. reference `this` in it > > > 3. uses readAllBytes instead of the internal method > > > 4. formatting > > > > > > running with java 11 or 12 (or java 8 using a substitute for > > readAllBytes) > > > results in: > > > this: test.SerializedLambdaTest$MyCode at 8efb846 > > > deSerializedThis: test.SerializedLambdaTest$MyCode at 2b71fc7e > > > runnable: > > > > > > test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > > > Exception in thread "main" java.lang.ClassCastException: cannot > > assign > > > instance of java.lang.invoke.SerializedLambda to field > > > test.SerializedLambdaTest$MyCode.runnable2 of type > > > test.SerializedLambdaTest$SerializableRunnable in instance of > > > test.SerializedLambdaTest$MyCode > > > at > > > java.base/java.io > > >.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > > > at > > > java.base/java.io > > >.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > > > at > > > java.base/java.io > > >.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > > > at > > > java.base/java.io > > >.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > > > at > > > java.base/java.io > > >.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > > > at > > > java.base/java.io > > >.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > > at > > > java.base/java.io > > >.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > > at > > > java.base/java.io > > >.ObjectInputStream.readArray(ObjectInputStream.java:1993) > > > at > > > java.base/java.io > > >.ObjectInputStream.readObject0(ObjectInputStream.java:1588) > > > at > > > java.base/java.io > > >.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > > > at > > > java.base/java.io > > >.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > > > at > > > java.base/java.io > > >.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > > at > > > java.base/java.io > > >.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > > at > > > java.base/java.io > > >.ObjectInputStream.readObject(ObjectInputStream.java:430) > > > at > > > > > > test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > > > at > test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > > > at test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8008770 > > > > > > > > > package test; > > > > > > import java.io.ByteArrayInputStream; > > > import java.io.ByteArrayOutputStream; > > > import java.io.IOException; > > > import java.io.InputStream; > > > import java.io.ObjectInputStream; > > > import java.io.ObjectOutputStream; > > > import java.io.Serializable; > > > > > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > > > public class SerializedLambdaTest { > > > public interface SerializableRunnable extends > > Runnable,Serializable { > > > } > > > public static class MyCode implements SerializableRunnable { > > > SerializableRunnable runnable2 = () > > > -> { > > > System.out.println("HELLO"+this.getClass()); > > > }; > > > private byte[] serialize(Object o) { > > > ByteArrayOutputStream baos; > > > try ( > > > ObjectOutputStream oos > > > = new ObjectOutputStream(baos = new > > > ByteArrayOutputStream())) { > > > oos.writeObject(o); > > > } catch (IOException e) { > > > throw new RuntimeException(e); > > > } > > > return baos.toByteArray(); > > > } > > > private T deserialize(byte[] bytes) { > > > try ( > > > ObjectInputStream ois > > > = new ObjectInputStream(new > > > ByteArrayInputStream(bytes))) { > > > return (T) ois.readObject(); > > > } catch (IOException|ClassNotFoundException e) { > > > throw new RuntimeException(e); > > > } > > > } > > > @Override > > > public void run() { > > > System.out.println(" this: "+this); > > > SerializableRunnable deSerializedThis > > > = deserialize(serialize(this)); > > > System.out.println(" deSerializedThis: " > > > +deSerializedThis); > > > > > > SerializableRunnable runnable = runnable2; > > > System.out.println(" runnable: > "+runnable); > > > SerializableRunnable deSerializedRunnable > > > = deserialize(serialize(runnable)); > > > System.out.println("deSerializedRunnable: " > > > +deSerializedRunnable); > > > } > > > } > > > public static void main(String[] args) throws Exception { > > > ClassLoader myCl = new MyClassLoader( > > > SerializedLambdaTest.class.getClassLoader() > > > ); > > > Class myCodeClass = Class.forName( > > > SerializedLambdaTest.class.getName()+"$MyCode", > > > true, > > > myCl > > > ); > > > Runnable myCode = (Runnable) myCodeClass.newInstance(); > > > myCode.run(); > > > } > > > static class MyClassLoader extends ClassLoader { > > > MyClassLoader(ClassLoader parent) { > > > super(parent); > > > } > > > @Override > > > protected Class loadClass(String name,boolean resolve) > > > throws ClassNotFoundException { > > > if (name.startsWith("test.")) > > > synchronized (getClassLoadingLock(name)) { > > > Class c = findLoadedClass(name); > > > if (c==null) > > > c = findClass(name); > > > if (resolve) > > > resolveClass(c); > > > return c; > > > } > > > else > > > return super.loadClass(name,resolve); > > > } > > > @Override > > > protected Class findClass(String name) throws > > > ClassNotFoundException { > > > String path = name.replace('.','/').concat(".class"); > > > try ( InputStream is = getResourceAsStream(path)) { > > > if (is!=null) { > > > byte[] bytes = is.readAllBytes(); > > > return > defineClass(name,bytes,0,bytes.length); > > > } else > > > throw new ClassNotFoundException(name); > > > } catch (IOException e) { > > > throw new ClassNotFoundException(name,e); > > > } > > > } > > > } > > > } > > > > > > From david.holmes at oracle.com Tue Mar 26 03:40:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 13:40:24 +1000 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Message-ID: On 26/03/2019 1:06 pm, seth lytle wrote: > i still get the same stack trace after breaking the example out into two > files. does that sufficiently address the nesting issue ? ?? public static class MyCode ... is still a nested class. David > file:?SerializedLambdaTest > package test; > > import java.io.ByteArrayInputStream; > import java.io.ByteArrayOutputStream; > import java.io.IOException; > import java.io.ObjectInputStream; > import java.io.ObjectOutputStream; > import java.io.Serializable; > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > public class SerializedLambdaTest implements Runnable { > ? ? public void run() { new MyCode().run(); } > ? ? public interface SerializableRunnable extends Runnable,Serializable { > ? ? } > ? ? public static class MyCode implements SerializableRunnable { > ? ? ? ? SerializableRunnable runnable2 = () > ? ? ? ? ? ? ? ? -> { > ? ? ? ? ? ? System.out.println("HELLO"+this.getClass()); > ? ? ? ? }; > ? ? ? ? private byte[] serialize(Object o) { > ? ? ? ? ? ? ByteArrayOutputStream baos; > ? ? ? ? ? ? try ( > ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos > ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos = new > ByteArrayOutputStream())) { > ? ? ? ? ? ? ? ? oos.writeObject(o); > ? ? ? ? ? ? } catch (IOException e) { > ? ? ? ? ? ? ? ? throw new RuntimeException(e); > ? ? ? ? ? ? } > ? ? ? ? ? ? return baos.toByteArray(); > ? ? ? ? } > ? ? ? ? private T deserialize(byte[] bytes) { > ? ? ? ? ? ? try ( > ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois > ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new > ByteArrayInputStream(bytes))) { > ? ? ? ? ? ? ? ? return (T) ois.readObject(); > ? ? ? ? ? ? } catch (IOException|ClassNotFoundException e) { > ? ? ? ? ? ? ? ? throw new RuntimeException(e); > ? ? ? ? ? ? } > ? ? ? ? } > ? ? ? ? @Override > ? ? ? ? public void run() { > ? ? ? ? ? ? System.out.println("? ? ? ? ? ? ? ? this: "+this); > ? ? ? ? ? ? SerializableRunnable deSerializedThis > ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); > ? ? ? ? ? ? System.out.println("? ? deSerializedThis: " > ? ? ? ? ? ? ? ? ? ? +deSerializedThis); > > ? ? ? ? ? ? SerializableRunnable runnable = runnable2; > ? ? ? ? ? ? System.out.println("? ? ? ? ? ? runnable: "+runnable); > ? ? ? ? ? ? SerializableRunnable deSerializedRunnable > ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(runnable)); > ? ? ? ? ? ? System.out.println("deSerializedRunnable: " > ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); > ? ? ? ? } > ? ? } > } > > > file:?MyClassLoader > package test; > > import java.io.IOException; > import java.io.InputStream; > > class MyClassLoader extends ClassLoader { > ? ? MyClassLoader(ClassLoader parent) { > ? ? ? ? super(parent); > ? ? } > ? ? @Override > ? ? protected Class loadClass(String name,boolean resolve) throws > ClassNotFoundException { > ? ? ? ? if (name.startsWith("test.")) > ? ? ? ? ? ? synchronized (getClassLoadingLock(name)) { > ? ? ? ? ? ? ? ? Class c = findLoadedClass(name); > ? ? ? ? ? ? ? ? if (c==null) c = findClass(name); > ? ? ? ? ? ? ? ? if (resolve) resolveClass(c); > ? ? ? ? ? ? ? ? return c; > ? ? ? ? ? ? } > ? ? ? ? else return super.loadClass(name,resolve); > ? ? } > ? ? @Override > ? ? protected Class findClass(String name) throws > ClassNotFoundException { > ? ? ? ? String path = name.replace('.','/').concat(".class"); > ? ? ? ? try (final InputStream is = getResourceAsStream(path)) { > ? ? ? ? ? ? if (is!=null) { > ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); > ? ? ? ? ? ? ? ? return defineClass(name,bytes,0,bytes.length); > ? ? ? ? ? ? } > ? ? ? ? ? ? else throw new ClassNotFoundException(name); > ? ? ? ? } catch (IOException e) { > ? ? ? ? ? ? throw new ClassNotFoundException(name,e); > ? ? ? ? } > ? ? } > ? ? public static void main(String[] args) throws Exception { > ? ? ? ? ClassLoader myCl = new MyClassLoader( > ? ? ? ? ? ? ? ? MyClassLoader.class.getClassLoader() > ? ? ? ? ); > ? ? ? ? Class myCodeClass = Class.forName( > ? ? ? ? ? ? ? ? "test.SerializedLambdaTest", > ? ? ? ? ? ? ? ? true, > ? ? ? ? ? ? ? ? myCl > ? ? ? ? ); > ? ? ? ? Runnable myCode = (Runnable) myCodeClass.newInstance(); > ? ? ? ? myCode.run(); > ? ? } > } > > > > > On Mon, Mar 25, 2019 at 10:34 PM David Holmes > wrote: > > Hi Seth, > > On 26/03/2019 12:16 pm, seth lytle wrote: > > i haven't changed the assignment from the original test case > (which was > > accepted as valid at the time). i haven't gone through it in > depth, but > > assume that it's ok and used it since people are already familiar > with > > it. it appears to me that that example uses reflection to > allocate an > > instance using a definitive class loader and then uses a runnable > for > > the serialization/deserialization cycle > > > > the class cast exception happens not at the example level, but deep > > inside `readObject` when it's doing an internal assignment > > > > perhaps my choice of words "into a new classloader" was > insufficient or > > misleading. in both examples that i've come up with so far, the > class > > loader calls defineClass directly without first delegating to > super (for > > a subset of the classes). so "into a definitive classloader" > might have > > been a better choice > > I think the basic problem is that this test loads a nested type into a > different classloader to its enclosing type. I can easily imagine this > messing up the code that gets generated to implement the lambda > expression - but I'd need to examine that code in detail to see exactly > why (others may know this more readily than I do). It's unclear to me > whether this would be considered a bug or a "don't do that" situation. > As of JDK 11, nested types define "nests" at the VM level (see JEP-181) > and it is a requirement that all nest members be defined in the same > package - which implies the same classloader. > > David > > > > > > > > > > > > > On Mon, Mar 25, 2019 at 9:34 PM David Holmes > > > >> wrote: > > > >? ? ?Hi Seth, > > > >? ? ?On 26/03/2019 11:22 am, seth lytle wrote: > >? ? ? > if a lambda is a field and captures `this`, and it's > deserialized > >? ? ?into a > >? ? ? > new class loader, it throws a ClassCastException. > > > >? ? ?Not sure I follow. If you load a class into a different > classloader > >? ? ?then > >? ? ?you get a different type. It might appear the same to you but > it is a > >? ? ?distinct type, so you can't assign across different instances > loaded by > >? ? ?different classloaders. > > > >? ? ?Cheers, > >? ? ?David > >? ? ?----- > > > >? ? ? > i came across this bug > >? ? ? > independently while writing a test, but then found an old > openjdk > >? ? ?bug with > >? ? ? > a similar issue and tweaked the test case (source below). > my version > >? ? ? > differs only in > >? ? ? > 1. moved the lambda to a field > >? ? ? > 2. reference `this` in it > >? ? ? > 3. uses readAllBytes instead of the internal method > >? ? ? > 4. formatting > >? ? ? > > >? ? ? > running with java 11 or 12 (or java 8 using a substitute for > >? ? ?readAllBytes) > >? ? ? > results in: > >? ? ? >? ? ? ? ? ? ? ? ? this: > test.SerializedLambdaTest$MyCode at 8efb846 > >? ? ? >? ? ? deSerializedThis: > test.SerializedLambdaTest$MyCode at 2b71fc7e > >? ? ? >? ? ? ? ? ? ? runnable: > >? ? ? > > > > ?test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > >? ? ? > Exception in thread "main" java.lang.ClassCastException: > cannot > >? ? ?assign > >? ? ? > instance of java.lang.invoke.SerializedLambda to field > >? ? ? > test.SerializedLambdaTest$MyCode.runnable2 of type > >? ? ? > test.SerializedLambdaTest$SerializableRunnable in instance of > >? ? ? > test.SerializedLambdaTest$MyCode > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readArray(ObjectInputStream.java:1993) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readObject0(ObjectInputStream.java:1588) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > >? ? ? > at > >? ? ? > java.base/java.io > > > ?.ObjectInputStream.readObject(ObjectInputStream.java:430) > >? ? ? > at > >? ? ? > > > > ?test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > >? ? ? > at > test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > >? ? ? > at > test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8008770 > >? ? ? > > >? ? ? > > >? ? ? > package test; > >? ? ? > > >? ? ? > import java.io.ByteArrayInputStream; > >? ? ? > import java.io.ByteArrayOutputStream; > >? ? ? > import java.io.IOException; > >? ? ? > import java.io.InputStream; > >? ? ? > import java.io.ObjectInputStream; > >? ? ? > import java.io.ObjectOutputStream; > >? ? ? > import java.io.Serializable; > >? ? ? > > >? ? ? > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > >? ? ? > public class SerializedLambdaTest { > >? ? ? >? ? ? public interface SerializableRunnable extends > >? ? ?Runnable,Serializable { > >? ? ? >? ? ? } > >? ? ? >? ? ? public static class MyCode implements > SerializableRunnable { > >? ? ? >? ? ? ? ? SerializableRunnable runnable2 = () > >? ? ? >? ? ? ? ? ? ? ? ? -> { > >? ? ? >? ? ? ? ? ? ? System.out.println("HELLO"+this.getClass()); > >? ? ? >? ? ? ? ? }; > >? ? ? >? ? ? ? ? private byte[] serialize(Object o) { > >? ? ? >? ? ? ? ? ? ? ByteArrayOutputStream baos; > >? ? ? >? ? ? ? ? ? ? try ( > >? ? ? >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos > >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos = new > >? ? ? > ByteArrayOutputStream())) { > >? ? ? >? ? ? ? ? ? ? ? ? oos.writeObject(o); > >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? >? ? ? ? ? ? ? } > >? ? ? >? ? ? ? ? ? ? return baos.toByteArray(); > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? ? ? private T deserialize(byte[] bytes) { > >? ? ? >? ? ? ? ? ? ? try ( > >? ? ? >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois > >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new > >? ? ? > ByteArrayInputStream(bytes))) { > >? ? ? >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); > >? ? ? >? ? ? ? ? ? ? } catch (IOException|ClassNotFoundException e) { > >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? >? ? ? ? ? ? ? } > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? ? ? @Override > >? ? ? >? ? ? ? ? public void run() { > >? ? ? >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? ? ? this: > "+this); > >? ? ? >? ? ? ? ? ? ? SerializableRunnable deSerializedThis > >? ? ? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); > >? ? ? >? ? ? ? ? ? ? System.out.println("? ? deSerializedThis: " > >? ? ? >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); > >? ? ? > > >? ? ? >? ? ? ? ? ? ? SerializableRunnable runnable = runnable2; > >? ? ? >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? runnable: > "+runnable); > >? ? ? >? ? ? ? ? ? ? SerializableRunnable deSerializedRunnable > >? ? ? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(runnable)); > >? ? ? >? ? ? ? ? ? ? System.out.println("deSerializedRunnable: " > >? ? ? >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? } > >? ? ? >? ? ? public static void main(String[] args) throws Exception { > >? ? ? >? ? ? ? ? ClassLoader myCl = new MyClassLoader( > >? ? ? >? ? ? ? ? ? ? ? ? SerializedLambdaTest.class.getClassLoader() > >? ? ? >? ? ? ? ? ); > >? ? ? >? ? ? ? ? Class myCodeClass = Class.forName( > >? ? ? > > SerializedLambdaTest.class.getName()+"$MyCode", > >? ? ? >? ? ? ? ? ? ? ? ? true, > >? ? ? >? ? ? ? ? ? ? ? ? myCl > >? ? ? >? ? ? ? ? ); > >? ? ? >? ? ? ? ? Runnable myCode = (Runnable) > myCodeClass.newInstance(); > >? ? ? >? ? ? ? ? myCode.run(); > >? ? ? >? ? ? } > >? ? ? >? ? ? static class MyClassLoader extends ClassLoader { > >? ? ? >? ? ? ? ? MyClassLoader(ClassLoader parent) { > >? ? ? >? ? ? ? ? ? ? super(parent); > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? ? ? @Override > >? ? ? >? ? ? ? ? protected Class loadClass(String name,boolean > resolve) > >? ? ? >? ? ? ? ? ? ? ? ? throws ClassNotFoundException { > >? ? ? >? ? ? ? ? ? ? if (name.startsWith("test.")) > >? ? ? >? ? ? ? ? ? ? ? ? synchronized (getClassLoadingLock(name)) { > >? ? ? >? ? ? ? ? ? ? ? ? ? ? Class c = findLoadedClass(name); > >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (c==null) > >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? c = findClass(name); > >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (resolve) > >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? resolveClass(c); > >? ? ? >? ? ? ? ? ? ? ? ? ? ? return c; > >? ? ? >? ? ? ? ? ? ? ? ? } > >? ? ? >? ? ? ? ? ? ? else > >? ? ? >? ? ? ? ? ? ? ? ? return super.loadClass(name,resolve); > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? ? ? @Override > >? ? ? >? ? ? ? ? protected Class findClass(String name) throws > >? ? ? >? ? ? ? ? ? ? ? ? ClassNotFoundException { > >? ? ? >? ? ? ? ? ? ? String path = > name.replace('.','/').concat(".class"); > >? ? ? >? ? ? ? ? ? ? try ( InputStream is = > getResourceAsStream(path)) { > >? ? ? >? ? ? ? ? ? ? ? ? if (is!=null) { > >? ? ? >? ? ? ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); > >? ? ? >? ? ? ? ? ? ? ? ? ? ? return > defineClass(name,bytes,0,bytes.length); > >? ? ? >? ? ? ? ? ? ? ? ? } else > >? ? ? >? ? ? ? ? ? ? ? ? ? ? throw new ClassNotFoundException(name); > >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? >? ? ? ? ? ? ? ? ? throw new ClassNotFoundException(name,e); > >? ? ? >? ? ? ? ? ? ? } > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? } > >? ? ? > } > >? ? ? > > > > From mandy.chung at oracle.com Tue Mar 26 03:51:29 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Mar 2019 20:51:29 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: On 3/25/19 11:36 AM, Adam Farley8 wrote: > Addendum: URL for new webrev: > http://cr.openjdk.java.net/~afarley/8216558.1/webrev/ Thanks for sending a versioned webrev. > > What is a USA test? > > UNREFLECT_SETTER_ACCESSIBLE. > > I was trying to be brief, and I lost readability. > > Will re-upload with the expanded name. > > > > > Why the assertion becomes conditional? > > Because we only need this check if the test is USA. > > Previously, setting a variable as accessible gave us a setter without > errors 100% of the time. > > The test expects this, and anticipates an empty list of variables > which threw errors when passed to unreflectSetter. > > Since we now throw an exception when calling the unreflectSetter > method, even when the variable is accessible, this check ensures that > the only variables throwing an exception are the static final fields. > > > > > Have you considered another way doing it? > > Yep, several. This seemed the simplest. > > Other options I considered were: > > -------------- > > 1) Changing the test to store a list of variables, rather than just > their names, so the "isAccessible" method could be used instead. > > Discarded because it makes the array compare slower for every test. > > 2) Editing the array of anticipated excludeds during test execution, > to remove the exceptions we don't expect to see. > > Discarded because the change seemed too bulky to accommodate a single > test. > > 3) Make the "isAccessible" methods smarter, and rely on them > exclusively to determine the list of anticipated exceptions. > > Ditto > > --------------------- > > Option 3 could work. I prefer the one-liner stream check. > > Thoughts? Each test case has a set of inaccessible fields under normal access checks. For MH_UNREFLECT_GETTER_ACCESSIBLE and MH_UNREFLECT_SETTER_ACCESSIBLE cases, before the patch, all fields are accessible as setAccessible(true) is called on all fields.? That's the special casing for these cases and expect actualFieldNames is empty. This patch now changes the set of inaccessible fields for unreflectSetter (static final fields are inaccessible).? A cleaner way to fix this is to filter a given set of inaccessible fields and return the set of inaccessible fields applicable to a FieldLookup case. Attached is my suggested patch.? It adds a new FieldLookup::inaccessibeFields method and the XXX_ACCESSIBLE Lookup overrides it to do the filtering. Mandy diff --git a/test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java b/test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java --- a/test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java +++ b/test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java @@ -22,7 +22,7 @@ ? */ ?/* @test - * @bug 8152645 + * @bug 8152645 8216558 ? * @summary test field lookup accessibility of MethodHandles and VarHandles ? * @compile TestFieldLookupAccessibility.java ? *????????? pkg/A.java pkg/B_extends_A.java pkg/C.java @@ -96,6 +96,12 @@ ???????????? Object lookup(MethodHandles.Lookup l, Field f) throws Exception { ???????????????? return l.unreflectGetter(cloneAndSetAccessible(f)); ???????????? } + +??????????? // Setting the accessibility bit of a Field grants access under +??????????? // all conditions for MethodHandler getters +??????????? Set inaccessibleFields(Set inaccessibleFields) { +??????????????? return new HashSet<>(); +??????????? } ???????? }, ???????? MH_UNREFLECT_SETTER() { ???????????? Object lookup(MethodHandles.Lookup l, Field f) throws Exception { @@ -103,13 +109,25 @@ ???????????? } ???????????? boolean isAccessible(Field f) { -??????????????? return f.isAccessible() || !Modifier.isFinal(f.getModifiers()); +??????????????? return f.isAccessible() && !Modifier.isStatic(f.getModifiers()) || !Modifier.isFinal(f.getModifiers()); ???????????? } ???????? }, ???????? MH_UNREFLECT_SETTER_ACCESSIBLE() { ???????????? Object lookup(MethodHandles.Lookup l, Field f) throws Exception { ???????????????? return l.unreflectSetter(cloneAndSetAccessible(f)); ???????????? } + +??????????? boolean isAccessible(Field f) { +??????????????? return !(Modifier.isStatic(f.getModifiers()) && Modifier.isFinal(f.getModifiers())); +??????????? } + +??????????? // Setting the accessibility bit of a Field grants access to non-static +??????????? // final fields for MethodHandler setters +??????????? Set inaccessibleFields(Set inaccessibleFields) { +??????????????? Set result = new HashSet<>(); +??????????????? inaccessibleFields.stream().filter(f -> f.contains("_static_")).forEach(result::add); +??????????????? return result; +??????????? } ???????? }, ???????? VH() { ???????????? Object lookup(MethodHandles.Lookup l, Field f) throws Exception { @@ -142,6 +160,10 @@ ???????????? return true; ???????? } +??????? Set inaccessibleFields(Set inaccessibleFields) { +??????????? return new HashSet<>(inaccessibleFields); +??????? } + ???????? static Field cloneAndSetAccessible(Field f) throws Exception { ???????????? // Clone to avoid mutating source field ???????????? f = f.getDeclaringClass().getDeclaredField(f.getName()); @@ -180,7 +202,7 @@ ???? @Test(dataProvider = "lookupProvider") ???? public void test(FieldLookup fl, Class src, MethodHandles.Lookup l, Set inaccessibleFields) { ???????? // Add to the expected failures all inaccessible fields due to accessibility modifiers -??????? Set expected = new HashSet<>(inaccessibleFields); +??????? Set expected = fl.inaccessibleFields(inaccessibleFields); ???????? Map actual = new HashMap<>(); ???????? for (Field f : fields(src)) { @@ -203,12 +225,9 @@ ???????? if (!actualFieldNames.equals(expected)) { ???????????? if (actualFieldNames.isEmpty()) { ???????????????? // Setting the accessibility bit of a Field grants access under -??????????????? // all conditions for MethodHander getters and setters -??????????????? if (fl != FieldLookup.MH_UNREFLECT_GETTER_ACCESSIBLE && -??????????????????? fl != FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE) { +??????????????? // all conditions for MethodHandler getters ???????????????????? Assert.assertEquals(actualFieldNames, expected, "No accessibility failures:"); ???????????????? } -??????????? } ???????????? else { ???????????????? Assert.assertEquals(actualFieldNames, expected, "Accessibility failures differ:"); ???????????? } From seth.lytle at gmail.com Tue Mar 26 04:03:41 2019 From: seth.lytle at gmail.com (seth lytle) Date: Tue, 26 Mar 2019 00:03:41 -0400 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Message-ID: it's a nested class, but it's loaded with the same class loader as the toplevel. which is what i thought you thought was the problem when you wrote: > this test loads a nested type into a different classloader to its enclosing type and: > it is a requirement that all nest members be defined in the same > package - which implies the same classloader On Mon, Mar 25, 2019 at 11:40 PM David Holmes wrote: > On 26/03/2019 1:06 pm, seth lytle wrote: > > i still get the same stack trace after breaking the example out into two > > files. does that sufficiently address the nesting issue ? > > ?? > > public static class MyCode ... > > is still a nested class. > > David > > > file: SerializedLambdaTest > > package test; > > > > import java.io.ByteArrayInputStream; > > import java.io.ByteArrayOutputStream; > > import java.io.IOException; > > import java.io.ObjectInputStream; > > import java.io.ObjectOutputStream; > > import java.io.Serializable; > > > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > > public class SerializedLambdaTest implements Runnable { > > public void run() { new MyCode().run(); } > > public interface SerializableRunnable extends Runnable,Serializable > { > > } > > public static class MyCode implements SerializableRunnable { > > SerializableRunnable runnable2 = () > > -> { > > System.out.println("HELLO"+this.getClass()); > > }; > > private byte[] serialize(Object o) { > > ByteArrayOutputStream baos; > > try ( > > ObjectOutputStream oos > > = new ObjectOutputStream(baos = new > > ByteArrayOutputStream())) { > > oos.writeObject(o); > > } catch (IOException e) { > > throw new RuntimeException(e); > > } > > return baos.toByteArray(); > > } > > private T deserialize(byte[] bytes) { > > try ( > > ObjectInputStream ois > > = new ObjectInputStream(new > > ByteArrayInputStream(bytes))) { > > return (T) ois.readObject(); > > } catch (IOException|ClassNotFoundException e) { > > throw new RuntimeException(e); > > } > > } > > @Override > > public void run() { > > System.out.println(" this: "+this); > > SerializableRunnable deSerializedThis > > = deserialize(serialize(this)); > > System.out.println(" deSerializedThis: " > > +deSerializedThis); > > > > SerializableRunnable runnable = runnable2; > > System.out.println(" runnable: "+runnable); > > SerializableRunnable deSerializedRunnable > > = deserialize(serialize(runnable)); > > System.out.println("deSerializedRunnable: " > > +deSerializedRunnable); > > } > > } > > } > > > > > > file: MyClassLoader > > package test; > > > > import java.io.IOException; > > import java.io.InputStream; > > > > class MyClassLoader extends ClassLoader { > > MyClassLoader(ClassLoader parent) { > > super(parent); > > } > > @Override > > protected Class loadClass(String name,boolean resolve) throws > > ClassNotFoundException { > > if (name.startsWith("test.")) > > synchronized (getClassLoadingLock(name)) { > > Class c = findLoadedClass(name); > > if (c==null) c = findClass(name); > > if (resolve) resolveClass(c); > > return c; > > } > > else return super.loadClass(name,resolve); > > } > > @Override > > protected Class findClass(String name) throws > > ClassNotFoundException { > > String path = name.replace('.','/').concat(".class"); > > try (final InputStream is = getResourceAsStream(path)) { > > if (is!=null) { > > byte[] bytes = is.readAllBytes(); > > return defineClass(name,bytes,0,bytes.length); > > } > > else throw new ClassNotFoundException(name); > > } catch (IOException e) { > > throw new ClassNotFoundException(name,e); > > } > > } > > public static void main(String[] args) throws Exception { > > ClassLoader myCl = new MyClassLoader( > > MyClassLoader.class.getClassLoader() > > ); > > Class myCodeClass = Class.forName( > > "test.SerializedLambdaTest", > > true, > > myCl > > ); > > Runnable myCode = (Runnable) myCodeClass.newInstance(); > > myCode.run(); > > } > > } > > > > > > > > > > On Mon, Mar 25, 2019 at 10:34 PM David Holmes > > wrote: > > > > Hi Seth, > > > > On 26/03/2019 12:16 pm, seth lytle wrote: > > > i haven't changed the assignment from the original test case > > (which was > > > accepted as valid at the time). i haven't gone through it in > > depth, but > > > assume that it's ok and used it since people are already familiar > > with > > > it. it appears to me that that example uses reflection to > > allocate an > > > instance using a definitive class loader and then uses a runnable > > for > > > the serialization/deserialization cycle > > > > > > the class cast exception happens not at the example level, but > deep > > > inside `readObject` when it's doing an internal assignment > > > > > > perhaps my choice of words "into a new classloader" was > > insufficient or > > > misleading. in both examples that i've come up with so far, the > > class > > > loader calls defineClass directly without first delegating to > > super (for > > > a subset of the classes). so "into a definitive classloader" > > might have > > > been a better choice > > > > I think the basic problem is that this test loads a nested type into > a > > different classloader to its enclosing type. I can easily imagine > this > > messing up the code that gets generated to implement the lambda > > expression - but I'd need to examine that code in detail to see > exactly > > why (others may know this more readily than I do). It's unclear to me > > whether this would be considered a bug or a "don't do that" > situation. > > As of JDK 11, nested types define "nests" at the VM level (see > JEP-181) > > and it is a requirement that all nest members be defined in the same > > package - which implies the same classloader. > > > > David > > > > > > > > > > > > > > > > > > > > On Mon, Mar 25, 2019 at 9:34 PM David Holmes > > > > > > >> wrote: > > > > > > Hi Seth, > > > > > > On 26/03/2019 11:22 am, seth lytle wrote: > > > > if a lambda is a field and captures `this`, and it's > > deserialized > > > into a > > > > new class loader, it throws a ClassCastException. > > > > > > Not sure I follow. If you load a class into a different > > classloader > > > then > > > you get a different type. It might appear the same to you but > > it is a > > > distinct type, so you can't assign across different instances > > loaded by > > > different classloaders. > > > > > > Cheers, > > > David > > > ----- > > > > > > > i came across this bug > > > > independently while writing a test, but then found an old > > openjdk > > > bug with > > > > a similar issue and tweaked the test case (source below). > > my version > > > > differs only in > > > > 1. moved the lambda to a field > > > > 2. reference `this` in it > > > > 3. uses readAllBytes instead of the internal method > > > > 4. formatting > > > > > > > > running with java 11 or 12 (or java 8 using a substitute > for > > > readAllBytes) > > > > results in: > > > > this: > > test.SerializedLambdaTest$MyCode at 8efb846 > > > > deSerializedThis: > > test.SerializedLambdaTest$MyCode at 2b71fc7e > > > > runnable: > > > > > > > > > > test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > > > > Exception in thread "main" java.lang.ClassCastException: > > cannot > > > assign > > > > instance of java.lang.invoke.SerializedLambda to field > > > > test.SerializedLambdaTest$MyCode.runnable2 of type > > > > test.SerializedLambdaTest$SerializableRunnable in instance > of > > > > test.SerializedLambdaTest$MyCode > > > > at > > > > java.base/java.io > > > > > >.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > > > > at > > > > java.base/java.io > > > > > >.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > > > > at > > > > java.base/java.io > > > > > >.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readArray(ObjectInputStream.java:1993) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readObject0(ObjectInputStream.java:1588) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > > > > at > > > > java.base/java.io > > > > > >.ObjectInputStream.readObject(ObjectInputStream.java:430) > > > > at > > > > > > > > > > test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > > > > at > > test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > > > > at > > test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > > > > > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8008770 > > > > > > > > > > > > package test; > > > > > > > > import java.io.ByteArrayInputStream; > > > > import java.io.ByteArrayOutputStream; > > > > import java.io.IOException; > > > > import java.io.InputStream; > > > > import java.io.ObjectInputStream; > > > > import java.io.ObjectOutputStream; > > > > import java.io.Serializable; > > > > > > > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > > > > public class SerializedLambdaTest { > > > > public interface SerializableRunnable extends > > > Runnable,Serializable { > > > > } > > > > public static class MyCode implements > > SerializableRunnable { > > > > SerializableRunnable runnable2 = () > > > > -> { > > > > System.out.println("HELLO"+this.getClass()); > > > > }; > > > > private byte[] serialize(Object o) { > > > > ByteArrayOutputStream baos; > > > > try ( > > > > ObjectOutputStream oos > > > > = new ObjectOutputStream(baos = new > > > > ByteArrayOutputStream())) { > > > > oos.writeObject(o); > > > > } catch (IOException e) { > > > > throw new RuntimeException(e); > > > > } > > > > return baos.toByteArray(); > > > > } > > > > private T deserialize(byte[] bytes) { > > > > try ( > > > > ObjectInputStream ois > > > > = new ObjectInputStream(new > > > > ByteArrayInputStream(bytes))) { > > > > return (T) ois.readObject(); > > > > } catch (IOException|ClassNotFoundException > e) { > > > > throw new RuntimeException(e); > > > > } > > > > } > > > > @Override > > > > public void run() { > > > > System.out.println(" this: > > "+this); > > > > SerializableRunnable deSerializedThis > > > > = deserialize(serialize(this)); > > > > System.out.println(" deSerializedThis: " > > > > +deSerializedThis); > > > > > > > > SerializableRunnable runnable = runnable2; > > > > System.out.println(" runnable: > > "+runnable); > > > > SerializableRunnable deSerializedRunnable > > > > = deserialize(serialize(runnable)); > > > > System.out.println("deSerializedRunnable: " > > > > +deSerializedRunnable); > > > > } > > > > } > > > > public static void main(String[] args) throws > Exception { > > > > ClassLoader myCl = new MyClassLoader( > > > > > SerializedLambdaTest.class.getClassLoader() > > > > ); > > > > Class myCodeClass = Class.forName( > > > > > > SerializedLambdaTest.class.getName()+"$MyCode", > > > > true, > > > > myCl > > > > ); > > > > Runnable myCode = (Runnable) > > myCodeClass.newInstance(); > > > > myCode.run(); > > > > } > > > > static class MyClassLoader extends ClassLoader { > > > > MyClassLoader(ClassLoader parent) { > > > > super(parent); > > > > } > > > > @Override > > > > protected Class loadClass(String name,boolean > > resolve) > > > > throws ClassNotFoundException { > > > > if (name.startsWith("test.")) > > > > synchronized (getClassLoadingLock(name)) { > > > > Class c = findLoadedClass(name); > > > > if (c==null) > > > > c = findClass(name); > > > > if (resolve) > > > > resolveClass(c); > > > > return c; > > > > } > > > > else > > > > return super.loadClass(name,resolve); > > > > } > > > > @Override > > > > protected Class findClass(String name) throws > > > > ClassNotFoundException { > > > > String path = > > name.replace('.','/').concat(".class"); > > > > try ( InputStream is = > > getResourceAsStream(path)) { > > > > if (is!=null) { > > > > byte[] bytes = is.readAllBytes(); > > > > return > > defineClass(name,bytes,0,bytes.length); > > > > } else > > > > throw new > ClassNotFoundException(name); > > > > } catch (IOException e) { > > > > throw new ClassNotFoundException(name,e); > > > > } > > > > } > > > > } > > > > } > > > > > > > > > > From david.holmes at oracle.com Tue Mar 26 04:08:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 14:08:51 +1000 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Message-ID: On 26/03/2019 2:03 pm, seth lytle wrote: > it's a nested class, but it's loaded with the same class loader as the > toplevel. which is what i thought you thought was the problem when Sorry, hard to see all the diffs inside the email. Not sure what relevance splitting into two files has given the main change was to load the enclosing class in the new loader rather than the nested class. Anyway, yes this gets rid of the "nested class in a different classloader" problem. I'll take a look and see what's getting generated under the hood. David ----- > you wrote: > > this test loads a nested type into a different classloader to its > enclosing type > > and: > > it is a requirement that all nest members be defined in the same > > package - which implies the same classloader > > > > > On Mon, Mar 25, 2019 at 11:40 PM David Holmes > wrote: > > On 26/03/2019 1:06 pm, seth lytle wrote: > > i still get the same stack trace after breaking the example out > into two > > files. does that sufficiently address the nesting issue ? > > ?? > > ? ? ?public static class MyCode ... > > is still a nested class. > > David > > > file:?SerializedLambdaTest > > package test; > > > > import java.io.ByteArrayInputStream; > > import java.io.ByteArrayOutputStream; > > import java.io.IOException; > > import java.io.ObjectInputStream; > > import java.io.ObjectOutputStream; > > import java.io.Serializable; > > > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > > public class SerializedLambdaTest implements Runnable { > >? ? ? public void run() { new MyCode().run(); } > >? ? ? public interface SerializableRunnable extends > Runnable,Serializable { > >? ? ? } > >? ? ? public static class MyCode implements SerializableRunnable { > >? ? ? ? ? SerializableRunnable runnable2 = () > >? ? ? ? ? ? ? ? ? -> { > >? ? ? ? ? ? ? System.out.println("HELLO"+this.getClass()); > >? ? ? ? ? }; > >? ? ? ? ? private byte[] serialize(Object o) { > >? ? ? ? ? ? ? ByteArrayOutputStream baos; > >? ? ? ? ? ? ? try ( > >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos > >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos = new > > ByteArrayOutputStream())) { > >? ? ? ? ? ? ? ? ? oos.writeObject(o); > >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? ? ? ? ? } > >? ? ? ? ? ? ? return baos.toByteArray(); > >? ? ? ? ? } > >? ? ? ? ? private T deserialize(byte[] bytes) { > >? ? ? ? ? ? ? try ( > >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois > >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new > > ByteArrayInputStream(bytes))) { > >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); > >? ? ? ? ? ? ? } catch (IOException|ClassNotFoundException e) { > >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? ? ? ? ? } > >? ? ? ? ? } > >? ? ? ? ? @Override > >? ? ? ? ? public void run() { > >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? ? ? this: "+this); > >? ? ? ? ? ? ? SerializableRunnable deSerializedThis > >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); > >? ? ? ? ? ? ? System.out.println("? ? deSerializedThis: " > >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); > > > >? ? ? ? ? ? ? SerializableRunnable runnable = runnable2; > >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? runnable: "+runnable); > >? ? ? ? ? ? ? SerializableRunnable deSerializedRunnable > >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(runnable)); > >? ? ? ? ? ? ? System.out.println("deSerializedRunnable: " > >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); > >? ? ? ? ? } > >? ? ? } > > } > > > > > > file:?MyClassLoader > > package test; > > > > import java.io.IOException; > > import java.io.InputStream; > > > > class MyClassLoader extends ClassLoader { > >? ? ? MyClassLoader(ClassLoader parent) { > >? ? ? ? ? super(parent); > >? ? ? } > >? ? ? @Override > >? ? ? protected Class loadClass(String name,boolean resolve) > throws > > ClassNotFoundException { > >? ? ? ? ? if (name.startsWith("test.")) > >? ? ? ? ? ? ? synchronized (getClassLoadingLock(name)) { > >? ? ? ? ? ? ? ? ? Class c = findLoadedClass(name); > >? ? ? ? ? ? ? ? ? if (c==null) c = findClass(name); > >? ? ? ? ? ? ? ? ? if (resolve) resolveClass(c); > >? ? ? ? ? ? ? ? ? return c; > >? ? ? ? ? ? ? } > >? ? ? ? ? else return super.loadClass(name,resolve); > >? ? ? } > >? ? ? @Override > >? ? ? protected Class findClass(String name) throws > > ClassNotFoundException { > >? ? ? ? ? String path = name.replace('.','/').concat(".class"); > >? ? ? ? ? try (final InputStream is = getResourceAsStream(path)) { > >? ? ? ? ? ? ? if (is!=null) { > >? ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); > >? ? ? ? ? ? ? ? ? return defineClass(name,bytes,0,bytes.length); > >? ? ? ? ? ? ? } > >? ? ? ? ? ? ? else throw new ClassNotFoundException(name); > >? ? ? ? ? } catch (IOException e) { > >? ? ? ? ? ? ? throw new ClassNotFoundException(name,e); > >? ? ? ? ? } > >? ? ? } > >? ? ? public static void main(String[] args) throws Exception { > >? ? ? ? ? ClassLoader myCl = new MyClassLoader( > >? ? ? ? ? ? ? ? ? MyClassLoader.class.getClassLoader() > >? ? ? ? ? ); > >? ? ? ? ? Class myCodeClass = Class.forName( > >? ? ? ? ? ? ? ? ? "test.SerializedLambdaTest", > >? ? ? ? ? ? ? ? ? true, > >? ? ? ? ? ? ? ? ? myCl > >? ? ? ? ? ); > >? ? ? ? ? Runnable myCode = (Runnable) myCodeClass.newInstance(); > >? ? ? ? ? myCode.run(); > >? ? ? } > > } > > > > > > > > > > On Mon, Mar 25, 2019 at 10:34 PM David Holmes > > > >> wrote: > > > >? ? ?Hi Seth, > > > >? ? ?On 26/03/2019 12:16 pm, seth lytle wrote: > >? ? ? > i haven't changed the assignment from the original test case > >? ? ?(which was > >? ? ? > accepted as valid at the time). i haven't gone through it in > >? ? ?depth, but > >? ? ? > assume that it's ok and used it since people are already > familiar > >? ? ?with > >? ? ? > it. it appears to me that that example uses reflection to > >? ? ?allocate an > >? ? ? > instance using a definitive class loader and then uses a > runnable > >? ? ?for > >? ? ? > the serialization/deserialization cycle > >? ? ? > > >? ? ? > the class cast exception happens not at the example level, > but deep > >? ? ? > inside `readObject` when it's doing an internal assignment > >? ? ? > > >? ? ? > perhaps my choice of words "into a new classloader" was > >? ? ?insufficient or > >? ? ? > misleading. in both examples that i've come up with so > far, the > >? ? ?class > >? ? ? > loader calls defineClass directly without first delegating to > >? ? ?super (for > >? ? ? > a subset of the classes). so "into a definitive classloader" > >? ? ?might have > >? ? ? > been a better choice > > > >? ? ?I think the basic problem is that this test loads a nested > type into a > >? ? ?different classloader to its enclosing type. I can easily > imagine this > >? ? ?messing up the code that gets generated to implement the lambda > >? ? ?expression - but I'd need to examine that code in detail to > see exactly > >? ? ?why (others may know this more readily than I do). It's > unclear to me > >? ? ?whether this would be considered a bug or a "don't do that" > situation. > >? ? ?As of JDK 11, nested types define "nests" at the VM level > (see JEP-181) > >? ? ?and it is a requirement that all nest members be defined in > the same > >? ? ?package - which implies the same classloader. > > > >? ? ?David > > > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > On Mon, Mar 25, 2019 at 9:34 PM David Holmes > >? ? ? > > > >? ? ? > > >? ? ? >>> wrote: > >? ? ? > > >? ? ? >? ? ?Hi Seth, > >? ? ? > > >? ? ? >? ? ?On 26/03/2019 11:22 am, seth lytle wrote: > >? ? ? >? ? ? > if a lambda is a field and captures `this`, and it's > >? ? ?deserialized > >? ? ? >? ? ?into a > >? ? ? >? ? ? > new class loader, it throws a ClassCastException. > >? ? ? > > >? ? ? >? ? ?Not sure I follow. If you load a class into a different > >? ? ?classloader > >? ? ? >? ? ?then > >? ? ? >? ? ?you get a different type. It might appear the same to > you but > >? ? ?it is a > >? ? ? >? ? ?distinct type, so you can't assign across different > instances > >? ? ?loaded by > >? ? ? >? ? ?different classloaders. > >? ? ? > > >? ? ? >? ? ?Cheers, > >? ? ? >? ? ?David > >? ? ? >? ? ?----- > >? ? ? > > >? ? ? >? ? ? > i came across this bug > >? ? ? >? ? ? > independently while writing a test, but then found > an old > >? ? ?openjdk > >? ? ? >? ? ?bug with > >? ? ? >? ? ? > a similar issue and tweaked the test case (source > below). > >? ? ?my version > >? ? ? >? ? ? > differs only in > >? ? ? >? ? ? > 1. moved the lambda to a field > >? ? ? >? ? ? > 2. reference `this` in it > >? ? ? >? ? ? > 3. uses readAllBytes instead of the internal method > >? ? ? >? ? ? > 4. formatting > >? ? ? >? ? ? > > >? ? ? >? ? ? > running with java 11 or 12 (or java 8 using a > substitute for > >? ? ? >? ? ?readAllBytes) > >? ? ? >? ? ? > results in: > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? this: > >? ? ?test.SerializedLambdaTest$MyCode at 8efb846 > >? ? ? >? ? ? >? ? ? deSerializedThis: > >? ? ?test.SerializedLambdaTest$MyCode at 2b71fc7e > >? ? ? >? ? ? >? ? ? ? ? ? ? runnable: > >? ? ? >? ? ? > > >? ? ? > > > > ?test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > >? ? ? >? ? ? > Exception in thread "main" > java.lang.ClassCastException: > >? ? ?cannot > >? ? ? >? ? ?assign > >? ? ? >? ? ? > instance of java.lang.invoke.SerializedLambda to field > >? ? ? >? ? ? > test.SerializedLambdaTest$MyCode.runnable2 of type > >? ? ? >? ? ? > test.SerializedLambdaTest$SerializableRunnable in > instance of > >? ? ? >? ? ? > test.SerializedLambdaTest$MyCode > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readArray(ObjectInputStream.java:1993) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readObject0(ObjectInputStream.java:1588) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > java.base/java.io > >? ? ? > > > > ?.ObjectInputStream.readObject(ObjectInputStream.java:430) > >? ? ? >? ? ? > at > >? ? ? >? ? ? > > >? ? ? > > > > ?test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > >? ? ? >? ? ? > at > > > ?test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > >? ? ? >? ? ? > at > >? ? ?test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8008770 > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > package test; > >? ? ? >? ? ? > > >? ? ? >? ? ? > import java.io.ByteArrayInputStream; > >? ? ? >? ? ? > import java.io.ByteArrayOutputStream; > >? ? ? >? ? ? > import java.io.IOException; > >? ? ? >? ? ? > import java.io.InputStream; > >? ? ? >? ? ? > import java.io.ObjectInputStream; > >? ? ? >? ? ? > import java.io.ObjectOutputStream; > >? ? ? >? ? ? > import java.io.Serializable; > >? ? ? >? ? ? > > >? ? ? >? ? ? > // from: > https://bugs.openjdk.java.net/browse/JDK-8008770 > >? ? ? >? ? ? > public class SerializedLambdaTest { > >? ? ? >? ? ? >? ? ? public interface SerializableRunnable extends > >? ? ? >? ? ?Runnable,Serializable { > >? ? ? >? ? ? >? ? ? } > >? ? ? >? ? ? >? ? ? public static class MyCode implements > >? ? ?SerializableRunnable { > >? ? ? >? ? ? >? ? ? ? ? SerializableRunnable runnable2 = () > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? -> { > >? ? ? >? ? ? > > System.out.println("HELLO"+this.getClass()); > >? ? ? >? ? ? >? ? ? ? ? }; > >? ? ? >? ? ? >? ? ? ? ? private byte[] serialize(Object o) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ByteArrayOutputStream baos; > >? ? ? >? ? ? >? ? ? ? ? ? ? try ( > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos > = new > >? ? ? >? ? ? > ByteArrayOutputStream())) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? oos.writeObject(o); > >? ? ? >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? >? ? ? >? ? ? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? ? ? return baos.toByteArray(); > >? ? ? >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? private T deserialize(byte[] bytes) { > >? ? ? >? ? ? >? ? ? ? ? ? ? try ( > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new > >? ? ? >? ? ? > ByteArrayInputStream(bytes))) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); > >? ? ? >? ? ? >? ? ? ? ? ? ? } catch > (IOException|ClassNotFoundException e) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); > >? ? ? >? ? ? >? ? ? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? @Override > >? ? ? >? ? ? >? ? ? ? ? public void run() { > >? ? ? >? ? ? >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? ? ? this: > >? ? ?"+this); > >? ? ? >? ? ? >? ? ? ? ? ? ? SerializableRunnable deSerializedThis > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); > >? ? ? >? ? ? >? ? ? ? ? ? ? System.out.println(" > deSerializedThis: " > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? ? ? ? ? SerializableRunnable runnable = runnable2; > >? ? ? >? ? ? >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? runnable: > >? ? ?"+runnable); > >? ? ? >? ? ? >? ? ? ? ? ? ? SerializableRunnable deSerializedRunnable > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = > deserialize(serialize(runnable)); > >? ? ? >? ? ? > > System.out.println("deSerializedRunnable: " > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); > >? ? ? >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? >? ? ? } > >? ? ? >? ? ? >? ? ? public static void main(String[] args) throws > Exception { > >? ? ? >? ? ? >? ? ? ? ? ClassLoader myCl = new MyClassLoader( > >? ? ? >? ? ? > > SerializedLambdaTest.class.getClassLoader() > >? ? ? >? ? ? >? ? ? ? ? ); > >? ? ? >? ? ? >? ? ? ? ? Class myCodeClass = Class.forName( > >? ? ? >? ? ? > > >? ? ?SerializedLambdaTest.class.getName()+"$MyCode", > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? true, > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? myCl > >? ? ? >? ? ? >? ? ? ? ? ); > >? ? ? >? ? ? >? ? ? ? ? Runnable myCode = (Runnable) > >? ? ?myCodeClass.newInstance(); > >? ? ? >? ? ? >? ? ? ? ? myCode.run(); > >? ? ? >? ? ? >? ? ? } > >? ? ? >? ? ? >? ? ? static class MyClassLoader extends ClassLoader { > >? ? ? >? ? ? >? ? ? ? ? MyClassLoader(ClassLoader parent) { > >? ? ? >? ? ? >? ? ? ? ? ? ? super(parent); > >? ? ? >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? @Override > >? ? ? >? ? ? >? ? ? ? ? protected Class loadClass(String > name,boolean > >? ? ?resolve) > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throws ClassNotFoundException { > >? ? ? >? ? ? >? ? ? ? ? ? ? if (name.startsWith("test.")) > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? synchronized > (getClassLoadingLock(name)) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? Class c = > findLoadedClass(name); > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (c==null) > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? c = findClass(name); > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (resolve) > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? resolveClass(c); > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? return c; > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? ? ? else > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? return super.loadClass(name,resolve); > >? ? ? >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? @Override > >? ? ? >? ? ? >? ? ? ? ? protected Class findClass(String name) > throws > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ClassNotFoundException { > >? ? ? >? ? ? >? ? ? ? ? ? ? String path = > >? ? ?name.replace('.','/').concat(".class"); > >? ? ? >? ? ? >? ? ? ? ? ? ? try ( InputStream is = > >? ? ?getResourceAsStream(path)) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? if (is!=null) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? return > >? ? ?defineClass(name,bytes,0,bytes.length); > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? } else > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? throw new > ClassNotFoundException(name); > >? ? ? >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { > >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new > ClassNotFoundException(name,e); > >? ? ? >? ? ? >? ? ? ? ? ? ? } > >? ? ? >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? >? ? ? } > >? ? ? >? ? ? > } > >? ? ? >? ? ? > > >? ? ? > > > > From david.holmes at oracle.com Tue Mar 26 05:12:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 15:12:53 +1000 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Message-ID: <9f40c8c6-487f-ed7d-639e-e49f89c023f6@oracle.com> Hi Seth, I think we've both been chasing red herrings :) The classloader is not relevant. I can run the test with everything loaded as normal by the app loader and it still gets the ClassCastException. Searching JBS it seems that serialization of lambdas is broken - ref: https://bugs.openjdk.java.net/browse/JDK-8154236 https://bugs.openjdk.java.net/browse/JDK-8174865 https://bugs.openjdk.java.net/browse/JDK-8174864 though I'm not clear if your testcase falls under the same categorization as above. David ----- On 26/03/2019 2:08 pm, David Holmes wrote: > On 26/03/2019 2:03 pm, seth lytle wrote: >> it's a nested class, but it's loaded with the same class loader as the >> toplevel. which is what i thought you thought was the problem when > > Sorry, hard to see all the diffs inside the email. Not sure what > relevance splitting into two files has given the main change was to load > the enclosing class in the new loader rather than the nested class. > > Anyway, yes this gets rid of the "nested class in a different > classloader" problem. > > I'll take a look and see what's getting generated under the hood. > > David > ----- > >> you wrote: >> ?> this test loads a nested type into a different classloader to its >> enclosing type >> >> and: >> ?> it is a requirement that all nest members be defined in the same >> ?> package - which implies the same classloader >> >> >> >> >> On Mon, Mar 25, 2019 at 11:40 PM David Holmes > > wrote: >> >> ??? On 26/03/2019 1:06 pm, seth lytle wrote: >> ???? > i still get the same stack trace after breaking the example out >> ??? into two >> ???? > files. does that sufficiently address the nesting issue ? >> >> ??? ?? >> >> ???? ? ? ?public static class MyCode ... >> >> ??? is still a nested class. >> >> ??? David >> >> ???? > file:?SerializedLambdaTest >> ???? > package test; >> ???? > >> ???? > import java.io.ByteArrayInputStream; >> ???? > import java.io.ByteArrayOutputStream; >> ???? > import java.io.IOException; >> ???? > import java.io.ObjectInputStream; >> ???? > import java.io.ObjectOutputStream; >> ???? > import java.io.Serializable; >> ???? > >> ???? > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 >> ???? > public class SerializedLambdaTest implements Runnable { >> ???? >? ? ? public void run() { new MyCode().run(); } >> ???? >? ? ? public interface SerializableRunnable extends >> ??? Runnable,Serializable { >> ???? >? ? ? } >> ???? >? ? ? public static class MyCode implements SerializableRunnable { >> ???? >? ? ? ? ? SerializableRunnable runnable2 = () >> ???? >? ? ? ? ? ? ? ? ? -> { >> ???? >? ? ? ? ? ? ? System.out.println("HELLO"+this.getClass()); >> ???? >? ? ? ? ? }; >> ???? >? ? ? ? ? private byte[] serialize(Object o) { >> ???? >? ? ? ? ? ? ? ByteArrayOutputStream baos; >> ???? >? ? ? ? ? ? ? try ( >> ???? >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos >> ???? >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos = new >> ???? > ByteArrayOutputStream())) { >> ???? >? ? ? ? ? ? ? ? ? oos.writeObject(o); >> ???? >? ? ? ? ? ? ? } catch (IOException e) { >> ???? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >> ???? >? ? ? ? ? ? ? } >> ???? >? ? ? ? ? ? ? return baos.toByteArray(); >> ???? >? ? ? ? ? } >> ???? >? ? ? ? ? private T deserialize(byte[] bytes) { >> ???? >? ? ? ? ? ? ? try ( >> ???? >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois >> ???? >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new >> ???? > ByteArrayInputStream(bytes))) { >> ???? >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); >> ???? >? ? ? ? ? ? ? } catch (IOException|ClassNotFoundException e) { >> ???? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >> ???? >? ? ? ? ? ? ? } >> ???? >? ? ? ? ? } >> ???? >? ? ? ? ? @Override >> ???? >? ? ? ? ? public void run() { >> ???? >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? ? ? this: "+this); >> ???? >? ? ? ? ? ? ? SerializableRunnable deSerializedThis >> ???? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); >> ???? >? ? ? ? ? ? ? System.out.println("? ? deSerializedThis: " >> ???? >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); >> ???? > >> ???? >? ? ? ? ? ? ? SerializableRunnable runnable = runnable2; >> ???? >? ? ? ? ? ? ? System.out.println("? ? ? ? ? ? runnable: >> "+runnable); >> ???? >? ? ? ? ? ? ? SerializableRunnable deSerializedRunnable >> ???? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(runnable)); >> ???? >? ? ? ? ? ? ? System.out.println("deSerializedRunnable: " >> ???? >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); >> ???? >? ? ? ? ? } >> ???? >? ? ? } >> ???? > } >> ???? > >> ???? > >> ???? > file:?MyClassLoader >> ???? > package test; >> ???? > >> ???? > import java.io.IOException; >> ???? > import java.io.InputStream; >> ???? > >> ???? > class MyClassLoader extends ClassLoader { >> ???? >? ? ? MyClassLoader(ClassLoader parent) { >> ???? >? ? ? ? ? super(parent); >> ???? >? ? ? } >> ???? >? ? ? @Override >> ???? >? ? ? protected Class loadClass(String name,boolean resolve) >> ??? throws >> ???? > ClassNotFoundException { >> ???? >? ? ? ? ? if (name.startsWith("test.")) >> ???? >? ? ? ? ? ? ? synchronized (getClassLoadingLock(name)) { >> ???? >? ? ? ? ? ? ? ? ? Class c = findLoadedClass(name); >> ???? >? ? ? ? ? ? ? ? ? if (c==null) c = findClass(name); >> ???? >? ? ? ? ? ? ? ? ? if (resolve) resolveClass(c); >> ???? >? ? ? ? ? ? ? ? ? return c; >> ???? >? ? ? ? ? ? ? } >> ???? >? ? ? ? ? else return super.loadClass(name,resolve); >> ???? >? ? ? } >> ???? >? ? ? @Override >> ???? >? ? ? protected Class findClass(String name) throws >> ???? > ClassNotFoundException { >> ???? >? ? ? ? ? String path = name.replace('.','/').concat(".class"); >> ???? >? ? ? ? ? try (final InputStream is = getResourceAsStream(path)) { >> ???? >? ? ? ? ? ? ? if (is!=null) { >> ???? >? ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); >> ???? >? ? ? ? ? ? ? ? ? return defineClass(name,bytes,0,bytes.length); >> ???? >? ? ? ? ? ? ? } >> ???? >? ? ? ? ? ? ? else throw new ClassNotFoundException(name); >> ???? >? ? ? ? ? } catch (IOException e) { >> ???? >? ? ? ? ? ? ? throw new ClassNotFoundException(name,e); >> ???? >? ? ? ? ? } >> ???? >? ? ? } >> ???? >? ? ? public static void main(String[] args) throws Exception { >> ???? >? ? ? ? ? ClassLoader myCl = new MyClassLoader( >> ???? >? ? ? ? ? ? ? ? ? MyClassLoader.class.getClassLoader() >> ???? >? ? ? ? ? ); >> ???? >? ? ? ? ? Class myCodeClass = Class.forName( >> ???? >? ? ? ? ? ? ? ? ? "test.SerializedLambdaTest", >> ???? >? ? ? ? ? ? ? ? ? true, >> ???? >? ? ? ? ? ? ? ? ? myCl >> ???? >? ? ? ? ? ); >> ???? >? ? ? ? ? Runnable myCode = (Runnable) myCodeClass.newInstance(); >> ???? >? ? ? ? ? myCode.run(); >> ???? >? ? ? } >> ???? > } >> ???? > >> ???? > >> ???? > >> ???? > >> ???? > On Mon, Mar 25, 2019 at 10:34 PM David Holmes >> ??? >> ???? > > ??? >> wrote: >> ???? > >> ???? >? ? ?Hi Seth, >> ???? > >> ???? >? ? ?On 26/03/2019 12:16 pm, seth lytle wrote: >> ???? >? ? ? > i haven't changed the assignment from the original test >> case >> ???? >? ? ?(which was >> ???? >? ? ? > accepted as valid at the time). i haven't gone through >> it in >> ???? >? ? ?depth, but >> ???? >? ? ? > assume that it's ok and used it since people are already >> ??? familiar >> ???? >? ? ?with >> ???? >? ? ? > it. it appears to me that that example uses reflection to >> ???? >? ? ?allocate an >> ???? >? ? ? > instance using a definitive class loader and then uses a >> ??? runnable >> ???? >? ? ?for >> ???? >? ? ? > the serialization/deserialization cycle >> ???? >? ? ? > >> ???? >? ? ? > the class cast exception happens not at the example level, >> ??? but deep >> ???? >? ? ? > inside `readObject` when it's doing an internal assignment >> ???? >? ? ? > >> ???? >? ? ? > perhaps my choice of words "into a new classloader" was >> ???? >? ? ?insufficient or >> ???? >? ? ? > misleading. in both examples that i've come up with so >> ??? far, the >> ???? >? ? ?class >> ???? >? ? ? > loader calls defineClass directly without first >> delegating to >> ???? >? ? ?super (for >> ???? >? ? ? > a subset of the classes). so "into a definitive >> classloader" >> ???? >? ? ?might have >> ???? >? ? ? > been a better choice >> ???? > >> ???? >? ? ?I think the basic problem is that this test loads a nested >> ??? type into a >> ???? >? ? ?different classloader to its enclosing type. I can easily >> ??? imagine this >> ???? >? ? ?messing up the code that gets generated to implement the >> lambda >> ???? >? ? ?expression - but I'd need to examine that code in detail to >> ??? see exactly >> ???? >? ? ?why (others may know this more readily than I do). It's >> ??? unclear to me >> ???? >? ? ?whether this would be considered a bug or a "don't do that" >> ??? situation. >> ???? >? ? ?As of JDK 11, nested types define "nests" at the VM level >> ??? (see JEP-181) >> ???? >? ? ?and it is a requirement that all nest members be defined in >> ??? the same >> ???? >? ? ?package - which implies the same classloader. >> ???? > >> ???? >? ? ?David >> ???? > >> ???? >? ? ? > >> ???? >? ? ? > >> ???? >? ? ? > >> ???? >? ? ? > >> ???? >? ? ? > >> ???? >? ? ? > On Mon, Mar 25, 2019 at 9:34 PM David Holmes >> ???? >? ? ? >> ??? > >> ???? >? ? ? > > ??? >> ???? >? ? ?> ??? >>> wrote: >> ???? >? ? ? > >> ???? >? ? ? >? ? ?Hi Seth, >> ???? >? ? ? > >> ???? >? ? ? >? ? ?On 26/03/2019 11:22 am, seth lytle wrote: >> ???? >? ? ? >? ? ? > if a lambda is a field and captures `this`, and it's >> ???? >? ? ?deserialized >> ???? >? ? ? >? ? ?into a >> ???? >? ? ? >? ? ? > new class loader, it throws a ClassCastException. >> ???? >? ? ? > >> ???? >? ? ? >? ? ?Not sure I follow. If you load a class into a different >> ???? >? ? ?classloader >> ???? >? ? ? >? ? ?then >> ???? >? ? ? >? ? ?you get a different type. It might appear the same to >> ??? you but >> ???? >? ? ?it is a >> ???? >? ? ? >? ? ?distinct type, so you can't assign across different >> ??? instances >> ???? >? ? ?loaded by >> ???? >? ? ? >? ? ?different classloaders. >> ???? >? ? ? > >> ???? >? ? ? >? ? ?Cheers, >> ???? >? ? ? >? ? ?David >> ???? >? ? ? >? ? ?----- >> ???? >? ? ? > >> ???? >? ? ? >? ? ? > i came across this bug >> ???? >? ? ? >? ? ? > independently while writing a test, but then found >> ??? an old >> ???? >? ? ?openjdk >> ???? >? ? ? >? ? ?bug with >> ???? >? ? ? >? ? ? > a similar issue and tweaked the test case (source >> ??? below). >> ???? >? ? ?my version >> ???? >? ? ? >? ? ? > differs only in >> ???? >? ? ? >? ? ? > 1. moved the lambda to a field >> ???? >? ? ? >? ? ? > 2. reference `this` in it >> ???? >? ? ? >? ? ? > 3. uses readAllBytes instead of the internal method >> ???? >? ? ? >? ? ? > 4. formatting >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > running with java 11 or 12 (or java 8 using a >> ??? substitute for >> ???? >? ? ? >? ? ?readAllBytes) >> ???? >? ? ? >? ? ? > results in: >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? this: >> ???? >? ? ?test.SerializedLambdaTest$MyCode at 8efb846 >> ???? >? ? ? >? ? ? >? ? ? deSerializedThis: >> ???? >? ? ?test.SerializedLambdaTest$MyCode at 2b71fc7e >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? runnable: >> ???? >? ? ? >? ? ? > >> ???? >? ? ? > >> ???? > >> ?test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 >> ???? >? ? ? >? ? ? > Exception in thread "main" >> ??? java.lang.ClassCastException: >> ???? >? ? ?cannot >> ???? >? ? ? >? ? ?assign >> ???? >? ? ? >? ? ? > instance of java.lang.invoke.SerializedLambda to >> field >> ???? >? ? ? >? ? ? > test.SerializedLambdaTest$MyCode.runnable2 of type >> ???? >? ? ? >? ? ? > test.SerializedLambdaTest$SerializableRunnable in >> ??? instance of >> ???? >? ? ? >? ? ? > test.SerializedLambdaTest$MyCode >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readArray(ObjectInputStream.java:1993) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readObject0(ObjectInputStream.java:1588) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > java.base/java.io >> ???? >? ? ? > >> ???? > >> ?.ObjectInputStream.readObject(ObjectInputStream.java:430) >> >> ???? >? ? ? >? ? ? > at >> ???? >? ? ? >? ? ? > >> ???? >? ? ? > >> ???? > >> ?test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) >> >> ???? >? ? ? >? ? ? > at >> ???? > >> ?test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) >> ???? >? ? ? >? ? ? > at >> ???? >? ? ?test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8008770 >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > package test; >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > import java.io.ByteArrayInputStream; >> ???? >? ? ? >? ? ? > import java.io.ByteArrayOutputStream; >> ???? >? ? ? >? ? ? > import java.io.IOException; >> ???? >? ? ? >? ? ? > import java.io.InputStream; >> ???? >? ? ? >? ? ? > import java.io.ObjectInputStream; >> ???? >? ? ? >? ? ? > import java.io.ObjectOutputStream; >> ???? >? ? ? >? ? ? > import java.io.Serializable; >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? > // from: >> ??? https://bugs.openjdk.java.net/browse/JDK-8008770 >> ???? >? ? ? >? ? ? > public class SerializedLambdaTest { >> ???? >? ? ? >? ? ? >? ? ? public interface SerializableRunnable extends >> ???? >? ? ? >? ? ?Runnable,Serializable { >> ???? >? ? ? >? ? ? >? ? ? } >> ???? >? ? ? >? ? ? >? ? ? public static class MyCode implements >> ???? >? ? ?SerializableRunnable { >> ???? >? ? ? >? ? ? >? ? ? ? ? SerializableRunnable runnable2 = () >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? -> { >> ???? >? ? ? >? ? ? > ??? System.out.println("HELLO"+this.getClass()); >> ???? >? ? ? >? ? ? >? ? ? ? ? }; >> ???? >? ? ? >? ? ? >? ? ? ? ? private byte[] serialize(Object o) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ByteArrayOutputStream baos; >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? try ( >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos >> ??? = new >> ???? >? ? ? >? ? ? > ByteArrayOutputStream())) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? oos.writeObject(o); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? return baos.toByteArray(); >> ???? >? ? ? >? ? ? >? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? private T deserialize(byte[] bytes) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? try ( >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new >> ???? >? ? ? >? ? ? > ByteArrayInputStream(bytes))) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } catch >> ??? (IOException|ClassNotFoundException e) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? @Override >> ???? >? ? ? >? ? ? >? ? ? ? ? public void run() { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? System.out.println(" >> this: >> ???? >? ? ?"+this); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? SerializableRunnable deSerializedThis >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? System.out.println(" >> deSerializedThis: " >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); >> ???? >? ? ? >? ? ? > >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? SerializableRunnable runnable = >> runnable2; >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? System.out.println(" >> runnable: >> ???? >? ? ?"+runnable); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? SerializableRunnable >> deSerializedRunnable >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = >> ??? deserialize(serialize(runnable)); >> ???? >? ? ? >? ? ? > ??? System.out.println("deSerializedRunnable: " >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); >> ???? >? ? ? >? ? ? >? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? } >> ???? >? ? ? >? ? ? >? ? ? public static void main(String[] args) throws >> ??? Exception { >> ???? >? ? ? >? ? ? >? ? ? ? ? ClassLoader myCl = new MyClassLoader( >> ???? >? ? ? >? ? ? > ??? SerializedLambdaTest.class.getClassLoader() >> ???? >? ? ? >? ? ? >? ? ? ? ? ); >> ???? >? ? ? >? ? ? >? ? ? ? ? Class myCodeClass = Class.forName( >> ???? >? ? ? >? ? ? > >> ???? >? ? ?SerializedLambdaTest.class.getName()+"$MyCode", >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? true, >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? myCl >> ???? >? ? ? >? ? ? >? ? ? ? ? ); >> ???? >? ? ? >? ? ? >? ? ? ? ? Runnable myCode = (Runnable) >> ???? >? ? ?myCodeClass.newInstance(); >> ???? >? ? ? >? ? ? >? ? ? ? ? myCode.run(); >> ???? >? ? ? >? ? ? >? ? ? } >> ???? >? ? ? >? ? ? >? ? ? static class MyClassLoader extends >> ClassLoader { >> ???? >? ? ? >? ? ? >? ? ? ? ? MyClassLoader(ClassLoader parent) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? super(parent); >> ???? >? ? ? >? ? ? >? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? @Override >> ???? >? ? ? >? ? ? >? ? ? ? ? protected Class loadClass(String >> ??? name,boolean >> ???? >? ? ?resolve) >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throws ClassNotFoundException { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? if (name.startsWith("test.")) >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? synchronized >> ??? (getClassLoadingLock(name)) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? Class c = >> ??? findLoadedClass(name); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (c==null) >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? c = findClass(name); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (resolve) >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? resolveClass(c); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? return c; >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? else >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? return >> super.loadClass(name,resolve); >> ???? >? ? ? >? ? ? >? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? @Override >> ???? >? ? ? >? ? ? >? ? ? ? ? protected Class findClass(String name) >> ??? throws >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ClassNotFoundException { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? String path = >> ???? >? ? ?name.replace('.','/').concat(".class"); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? try ( InputStream is = >> ???? >? ? ?getResourceAsStream(path)) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? if (is!=null) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? byte[] bytes = >> is.readAllBytes(); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? return >> ???? >? ? ?defineClass(name,bytes,0,bytes.length); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? } else >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? throw new >> ??? ClassNotFoundException(name); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new >> ??? ClassNotFoundException(name,e); >> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? ? ? } >> ???? >? ? ? >? ? ? >? ? ? } >> ???? >? ? ? >? ? ? > } >> ???? >? ? ? >? ? ? > >> ???? >? ? ? > >> ???? > >> From thomas.stuefe at gmail.com Tue Mar 26 06:03:49 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Mar 2019 07:03:49 +0100 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: On Mon, Mar 25, 2019 at 10:49 PM Martijn Verburg wrote: > Hi all, > > Snipping much, but commenting on one statement inline below. > > On Mon, 25 Mar 2019 at 01:58, David Holmes > wrote: > >> Hi Thomas, >> >> A few queries, comments and concerns ... >> >> On 25/03/2019 6:58 am, Thomas St?fe wrote: >> > Hi all, >> > >> > After a long time I tried to build a Windows 32bit VM (VS2017) and >> failed; >> >> I'm somewhat surprised as I thought someone was actively doing Windows >> 32-bit builds out there, plus there are shared code changes that should >> also have been caught by non-Windows 32-bit builds. :( >> > > AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 to > do so and have hit the same issues (Thomas beat us to reporting!). > > Still curious what you actually build, since I believe not all of the issues are related to vs2017. Do you build release only or also debug? Do you build with warnings-as-errors disabled? > Hopefully, we'll have that nightly warning system in place for you going > forward soon. > > That would be helpful. Cheers, Thomas > Cheers, > Martijn > From peter.levart at gmail.com Tue Mar 26 07:54:35 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 26 Mar 2019 08:54:35 +0100 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> Message-ID: <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> Hi Seth, I think you stumbled on a "defect" of Java Serialization mechanism. Namely, the inability for it to correctly deserialize object graphs containing a cycle when an object in such cycle uses the "readResolve()" special method to replace the deserialized object with a replacement object. SerializedLambda is a class with instances that are 1st deserialized from stream then "replaced" with real lambda objects via the "readResolve()" method which constructs and returns the "real" lambda object. The deserialized SerializedLambda object is nevertheless attempted to be (temporarily) assigned to the field that would hold the final lambda object, which fails as the filed is of different type than SerializedLambda (or supertype). You can check my claims by changing the type of the field holding the lambda to java.lang.Object and see if it works... (It should if my memory serves me well :-) This is a known defect of Java serialization and is not specific to serialized lambda. There were some unsuccessful attempts to fix it during (re)discovery when lambdas were being added to Java. Regards, Peter On 3/26/19 5:03 AM, seth lytle wrote: > it's a nested class, but it's loaded with the same class loader as the > toplevel. > which is what i thought you thought was the problem when > > you wrote: >> this test loads a nested type into a different classloader to its > enclosing type > > and: >> it is a requirement that all nest members be defined in the same >> package - which implies the same classloader > > > > On Mon, Mar 25, 2019 at 11:40 PM David Holmes > wrote: > >> On 26/03/2019 1:06 pm, seth lytle wrote: >>> i still get the same stack trace after breaking the example out into two >>> files. does that sufficiently address the nesting issue ? >> ?? >> >> public static class MyCode ... >> >> is still a nested class. >> >> David >> >>> file: SerializedLambdaTest >>> package test; >>> >>> import java.io.ByteArrayInputStream; >>> import java.io.ByteArrayOutputStream; >>> import java.io.IOException; >>> import java.io.ObjectInputStream; >>> import java.io.ObjectOutputStream; >>> import java.io.Serializable; >>> >>> // from: https://bugs.openjdk.java.net/browse/JDK-8008770 >>> public class SerializedLambdaTest implements Runnable { >>> public void run() { new MyCode().run(); } >>> public interface SerializableRunnable extends Runnable,Serializable >> { >>> } >>> public static class MyCode implements SerializableRunnable { >>> SerializableRunnable runnable2 = () >>> -> { >>> System.out.println("HELLO"+this.getClass()); >>> }; >>> private byte[] serialize(Object o) { >>> ByteArrayOutputStream baos; >>> try ( >>> ObjectOutputStream oos >>> = new ObjectOutputStream(baos = new >>> ByteArrayOutputStream())) { >>> oos.writeObject(o); >>> } catch (IOException e) { >>> throw new RuntimeException(e); >>> } >>> return baos.toByteArray(); >>> } >>> private T deserialize(byte[] bytes) { >>> try ( >>> ObjectInputStream ois >>> = new ObjectInputStream(new >>> ByteArrayInputStream(bytes))) { >>> return (T) ois.readObject(); >>> } catch (IOException|ClassNotFoundException e) { >>> throw new RuntimeException(e); >>> } >>> } >>> @Override >>> public void run() { >>> System.out.println(" this: "+this); >>> SerializableRunnable deSerializedThis >>> = deserialize(serialize(this)); >>> System.out.println(" deSerializedThis: " >>> +deSerializedThis); >>> >>> SerializableRunnable runnable = runnable2; >>> System.out.println(" runnable: "+runnable); >>> SerializableRunnable deSerializedRunnable >>> = deserialize(serialize(runnable)); >>> System.out.println("deSerializedRunnable: " >>> +deSerializedRunnable); >>> } >>> } >>> } >>> >>> >>> file: MyClassLoader >>> package test; >>> >>> import java.io.IOException; >>> import java.io.InputStream; >>> >>> class MyClassLoader extends ClassLoader { >>> MyClassLoader(ClassLoader parent) { >>> super(parent); >>> } >>> @Override >>> protected Class loadClass(String name,boolean resolve) throws >>> ClassNotFoundException { >>> if (name.startsWith("test.")) >>> synchronized (getClassLoadingLock(name)) { >>> Class c = findLoadedClass(name); >>> if (c==null) c = findClass(name); >>> if (resolve) resolveClass(c); >>> return c; >>> } >>> else return super.loadClass(name,resolve); >>> } >>> @Override >>> protected Class findClass(String name) throws >>> ClassNotFoundException { >>> String path = name.replace('.','/').concat(".class"); >>> try (final InputStream is = getResourceAsStream(path)) { >>> if (is!=null) { >>> byte[] bytes = is.readAllBytes(); >>> return defineClass(name,bytes,0,bytes.length); >>> } >>> else throw new ClassNotFoundException(name); >>> } catch (IOException e) { >>> throw new ClassNotFoundException(name,e); >>> } >>> } >>> public static void main(String[] args) throws Exception { >>> ClassLoader myCl = new MyClassLoader( >>> MyClassLoader.class.getClassLoader() >>> ); >>> Class myCodeClass = Class.forName( >>> "test.SerializedLambdaTest", >>> true, >>> myCl >>> ); >>> Runnable myCode = (Runnable) myCodeClass.newInstance(); >>> myCode.run(); >>> } >>> } >>> >>> >>> >>> >>> On Mon, Mar 25, 2019 at 10:34 PM David Holmes >> > wrote: >>> >>> Hi Seth, >>> >>> On 26/03/2019 12:16 pm, seth lytle wrote: >>> > i haven't changed the assignment from the original test case >>> (which was >>> > accepted as valid at the time). i haven't gone through it in >>> depth, but >>> > assume that it's ok and used it since people are already familiar >>> with >>> > it. it appears to me that that example uses reflection to >>> allocate an >>> > instance using a definitive class loader and then uses a runnable >>> for >>> > the serialization/deserialization cycle >>> > >>> > the class cast exception happens not at the example level, but >> deep >>> > inside `readObject` when it's doing an internal assignment >>> > >>> > perhaps my choice of words "into a new classloader" was >>> insufficient or >>> > misleading. in both examples that i've come up with so far, the >>> class >>> > loader calls defineClass directly without first delegating to >>> super (for >>> > a subset of the classes). so "into a definitive classloader" >>> might have >>> > been a better choice >>> >>> I think the basic problem is that this test loads a nested type into >> a >>> different classloader to its enclosing type. I can easily imagine >> this >>> messing up the code that gets generated to implement the lambda >>> expression - but I'd need to examine that code in detail to see >> exactly >>> why (others may know this more readily than I do). It's unclear to me >>> whether this would be considered a bug or a "don't do that" >> situation. >>> As of JDK 11, nested types define "nests" at the VM level (see >> JEP-181) >>> and it is a requirement that all nest members be defined in the same >>> package - which implies the same classloader. >>> >>> David >>> >>> > >>> > >>> > >>> > >>> > >>> > On Mon, Mar 25, 2019 at 9:34 PM David Holmes >>> >>> > >> >> wrote: >>> > >>> > Hi Seth, >>> > >>> > On 26/03/2019 11:22 am, seth lytle wrote: >>> > > if a lambda is a field and captures `this`, and it's >>> deserialized >>> > into a >>> > > new class loader, it throws a ClassCastException. >>> > >>> > Not sure I follow. If you load a class into a different >>> classloader >>> > then >>> > you get a different type. It might appear the same to you but >>> it is a >>> > distinct type, so you can't assign across different instances >>> loaded by >>> > different classloaders. >>> > >>> > Cheers, >>> > David >>> > ----- >>> > >>> > > i came across this bug >>> > > independently while writing a test, but then found an old >>> openjdk >>> > bug with >>> > > a similar issue and tweaked the test case (source below). >>> my version >>> > > differs only in >>> > > 1. moved the lambda to a field >>> > > 2. reference `this` in it >>> > > 3. uses readAllBytes instead of the internal method >>> > > 4. formatting >>> > > >>> > > running with java 11 or 12 (or java 8 using a substitute >> for >>> > readAllBytes) >>> > > results in: >>> > > this: >>> test.SerializedLambdaTest$MyCode at 8efb846 >>> > > deSerializedThis: >>> test.SerializedLambdaTest$MyCode at 2b71fc7e >>> > > runnable: >>> > > >>> > >>> >> test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 >>> > > Exception in thread "main" java.lang.ClassCastException: >>> cannot >>> > assign >>> > > instance of java.lang.invoke.SerializedLambda to field >>> > > test.SerializedLambdaTest$MyCode.runnable2 of type >>> > > test.SerializedLambdaTest$SerializableRunnable in instance >> of >>> > > test.SerializedLambdaTest$MyCode >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readSerialData(ObjectInputStream.java:2278) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readObject0(ObjectInputStream.java:1594) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readArray(ObjectInputStream.java:1993) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readObject0(ObjectInputStream.java:1588) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readSerialData(ObjectInputStream.java:2249) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readObject0(ObjectInputStream.java:1594) >>> > > at >>> > > java.base/java.io >>> > >>> >> .ObjectInputStream.readObject(ObjectInputStream.java:430) >>> > > at >>> > > >>> > >>> >> test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) >>> > > at >>> test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) >>> > > at >>> test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) >>> > > >>> > > >>> > > >>> > > https://bugs.openjdk.java.net/browse/JDK-8008770 >>> > > >>> > > >>> > > package test; >>> > > >>> > > import java.io.ByteArrayInputStream; >>> > > import java.io.ByteArrayOutputStream; >>> > > import java.io.IOException; >>> > > import java.io.InputStream; >>> > > import java.io.ObjectInputStream; >>> > > import java.io.ObjectOutputStream; >>> > > import java.io.Serializable; >>> > > >>> > > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 >>> > > public class SerializedLambdaTest { >>> > > public interface SerializableRunnable extends >>> > Runnable,Serializable { >>> > > } >>> > > public static class MyCode implements >>> SerializableRunnable { >>> > > SerializableRunnable runnable2 = () >>> > > -> { >>> > > System.out.println("HELLO"+this.getClass()); >>> > > }; >>> > > private byte[] serialize(Object o) { >>> > > ByteArrayOutputStream baos; >>> > > try ( >>> > > ObjectOutputStream oos >>> > > = new ObjectOutputStream(baos = new >>> > > ByteArrayOutputStream())) { >>> > > oos.writeObject(o); >>> > > } catch (IOException e) { >>> > > throw new RuntimeException(e); >>> > > } >>> > > return baos.toByteArray(); >>> > > } >>> > > private T deserialize(byte[] bytes) { >>> > > try ( >>> > > ObjectInputStream ois >>> > > = new ObjectInputStream(new >>> > > ByteArrayInputStream(bytes))) { >>> > > return (T) ois.readObject(); >>> > > } catch (IOException|ClassNotFoundException >> e) { >>> > > throw new RuntimeException(e); >>> > > } >>> > > } >>> > > @Override >>> > > public void run() { >>> > > System.out.println(" this: >>> "+this); >>> > > SerializableRunnable deSerializedThis >>> > > = deserialize(serialize(this)); >>> > > System.out.println(" deSerializedThis: " >>> > > +deSerializedThis); >>> > > >>> > > SerializableRunnable runnable = runnable2; >>> > > System.out.println(" runnable: >>> "+runnable); >>> > > SerializableRunnable deSerializedRunnable >>> > > = deserialize(serialize(runnable)); >>> > > System.out.println("deSerializedRunnable: " >>> > > +deSerializedRunnable); >>> > > } >>> > > } >>> > > public static void main(String[] args) throws >> Exception { >>> > > ClassLoader myCl = new MyClassLoader( >>> > > >> SerializedLambdaTest.class.getClassLoader() >>> > > ); >>> > > Class myCodeClass = Class.forName( >>> > > >>> SerializedLambdaTest.class.getName()+"$MyCode", >>> > > true, >>> > > myCl >>> > > ); >>> > > Runnable myCode = (Runnable) >>> myCodeClass.newInstance(); >>> > > myCode.run(); >>> > > } >>> > > static class MyClassLoader extends ClassLoader { >>> > > MyClassLoader(ClassLoader parent) { >>> > > super(parent); >>> > > } >>> > > @Override >>> > > protected Class loadClass(String name,boolean >>> resolve) >>> > > throws ClassNotFoundException { >>> > > if (name.startsWith("test.")) >>> > > synchronized (getClassLoadingLock(name)) { >>> > > Class c = findLoadedClass(name); >>> > > if (c==null) >>> > > c = findClass(name); >>> > > if (resolve) >>> > > resolveClass(c); >>> > > return c; >>> > > } >>> > > else >>> > > return super.loadClass(name,resolve); >>> > > } >>> > > @Override >>> > > protected Class findClass(String name) throws >>> > > ClassNotFoundException { >>> > > String path = >>> name.replace('.','/').concat(".class"); >>> > > try ( InputStream is = >>> getResourceAsStream(path)) { >>> > > if (is!=null) { >>> > > byte[] bytes = is.readAllBytes(); >>> > > return >>> defineClass(name,bytes,0,bytes.length); >>> > > } else >>> > > throw new >> ClassNotFoundException(name); >>> > > } catch (IOException e) { >>> > > throw new ClassNotFoundException(name,e); >>> > > } >>> > > } >>> > > } >>> > > } >>> > > >>> > >>> From peter.levart at gmail.com Tue Mar 26 08:06:36 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 26 Mar 2019 09:06:36 +0100 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> Message-ID: As I have suspected, this code works (see that there's no custom class loaders involved as they are unimportant in this situation): package test; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; public class SerializedLambdaTest implements Runnable { ??? public void run() { new MyCode().run(); } ??? public interface SerializableRunnable extends Runnable, Serializable { ??? } ??? public static class MyCode implements SerializableRunnable { ??????? Object runnable2 = (SerializableRunnable) ??????????? () -> System.out.println("HELLO" + this.getClass()); ??????? private byte[] serialize(Object o) { ??????????? ByteArrayOutputStream baos; ??????????? try ( ??????????????? ObjectOutputStream oos ??????????????????? = new ObjectOutputStream(baos = new ??????????????????? ByteArrayOutputStream())) { ??????????????? oos.writeObject(o); ??????????? } catch (IOException e) { ??????????????? throw new RuntimeException(e); ??????????? } ??????????? return baos.toByteArray(); ??????? } ??????? private T deserialize(byte[] bytes) { ??????????? try ( ??????????????? ObjectInputStream ois ??????????????????? = new ObjectInputStream(new ByteArrayInputStream(bytes))) { ??????????????? return (T) ois.readObject(); ??????????? } catch (IOException | ClassNotFoundException e) { ??????????????? throw new RuntimeException(e); ??????????? } ??????? } ??????? @Override ??????? public void run() { ??????????? System.out.println("??????????????? this: " + this); ??????????? SerializableRunnable deSerializedThis ??????????????? = deserialize(serialize(this)); ??????????? System.out.println("??? deSerializedThis: " ?????????????????????????????? + deSerializedThis); ??????????? SerializableRunnable runnable = (SerializableRunnable) runnable2; ??????????? System.out.println("??????????? runnable: " + runnable); ??????????? SerializableRunnable deSerializedRunnable ??????????????? = deserialize(serialize(runnable)); ??????????? System.out.println("deSerializedRunnable: " ?????????????????????????????? + deSerializedRunnable); ??????? } ??? } ??? public static void main(String[] args) { ??????? new SerializedLambdaTest().run(); ??? } } ...the original code failed with a very descriptive message: Exception in thread "main" java.lang.ClassCastException: cannot assign instance of java.lang.invoke.SerializedLambda to field test.SerializedLambdaTest$MyCode.runnable2 of type test.SerializedLambdaTest$SerializableRunnable in instance of test.SerializedLambdaTest$MyCode ??? at java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) ??? at java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) ??? at java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) ??? at java.base/java.io.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) ??? at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) ??? ... which suggests that my claims are correct... Peter On 3/26/19 8:54 AM, Peter Levart wrote: > Hi Seth, > > I think you stumbled on a "defect" of Java Serialization mechanism. > Namely, the inability for it to correctly deserialize object graphs > containing a cycle when an object in such cycle uses the > "readResolve()" special method to replace the deserialized object with > a replacement object. SerializedLambda is a class with instances that > are 1st deserialized from stream then "replaced" with real lambda > objects via the "readResolve()" method which constructs and returns > the "real" lambda object. The deserialized SerializedLambda object is > nevertheless attempted to be (temporarily) assigned to the field that > would hold the final lambda object, which fails as the filed is of > different type than SerializedLambda (or supertype). > > You can check my claims by changing the type of the field holding the > lambda to java.lang.Object and see if it works... (It should if my > memory serves me well :-) > > This is a known defect of Java serialization and is not specific to > serialized lambda. > > There were some unsuccessful attempts to fix it during (re)discovery > when lambdas were being added to Java. > > Regards, Peter > > On 3/26/19 5:03 AM, seth lytle wrote: >> it's a nested class, but it's loaded with the same class loader as the >> toplevel. >> which is what i thought you thought was the problem when >> >> you wrote: >>> this test loads a nested type into a different classloader to its >> enclosing type >> >> and: >>> it is a requirement that all nest members be defined in the same >>> package - which implies the same classloader >> >> >> >> On Mon, Mar 25, 2019 at 11:40 PM David Holmes >> wrote: >> >>> On 26/03/2019 1:06 pm, seth lytle wrote: >>>> i still get the same stack trace after breaking the example out >>>> into two >>>> files. does that sufficiently address the nesting issue ? >>> ?? >>> >>> ????? public static class MyCode ... >>> >>> is still a nested class. >>> >>> David >>> >>>> file: SerializedLambdaTest >>>> package test; >>>> >>>> import java.io.ByteArrayInputStream; >>>> import java.io.ByteArrayOutputStream; >>>> import java.io.IOException; >>>> import java.io.ObjectInputStream; >>>> import java.io.ObjectOutputStream; >>>> import java.io.Serializable; >>>> >>>> // from: https://bugs.openjdk.java.net/browse/JDK-8008770 >>>> public class SerializedLambdaTest implements Runnable { >>>> ????? public void run() { new MyCode().run(); } >>>> ????? public interface SerializableRunnable extends >>>> Runnable,Serializable >>> { >>>> ????? } >>>> ????? public static class MyCode implements SerializableRunnable { >>>> ????????? SerializableRunnable runnable2 = () >>>> ????????????????? -> { >>>> ????????????? System.out.println("HELLO"+this.getClass()); >>>> ????????? }; >>>> ????????? private byte[] serialize(Object o) { >>>> ????????????? ByteArrayOutputStream baos; >>>> ????????????? try ( >>>> ?????????????????????? ObjectOutputStream oos >>>> ????????????????????? = new ObjectOutputStream(baos = new >>>> ByteArrayOutputStream())) { >>>> ????????????????? oos.writeObject(o); >>>> ????????????? } catch (IOException e) { >>>> ????????????????? throw new RuntimeException(e); >>>> ????????????? } >>>> ????????????? return baos.toByteArray(); >>>> ????????? } >>>> ????????? private T deserialize(byte[] bytes) { >>>> ????????????? try ( >>>> ?????????????????????? ObjectInputStream ois >>>> ????????????????????? = new ObjectInputStream(new >>>> ByteArrayInputStream(bytes))) { >>>> ????????????????? return (T) ois.readObject(); >>>> ????????????? } catch (IOException|ClassNotFoundException e) { >>>> ????????????????? throw new RuntimeException(e); >>>> ????????????? } >>>> ????????? } >>>> ????????? @Override >>>> ????????? public void run() { >>>> ????????????? System.out.println("??????????????? this: "+this); >>>> ????????????? SerializableRunnable deSerializedThis >>>> ????????????????????? = deserialize(serialize(this)); >>>> ????????????? System.out.println("??? deSerializedThis: " >>>> ????????????????????? +deSerializedThis); >>>> >>>> ????????????? SerializableRunnable runnable = runnable2; >>>> ????????????? System.out.println("??????????? runnable: "+runnable); >>>> ????????????? SerializableRunnable deSerializedRunnable >>>> ????????????????????? = deserialize(serialize(runnable)); >>>> ????????????? System.out.println("deSerializedRunnable: " >>>> ????????????????????? +deSerializedRunnable); >>>> ????????? } >>>> ????? } >>>> } >>>> >>>> >>>> file: MyClassLoader >>>> package test; >>>> >>>> import java.io.IOException; >>>> import java.io.InputStream; >>>> >>>> class MyClassLoader extends ClassLoader { >>>> ????? MyClassLoader(ClassLoader parent) { >>>> ????????? super(parent); >>>> ????? } >>>> ????? @Override >>>> ????? protected Class loadClass(String name,boolean resolve) throws >>>> ClassNotFoundException { >>>> ????????? if (name.startsWith("test.")) >>>> ????????????? synchronized (getClassLoadingLock(name)) { >>>> ????????????????? Class c = findLoadedClass(name); >>>> ????????????????? if (c==null) c = findClass(name); >>>> ????????????????? if (resolve) resolveClass(c); >>>> ????????????????? return c; >>>> ????????????? } >>>> ????????? else return super.loadClass(name,resolve); >>>> ????? } >>>> ????? @Override >>>> ????? protected Class findClass(String name) throws >>>> ClassNotFoundException { >>>> ????????? String path = name.replace('.','/').concat(".class"); >>>> ????????? try (final InputStream is = getResourceAsStream(path)) { >>>> ????????????? if (is!=null) { >>>> ????????????????? byte[] bytes = is.readAllBytes(); >>>> ????????????????? return defineClass(name,bytes,0,bytes.length); >>>> ????????????? } >>>> ????????????? else throw new ClassNotFoundException(name); >>>> ????????? } catch (IOException e) { >>>> ????????????? throw new ClassNotFoundException(name,e); >>>> ????????? } >>>> ????? } >>>> ????? public static void main(String[] args) throws Exception { >>>> ????????? ClassLoader myCl = new MyClassLoader( >>>> ????????????????? MyClassLoader.class.getClassLoader() >>>> ????????? ); >>>> ????????? Class myCodeClass = Class.forName( >>>> ????????????????? "test.SerializedLambdaTest", >>>> ????????????????? true, >>>> ????????????????? myCl >>>> ????????? ); >>>> ????????? Runnable myCode = (Runnable) myCodeClass.newInstance(); >>>> ????????? myCode.run(); >>>> ????? } >>>> } >>>> >>>> >>>> >>>> >>>> On Mon, Mar 25, 2019 at 10:34 PM David Holmes >>> > wrote: >>>> >>>> ???? Hi Seth, >>>> >>>> ???? On 26/03/2019 12:16 pm, seth lytle wrote: >>>> ????? > i haven't changed the assignment from the original test case >>>> ???? (which was >>>> ????? > accepted as valid at the time). i haven't gone through it in >>>> ???? depth, but >>>> ????? > assume that it's ok and used it since people are already >>>> familiar >>>> ???? with >>>> ????? > it. it appears to me that that example uses reflection to >>>> ???? allocate an >>>> ????? > instance using a definitive class loader and then uses a >>>> runnable >>>> ???? for >>>> ????? > the serialization/deserialization cycle >>>> ????? > >>>> ????? > the class cast exception happens not at the example level, but >>> deep >>>> ????? > inside `readObject` when it's doing an internal assignment >>>> ????? > >>>> ????? > perhaps my choice of words "into a new classloader" was >>>> ???? insufficient or >>>> ????? > misleading. in both examples that i've come up with so far, >>>> the >>>> ???? class >>>> ????? > loader calls defineClass directly without first delegating to >>>> ???? super (for >>>> ????? > a subset of the classes). so "into a definitive classloader" >>>> ???? might have >>>> ????? > been a better choice >>>> >>>> ???? I think the basic problem is that this test loads a nested >>>> type into >>> a >>>> ???? different classloader to its enclosing type. I can easily imagine >>> this >>>> ???? messing up the code that gets generated to implement the lambda >>>> ???? expression - but I'd need to examine that code in detail to see >>> exactly >>>> ???? why (others may know this more readily than I do). It's >>>> unclear to me >>>> ???? whether this would be considered a bug or a "don't do that" >>> situation. >>>> ???? As of JDK 11, nested types define "nests" at the VM level (see >>> JEP-181) >>>> ???? and it is a requirement that all nest members be defined in >>>> the same >>>> ???? package - which implies the same classloader. >>>> >>>> ???? David >>>> >>>> ????? > >>>> ????? > >>>> ????? > >>>> ????? > >>>> ????? > >>>> ????? > On Mon, Mar 25, 2019 at 9:34 PM David Holmes >>>> ???? >>>> ????? > >>> ???? >> wrote: >>>> ????? > >>>> ????? >???? Hi Seth, >>>> ????? > >>>> ????? >???? On 26/03/2019 11:22 am, seth lytle wrote: >>>> ????? >????? > if a lambda is a field and captures `this`, and it's >>>> ???? deserialized >>>> ????? >???? into a >>>> ????? >????? > new class loader, it throws a ClassCastException. >>>> ????? > >>>> ????? >???? Not sure I follow. If you load a class into a different >>>> ???? classloader >>>> ????? >???? then >>>> ????? >???? you get a different type. It might appear the same to >>>> you but >>>> ???? it is a >>>> ????? >???? distinct type, so you can't assign across different >>>> instances >>>> ???? loaded by >>>> ????? >???? different classloaders. >>>> ????? > >>>> ????? >???? Cheers, >>>> ????? >???? David >>>> ????? >???? ----- >>>> ????? > >>>> ????? >????? > i came across this bug >>>> ????? >????? > independently while writing a test, but then found >>>> an old >>>> ???? openjdk >>>> ????? >???? bug with >>>> ????? >????? > a similar issue and tweaked the test case (source >>>> below). >>>> ???? my version >>>> ????? >????? > differs only in >>>> ????? >????? > 1. moved the lambda to a field >>>> ????? >????? > 2. reference `this` in it >>>> ????? >????? > 3. uses readAllBytes instead of the internal method >>>> ????? >????? > 4. formatting >>>> ????? >????? > >>>> ????? >????? > running with java 11 or 12 (or java 8 using a >>>> substitute >>> for >>>> ????? >???? readAllBytes) >>>> ????? >????? > results in: >>>> ????? >????? >????????????????? this: >>>> ???? test.SerializedLambdaTest$MyCode at 8efb846 >>>> ????? >????? >????? deSerializedThis: >>>> ???? test.SerializedLambdaTest$MyCode at 2b71fc7e >>>> ????? >????? >????????????? runnable: >>>> ????? >????? > >>>> ????? > >>>> >>> test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 >>>> ????? >????? > Exception in thread "main" >>>> java.lang.ClassCastException: >>>> ???? cannot >>>> ????? >???? assign >>>> ????? >????? > instance of java.lang.invoke.SerializedLambda to field >>>> ????? >????? > test.SerializedLambdaTest$MyCode.runnable2 of type >>>> ????? >????? > test.SerializedLambdaTest$SerializableRunnable in >>>> instance >>> of >>>> ????? >????? > test.SerializedLambdaTest$MyCode >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) >>>> >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) >>>> >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) >>>> >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) >>>> >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readSerialData(ObjectInputStream.java:2278) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readObject0(ObjectInputStream.java:1594) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readArray(ObjectInputStream.java:1993) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readObject0(ObjectInputStream.java:1588) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readSerialData(ObjectInputStream.java:2249) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readObject0(ObjectInputStream.java:1594) >>>> ????? >????? > at >>>> ????? >????? > java.base/java.io >>>> ????? > >>>> ?????? >>> .ObjectInputStream.readObject(ObjectInputStream.java:430) >>>> ????? >????? > at >>>> ????? >????? > >>>> ????? > >>>> >>> test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) >>>> ????? >????? > at >>>> test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) >>>> ????? >????? > at >>>> test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) >>>> ????? >????? > >>>> ????? >????? > >>>> ????? >????? > >>>> ????? >????? > https://bugs.openjdk.java.net/browse/JDK-8008770 >>>> ????? >????? > >>>> ????? >????? > >>>> ????? >????? > package test; >>>> ????? >????? > >>>> ????? >????? > import java.io.ByteArrayInputStream; >>>> ????? >????? > import java.io.ByteArrayOutputStream; >>>> ????? >????? > import java.io.IOException; >>>> ????? >????? > import java.io.InputStream; >>>> ????? >????? > import java.io.ObjectInputStream; >>>> ????? >????? > import java.io.ObjectOutputStream; >>>> ????? >????? > import java.io.Serializable; >>>> ????? >????? > >>>> ????? >????? > // from: >>>> https://bugs.openjdk.java.net/browse/JDK-8008770 >>>> ????? >????? > public class SerializedLambdaTest { >>>> ????? >????? >????? public interface SerializableRunnable extends >>>> ????? >???? Runnable,Serializable { >>>> ????? >????? >????? } >>>> ????? >????? >????? public static class MyCode implements >>>> ???? SerializableRunnable { >>>> ????? >????? >????????? SerializableRunnable runnable2 = () >>>> ????? >????? >????????????????? -> { >>>> ????? >????? > System.out.println("HELLO"+this.getClass()); >>>> ????? >????? >????????? }; >>>> ????? >????? >????????? private byte[] serialize(Object o) { >>>> ????? >????? >????????????? ByteArrayOutputStream baos; >>>> ????? >????? >????????????? try ( >>>> ????? >????? > ObjectOutputStream oos >>>> ????? >????? >????????????????????? = new ObjectOutputStream(baos = >>>> new >>>> ????? >????? > ByteArrayOutputStream())) { >>>> ????? >????? >????????????????? oos.writeObject(o); >>>> ????? >????? >????????????? } catch (IOException e) { >>>> ????? >????? >????????????????? throw new RuntimeException(e); >>>> ????? >????? >????????????? } >>>> ????? >????? >????????????? return baos.toByteArray(); >>>> ????? >????? >????????? } >>>> ????? >????? >????????? private T deserialize(byte[] bytes) { >>>> ????? >????? >????????????? try ( >>>> ????? >????? >?????????????????????? ObjectInputStream ois >>>> ????? >????? >????????????????????? = new ObjectInputStream(new >>>> ????? >????? > ByteArrayInputStream(bytes))) { >>>> ????? >????? >????????????????? return (T) ois.readObject(); >>>> ????? >????? >????????????? } catch >>>> (IOException|ClassNotFoundException >>> e) { >>>> ????? >????? > throw new RuntimeException(e); >>>> ????? >????? >????????????? } >>>> ????? >????? >????????? } >>>> ????? >????? >????????? @Override >>>> ????? >????? >????????? public void run() { >>>> ????? >????? > System.out.println("??????????????? this: >>>> ???? "+this); >>>> ????? >????? >????????????? SerializableRunnable deSerializedThis >>>> ????? >????? >????????????????????? = deserialize(serialize(this)); >>>> ????? >????? >????????????? System.out.println(" deSerializedThis: " >>>> ????? >????? > +deSerializedThis); >>>> ????? >????? > >>>> ????? >????? >????????????? SerializableRunnable runnable = runnable2; >>>> ????? >????? > System.out.println("??????????? runnable: >>>> ???? "+runnable); >>>> ????? >????? >????????????? SerializableRunnable deSerializedRunnable >>>> ????? >????? >????????????????????? = >>>> deserialize(serialize(runnable)); >>>> ????? >????? > System.out.println("deSerializedRunnable: " >>>> ????? >????? > +deSerializedRunnable); >>>> ????? >????? >????????? } >>>> ????? >????? >????? } >>>> ????? >????? >????? public static void main(String[] args) throws >>> Exception { >>>> ????? >????? > ClassLoader myCl = new MyClassLoader( >>>> ????? >????? > >>> SerializedLambdaTest.class.getClassLoader() >>>> ????? >????? >????????? ); >>>> ????? >????? >????????? Class myCodeClass = Class.forName( >>>> ????? >????? > >>>> ???? SerializedLambdaTest.class.getName()+"$MyCode", >>>> ????? >????? >????????????????? true, >>>> ????? >????? >????????????????? myCl >>>> ????? >????? >????????? ); >>>> ????? >????? >????????? Runnable myCode = (Runnable) >>>> ???? myCodeClass.newInstance(); >>>> ????? >????? >????????? myCode.run(); >>>> ????? >????? >????? } >>>> ????? >????? >????? static class MyClassLoader extends ClassLoader { >>>> ????? >????? >????????? MyClassLoader(ClassLoader parent) { >>>> ????? >????? >????????????? super(parent); >>>> ????? >????? >????????? } >>>> ????? >????? >????????? @Override >>>> ????? >????? >????????? protected Class loadClass(String >>>> name,boolean >>>> ???? resolve) >>>> ????? >????? >????????????????? throws ClassNotFoundException { >>>> ????? >????? >????????????? if (name.startsWith("test.")) >>>> ????? >????? >????????????????? synchronized >>>> (getClassLoadingLock(name)) { >>>> ????? >????? >????????????????????? Class c = >>>> findLoadedClass(name); >>>> ????? >????? >????????????????????? if (c==null) >>>> ????? >????? >????????????????????????? c = findClass(name); >>>> ????? >????? >????????????????????? if (resolve) >>>> ????? >????? > resolveClass(c); >>>> ????? >????? >????????????????????? return c; >>>> ????? >????? >????????????????? } >>>> ????? >????? >????????????? else >>>> ????? >????? >????????????????? return super.loadClass(name,resolve); >>>> ????? >????? >????????? } >>>> ????? >????? >????????? @Override >>>> ????? >????? >????????? protected Class findClass(String name) >>>> throws >>>> ????? >????? >????????????????? ClassNotFoundException { >>>> ????? >????? >????????????? String path = >>>> ???? name.replace('.','/').concat(".class"); >>>> ????? >????? >????????????? try ( InputStream is = >>>> ???? getResourceAsStream(path)) { >>>> ????? >????? >????????????????? if (is!=null) { >>>> ????? >????? >????????????????????? byte[] bytes = is.readAllBytes(); >>>> ????? >????? >????????????????????? return >>>> ???? defineClass(name,bytes,0,bytes.length); >>>> ????? >????? >????????????????? } else >>>> ????? >????? >????????????????????? throw new >>> ClassNotFoundException(name); >>>> ????? >????? >????????????? } catch (IOException e) { >>>> ????? >????? >????????????????? throw new >>>> ClassNotFoundException(name,e); >>>> ????? >????? >????????????? } >>>> ????? >????? >????????? } >>>> ????? >????? >????? } >>>> ????? >????? > } >>>> ????? >????? > >>>> ????? > >>>> > From christoph.langer at sap.com Tue Mar 26 08:09:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 26 Mar 2019 08:09:42 +0000 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Message-ID: Hi Deepak, > Thanks for review. I think Naoto and Ramanand are right, we do update the > copyright year when it is not a clean backport. Please find the updated > version of webrev. > > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ Ok, you are right... Still wondering, whether in the test the copyright year should be 2012, 2019, since it is very much derived from the upstream version. But in the end, I don't want to bikeshed. All good for me ?? Thanks Christoph From chris.hegarty at oracle.com Tue Mar 26 09:07:19 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Mar 2019 09:07:19 +0000 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> Message-ID: <871D0D3C-1BCF-49F5-BA4A-9E1AF85B5C7A@oracle.com> > On 26 Mar 2019, at 07:54, Peter Levart wrote: > > Hi Seth, > > I think you stumbled on a "defect" of Java Serialization mechanism. Namely, the inability for it to correctly deserialize object graphs containing a cycle when an object in such cycle uses the "readResolve()" special method to replace the deserialized object with a replacement object. SerializedLambda is a class with instances that are 1st deserialized from stream then "replaced" with real lambda objects via the "readResolve()" method which constructs and returns the "real" lambda object. The deserialized SerializedLambda object is nevertheless attempted to be (temporarily) assigned to the field that would hold the final lambda object, which fails as the filed is of different type than SerializedLambda (or supertype). > > You can check my claims by changing the type of the field holding the lambda to java.lang.Object and see if it works... (It should if my memory serves me well :-) > > This is a known defect of Java serialization and is not specific to serialized lambda. Correct. Cycles in the object graph can be problematic when mixed with Serializable classes that have a readResolve method or the follow the Serialization Proxy Pattern. The Immutable Collection implementations are another such example. I see David pointed to some specific unresolved issues relating to Serializable lambdas. I haven't looked into them. -Chris. From goetz.lindenmaier at sap.com Tue Mar 26 11:57:45 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Mar 2019 11:57:45 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> Message-ID: Hi Mandy, thanks for reading the JEP and giving detailed feedback! > In the "Basic algorithm to compute the message" section: > > "This dataflow analysis walks the bytecodes forward simulating the execution > stack." > > Please elaborate it. Given a stack trace, it starts with the most recently > executed method and bytecode index, I assume it simulates the method from > the beginning of the method until it hits the instruction with the matching BCI. > Please describe it A data flow analysis is a fixpoint iteration on the code. It is a basic concept of compiler construction and used in lots of places in the hotspot code. I don't think I should further give an explanation of this. Maybe I could point to Wikipedia? https://en.wikipedia.org/wiki/Data-flow_analysis > and also the cases when it requires to look at its caller frame. Never. Only the method that was executed when the exception is thrown is needed. I only mention the backtrace because it happens to store the top method and the corresponding bytecode position in the top method. I tried to make this more clear by changing the formulation of the first two paragraphs. > "Computing either part of these messages can fail due to insufficient > information." > What are the cases that it fails to obtain the information? It'd be useful > to list some examples if not all. (a ? b : c).d You can not know whether the ?-expression yielded b or c, thus you don't know why the access .d failed. There is a corresponding example in [1]. > > The "Different bytecode variants of a method" section > > This section raises the case when a method representing an execution stack > frame throwing NPE becomes obsolete, it does not have the information > to compute the message lazily. So this falls into the "insufficient > information" category and no improved NPE message can be generated. Yes, note this also only addresses the method in which the exception was raised. > The "computation overhead" section > > I agree with the requirement to have minimal performance overhead to > the NPE construction cost. > > "NullPointerExceptions are thrown frequently." > "Fortunately, most Exceptions are discarded without looking at the message." > > This is interesting. Do you have any statistic on the number of NPE thrown > and swallowed on certain application/environment that you have gathered? No, I can try to generate some numbers, though. But this assumption was made by several others that commented on the previous review thread. For Throwable in general, it is also the assumption why the intermediate backtrace data structure is implemented instead of generating the stackFrames right away. > "If the message is printed based on the backtrace, it must be omitted > if the top frame was dropped from the backtrace." > > If NPE includes the hidden frames, `Throwable::getStackTrace` and > `Throwable::toString` and the VM printing of NPE stack trace needs to > filter the hidden frames. I think it's appropriate for this JEP to > cover rather than in a separate JBS issue. Hmm, I don't completely understand what you want to say, please excuse, I'm a foreign speaker :). I'll give a comprehensive answer: To my understanding this is a consequence of the existing JVM/class file implementation that calls methods that should be hidden to the user. The implementation drops these frames when the backtrace datastructure is computed. If this happens, the information needed to compute the message is lost, and it can not be printed. The fact that this happened must be remembered in the VM so that printing the message can be suppressed. Else a message for a completely wrong bytecode is printed. I think the JEP should mention that this is happening. How this is implemented and then pushed to the repo is not subject to a JEP, is it? I made a webrev of its own for this problem, so that the code can be looked at isolated of other, orthogonal issues. http://cr.openjdk.java.net/~goetz/wr19/8221077-hidden_to_frame/ > The "Message persistance" section > > I read this section like an implementation details Yes, I had the feeling that I was talking too much about implementation details, but mostly in the "Basic algorithm" section. This section discusses characteristics of NPE that differ from other exceptions and that were proposed in the course of the review of my original webrev. They are visible to the Java implementor. So I think this is just the basic information needed in a JEP. > I think this section > intends to call out that the message of NPE if constructed by user code > i.e. via public constructor, should not be altered including no-arg > constructor or pass a null message to 1-arg constructor. The enhanced > NPE message is proposed only when NPE is thrown due to null dereference > when executing bytecode. Yes. > I don't understand what you tried to say about "npe.getMessage() == > npe.getMessage()". > Throwable::getMessage does not guarantee to return same String object for > each invocation. It does not guarantee so, but it's the case for most exceptions. Usually, one calls super(msg) in an Exception constructor. It is a design decision to implement it that way, my original proposal was different. I'm fine with this design, but it should be mentioned I think. > When deserializing the class bytes may be of a different version, so > StackTraceElements > are serialized with its string form. Serializing NPE with a computed message > seems to be the only viable solution. I think implementing writeReplace() is a good idea, too. But Roger does not like it: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058513.html > The "Message content" section > > I think this section can break down into clear scenarios > 1. debug information is present > 2. debug information is absent > 3. the matching version of bytecode is not available > > I agree that the message should be easy for Java developers including the > beginners to understand the error. Hmm, only printing local variable names is affected by the debug information. So I don't think a section of its own is necessary. If the matching bytecode is not available, nothing can be printed. So it does not affect the content of the message. Should I call this section "Message wording"? I think this is closer to what I want to discuss in this paragraph. > You bring up a good question about the exception message format e.g. > whether with > quotation (none vs single quote vs double quote). It's good to have a guideline > on that while this is out of scope of this JEP. IAE was updated to include > module name, loader name and improve the error message for the developers > to understand the exception which is a good improvement. IAE quotes the names, which are user defined strings. It does not quote class names, method names etc. Here, I was asked to quote these, which is inconsistent with IAE. But there are other examples where method names are quoted ... So there is no clear line followed yet. In the end, I don't care, but want advice how to do it. (I would not quote ...). > "Alternatives" section > > "The current proposal is to implement this in the Java runtime in C++ accessing > directly the available datastructures in the metaspace." > > "Also, ASM and StackWalker do not support the full functionality needed. > StackWalker must be called in the NullPointerException constructor." > This is not true as you wrote in the subsequent sentence. If we choose > the implementation to Java, StackWalker will need to be extended to > read Throwable's backtrace. The senctence above describes the status quo. The current implementation of StackWalker must be called in the constructor. > Such specialized form can provide the > ability to fetch the bytecode in Method* if appropriate. This is > the implementation details. As discussed in the email thread, another > implementation choice could be a hybrid of native in the VM and Java > to accomplish this task (for example fetching the bytecode of the > current version could be done in the VM if we agree supporting > the redefinition case). Yes, obviously we can implement a lot of solutions. Instead of changing StackWalker, we could simply expose [2] java_lang_Throwable::get_method_and_bci() to Java in NPE. After all, we only need the method which happens to be stored as top frame in backtrace. > For logic that is not strictly needed to be done in the VM, doing it > in Java and library is a good option to consider (putting aside the > amount of new code you have to write). Looks like you can't evaluate > the alternatives since existing library code requires work in order to > prototype this in Java. So I'd say more investigation needs to be done > to decide on alternative implementation approaches. > "Testing" section > > "The basic implementation is in use in SAP's internal Java virtual machine since > 2006." > > This is good information. This assumes if the same implementation goes into > JDK. > So this is subject to the discussion and code review. I think it's adequate to say > unit tests will need to be developed. There is a unit test in the webrev. Please point out test cases you think are missing. [1] stems from this test. > I think this feature should not impact much of the existing VM code > and so running existing jtreg tests, jck tests and other existing test suites should > provide adequate coverage. > > I found [1] is quite useful to understand the scenarios this JEP considers. I > think it > would be useful to include them in the JEP perhaps as examples when > describing > the data flow analysis. I thought I picked out the most obvious example, pointer chasing, and used it in the motivation and the description of the basic algorithm. > [1] can be grouped into several categories and the JEP > can > just talk about the worthnoting groups and does not need to list all messages > such as > dereference a null receive on getfield, null array element vs null array Yes, I think it makes sense to put more messages into the JEP. But I would like to do that once it is agreed on the messages, so I don't need to edit the JEP all the time. The file referenced is simply generated by the test, so it's easy to update and sure to reflect the implementation. > This JEP includes a few links to the C++ functions in the current webrev. I > appreciate that and I assume they will be taken out at some point. Yes, sure, I can remove that. Best regards, Goetz. From andy.herrick at oracle.com Tue Mar 26 12:30:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Mar 2019 08:30:10 -0400 Subject: RFR: JDK-8215019: Allow --install-dir on windows In-Reply-To: <5559cac3-1685-d149-d816-bd45e4ad8f3c@oracle.com> References: <83569542-51ad-7d06-247b-274655fcbf51@oracle.com> <5559cac3-1685-d149-d816-bd45e4ad8f3c@oracle.com> Message-ID: <7085fd85-7c85-70d6-9987-5193f622014f@oracle.com> looks good. /Andy On 3/25/2019 6:35 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~almatvee/8215019/webrev.01/ > Updated webrev with added missing message in > HelpResources_zh_CN.properties and updated messages below: > > MSG_Help_win_install_dir=\ > \Relative sub-path under the default installation location\n\ > > message.invalid.install.dir=Warning: Invalid install directory {0}. > Install directory should be a relative sub-path under the default > installation location such as "Program Files". Defaulting to > application name "{1}". > > Thanks, > Alexander > > On 3/21/2019 10:08 AM, Andy Herrick wrote: >> I think you missed HelpResources_zh_CN.properties >> >> I think wording of help text: 'sub-path of the installation location >> of the application such as"Program Files" or "AppData"' is? >> misleading.? It reads like "Program files" or "AppDAta" are examples >> of the sub-path. >> >> The error message says: 'sub-path under default installation >> location" which is a little better. (though there should be a "the" >> before default). >> >> /Andy >> >> >> On 3/20/2019 8:05 PM, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Added support for --install-dir on Windows. It should be relative >>> path to "Program Files" or "AppData". >>> - If --install-dir is invalid we will use app name instead. >>> - Added two new tests to validate --install-dir and related >>> functionality. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8215019 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8215019/webrev.00/ >>> >>> Thanks, >>> Alexander >> > From shade at redhat.com Tue Mar 26 13:00:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Mar 2019 14:00:36 +0100 Subject: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms In-Reply-To: References: Message-ID: Ping, no takers? -Aleksey On 3/25/19 3:33 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221401 > > My major concern is to make tier1 passing on x86_32. This is one of the tests that fail. Smaller > heap size does not fit this test case, unfortunately. So, we have to disable it for 32-bit builds. > In fact, somebody did it already for 8u backport, but not upstream! > > Fix: > > diff -r 59816a32df2c test/jdk/java/math/BigInteger/LargeValueExceptions.java > --- a/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar 25 13:12:37 2019 +0100 > +++ b/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar 25 15:29:16 2019 +0100 > @@ -23,11 +23,11 @@ > > /* > * @test > * @bug 8200698 > * @summary Tests that exceptions are thrown for ops which would overflow > - * @requires os.maxMemory >= 4g > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g) > * @run testng/othervm -Xmx4g LargeValueExceptions > */ > import java.math.BigInteger; > import static java.math.BigInteger.ONE; > import org.testng.annotations.Test; > > > Testing: Linux {x86_64, x86_32} fastdebug build and test, jdk-submit (running) > > Thanks, > -Aleksey > -- Thanks, -Aleksey ------------------- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander From shade at redhat.com Tue Mar 26 13:02:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Mar 2019 14:02:18 +0100 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <5780df56-67ac-bfcd-04fd-cbd2941375b8@oracle.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> <5780df56-67ac-bfcd-04fd-cbd2941375b8@oracle.com> Message-ID: <9a787261-6ddf-8245-8904-22ed05508683@redhat.com> On 3/25/19 4:10 PM, Alan Bateman wrote: > On 25/03/2019 14:47, Aleksey Shipilev wrote: >> On 3/25/19 2:40 PM, Thomas St?fe wrote: >>> Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I >>> just built) is 1400m. >> That probably means something else is mapped into process memory that prevents continuous heap >> alloc. Does -Xmx2g work with fastdebug on your win32? We can adjust it later. > Sometimes -Xshare:off can help a bit on Windows 32-bit. > > -Alan. Alan, cannot see if you agree with the patch? Also, are we not doing "[TESTBUG]" prefixes in synopsis anymore? I see you changed it in JIRA. -- Thanks, -Aleksey From Alan.Bateman at oracle.com Tue Mar 26 13:28:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Mar 2019 13:28:30 +0000 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <9a787261-6ddf-8245-8904-22ed05508683@redhat.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> <5780df56-67ac-bfcd-04fd-cbd2941375b8@oracle.com> <9a787261-6ddf-8245-8904-22ed05508683@redhat.com> Message-ID: <58077756-f793-5769-7ea9-4188fe25f5ab@oracle.com> On 26/03/2019 13:02, Aleksey Shipilev wrote: > On 3/25/19 4:10 PM, Alan Bateman wrote: >> On 25/03/2019 14:47, Aleksey Shipilev wrote: >>> On 3/25/19 2:40 PM, Thomas St?fe wrote: >>>> Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I >>>> just built) is 1400m. >>> That probably means something else is mapped into process memory that prevents continuous heap >>> alloc. Does -Xmx2g work with fastdebug on your win32? We can adjust it later. >> Sometimes -Xshare:off can help a bit on Windows 32-bit. >> >> -Alan. > Alan, cannot see if you agree with the patch? The patch is okay, I just pointing out that disabling CDS will sometime help on Windows 32-bit, assuming it is enabled by default. > Also, are we not doing "[TESTBUG]" prefixes in > synopsis anymore? I see you changed it in JIRA. > The "testbug" label is used to tag test only issues, encoding in the bug description/commit message isn't really reliable. Yes, some areas have used "[TESTBUG]", there was a time when some people put a "TEST-BUG" prefix. There isn't a JDK-wide convention (at least not to my knowledge). -Alan From claes.redestad at oracle.com Tue Mar 26 13:33:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 Mar 2019 14:33:28 +0100 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf Message-ID: Hi, replacing a lingering use of Collections.unmodifiableSet with Set.copyOf in java.lang.module.Configuration is a small startup optimization. Bug: https://bugs.openjdk.java.net/browse/JDK-8221473 Patch: diff -r 5ee30b6991a7 src/java.base/share/classes/java/lang/module/Configuration.java --- a/src/java.base/share/classes/java/lang/module/Configuration.java Mon Dec 03 16:25:27 2018 +0100 +++ b/src/java.base/share/classes/java/lang/module/Configuration.java Tue Mar 26 14:39:16 2019 +0100 @@ -575,7 +575,10 @@ } Set reads(ResolvedModule m) { - return Collections.unmodifiableSet(graph.get(m)); + // The sets stored in the graph are immutable sets, so copyOf is a + // cheap way to return an unmodifiable Set, while also explicitly + // null-checking. + return Set.copyOf(graph.get(m)); } /** Thanks! /Claes From claes.redestad at oracle.com Tue Mar 26 13:44:06 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 Mar 2019 14:44:06 +0100 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: References: Message-ID: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> On 2019-03-26 14:33, Claes Redestad wrote: > Hi, > > replacing a lingering use of Collections.unmodifiableSet with Set.copyOf > in java.lang.module.Configuration is a small startup optimization. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221473 Or with this less verbose comment (suggested offline by Alan): diff -r 5ee30b6991a7 src/java.base/share/classes/java/lang/module/Configuration.java --- a/src/java.base/share/classes/java/lang/module/Configuration.java Mon Dec 03 16:25:27 2018 +0100 +++ b/src/java.base/share/classes/java/lang/module/Configuration.java Tue Mar 26 14:50:55 2019 +0100 @@ -575,7 +575,8 @@ } Set reads(ResolvedModule m) { - return Collections.unmodifiableSet(graph.get(m)); + // The sets stored in the graph are already immutable sets + return Set.copyOf(graph.get(m)); } /** From forax at univ-mlv.fr Tue Mar 26 13:53:35 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 26 Mar 2019 14:53:35 +0100 (CET) Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> References: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> Message-ID: <1447934259.599888.1553608415982.JavaMail.zimbra@u-pem.fr> Looks good to me. R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev" > Envoy?: Mardi 26 Mars 2019 14:44:06 > Objet: Re: RFR: 8221473: Configuration::reads can use Set.copyOf > On 2019-03-26 14:33, Claes Redestad wrote: >> Hi, >> >> replacing a lingering use of Collections.unmodifiableSet with Set.copyOf >> in java.lang.module.Configuration is a small startup optimization. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221473 > > Or with this less verbose comment (suggested offline by Alan): > > diff -r 5ee30b6991a7 > src/java.base/share/classes/java/lang/module/Configuration.java > --- a/src/java.base/share/classes/java/lang/module/Configuration.java > Mon Dec 03 16:25:27 2018 +0100 > +++ b/src/java.base/share/classes/java/lang/module/Configuration.java > Tue Mar 26 14:50:55 2019 +0100 > @@ -575,7 +575,8 @@ > } > > Set reads(ResolvedModule m) { > - return Collections.unmodifiableSet(graph.get(m)); > + // The sets stored in the graph are already immutable sets > + return Set.copyOf(graph.get(m)); > } > > /** From Alan.Bateman at oracle.com Tue Mar 26 13:54:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Mar 2019 13:54:17 +0000 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> References: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> Message-ID: On 26/03/2019 13:44, Claes Redestad wrote: > > Or with this less verbose comment (suggested offline by Alan): > > diff -r 5ee30b6991a7 > src/java.base/share/classes/java/lang/module/Configuration.java > --- a/src/java.base/share/classes/java/lang/module/Configuration.java > Mon Dec 03 16:25:27 2018 +0100 > +++ b/src/java.base/share/classes/java/lang/module/Configuration.java > Tue Mar 26 14:50:55 2019 +0100 > @@ -575,7 +575,8 @@ > ???? } > > ???? Set reads(ResolvedModule m) { > -??????? return Collections.unmodifiableSet(graph.get(m)); > +??????? // The sets stored in the graph are already immutable sets > +??????? return Set.copyOf(graph.get(m)); > ???? } This looks good. -Alan From shade at redhat.com Tue Mar 26 13:56:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Mar 2019 14:56:44 +0100 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <58077756-f793-5769-7ea9-4188fe25f5ab@oracle.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> <5780df56-67ac-bfcd-04fd-cbd2941375b8@oracle.com> <9a787261-6ddf-8245-8904-22ed05508683@redhat.com> <58077756-f793-5769-7ea9-4188fe25f5ab@oracle.com> Message-ID: <06d34271-8c77-2f0f-8bd0-f30c399d72ee@redhat.com> On 3/26/19 2:28 PM, Alan Bateman wrote: >> Also, are we not doing "[TESTBUG]" prefixes in >> synopsis anymore? I see you changed it in JIRA. >> > The "testbug" label is used to tag test only issues, encoding in the bug description/commit message > isn't really reliable. Yes, some areas have used "[TESTBUG]", there was a time when some people put > a "TEST-BUG" prefix. There isn't a JDK-wide convention (at least not to my knowledge). Understood, dropped "[TESTBUG]" from the other issue I have around. Thanks, -Aleksey From claes.redestad at oracle.com Tue Mar 26 14:11:48 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 Mar 2019 15:11:48 +0100 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: <1447934259.599888.1553608415982.JavaMail.zimbra@u-pem.fr> References: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> <1447934259.599888.1553608415982.JavaMail.zimbra@u-pem.fr> Message-ID: <931221b2-7d17-33ca-a657-987cf4f66cce@oracle.com> R?mi, Alan, thanks for reviewing! /Claes On 2019-03-26 14:53, Remi Forax wrote: > Looks good to me. > > R?mi From mik3hall at gmail.com Tue Mar 26 14:55:01 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 26 Mar 2019 09:55:01 -0500 Subject: jpackage Packaging Tool Early Access Update 4 In-Reply-To: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> References: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> Message-ID: > On Mar 19, 2019, at 11:17 AM, Andy Herrick wrote: > > The fourth EA build (Build 30) of jpackage tool is available at https://jdk.java.net/jpackage/ > > Note this build contains significant Command Line Interface changes. > > Issues addressed since EA 3 (build 17): > > JDK-8219678 CLI changes in jpackage I just tried re-building my OS X app with this version - Update 4. I am assuming that ?overwrite is no longer an option because it is now the default only choice? This one I?m not sure I?m understanding? jdk.jpackage.internal.PackagerException: Error: Option [--mac-bundle-identifier] is not valid in create-image mode. I had added this because the default generated bundle identifier at the time didn?t seem the best. It was IIRC the same as the application name or something one level. My understanding is sort of best practice is to use a url or reverse url type id. But shouldn?t there be some way when creating the OS X application image to indicate this? Bundle identifiers https://stackoverflow.com/questions/40619639/os-x-bundle-identifier-name-best-practice-in-this-situation https://discussions.apple.com/thread/1626954 From andrew_m_leonard at uk.ibm.com Tue Mar 26 14:57:34 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 14:57:34 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> Message-ID: Hi Ivan, Yes, i'm happy with that, as you say the simple constructor change fixes the immediate issue, but not necessarily the extended issue of a non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably an enhanced issue to cover in a separate bug... I've created a new webrev.02 with just the constructor change and the testcase: http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ 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 From: Ivan Gerasimov To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 01:18 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Thanks Andrew! Introducing getCharSequenceCoder() is actually an enhancement, which may improve pre-allocation in certain cases. It's not actually required to restore correctness of StringBuilder/Buffer constructors. I recommend to separate it from this bug fix, so it can be discussed separately, and determined if this is the best approach to this enhancement. If you agree, I can adjust your latest patch accordingly, run it through the Mach5 test systems and push it on your behalf. With kind regards, Ivan On 3/25/19 5:00 PM, Andrew Leonard wrote: Hi Ivan, Here is my updated webrev: http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ 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 From: Ivan Gerasimov To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 25/03/2019 22:55 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified I was thinking of organizing code similar to what is done in AbstractStringBuilder(int): if (COMPACT_STRINGS && coderHint == LATIN1) { value = new byte[capacity]; coder = LATIN1; } else { value = StringUTF16.newBytesFor(capacity); coder = UTF16; } With kind regards, Ivan On 3/25/19 3:45 PM, Andrew Leonard wrote: Hi Ivan, I think I see what you're saying, you mean we also need to correct this line in AbstractStringBuilder constructor: value = (coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); to be maybe: value = (COMPACT_STRINGS && coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); The passed in coder stills need to be correct, since with COMPACT_STRINGS a string could be UTF16 if it cannot be compacted, so it's more than just a hint isn't it? 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 From: Ivan Gerasimov To: Andrew Leonard , core-libs-dev at openjdk.java.net Date: 25/03/2019 22:20 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew! Thanks for finding this bug! Your fix solves the problem. However, I think the main issue is that the constructor AbstractStringBuilder(byte,int,int) is now broken: as you discovered, it allows to create a string buffer with the coder LATIN1 when COMPACT_STRINGS is false. Wouldn't it make sense to rename the argument of the constructor to, say, coderHint, and then either use it as the coder if COMPACT_STRINGS==true, or discard it otherwise. What do you think? With kind regards, Ivan On 3/25/19 12:45 PM, Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to a JDK-13 regression? > > Patch with jtreg testcase here: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > > Many 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 > -- With kind regards, Ivan Gerasimov 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 -- With kind regards, Ivan Gerasimov 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 -- With kind regards, Ivan Gerasimov 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 seth.lytle at gmail.com Tue Mar 26 15:04:59 2019 From: seth.lytle at gmail.com (seth lytle) Date: Tue, 26 Mar 2019 11:04:59 -0400 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> <883c06a4-13f4-98e0-23f3-b34525c35bc1@gmail.com> Message-ID: awesome ! thanks for the workaround peter wrote: > You can check my claims by changing the type of the field holding the > lambda to java.lang.Object and see if it works... (It should if my > memory serves me well :-) On Tue, Mar 26, 2019 at 3:54 AM Peter Levart wrote: > Hi Seth, > > I think you stumbled on a "defect" of Java Serialization mechanism. > Namely, the inability for it to correctly deserialize object graphs > containing a cycle when an object in such cycle uses the "readResolve()" > special method to replace the deserialized object with a replacement > object. SerializedLambda is a class with instances that are 1st > deserialized from stream then "replaced" with real lambda objects via > the "readResolve()" method which constructs and returns the "real" > lambda object. The deserialized SerializedLambda object is nevertheless > attempted to be (temporarily) assigned to the field that would hold the > final lambda object, which fails as the filed is of different type than > SerializedLambda (or supertype). > > You can check my claims by changing the type of the field holding the > lambda to java.lang.Object and see if it works... (It should if my > memory serves me well :-) > > This is a known defect of Java serialization and is not specific to > serialized lambda. > > There were some unsuccessful attempts to fix it during (re)discovery > when lambdas were being added to Java. > > Regards, Peter > > On 3/26/19 5:03 AM, seth lytle wrote: > > it's a nested class, but it's loaded with the same class loader as the > > toplevel. > > which is what i thought you thought was the problem when > > > > you wrote: > >> this test loads a nested type into a different classloader to its > > enclosing type > > > > and: > >> it is a requirement that all nest members be defined in the same > >> package - which implies the same classloader > > > > > > > > On Mon, Mar 25, 2019 at 11:40 PM David Holmes > > wrote: > > > >> On 26/03/2019 1:06 pm, seth lytle wrote: > >>> i still get the same stack trace after breaking the example out into > two > >>> files. does that sufficiently address the nesting issue ? > >> ?? > >> > >> public static class MyCode ... > >> > >> is still a nested class. > >> > >> David > >> > >>> file: SerializedLambdaTest > >>> package test; > >>> > >>> import java.io.ByteArrayInputStream; > >>> import java.io.ByteArrayOutputStream; > >>> import java.io.IOException; > >>> import java.io.ObjectInputStream; > >>> import java.io.ObjectOutputStream; > >>> import java.io.Serializable; > >>> > >>> // from: https://bugs.openjdk.java.net/browse/JDK-8008770 > >>> public class SerializedLambdaTest implements Runnable { > >>> public void run() { new MyCode().run(); } > >>> public interface SerializableRunnable extends > Runnable,Serializable > >> { > >>> } > >>> public static class MyCode implements SerializableRunnable { > >>> SerializableRunnable runnable2 = () > >>> -> { > >>> System.out.println("HELLO"+this.getClass()); > >>> }; > >>> private byte[] serialize(Object o) { > >>> ByteArrayOutputStream baos; > >>> try ( > >>> ObjectOutputStream oos > >>> = new ObjectOutputStream(baos = new > >>> ByteArrayOutputStream())) { > >>> oos.writeObject(o); > >>> } catch (IOException e) { > >>> throw new RuntimeException(e); > >>> } > >>> return baos.toByteArray(); > >>> } > >>> private T deserialize(byte[] bytes) { > >>> try ( > >>> ObjectInputStream ois > >>> = new ObjectInputStream(new > >>> ByteArrayInputStream(bytes))) { > >>> return (T) ois.readObject(); > >>> } catch (IOException|ClassNotFoundException e) { > >>> throw new RuntimeException(e); > >>> } > >>> } > >>> @Override > >>> public void run() { > >>> System.out.println(" this: "+this); > >>> SerializableRunnable deSerializedThis > >>> = deserialize(serialize(this)); > >>> System.out.println(" deSerializedThis: " > >>> +deSerializedThis); > >>> > >>> SerializableRunnable runnable = runnable2; > >>> System.out.println(" runnable: "+runnable); > >>> SerializableRunnable deSerializedRunnable > >>> = deserialize(serialize(runnable)); > >>> System.out.println("deSerializedRunnable: " > >>> +deSerializedRunnable); > >>> } > >>> } > >>> } > >>> > >>> > >>> file: MyClassLoader > >>> package test; > >>> > >>> import java.io.IOException; > >>> import java.io.InputStream; > >>> > >>> class MyClassLoader extends ClassLoader { > >>> MyClassLoader(ClassLoader parent) { > >>> super(parent); > >>> } > >>> @Override > >>> protected Class loadClass(String name,boolean resolve) throws > >>> ClassNotFoundException { > >>> if (name.startsWith("test.")) > >>> synchronized (getClassLoadingLock(name)) { > >>> Class c = findLoadedClass(name); > >>> if (c==null) c = findClass(name); > >>> if (resolve) resolveClass(c); > >>> return c; > >>> } > >>> else return super.loadClass(name,resolve); > >>> } > >>> @Override > >>> protected Class findClass(String name) throws > >>> ClassNotFoundException { > >>> String path = name.replace('.','/').concat(".class"); > >>> try (final InputStream is = getResourceAsStream(path)) { > >>> if (is!=null) { > >>> byte[] bytes = is.readAllBytes(); > >>> return defineClass(name,bytes,0,bytes.length); > >>> } > >>> else throw new ClassNotFoundException(name); > >>> } catch (IOException e) { > >>> throw new ClassNotFoundException(name,e); > >>> } > >>> } > >>> public static void main(String[] args) throws Exception { > >>> ClassLoader myCl = new MyClassLoader( > >>> MyClassLoader.class.getClassLoader() > >>> ); > >>> Class myCodeClass = Class.forName( > >>> "test.SerializedLambdaTest", > >>> true, > >>> myCl > >>> ); > >>> Runnable myCode = (Runnable) myCodeClass.newInstance(); > >>> myCode.run(); > >>> } > >>> } > >>> > >>> > >>> > >>> > >>> On Mon, Mar 25, 2019 at 10:34 PM David Holmes >>> > wrote: > >>> > >>> Hi Seth, > >>> > >>> On 26/03/2019 12:16 pm, seth lytle wrote: > >>> > i haven't changed the assignment from the original test case > >>> (which was > >>> > accepted as valid at the time). i haven't gone through it in > >>> depth, but > >>> > assume that it's ok and used it since people are already > familiar > >>> with > >>> > it. it appears to me that that example uses reflection to > >>> allocate an > >>> > instance using a definitive class loader and then uses a > runnable > >>> for > >>> > the serialization/deserialization cycle > >>> > > >>> > the class cast exception happens not at the example level, but > >> deep > >>> > inside `readObject` when it's doing an internal assignment > >>> > > >>> > perhaps my choice of words "into a new classloader" was > >>> insufficient or > >>> > misleading. in both examples that i've come up with so far, the > >>> class > >>> > loader calls defineClass directly without first delegating to > >>> super (for > >>> > a subset of the classes). so "into a definitive classloader" > >>> might have > >>> > been a better choice > >>> > >>> I think the basic problem is that this test loads a nested type > into > >> a > >>> different classloader to its enclosing type. I can easily imagine > >> this > >>> messing up the code that gets generated to implement the lambda > >>> expression - but I'd need to examine that code in detail to see > >> exactly > >>> why (others may know this more readily than I do). It's unclear > to me > >>> whether this would be considered a bug or a "don't do that" > >> situation. > >>> As of JDK 11, nested types define "nests" at the VM level (see > >> JEP-181) > >>> and it is a requirement that all nest members be defined in the > same > >>> package - which implies the same classloader. > >>> > >>> David > >>> > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > On Mon, Mar 25, 2019 at 9:34 PM David Holmes > >>> > >>> > >>> >> wrote: > >>> > > >>> > Hi Seth, > >>> > > >>> > On 26/03/2019 11:22 am, seth lytle wrote: > >>> > > if a lambda is a field and captures `this`, and it's > >>> deserialized > >>> > into a > >>> > > new class loader, it throws a ClassCastException. > >>> > > >>> > Not sure I follow. If you load a class into a different > >>> classloader > >>> > then > >>> > you get a different type. It might appear the same to you > but > >>> it is a > >>> > distinct type, so you can't assign across different > instances > >>> loaded by > >>> > different classloaders. > >>> > > >>> > Cheers, > >>> > David > >>> > ----- > >>> > > >>> > > i came across this bug > >>> > > independently while writing a test, but then found an > old > >>> openjdk > >>> > bug with > >>> > > a similar issue and tweaked the test case (source > below). > >>> my version > >>> > > differs only in > >>> > > 1. moved the lambda to a field > >>> > > 2. reference `this` in it > >>> > > 3. uses readAllBytes instead of the internal method > >>> > > 4. formatting > >>> > > > >>> > > running with java 11 or 12 (or java 8 using a substitute > >> for > >>> > readAllBytes) > >>> > > results in: > >>> > > this: > >>> test.SerializedLambdaTest$MyCode at 8efb846 > >>> > > deSerializedThis: > >>> test.SerializedLambdaTest$MyCode at 2b71fc7e > >>> > > runnable: > >>> > > > >>> > > >>> > >> test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 > >>> > > Exception in thread "main" java.lang.ClassCastException: > >>> cannot > >>> > assign > >>> > > instance of java.lang.invoke.SerializedLambda to field > >>> > > test.SerializedLambdaTest$MyCode.runnable2 of type > >>> > > test.SerializedLambdaTest$SerializableRunnable in > instance > >> of > >>> > > test.SerializedLambdaTest$MyCode > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> > .ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> > .ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readSerialData(ObjectInputStream.java:2278) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readObject0(ObjectInputStream.java:1594) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readArray(ObjectInputStream.java:1993) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readObject0(ObjectInputStream.java:1588) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readSerialData(ObjectInputStream.java:2249) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readObject0(ObjectInputStream.java:1594) > >>> > > at > >>> > > java.base/java.io > >>> > > >>> >>> .ObjectInputStream.readObject(ObjectInputStream.java:430) > >>> > > at > >>> > > > >>> > > >>> > >> > test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) > >>> > > at > >>> test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) > >>> > > at > >>> test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) > >>> > > > >>> > > > >>> > > > >>> > > https://bugs.openjdk.java.net/browse/JDK-8008770 > >>> > > > >>> > > > >>> > > package test; > >>> > > > >>> > > import java.io.ByteArrayInputStream; > >>> > > import java.io.ByteArrayOutputStream; > >>> > > import java.io.IOException; > >>> > > import java.io.InputStream; > >>> > > import java.io.ObjectInputStream; > >>> > > import java.io.ObjectOutputStream; > >>> > > import java.io.Serializable; > >>> > > > >>> > > // from: > https://bugs.openjdk.java.net/browse/JDK-8008770 > >>> > > public class SerializedLambdaTest { > >>> > > public interface SerializableRunnable extends > >>> > Runnable,Serializable { > >>> > > } > >>> > > public static class MyCode implements > >>> SerializableRunnable { > >>> > > SerializableRunnable runnable2 = () > >>> > > -> { > >>> > > > System.out.println("HELLO"+this.getClass()); > >>> > > }; > >>> > > private byte[] serialize(Object o) { > >>> > > ByteArrayOutputStream baos; > >>> > > try ( > >>> > > ObjectOutputStream oos > >>> > > = new ObjectOutputStream(baos = new > >>> > > ByteArrayOutputStream())) { > >>> > > oos.writeObject(o); > >>> > > } catch (IOException e) { > >>> > > throw new RuntimeException(e); > >>> > > } > >>> > > return baos.toByteArray(); > >>> > > } > >>> > > private T deserialize(byte[] bytes) { > >>> > > try ( > >>> > > ObjectInputStream ois > >>> > > = new ObjectInputStream(new > >>> > > ByteArrayInputStream(bytes))) { > >>> > > return (T) ois.readObject(); > >>> > > } catch (IOException|ClassNotFoundException > >> e) { > >>> > > throw new RuntimeException(e); > >>> > > } > >>> > > } > >>> > > @Override > >>> > > public void run() { > >>> > > System.out.println(" this: > >>> "+this); > >>> > > SerializableRunnable deSerializedThis > >>> > > = deserialize(serialize(this)); > >>> > > System.out.println(" deSerializedThis: " > >>> > > +deSerializedThis); > >>> > > > >>> > > SerializableRunnable runnable = runnable2; > >>> > > System.out.println(" runnable: > >>> "+runnable); > >>> > > SerializableRunnable deSerializedRunnable > >>> > > = deserialize(serialize(runnable)); > >>> > > System.out.println("deSerializedRunnable: " > >>> > > +deSerializedRunnable); > >>> > > } > >>> > > } > >>> > > public static void main(String[] args) throws > >> Exception { > >>> > > ClassLoader myCl = new MyClassLoader( > >>> > > > >> SerializedLambdaTest.class.getClassLoader() > >>> > > ); > >>> > > Class myCodeClass = Class.forName( > >>> > > > >>> SerializedLambdaTest.class.getName()+"$MyCode", > >>> > > true, > >>> > > myCl > >>> > > ); > >>> > > Runnable myCode = (Runnable) > >>> myCodeClass.newInstance(); > >>> > > myCode.run(); > >>> > > } > >>> > > static class MyClassLoader extends ClassLoader { > >>> > > MyClassLoader(ClassLoader parent) { > >>> > > super(parent); > >>> > > } > >>> > > @Override > >>> > > protected Class loadClass(String > name,boolean > >>> resolve) > >>> > > throws ClassNotFoundException { > >>> > > if (name.startsWith("test.")) > >>> > > synchronized > (getClassLoadingLock(name)) { > >>> > > Class c = findLoadedClass(name); > >>> > > if (c==null) > >>> > > c = findClass(name); > >>> > > if (resolve) > >>> > > resolveClass(c); > >>> > > return c; > >>> > > } > >>> > > else > >>> > > return super.loadClass(name,resolve); > >>> > > } > >>> > > @Override > >>> > > protected Class findClass(String name) > throws > >>> > > ClassNotFoundException { > >>> > > String path = > >>> name.replace('.','/').concat(".class"); > >>> > > try ( InputStream is = > >>> getResourceAsStream(path)) { > >>> > > if (is!=null) { > >>> > > byte[] bytes = is.readAllBytes(); > >>> > > return > >>> defineClass(name,bytes,0,bytes.length); > >>> > > } else > >>> > > throw new > >> ClassNotFoundException(name); > >>> > > } catch (IOException e) { > >>> > > throw new > ClassNotFoundException(name,e); > >>> > > } > >>> > > } > >>> > > } > >>> > > } > >>> > > > >>> > > >>> > > From Roger.Riggs at oracle.com Tue Mar 26 15:20:03 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Mar 2019 11:20:03 -0400 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> Message-ID: <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 >> >> Many 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 andrew_m_leonard at uk.ibm.com Tue Mar 26 15:45:12 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 15:45:12 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> Message-ID: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Ivan's view is that behaviour was an extended issue, which it is, but I thought it was nice to add.. Which patch do we favour? webrev-01 or -02 ? 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 From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 26/03/2019 15:24 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Sent by: "core-libs-dev" Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.02_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=ngqEACtWA78nk3hjU2xnyCiSOxIWND78nu1cyLEm-AY&s=aSxSRCsMKXFdSan44pFE_HDyFSrG74ouBFHWRgNMpwU&e= > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=ngqEACtWA78nk3hjU2xnyCiSOxIWND78nu1cyLEm-AY&s=r838cg8M1zsCUnl92A3BDPbi8A9079OZgVAns6y9UaQ&e= > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.00_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=ngqEACtWA78nk3hjU2xnyCiSOxIWND78nu1cyLEm-AY&s=Ej64_gAZAfrZ4BorSUPkbteQmpKzK8MbOU64AMdu-0A&e= >> >> bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221430&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=ngqEACtWA78nk3hjU2xnyCiSOxIWND78nu1cyLEm-AY&s=bPBLgiXGX5onQ7uEJfpSnzz5bb-WsCUBmucWCU77hDs&e= >> >> Many 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 andy.herrick at oracle.com Tue Mar 26 15:56:43 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Mar 2019 11:56:43 -0400 Subject: jpackage Packaging Tool Early Access Update 4 In-Reply-To: References: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> Message-ID: <3f3f339c-8455-f012-a08f-48884de93b7e@oracle.com> yes - this is a late regression in EA 4 which will shortly be remedied . The option --file-associations, and all of the mac specific options, need to be valid in create-image mode on MAC. see: https://bugs.openjdk.java.net/browse/JDK-8221256 /Andy On 3/26/2019 10:55 AM, Michael Hall wrote: > > >> On Mar 19, 2019, at 11:17 AM, Andy Herrick > > wrote: >> >> The fourth EA build (Build 30) of jpackage tool is available at >> https://jdk.java.net/jpackage/ >> >> Note this build contains significant Command Line Interface changes. >> >> Issues addressed since EA 3 (build 17): >> >> JDK-8219678???? CLI changes in jpackage > > I just tried re-building my OS X app with this version - Update 4. > I am assuming that ?overwrite is no longer an option because it is now > the default only choice? > > This one I?m not sure I?m understanding? > jdk.jpackage.internal.PackagerException: Error: Option > [--mac-bundle-identifier] is not valid in create-image mode. > > I had added this because the default generated bundle identifier at > the time didn?t seem the best. It was IIRC the same as the application > name or something one level. > My understanding is sort of best practice is to use a url or reverse > url type id. > But shouldn?t there be some way when creating the OS X application > image to indicate this? > > Bundle identifiers > https://stackoverflow.com/questions/40619639/os-x-bundle-identifier-name-best-practice-in-this-situation > https://discussions.apple.com/thread/1626954 > From mik3hall at gmail.com Tue Mar 26 16:01:58 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 26 Mar 2019 11:01:58 -0500 Subject: jpackage Packaging Tool Early Access Update 4 In-Reply-To: <3f3f339c-8455-f012-a08f-48884de93b7e@oracle.com> References: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> <3f3f339c-8455-f012-a08f-48884de93b7e@oracle.com> Message-ID: > On Mar 26, 2019, at 10:56 AM, Andy Herrick wrote: > > yes - this is a late regression in EA 4 which will shortly be remedied . > > The option --file-associations, and all of the mac specific options, need to be valid in create-image mode on MAC. > > see: https://bugs.openjdk.java.net/browse/JDK-8221256 > > /Andy > OK thanks. But I guess now I don?t get why ?overwrite was removed. This does keep it from writing over an old one. You can manually do that first but why not include a CLI option to do it? From andy.herrick at oracle.com Tue Mar 26 16:13:02 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Mar 2019 12:13:02 -0400 Subject: jpackage Packaging Tool Early Access Update 4 In-Reply-To: References: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> <3f3f339c-8455-f012-a08f-48884de93b7e@oracle.com> Message-ID: <45510f07-8173-1def-1a46-5a791a94c51c@oracle.com> --overwrite was removed because our internal reviewers thought that was inconsistent with other tools. the problem was that the option required us to fully remove the directory tree /[.app], without regard to what is in it. other tools like jlink require a non-existent output path, and developer can easily "rm -rf" the directory before running jpackage. /Andy On 3/26/2019 12:01 PM, Michael Hall wrote: > > >> On Mar 26, 2019, at 10:56 AM, Andy Herrick > > wrote: >> >> yes - this is a late regression in EA 4 which will shortly be remedied . >> >> The option --file-associations, and all of the mac specific options, >> need to be valid in create-image mode on MAC. >> >> see: https://bugs.openjdk.java.net/browse/JDK-8221256 >> >> /Andy >> > > OK thanks. > But I guess now I don?t get why ?overwrite was removed. This does keep > it from writing over an old one. > You can manually do that first but why not include a CLI option to do it? > From mik3hall at gmail.com Tue Mar 26 16:17:57 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 26 Mar 2019 11:17:57 -0500 Subject: jpackage Packaging Tool Early Access Update 4 In-Reply-To: <45510f07-8173-1def-1a46-5a791a94c51c@oracle.com> References: <4dbd2f14-3168-037d-ede9-60b6515e328e@oracle.com> <3f3f339c-8455-f012-a08f-48884de93b7e@oracle.com> <45510f07-8173-1def-1a46-5a791a94c51c@oracle.com> Message-ID: <8ADB4CD7-68B6-48BC-BF88-DE7B6420E368@gmail.com> > On Mar 26, 2019, at 11:13 AM, Andy Herrick wrote: > > --overwrite was removed because our internal reviewers thought that was inconsistent with other tools. > > the problem was that the option required us to fully remove the directory tree /[.app], without regard to what is in it. > > other tools like jlink require a non-existent output path, and developer can easily "rm -rf" the directory before running jpackage. > > /Andy > > Yeah ok, I would say having it a CLI option puts the risk on the user. But as you say an easy work around. You do have to sudo for some of the embedded jdk files. Thanks From thomas.stuefe at gmail.com Tue Mar 26 16:26:55 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Mar 2019 17:26:55 +0100 Subject: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms In-Reply-To: References: Message-ID: Looks fine and trivial. ..Thomas On Tue, Mar 26, 2019 at 2:02 PM Aleksey Shipilev wrote: > Ping, no takers? > > -Aleksey > > On 3/25/19 3:33 PM, Aleksey Shipilev wrote: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8221401 > > > > My major concern is to make tier1 passing on x86_32. This is one of the > tests that fail. Smaller > > heap size does not fit this test case, unfortunately. So, we have to > disable it for 32-bit builds. > > In fact, somebody did it already for 8u backport, but not upstream! > > > > Fix: > > > > diff -r 59816a32df2c > test/jdk/java/math/BigInteger/LargeValueExceptions.java > > --- a/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar > 25 13:12:37 2019 +0100 > > +++ b/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar > 25 15:29:16 2019 +0100 > > @@ -23,11 +23,11 @@ > > > > /* > > * @test > > * @bug 8200698 > > * @summary Tests that exceptions are thrown for ops which would > overflow > > - * @requires os.maxMemory >= 4g > > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g) > > * @run testng/othervm -Xmx4g LargeValueExceptions > > */ > > import java.math.BigInteger; > > import static java.math.BigInteger.ONE; > > import org.testng.annotations.Test; > > > > > > Testing: Linux {x86_64, x86_32} fastdebug build and test, jdk-submit > (running) > > > > Thanks, > > -Aleksey > > > > > -- > Thanks, > -Aleksey > > ------------------- > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric > Shander > > From brian.burkhalter at oracle.com Tue Mar 26 17:01:15 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Mar 2019 10:01:15 -0700 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: <1fbbace9-7b29-725a-147e-2dee9976b1b2@oracle.com> References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> <1fbbace9-7b29-725a-147e-2dee9976b1b2@oracle.com> Message-ID: I had to revise this again as I had put the new @throws UTFDataFomatException clause only on the package version of writeUTF() but not also on the public API version. CSR [2] withdrawn and updated also. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8219196/webrev.04/ [2] https://bugs.openjdk.java.net/browse/JDK-8221428 > On Mar 25, 2019, at 7:56 AM, Roger Riggs wrote: > > +1 > > On 03/22/2019 07:41 PM, Brian Burkhalter wrote: >> Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/ >> >>> On Mar 22, 2019, at 4:32 PM, Brian Burkhalter wrote: >>> >>> Patch updated for the sake of formality. > From ivan.gerasimov at oracle.com Tue Mar 26 17:21:54 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 26 Mar 2019 10:21:54 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> Message-ID: <717c96eb-b36a-b306-079b-de7f8d0a95bd@oracle.com> On 3/26/19 8:45 AM, Andrew Leonard wrote: > Hi Roger, > No worries, the more the merrier! > So that was one of my reasoning for adding getCharSequenceCode() was, > I think what you're suggesting is my webrev.01, > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > Ivan's view is that behaviour was an extended issue, which it is, but > I thought it was nice to add.. > Right. I agree it would be nice to add this as an enhancement, though I believe it would be clearer to fix one issue at a time. Personally, I like what you have in webrev-02, as it fixes the issue with wrong coder when compact strings are disabled. (The only minor change left is to add the bug id to the list of bugs in the regression test.) For the enhancement with determining the coder of the argument, I was thinking if it may be sensible to extend it to general CharSequence also (i.e. scan it in advance and see if all characters can be encoded with LATIN1). Maybe not. That's why I think it should be discussed within different request. With kind regards, Ivan > Which patch do we favour? webrev-01 or -02 ? > 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 > > > > > From: Roger Riggs > To: core-libs-dev at openjdk.java.net > Date: 26/03/2019 15:24 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > Sent by: "core-libs-dev" > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Sorry to be late to the review. > > For symmetry with the constructors StringBuffer(String), and > StringBuilder(String) > the determine the coder based on the input argument, I would recommend > using the getCharSequenceCoder added in the -01 webrev and calling > it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) > constructors. > > It would be symmetric with the getCoder() method (line 1635) > and select the appropriate coder base on the input value (if known.) > > Thanks, Roger > > > > On 03/26/2019 10:57 AM, Andrew Leonard wrote: > > Hi Ivan, > > Yes, i'm happy with that, as you say the simple constructor change fixes > > the immediate issue, but not necessarily the extended issue of a > > non-compactable CharSequence in COMPACT_STRINGS mode, but that's > probably > > an enhanced issue to cover in a separate bug... > > I've created a new webrev.02 with just the constructor change and the > > testcase: > > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > > > > 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 > > > > > > > > > > From: Ivan Gerasimov > > To: Andrew Leonard > > Cc: core-libs-dev at openjdk.java.net > > Date: 26/03/2019 01:18 > > Subject: Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Thanks Andrew! > > Introducing getCharSequenceCoder() is actually an enhancement, which may > > improve pre-allocation in certain cases. > > It's not actually required to restore correctness of > StringBuilder/Buffer > > constructors. > > I recommend to separate it from this bug fix, so it can be discussed > > separately, and determined if this is the best approach to this > > enhancement. > > If you agree, I can adjust your latest patch accordingly, run it through > > the Mach5 test systems and push it on your behalf. > > With kind regards, > > Ivan > > > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > > Hi Ivan, > > Here is my updated webrev: > > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > > > > 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 > > > > > > > > > > From: Ivan Gerasimov > > To: Andrew Leonard > > Cc: core-libs-dev at openjdk.java.net > > Date: 25/03/2019 22:55 > > Subject: Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > I was thinking of organizing code similar to what is done in > > AbstractStringBuilder(int): > > > > if (COMPACT_STRINGS && coderHint == LATIN1) { > > value = new byte[capacity]; > > coder = LATIN1; > > } else { > > value = StringUTF16.newBytesFor(capacity); > > coder = UTF16; > > } > > > > With kind regards, > > Ivan > > > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > > Hi Ivan, > > I think I see what you're saying, you mean we also need to correct this > > line in AbstractStringBuilder > > constructor: > > value = (coder == LATIN1) > > ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > to be maybe: > > value = (COMPACT_STRINGS && coder == LATIN1) > > ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS > > a string could be UTF16 if > > it cannot be compacted, so it's more than just a hint isn't it? > > > > 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 > > > > > > > > > > From: Ivan Gerasimov > > To: Andrew Leonard , > > core-libs-dev at openjdk.java.net > > Date: 25/03/2019 22:20 > > Subject: Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Hi Andrew! > > > > Thanks for finding this bug! > > > > Your fix solves the problem. > > > > However, I think the main issue is that the constructor > > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > > it allows to create a string buffer with the coder LATIN1 when > > COMPACT_STRINGS is false. > > > > Wouldn't it make sense to rename the argument of the constructor to, > > say, coderHint, and then either use it as the coder if > > COMPACT_STRINGS==true, or discard it otherwise. > > > > What do you think? > > > > With kind regards, > > Ivan > > > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > >> Hi, > >> Please can I request a sponsor for this fix to a JDK-13 regression? > >> > >> Patch with jtreg testcase here: > >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > >> > >> Many 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 -- With kind regards, Ivan Gerasimov From adam.farley at uk.ibm.com Tue Mar 26 17:24:13 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 26 Mar 2019 17:24:13 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: Hiya Mandy, I've updated the webrev with your proposal, plus a few tweaks for formatting. http://cr.openjdk.java.net/~afarley/8216558.2/webrev Let me know what you think. Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 26/03/2019 03:51:29: > From: Mandy Chung > To: Adam Farley8 , Joe Darcy > Cc: core-libs-dev > Date: 26/03/2019 03:51 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > > On 3/25/19 11:36 AM, Adam Farley8 wrote: > Addendum: URL for new webrev: http://cr.openjdk.java.net/~afarley/ > 8216558.1/webrev/ > > Thanks for sending a versioned webrev. > > What is a USA test? > > UNREFLECT_SETTER_ACCESSIBLE. > > I was trying to be brief, and I lost readability. > > Will re-upload with the expanded name. > > > > > Why the assertion becomes conditional? > > Because we only need this check if the test is USA. > > Previously, setting a variable as accessible gave us a setter > without errors 100% of the time. > > The test expects this, and anticipates an empty list of variables > which threw errors when passed to unreflectSetter. > > Since we now throw an exception when calling the unreflectSetter > method, even when the variable is accessible, this check ensures > that the only variables throwing an exception are the static final fields. > > > > > Have you considered another way doing it? > > Yep, several. This seemed the simplest. > > Other options I considered were: > > -------------- > > 1) Changing the test to store a list of variables, rather than just > their names, so the "isAccessible" method could be used instead. > > Discarded because it makes the array compare slower for every test. > > 2) Editing the array of anticipated excludeds during test execution, > to remove the exceptions we don't expect to see. > > Discarded because the change seemed too bulky to accommodate a single test. > > 3) Make the "isAccessible" methods smarter, and rely on them > exclusively to determine the list of anticipated exceptions. > > Ditto > > --------------------- > > Option 3 could work. I prefer the one-liner stream check. > > Thoughts? > > > Each test case has a set of inaccessible fields under normal access checks. > For MH_UNREFLECT_GETTER_ACCESSIBLE and MH_UNREFLECT_SETTER_ACCESSIBLE > cases, before the patch, all fields are accessible as setAccessible(true) > is called on all fields. That's the special casing for these cases and > expect actualFieldNames is empty. > > This patch now changes the set of inaccessible fields for unreflectSetter > (static final fields are inaccessible). A cleaner way to fix this is > to filter a given set of inaccessible fields and return the set of > inaccessible fields applicable to a FieldLookup case. > > Attached is my suggested patch. It adds a new FieldLookup::inaccessibeFields > method and the XXX_ACCESSIBLE Lookup overrides it to do the filtering. > > Mandy > > > diff --git a/test/jdk/java/lang/invoke/VarHandles/accessibility/ > TestFieldLookupAccessibility.java b/test/jdk/java/lang/invoke/ > VarHandles/accessibility/TestFieldLookupAccessibility.java > --- a/test/jdk/java/lang/invoke/VarHandles/accessibility/ > TestFieldLookupAccessibility.java > +++ b/test/jdk/java/lang/invoke/VarHandles/accessibility/ > TestFieldLookupAccessibility.java > @@ -22,7 +22,7 @@ > */ > > /* @test > - * @bug 8152645 > + * @bug 8152645 8216558 > * @summary test field lookup accessibility of MethodHandles and VarHandles > * @compile TestFieldLookupAccessibility.java > * pkg/A.java pkg/B_extends_A.java pkg/C.java > @@ -96,6 +96,12 @@ > Object lookup(MethodHandles.Lookup l, Field f) throws Exception { > return l.unreflectGetter(cloneAndSetAccessible(f)); > } > + > + // Setting the accessibility bit of a Field grants access under > + // all conditions for MethodHandler getters > + Set inaccessibleFields(Set inaccessibleFields) { > + return new HashSet<>(); > + } > }, > MH_UNREFLECT_SETTER() { > Object lookup(MethodHandles.Lookup l, Field f) throws Exception { > @@ -103,13 +109,25 @@ > } > > boolean isAccessible(Field f) { > - return f.isAccessible() || !Modifier.isFinal > (f.getModifiers()); > + return f.isAccessible() && !Modifier.isStatic > (f.getModifiers()) || !Modifier.isFinal(f.getModifiers()); > } > }, > MH_UNREFLECT_SETTER_ACCESSIBLE() { > Object lookup(MethodHandles.Lookup l, Field f) throws Exception { > return l.unreflectSetter(cloneAndSetAccessible(f)); > } > + > + boolean isAccessible(Field f) { > + return !(Modifier.isStatic(f.getModifiers()) && > Modifier.isFinal(f.getModifiers())); > + } > + > + // Setting the accessibility bit of a Field grants > access to non-static > + // final fields for MethodHandler setters > + Set inaccessibleFields(Set inaccessibleFields) { > + Set result = new HashSet<>(); > + inaccessibleFields.stream().filter(f -> f.contains > ("_static_")).forEach(result::add); > + return result; > + } > }, > VH() { > Object lookup(MethodHandles.Lookup l, Field f) throws Exception { > @@ -142,6 +160,10 @@ > return true; > } > > + Set inaccessibleFields(Set inaccessibleFields) { > + return new HashSet<>(inaccessibleFields); > + } > + > static Field cloneAndSetAccessible(Field f) throws Exception { > // Clone to avoid mutating source field > f = f.getDeclaringClass().getDeclaredField(f.getName()); > @@ -180,7 +202,7 @@ > @Test(dataProvider = "lookupProvider") > public void test(FieldLookup fl, Class src, > MethodHandles.Lookup l, Set inaccessibleFields) { > // Add to the expected failures all inaccessible fields due > to accessibility modifiers > - Set expected = new HashSet<>(inaccessibleFields); > + Set expected = fl.inaccessibleFields(inaccessibleFields); > Map actual = new HashMap<>(); > > for (Field f : fields(src)) { > @@ -203,12 +225,9 @@ > if (!actualFieldNames.equals(expected)) { > if (actualFieldNames.isEmpty()) { > // Setting the accessibility bit of a Field grants > access under > - // all conditions for MethodHander getters and setters > - if (fl != FieldLookup.MH_UNREFLECT_GETTER_ACCESSIBLE && > - fl != FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE) { > + // all conditions for MethodHandler getters > Assert.assertEquals(actualFieldNames, expected, > "No accessibility failures:"); > } > - } > else { > Assert.assertEquals(actualFieldNames, expected, > "Accessibility failures differ:"); > } 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 Mar 26 17:25:25 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 26 Mar 2019 18:25:25 +0100 Subject: ClassCastException: cannot assign SerializedLambda to field with ClassLoader In-Reply-To: <9f40c8c6-487f-ed7d-639e-e49f89c023f6@oracle.com> References: <55c435f3-ad63-5674-e6e4-5ac0528bba56@oracle.com> <40e994d8-f65f-378e-3d53-3375647ee2f1@oracle.com> <9f40c8c6-487f-ed7d-639e-e49f89c023f6@oracle.com> Message-ID: Hi, I think that Seth's case is a general problem with serialization of circular graph(s) with classes containing readResolve() method(s). The issue is being described here in full: https://bugs.openjdk.java.net/browse/JDK-6785441 In short: readResolve() method is specified to be invoked after the deserialized object's state (fields) are fully initialized and the result of that method is than used instead of the deserialized object as the result of deserialization. But what if deserialized object's fields refer (directly or indirectly) to the object that is to be the result of readResolve method? We then have chicked-egg problem that seems impossible to fix while maintaining the specification/compatibility. Regards, Peter On 3/26/19 6:12 AM, David Holmes wrote: > Hi Seth, > > I think we've both been chasing red herrings :) The classloader is not > relevant. I can run the test with everything loaded as normal by the > app loader and it still gets the ClassCastException. Searching JBS it > seems that serialization of lambdas is broken - ref: > > https://bugs.openjdk.java.net/browse/JDK-8154236 > https://bugs.openjdk.java.net/browse/JDK-8174865 > https://bugs.openjdk.java.net/browse/JDK-8174864 > > though I'm not clear if your testcase falls under the same > categorization as above. > > David > ----- > > On 26/03/2019 2:08 pm, David Holmes wrote: >> On 26/03/2019 2:03 pm, seth lytle wrote: >>> it's a nested class, but it's loaded with the same class loader as >>> the toplevel. which is what i thought you thought was the problem when >> >> Sorry, hard to see all the diffs inside the email. Not sure what >> relevance splitting into two files has given the main change was to >> load the enclosing class in the new loader rather than the nested class. >> >> Anyway, yes this gets rid of the "nested class in a different >> classloader" problem. >> >> I'll take a look and see what's getting generated under the hood. >> >> David >> ----- >> >>> you wrote: >>> ?> this test loads a nested type into a different classloader to its >>> enclosing type >>> >>> and: >>> ?> it is a requirement that all nest members be defined in the same >>> ?> package - which implies the same classloader >>> >>> >>> >>> >>> On Mon, Mar 25, 2019 at 11:40 PM David Holmes >>> > wrote: >>> >>> ??? On 26/03/2019 1:06 pm, seth lytle wrote: >>> ???? > i still get the same stack trace after breaking the example out >>> ??? into two >>> ???? > files. does that sufficiently address the nesting issue ? >>> >>> ??? ?? >>> >>> ???? ? ? ?public static class MyCode ... >>> >>> ??? is still a nested class. >>> >>> ??? David >>> >>> ???? > file:?SerializedLambdaTest >>> ???? > package test; >>> ???? > >>> ???? > import java.io.ByteArrayInputStream; >>> ???? > import java.io.ByteArrayOutputStream; >>> ???? > import java.io.IOException; >>> ???? > import java.io.ObjectInputStream; >>> ???? > import java.io.ObjectOutputStream; >>> ???? > import java.io.Serializable; >>> ???? > >>> ???? > // from: https://bugs.openjdk.java.net/browse/JDK-8008770 >>> ???? > public class SerializedLambdaTest implements Runnable { >>> ???? >? ? ? public void run() { new MyCode().run(); } >>> ???? >? ? ? public interface SerializableRunnable extends >>> ??? Runnable,Serializable { >>> ???? >? ? ? } >>> ???? >? ? ? public static class MyCode implements >>> SerializableRunnable { >>> ???? >? ? ? ? ? SerializableRunnable runnable2 = () >>> ???? >? ? ? ? ? ? ? ? ? -> { >>> ???? > System.out.println("HELLO"+this.getClass()); >>> ???? >? ? ? ? ? }; >>> ???? >? ? ? ? ? private byte[] serialize(Object o) { >>> ???? >? ? ? ? ? ? ? ByteArrayOutputStream baos; >>> ???? >? ? ? ? ? ? ? try ( >>> ???? >? ? ? ? ? ? ? ? ? ? ? ?ObjectOutputStream oos >>> ???? >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos = new >>> ???? > ByteArrayOutputStream())) { >>> ???? >? ? ? ? ? ? ? ? ? oos.writeObject(o); >>> ???? >? ? ? ? ? ? ? } catch (IOException e) { >>> ???? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >>> ???? >? ? ? ? ? ? ? } >>> ???? >? ? ? ? ? ? ? return baos.toByteArray(); >>> ???? >? ? ? ? ? } >>> ???? >? ? ? ? ? private T deserialize(byte[] bytes) { >>> ???? >? ? ? ? ? ? ? try ( >>> ???? >? ? ? ? ? ? ? ? ? ? ? ?ObjectInputStream ois >>> ???? >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new >>> ???? > ByteArrayInputStream(bytes))) { >>> ???? >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); >>> ???? >? ? ? ? ? ? ? } catch (IOException|ClassNotFoundException e) { >>> ???? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >>> ???? >? ? ? ? ? ? ? } >>> ???? >? ? ? ? ? } >>> ???? >? ? ? ? ? @Override >>> ???? >? ? ? ? ? public void run() { >>> ???? >? ? ? ? ? ? ? System.out.println(" this: "+this); >>> ???? >? ? ? ? ? ? ? SerializableRunnable deSerializedThis >>> ???? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(this)); >>> ???? >? ? ? ? ? ? ? System.out.println(" deSerializedThis: " >>> ???? >? ? ? ? ? ? ? ? ? ? ? +deSerializedThis); >>> ???? > >>> ???? >? ? ? ? ? ? ? SerializableRunnable runnable = runnable2; >>> ???? >? ? ? ? ? ? ? System.out.println(" runnable: "+runnable); >>> ???? >? ? ? ? ? ? ? SerializableRunnable deSerializedRunnable >>> ???? >? ? ? ? ? ? ? ? ? ? ? = deserialize(serialize(runnable)); >>> ???? > System.out.println("deSerializedRunnable: " >>> ???? >? ? ? ? ? ? ? ? ? ? ? +deSerializedRunnable); >>> ???? >? ? ? ? ? } >>> ???? >? ? ? } >>> ???? > } >>> ???? > >>> ???? > >>> ???? > file:?MyClassLoader >>> ???? > package test; >>> ???? > >>> ???? > import java.io.IOException; >>> ???? > import java.io.InputStream; >>> ???? > >>> ???? > class MyClassLoader extends ClassLoader { >>> ???? >? ? ? MyClassLoader(ClassLoader parent) { >>> ???? >? ? ? ? ? super(parent); >>> ???? >? ? ? } >>> ???? >? ? ? @Override >>> ???? >? ? ? protected Class loadClass(String name,boolean resolve) >>> ??? throws >>> ???? > ClassNotFoundException { >>> ???? >? ? ? ? ? if (name.startsWith("test.")) >>> ???? >? ? ? ? ? ? ? synchronized (getClassLoadingLock(name)) { >>> ???? >? ? ? ? ? ? ? ? ? Class c = findLoadedClass(name); >>> ???? >? ? ? ? ? ? ? ? ? if (c==null) c = findClass(name); >>> ???? >? ? ? ? ? ? ? ? ? if (resolve) resolveClass(c); >>> ???? >? ? ? ? ? ? ? ? ? return c; >>> ???? >? ? ? ? ? ? ? } >>> ???? >? ? ? ? ? else return super.loadClass(name,resolve); >>> ???? >? ? ? } >>> ???? >? ? ? @Override >>> ???? >? ? ? protected Class findClass(String name) throws >>> ???? > ClassNotFoundException { >>> ???? >? ? ? ? ? String path = name.replace('.','/').concat(".class"); >>> ???? >? ? ? ? ? try (final InputStream is = >>> getResourceAsStream(path)) { >>> ???? >? ? ? ? ? ? ? if (is!=null) { >>> ???? >? ? ? ? ? ? ? ? ? byte[] bytes = is.readAllBytes(); >>> ???? >? ? ? ? ? ? ? ? ? return defineClass(name,bytes,0,bytes.length); >>> ???? >? ? ? ? ? ? ? } >>> ???? >? ? ? ? ? ? ? else throw new ClassNotFoundException(name); >>> ???? >? ? ? ? ? } catch (IOException e) { >>> ???? >? ? ? ? ? ? ? throw new ClassNotFoundException(name,e); >>> ???? >? ? ? ? ? } >>> ???? >? ? ? } >>> ???? >? ? ? public static void main(String[] args) throws Exception { >>> ???? >? ? ? ? ? ClassLoader myCl = new MyClassLoader( >>> ???? > MyClassLoader.class.getClassLoader() >>> ???? >? ? ? ? ? ); >>> ???? >? ? ? ? ? Class myCodeClass = Class.forName( >>> ???? >? ? ? ? ? ? ? ? ? "test.SerializedLambdaTest", >>> ???? >? ? ? ? ? ? ? ? ? true, >>> ???? >? ? ? ? ? ? ? ? ? myCl >>> ???? >? ? ? ? ? ); >>> ???? >? ? ? ? ? Runnable myCode = (Runnable) myCodeClass.newInstance(); >>> ???? >? ? ? ? ? myCode.run(); >>> ???? >? ? ? } >>> ???? > } >>> ???? > >>> ???? > >>> ???? > >>> ???? > >>> ???? > On Mon, Mar 25, 2019 at 10:34 PM David Holmes >>> ??? >>> ???? > >> ??? >> wrote: >>> ???? > >>> ???? >? ? ?Hi Seth, >>> ???? > >>> ???? >? ? ?On 26/03/2019 12:16 pm, seth lytle wrote: >>> ???? >? ? ? > i haven't changed the assignment from the original >>> test case >>> ???? >? ? ?(which was >>> ???? >? ? ? > accepted as valid at the time). i haven't gone through >>> it in >>> ???? >? ? ?depth, but >>> ???? >? ? ? > assume that it's ok and used it since people are already >>> ??? familiar >>> ???? >? ? ?with >>> ???? >? ? ? > it. it appears to me that that example uses reflection to >>> ???? >? ? ?allocate an >>> ???? >? ? ? > instance using a definitive class loader and then uses a >>> ??? runnable >>> ???? >? ? ?for >>> ???? >? ? ? > the serialization/deserialization cycle >>> ???? >? ? ? > >>> ???? >? ? ? > the class cast exception happens not at the example >>> level, >>> ??? but deep >>> ???? >? ? ? > inside `readObject` when it's doing an internal >>> assignment >>> ???? >? ? ? > >>> ???? >? ? ? > perhaps my choice of words "into a new classloader" was >>> ???? >? ? ?insufficient or >>> ???? >? ? ? > misleading. in both examples that i've come up with so >>> ??? far, the >>> ???? >? ? ?class >>> ???? >? ? ? > loader calls defineClass directly without first >>> delegating to >>> ???? >? ? ?super (for >>> ???? >? ? ? > a subset of the classes). so "into a definitive >>> classloader" >>> ???? >? ? ?might have >>> ???? >? ? ? > been a better choice >>> ???? > >>> ???? >? ? ?I think the basic problem is that this test loads a nested >>> ??? type into a >>> ???? >? ? ?different classloader to its enclosing type. I can easily >>> ??? imagine this >>> ???? >? ? ?messing up the code that gets generated to implement the >>> lambda >>> ???? >? ? ?expression - but I'd need to examine that code in detail to >>> ??? see exactly >>> ???? >? ? ?why (others may know this more readily than I do). It's >>> ??? unclear to me >>> ???? >? ? ?whether this would be considered a bug or a "don't do that" >>> ??? situation. >>> ???? >? ? ?As of JDK 11, nested types define "nests" at the VM level >>> ??? (see JEP-181) >>> ???? >? ? ?and it is a requirement that all nest members be defined in >>> ??? the same >>> ???? >? ? ?package - which implies the same classloader. >>> ???? > >>> ???? >? ? ?David >>> ???? > >>> ???? >? ? ? > >>> ???? >? ? ? > >>> ???? >? ? ? > >>> ???? >? ? ? > >>> ???? >? ? ? > >>> ???? >? ? ? > On Mon, Mar 25, 2019 at 9:34 PM David Holmes >>> ???? >? ? ? >>> ??? > >>> ???? >? ? ? > >> ??? >>> ???? >? ? ?>> ??? >>> wrote: >>> ???? >? ? ? > >>> ???? >? ? ? >? ? ?Hi Seth, >>> ???? >? ? ? > >>> ???? >? ? ? >? ? ?On 26/03/2019 11:22 am, seth lytle wrote: >>> ???? >? ? ? >? ? ? > if a lambda is a field and captures `this`, and >>> it's >>> ???? >? ? ?deserialized >>> ???? >? ? ? >? ? ?into a >>> ???? >? ? ? >? ? ? > new class loader, it throws a ClassCastException. >>> ???? >? ? ? > >>> ???? >? ? ? >? ? ?Not sure I follow. If you load a class into a >>> different >>> ???? >? ? ?classloader >>> ???? >? ? ? >? ? ?then >>> ???? >? ? ? >? ? ?you get a different type. It might appear the same to >>> ??? you but >>> ???? >? ? ?it is a >>> ???? >? ? ? >? ? ?distinct type, so you can't assign across different >>> ??? instances >>> ???? >? ? ?loaded by >>> ???? >? ? ? >? ? ?different classloaders. >>> ???? >? ? ? > >>> ???? >? ? ? >? ? ?Cheers, >>> ???? >? ? ? >? ? ?David >>> ???? >? ? ? >? ? ?----- >>> ???? >? ? ? > >>> ???? >? ? ? >? ? ? > i came across this bug >>> ???? >? ? ? >? ? ? > independently while writing a test, but then found >>> ??? an old >>> ???? >? ? ?openjdk >>> ???? >? ? ? >? ? ?bug with >>> ???? >? ? ? >? ? ? > a similar issue and tweaked the test case (source >>> ??? below). >>> ???? >? ? ?my version >>> ???? >? ? ? >? ? ? > differs only in >>> ???? >? ? ? >? ? ? > 1. moved the lambda to a field >>> ???? >? ? ? >? ? ? > 2. reference `this` in it >>> ???? >? ? ? >? ? ? > 3. uses readAllBytes instead of the internal >>> method >>> ???? >? ? ? >? ? ? > 4. formatting >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > running with java 11 or 12 (or java 8 using a >>> ??? substitute for >>> ???? >? ? ? >? ? ?readAllBytes) >>> ???? >? ? ? >? ? ? > results in: >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? this: >>> ???? >? ? ?test.SerializedLambdaTest$MyCode at 8efb846 >>> ???? >? ? ? >? ? ? >? ? ? deSerializedThis: >>> ???? >? ? ?test.SerializedLambdaTest$MyCode at 2b71fc7e >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? runnable: >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? > >>> ???? > >>> ?test.SerializedLambdaTest$MyCode$$Lambda$1/0x0000000801188440 at 37bba400 >>> ???? >? ? ? >? ? ? > Exception in thread "main" >>> ??? java.lang.ClassCastException: >>> ???? >? ? ?cannot >>> ???? >? ? ? >? ? ?assign >>> ???? >? ? ? >? ? ? > instance of java.lang.invoke.SerializedLambda >>> to field >>> ???? >? ? ? >? ? ? > test.SerializedLambdaTest$MyCode.runnable2 of type >>> ???? >? ? ? >? ? ? > test.SerializedLambdaTest$SerializableRunnable in >>> ??? instance of >>> ???? >? ? ? >? ? ? > test.SerializedLambdaTest$MyCode >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2190) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2153) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1407) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2278) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readArray(ObjectInputStream.java:1993) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readObject0(ObjectInputStream.java:1588) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2355) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readSerialData(ObjectInputStream.java:2249) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2087) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readObject0(ObjectInputStream.java:1594) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > java.base/java.io >>> >>> ???? >? ? ? > >>> ???? > >>> ?.ObjectInputStream.readObject(ObjectInputStream.java:430) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? > >>> ???? > >>> ?test.SerializedLambdaTest$MyCode.deserialize(SerializedLambdaTest.java:35) >>> >>> ???? >? ? ? >? ? ? > at >>> ???? > >>> ?test.SerializedLambdaTest$MyCode.run(SerializedLambdaTest.java:51) >>> ???? >? ? ? >? ? ? > at >>> ???? > ?test.SerializedLambdaTest.main(SerializedLambdaTest.java:66) >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8008770 >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > package test; >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > import java.io.ByteArrayInputStream; >>> ???? >? ? ? >? ? ? > import java.io.ByteArrayOutputStream; >>> ???? >? ? ? >? ? ? > import java.io.IOException; >>> ???? >? ? ? >? ? ? > import java.io.InputStream; >>> ???? >? ? ? >? ? ? > import java.io.ObjectInputStream; >>> ???? >? ? ? >? ? ? > import java.io.ObjectOutputStream; >>> ???? >? ? ? >? ? ? > import java.io.Serializable; >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > // from: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8008770 >>> ???? >? ? ? >? ? ? > public class SerializedLambdaTest { >>> ???? >? ? ? >? ? ? >? ? ? public interface SerializableRunnable extends >>> ???? >? ? ? >? ? ?Runnable,Serializable { >>> ???? >? ? ? >? ? ? >? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? public static class MyCode implements >>> ???? >? ? ?SerializableRunnable { >>> ???? >? ? ? >? ? ? >? ? ? ? ? SerializableRunnable runnable2 = () >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? -> { >>> ???? >? ? ? >? ? ? > System.out.println("HELLO"+this.getClass()); >>> ???? >? ? ? >? ? ? >? ? ? ? ? }; >>> ???? >? ? ? >? ? ? >? ? ? ? ? private byte[] serialize(Object o) { >>> ???? >? ? ? >? ? ? > ByteArrayOutputStream baos; >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? try ( >>> ???? >? ? ? >? ? ? > ?ObjectOutputStream oos >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectOutputStream(baos >>> ??? = new >>> ???? >? ? ? >? ? ? > ByteArrayOutputStream())) { >>> ???? >? ? ? >? ? ? > oos.writeObject(o); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? return baos.toByteArray(); >>> ???? >? ? ? >? ? ? >? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? private T deserialize(byte[] bytes) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? try ( >>> ???? >? ? ? >? ? ? > ?ObjectInputStream ois >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = new ObjectInputStream(new >>> ???? >? ? ? >? ? ? > ByteArrayInputStream(bytes))) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? return (T) ois.readObject(); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } catch >>> ??? (IOException|ClassNotFoundException e) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new RuntimeException(e); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? @Override >>> ???? >? ? ? >? ? ? >? ? ? ? ? public void run() { >>> ???? >? ? ? >? ? ? > System.out.println("??????????????? this: >>> ???? >? ? ?"+this); >>> ???? >? ? ? >? ? ? > SerializableRunnable deSerializedThis >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = >>> deserialize(serialize(this)); >>> ???? >? ? ? >? ? ? > System.out.println("???? deSerializedThis: " >>> ???? >? ? ? >? ? ? > +deSerializedThis); >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? >? ? ? > SerializableRunnable runnable = runnable2; >>> ???? >? ? ? >? ? ? > System.out.println("??????????? runnable: >>> ???? >? ? ?"+runnable); >>> ???? >? ? ? >? ? ? > SerializableRunnable deSerializedRunnable >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? = >>> ??? deserialize(serialize(runnable)); >>> ???? >? ? ? >? ? ? > System.out.println("deSerializedRunnable: " >>> ???? >? ? ? >? ? ? > +deSerializedRunnable); >>> ???? >? ? ? >? ? ? >? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? public static void main(String[] args) throws >>> ??? Exception { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ClassLoader myCl = new MyClassLoader( >>> ???? >? ? ? >? ? ? > SerializedLambdaTest.class.getClassLoader() >>> ???? >? ? ? >? ? ? >? ? ? ? ? ); >>> ???? >? ? ? >? ? ? >? ? ? ? ? Class myCodeClass = Class.forName( >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ?SerializedLambdaTest.class.getName()+"$MyCode", >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? true, >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? myCl >>> ???? >? ? ? >? ? ? >? ? ? ? ? ); >>> ???? >? ? ? >? ? ? >? ? ? ? ? Runnable myCode = (Runnable) >>> ???? >? ? ?myCodeClass.newInstance(); >>> ???? >? ? ? >? ? ? >? ? ? ? ? myCode.run(); >>> ???? >? ? ? >? ? ? >? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? static class MyClassLoader extends >>> ClassLoader { >>> ???? >? ? ? >? ? ? > MyClassLoader(ClassLoader parent) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? super(parent); >>> ???? >? ? ? >? ? ? >? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? @Override >>> ???? >? ? ? >? ? ? >? ? ? ? ? protected Class loadClass(String >>> ??? name,boolean >>> ???? >? ? ?resolve) >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throws ClassNotFoundException { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? if (name.startsWith("test.")) >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? synchronized >>> ??? (getClassLoadingLock(name)) { >>> ???? >? ? ? >? ? ? > Class c = >>> ??? findLoadedClass(name); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (c==null) >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? c = findClass(name); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? if (resolve) >>> ???? >? ? ? >? ? ? > resolveClass(c); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? return c; >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? else >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? return >>> super.loadClass(name,resolve); >>> ???? >? ? ? >? ? ? >? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? @Override >>> ???? >? ? ? >? ? ? >? ? ? ? ? protected Class findClass(String name) >>> ??? throws >>> ???? >? ? ? >? ? ? > ClassNotFoundException { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? String path = >>> ???? >? ? ?name.replace('.','/').concat(".class"); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? try ( InputStream is = >>> ???? >? ? ?getResourceAsStream(path)) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? if (is!=null) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? byte[] bytes = >>> is.readAllBytes(); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? return >>> ???? >? ? ?defineClass(name,bytes,0,bytes.length); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? } else >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? throw new >>> ??? ClassNotFoundException(name); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } catch (IOException e) { >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? throw new >>> ??? ClassNotFoundException(name,e); >>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? ? ? } >>> ???? >? ? ? >? ? ? >? ? ? } >>> ???? >? ? ? >? ? ? > } >>> ???? >? ? ? >? ? ? > >>> ???? >? ? ? > >>> ???? > >>> From andrew_m_leonard at uk.ibm.com Tue Mar 26 17:33:50 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 17:33:50 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <717c96eb-b36a-b306-079b-de7f8d0a95bd@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <717c96eb-b36a-b306-079b-de7f8d0a95bd@oracle.com> Message-ID: I'm happy with that Ivan. I've added the @bug id, good spot!, webrev-03 with that change added: http://cr.openjdk.java.net/~aleonard/8221430/webrev.03/ 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 From: Ivan Gerasimov To: Andrew Leonard , Roger Riggs Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 17:19 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified On 3/26/19 8:45 AM, Andrew Leonard wrote: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Ivan's view is that behaviour was an extended issue, which it is, but I thought it was nice to add.. Right. I agree it would be nice to add this as an enhancement, though I believe it would be clearer to fix one issue at a time. Personally, I like what you have in webrev-02, as it fixes the issue with wrong coder when compact strings are disabled. (The only minor change left is to add the bug id to the list of bugs in the regression test.) For the enhancement with determining the coder of the argument, I was thinking if it may be sensible to extend it to general CharSequence also (i.e. scan it in advance and see if all characters can be encoded with LATIN1). Maybe not. That's why I think it should be discussed within different request. With kind regards, Ivan Which patch do we favour? webrev-01 or -02 ? 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 From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 26/03/2019 15:24 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Sent by: "core-libs-dev" Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 >> >> Many 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 -- With kind regards, Ivan Gerasimov 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 Mar 26 18:01:54 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 26 Mar 2019 19:01:54 +0100 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: References: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> Message-ID: Hi, This change is OK, but I was thinking that in general, for cases like this one, it would be better to check that the Set obtained from the 'graph' Map is already immutable and throw an exception if that is not the case. Like Objects.requireNonNull method, there could be a similar static method in Set interface: static Set requireImmutable(Set set) Why is this better than Set.copyOf()? Because here we know that the parameter to Set.copyOf() is already an immutable Set and this method just returns it in that case. But what if some changes to internal logic fail to maintain this invariant? In that case Set.copyOf() would silently start copying the elements and returning new immutable instances. In case that happens, Set.requireImmutable() would throw and it would be necessary to fix code so that the invariant is preserved or replace Set.requireImmutable() with Set.copyOf(). But that last option would be a conscious decision which trades correctness for performance, not a result of oversight. Would such method addition be worth it? Regards, Peter On 3/26/19 2:54 PM, Alan Bateman wrote: > On 26/03/2019 13:44, Claes Redestad wrote: >> >> Or with this less verbose comment (suggested offline by Alan): >> >> diff -r 5ee30b6991a7 >> src/java.base/share/classes/java/lang/module/Configuration.java >> --- a/src/java.base/share/classes/java/lang/module/Configuration.java >> Mon Dec 03 16:25:27 2018 +0100 >> +++ b/src/java.base/share/classes/java/lang/module/Configuration.java >> Tue Mar 26 14:50:55 2019 +0100 >> @@ -575,7 +575,8 @@ >> ???? } >> >> ???? Set reads(ResolvedModule m) { >> -??????? return Collections.unmodifiableSet(graph.get(m)); >> +??????? // The sets stored in the graph are already immutable sets >> +??????? return Set.copyOf(graph.get(m)); >> ???? } > This looks good. > > -Alan From Roger.Riggs at oracle.com Tue Mar 26 18:17:05 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Mar 2019 14:17:05 -0400 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> Message-ID: <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> Hi Andrew, You are going to have to change the same code twice because the changes should be the StringBuffer and StringBuilder constructors and would remove the code that is added to the AbstractStringBuilder constructor.? That's a waste of review cycles. On 03/26/2019 11:45 AM, Andrew Leonard wrote: > Hi Roger, > No worries, the more the merrier! > So that was one of my reasoning for adding getCharSequenceCode() was, > I think what you're suggesting is my webrev.01, > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > Ivan's view is that behaviour was an extended issue, which it is, but > I thought it was nice to add.. > > Which patch do we favour? webrev-01 or -02 ? Neither, there should be no change to the AbstractStringBuilder constructor and the change should be done in the subclass constructors. Roger > > 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 > > > > > From: Roger Riggs > To: core-libs-dev at openjdk.java.net > Date: 26/03/2019 15:24 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > Sent by: "core-libs-dev" > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Sorry to be late to the review. > > For symmetry with the constructors StringBuffer(String), and > StringBuilder(String) > the determine the coder based on the input argument, I would recommend > using the getCharSequenceCoder added in the -01 webrev and calling > it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) > constructors. > > It would be symmetric with the getCoder() method (line 1635) > and select the appropriate coder base on the input value (if known.) > > Thanks, Roger > > > > On 03/26/2019 10:57 AM, Andrew Leonard wrote: > > Hi Ivan, > > Yes, i'm happy with that, as you say the simple constructor change fixes > > the immediate issue, but not necessarily the extended issue of a > > non-compactable CharSequence in COMPACT_STRINGS mode, but that's > probably > > an enhanced issue to cover in a separate bug... > > I've created a new webrev.02 with just the constructor change and the > > testcase: > > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > > > > 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 > > > > > > > > > > From: ? Ivan Gerasimov > > To: ? ? Andrew Leonard > > Cc: ? ? core-libs-dev at openjdk.java.net > > Date: ? 26/03/2019 01:18 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Thanks Andrew! > > Introducing getCharSequenceCoder() is actually an enhancement, which may > > improve pre-allocation in certain cases. > > It's not actually required to restore correctness of > StringBuilder/Buffer > > constructors. > > I recommend to separate it from this bug fix, so it can be discussed > > separately, and determined if this is the best approach to this > > enhancement. > > If you agree, I can adjust your latest patch accordingly, run it through > > the Mach5 test systems and push it on your behalf. > > With kind regards, > > Ivan > > > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > > Hi Ivan, > > Here is my updated webrev: > > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > > > > 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 > > > > > > > > > > From: ? ? ? ?Ivan Gerasimov > > To: ? ? ? ?Andrew Leonard > > Cc: ? ? ? ?core-libs-dev at openjdk.java.net > > Date: ? ? ? ?25/03/2019 22:55 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > I was thinking of organizing code similar to what is done in > > AbstractStringBuilder(int): > > > > if (COMPACT_STRINGS && coderHint == LATIN1) { > > ? ? ?value = new byte[capacity]; > > ? ? ?coder = LATIN1; > > } else { > > ? ? ?value = StringUTF16.newBytesFor(capacity); > > ? ? ?coder = UTF16; > > } > > > > With kind regards, > > Ivan > > > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > > Hi Ivan, > > I think I see what you're saying, you mean we also need to correct this > > line in AbstractStringBuilder > > constructor: > > value = (coder == LATIN1) > > ? ? ? ? ? ? ? ? ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > to be maybe: > > value = (COMPACT_STRINGS && coder == LATIN1) > > ? ? ? ? ? ? ? ? ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS > > a string could be UTF16 if > > it cannot be compacted, so it's more than just a hint isn't it? > > > > 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 > > > > > > > > > > From: ? ? ? ?Ivan Gerasimov > > To: ? ? ? ?Andrew Leonard , > > core-libs-dev at openjdk.java.net > > Date: ? ? ? ?25/03/2019 22:20 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Hi Andrew! > > > > Thanks for finding this bug! > > > > Your fix solves the problem. > > > > However, I think the main issue is that the constructor > > AbstractStringBuilder(byte,int,int) is now broken: ?as you discovered, > > it allows to create a string buffer with the coder LATIN1 when > > COMPACT_STRINGS is false. > > > > Wouldn't it make sense to rename the argument of the constructor to, > > say, coderHint, and then either use it as the coder if > > COMPACT_STRINGS==true, or discard it otherwise. > > > > What do you think? > > > > With kind regards, > > Ivan > > > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > >> Hi, > >> Please can I request a sponsor for this fix to a JDK-13 regression? > >> > >> Patch with jtreg testcase here: > >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ > > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 > >> > >> Many 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 brian.burkhalter at oracle.com Tue Mar 26 18:35:19 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Mar 2019 11:35:19 -0700 Subject: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms In-Reply-To: References: Message-ID: Looks all right. Thanks, Brian > On Mar 26, 2019, at 9:26 AM, Thomas St?fe wrote: > > Looks fine and trivial. > > ..Thomas > > On Tue, Mar 26, 2019 at 2:02 PM Aleksey Shipilev wrote: > >> Ping, no takers? >> >> -Aleksey >> >> On 3/25/19 3:33 PM, Aleksey Shipilev wrote: >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8221401 >>> >>> My major concern is to make tier1 passing on x86_32. This is one of the >> tests that fail. Smaller >>> heap size does not fit this test case, unfortunately. So, we have to >> disable it for 32-bit builds. >>> In fact, somebody did it already for 8u backport, but not upstream! >>> >>> Fix: >>> >>> diff -r 59816a32df2c >> test/jdk/java/math/BigInteger/LargeValueExceptions.java >>> --- a/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar >> 25 13:12:37 2019 +0100 >>> +++ b/test/jdk/java/math/BigInteger/LargeValueExceptions.java Mon Mar >> 25 15:29:16 2019 +0100 >>> @@ -23,11 +23,11 @@ >>> >>> /* >>> * @test >>> * @bug 8200698 >>> * @summary Tests that exceptions are thrown for ops which would >> overflow >>> - * @requires os.maxMemory >= 4g >>> + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g) >>> * @run testng/othervm -Xmx4g LargeValueExceptions >>> */ >>> import java.math.BigInteger; >>> import static java.math.BigInteger.ONE; >>> import org.testng.annotations.Test; >>> >>> >>> Testing: Linux {x86_64, x86_32} fastdebug build and test, jdk-submit >> (running) >>> >>> Thanks, >>> -Aleksey >>> >> >> >> -- >> Thanks, >> -Aleksey >> >> ------------------- >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric >> Shander From andrew_m_leonard at uk.ibm.com Tue Mar 26 18:38:42 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 18:38:42 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> Message-ID: Sorry chaps, I think my brain is getting confused!, I think we have conflicting reviews here? Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so it was only defined in one place.. I agree with this being called in StringBuffer/Builder then we don't need the change to AbstractStringBuild() constuctor, however Ivan wants getCharSequenceCoder() that done as a separate "bug". So I think it comes down to do we do this as 2 "bugs" or 1 ? 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 From: Roger Riggs To: Andrew Leonard , Ivan Gerasimov Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 18:19 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew, You are going to have to change the same code twice because the changes should be the StringBuffer and StringBuilder constructors and would remove the code that is added to the AbstractStringBuilder constructor. That's a waste of review cycles. On 03/26/2019 11:45 AM, Andrew Leonard wrote: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Ivan's view is that behaviour was an extended issue, which it is, but I thought it was nice to add.. Which patch do we favour? webrev-01 or -02 ? Neither, there should be no change to the AbstractStringBuilder constructor and the change should be done in the subclass constructors. Roger 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 From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 26/03/2019 15:24 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Sent by: "core-libs-dev" Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 >> >> Many 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 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 daniel.fuchs at oracle.com Tue Mar 26 18:44:02 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Mar 2019 18:44:02 +0000 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: References: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> Message-ID: <741d52ce-931d-2e51-1806-bdc45d4cca30@oracle.com> Hi Peter, On 26/03/2019 18:01, Peter Levart wrote: > Would such method addition be worth it? Here is the impl of Set.copyOf: static Set copyOf(Collection coll) { if (coll instanceof ImmutableCollections.AbstractImmutableSet) { return (Set)coll; } else { return (Set)Set.of(new HashSet<>(coll).toArray()); } } Best regards, -- daniel From Roger.Riggs at oracle.com Tue Mar 26 19:14:09 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Mar 2019 15:14:09 -0400 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> Message-ID: <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> Hi, We've got the subject open and its fresh, there's no need for a separate review cycle. The first fix (-01) does not seem to be consistent with the original design and handling of the coder.? The StringBuilder(String) and StringBuffer(String) constructors are the pattern that should be followed for determining the coder for the new instance. Checking for COMPACT_STRING in two places (the AbstractStringBuilder and the sub classes) is unnecessary and distributes the information about the correct coder across two classes where determining what it should be in the subclass has more complete? information and can correctly determine the coder once. We can likely find a reviewer to be a tie-breaker if Ivan sees it as desirable. Thanks, Roger On 03/26/2019 02:38 PM, Andrew Leonard wrote: > Sorry chaps, I think my brain is getting confused!, I think we have > conflicting reviews here? > > Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so > it was only defined in one place.. > I agree with this being called in StringBuffer/Builder then we don't > need the change to AbstractStringBuild() constuctor, however Ivan > wants getCharSequenceCoder() that done as a separate "bug". > > So I think it comes down to do we do this as 2 "bugs" or 1 ? > > 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 > > > > > From: Roger Riggs > To: Andrew Leonard , Ivan Gerasimov > > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 18:19 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi Andrew, > > You are going to have to change the same code twice > because the changes should be the StringBuffer and StringBuilder > constructors and would remove the code that is added to > the AbstractStringBuilder constructor.? That's a waste of review cycles. > > > On 03/26/2019 11:45 AM, Andrew Leonard wrote: > Hi Roger, > No worries, the more the merrier! > So that was one of my reasoning for adding getCharSequenceCode() was, > I think what you're suggesting is my webrev.01, > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ > > Ivan's view is that behaviour was an extended issue, which it is, but > I thought it was nice to add.. > > Which patch do we favour? webrev-01 or -02 ? > > Neither, there should be no change to the AbstractStringBuilder > constructor > and the change should be done in the subclass constructors. > > Roger > > > 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_ > > > > > > From: Roger Riggs __ > > To: _core-libs-dev at openjdk.java.net_ > > Date: 26/03/2019 15:24 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > Sent by: "core-libs-dev" __ > > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Sorry to be late to the review. > > For symmetry with the constructors StringBuffer(String), and > StringBuilder(String) > the determine the coder based on the input argument, I would recommend > using the getCharSequenceCoder added in the -01 webrev and calling > it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) > constructors. > > It would be symmetric with the getCoder() method (line 1635) > and select the appropriate coder base on the input value (if known.) > > Thanks, Roger > > > > On 03/26/2019 10:57 AM, Andrew Leonard wrote: > > Hi Ivan, > > Yes, i'm happy with that, as you say the simple constructor change fixes > > the immediate issue, but not necessarily the extended issue of a > > non-compactable CharSequence in COMPACT_STRINGS mode, but that's > probably > > an enhanced issue to cover in a separate bug... > > I've created a new webrev.02 with just the constructor change and the > > testcase: > > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/_ > > > > > 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_ > > > > > > > > > > > From: ? Ivan Gerasimov __ > > > To: ? ? Andrew Leonard __ > > > Cc: _core-libs-dev at openjdk.java.net_ > > > Date: ? 26/03/2019 01:18 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Thanks Andrew! > > Introducing getCharSequenceCoder() is actually an enhancement, which may > > improve pre-allocation in certain cases. > > It's not actually required to restore correctness of > StringBuilder/Buffer > > constructors. > > I recommend to separate it from this bug fix, so it can be discussed > > separately, and determined if this is the best approach to this > > enhancement. > > If you agree, I can adjust your latest patch accordingly, run it through > > the Mach5 test systems and push it on your behalf. > > With kind regards, > > Ivan > > > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > > Hi Ivan, > > Here is my updated webrev: > > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ > > > > > 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_ > > > > > > > > > > > From: ? ? ? ?Ivan Gerasimov __ > > > To: ? ? ? ?Andrew Leonard __ > > > Cc: _core-libs-dev at openjdk.java.net_ > > > Date: ? ? ? ?25/03/2019 22:55 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > I was thinking of organizing code similar to what is done in > > AbstractStringBuilder(int): > > > > if (COMPACT_STRINGS && coderHint == LATIN1) { > > ? ? ?value = new byte[capacity]; > > ? ? ?coder = LATIN1; > > } else { > > ? ? ?value = StringUTF16.newBytesFor(capacity); > > ? ? ?coder = UTF16; > > } > > > > With kind regards, > > Ivan > > > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > > Hi Ivan, > > I think I see what you're saying, you mean we also need to correct this > > line in AbstractStringBuilder > > constructor: > > value = (coder == LATIN1) > > ? ? ? ? ? ? ? ? ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > to be maybe: > > value = (COMPACT_STRINGS && coder == LATIN1) > > ? ? ? ? ? ? ? ? ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS > > a string could be UTF16 if > > it cannot be compacted, so it's more than just a hint isn't it? > > > > 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_ > > > > > > > > > > > From: ? ? ? ?Ivan Gerasimov __ > > > To: ? ? ? ?Andrew Leonard __ > , > > _core-libs-dev at openjdk.java.net_ > > Date: ? ? ? ?25/03/2019 22:20 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Hi Andrew! > > > > Thanks for finding this bug! > > > > Your fix solves the problem. > > > > However, I think the main issue is that the constructor > > AbstractStringBuilder(byte,int,int) is now broken: ?as you discovered, > > it allows to create a string buffer with the coder LATIN1 when > > COMPACT_STRINGS is false. > > > > Wouldn't it make sense to rename the argument of the constructor to, > > say, coderHint, and then either use it as the coder if > > COMPACT_STRINGS==true, or discard it otherwise. > > > > What do you think? > > > > With kind regards, > > Ivan > > > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > >> Hi, > >> Please can I request a sponsor for this fix to a JDK-13 regression? > >> > >> Patch with jtreg testcase here: > >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ > > >> > >> bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ > >> > >> Many 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 > > > > 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 Mar 26 19:19:24 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Mar 2019 15:19:24 -0400 Subject: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions In-Reply-To: References: <634e758f-d9cf-77af-45a1-1cf8d6b96299@oracle.com> <73A422CC-23A6-42E7-A725-B46A4FF2823F@oracle.com> <9278C4AC-A125-407A-A231-1ECEEDC90474@oracle.com> <1fbbace9-7b29-725a-147e-2dee9976b1b2@oracle.com> Message-ID: <41e9588f-4c9e-e051-02c8-21d3f0001095@oracle.com> +1 On 03/26/2019 01:01 PM, Brian Burkhalter wrote: > I had to revise this again as I had put the new @throws UTFDataFomatException clause only on the package version of writeUTF() but not also on the public API version. CSR [2] withdrawn and updated also. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8219196/webrev.04/ > [2] https://bugs.openjdk.java.net/browse/JDK-8221428 > >> On Mar 25, 2019, at 7:56 AM, Roger Riggs wrote: >> >> +1 >> >> On 03/22/2019 07:41 PM, Brian Burkhalter wrote: >>> Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/ >>> >>>> On Mar 22, 2019, at 4:32 PM, Brian Burkhalter wrote: >>>> >>>> Patch updated for the sake of formality. From andrew_m_leonard at uk.ibm.com Tue Mar 26 19:37:02 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 19:37:02 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> Message-ID: So my creation of getCharSequenceCoder() was in trying to use the same method as the StringBuffer(String) constructors, ie.String.coder(), however with the StringBuffer(CharSequence,..) constructor the seq can be a String or a StringBuilder or a StringBuffer, hence I created the static getCharSequenceCoder() which switched on the sequence type to obtain the coder... Isn't that in keeping with the (String) constructor? i'm not sure how else we can determine the coder from a CharSequence ? unless we change the constructor to delegate to the caller to pass in the coder? 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 From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net, Ivan Gerasimov Date: 26/03/2019 19:15 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi, We've got the subject open and its fresh, there's no need for a separate review cycle. The first fix (-01) does not seem to be consistent with the original design and handling of the coder. The StringBuilder(String) and StringBuffer(String) constructors are the pattern that should be followed for determining the coder for the new instance. Checking for COMPACT_STRING in two places (the AbstractStringBuilder and the sub classes) is unnecessary and distributes the information about the correct coder across two classes where determining what it should be in the subclass has more complete information and can correctly determine the coder once. We can likely find a reviewer to be a tie-breaker if Ivan sees it as desirable. Thanks, Roger On 03/26/2019 02:38 PM, Andrew Leonard wrote: Sorry chaps, I think my brain is getting confused!, I think we have conflicting reviews here? Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so it was only defined in one place.. I agree with this being called in StringBuffer/Builder then we don't need the change to AbstractStringBuild() constuctor, however Ivan wants getCharSequenceCoder() that done as a separate "bug". So I think it comes down to do we do this as 2 "bugs" or 1 ? 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 From: Roger Riggs To: Andrew Leonard , Ivan Gerasimov Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 18:19 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew, You are going to have to change the same code twice because the changes should be the StringBuffer and StringBuilder constructors and would remove the code that is added to the AbstractStringBuilder constructor. That's a waste of review cycles. On 03/26/2019 11:45 AM, Andrew Leonard wrote: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Ivan's view is that behaviour was an extended issue, which it is, but I thought it was nice to add.. Which patch do we favour? webrev-01 or -02 ? Neither, there should be no change to the AbstractStringBuilder constructor and the change should be done in the subclass constructors. Roger 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 From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 26/03/2019 15:24 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Sent by: "core-libs-dev" Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 >> >> Many 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 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 Mar 26 19:45:33 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Mar 2019 15:45:33 -0400 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> Message-ID: Hi Leonard, The introduction (in -01) of getCharSequenceCoder() and its use in StringBuilder and StringBuffer are fine. The change that is unnecessary is the change to the constructor in AbstractStringBuilder(coder, length, addition) to check COMPACT_STRINGS before using the coder. The existing code that uses the coder literally is fine since it is computed from getCharSequenceCoder(). I should have been more specific. Roger On 03/26/2019 03:37 PM, Andrew Leonard wrote: > So my creation of getCharSequenceCoder() was in trying to use the same > method as the StringBuffer(String) constructors, ie.String.coder(), > however with the StringBuffer(CharSequence,..) constructor the seq can > be a String or a StringBuilder or a StringBuffer, hence I created the > static getCharSequenceCoder() which switched on the sequence type to > obtain the coder... > Isn't that in keeping with the (String) constructor? i'm not sure how > else we can determine the coder from a CharSequence ? unless we change > the constructor to delegate to the caller to pass in the coder? > > 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 > > > > > From: Roger Riggs > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net, Ivan Gerasimov > > Date: 26/03/2019 19:15 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi, > > We've got the subject open and its fresh, there's no need for a > separate review cycle. > > The first fix (-01) does not seem to be consistent with the original > design > and handling of the coder.? The StringBuilder(String) and > StringBuffer(String) > constructors are the pattern that should be followed for determining > the coder for the new instance. > > Checking for COMPACT_STRING in two places (the AbstractStringBuilder and > the sub classes) is unnecessary and distributes the information about the > correct coder across two classes where determining what it should be > in the subclass has more complete? information and can correctly > determine > the coder once. > > We can likely find a reviewer to be a tie-breaker if Ivan sees it as > desirable. > > Thanks, Roger > > > On 03/26/2019 02:38 PM, Andrew Leonard wrote: > Sorry chaps, I think my brain is getting confused!, I think we have > conflicting reviews here? > > Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so > it was only defined in one place.. > I agree with this being called in StringBuffer/Builder then we don't > need the change to AbstractStringBuild() constuctor, however Ivan > wants getCharSequenceCoder() that done as a separate "bug". > > So I think it comes down to do we do this as 2 "bugs" or 1 ? > > 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_ > > > > > > From: Roger Riggs __ > > To: Andrew Leonard __ > , Ivan Gerasimov > __ > Cc: _core-libs-dev at openjdk.java.net_ > > Date: 26/03/2019 18:19 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi Andrew, > > You are going to have to change the same code twice > because the changes should be the StringBuffer and StringBuilder > constructors and would remove the code that is added to > the AbstractStringBuilder constructor.? That's a waste of review cycles. > > > On 03/26/2019 11:45 AM, Andrew Leonard wrote: > Hi Roger, > No worries, the more the merrier! > So that was one of my reasoning for adding getCharSequenceCode() was, > I think what you're suggesting is my webrev.01, > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ > > Ivan's view is that behaviour was an extended issue, which it is, but > I thought it was nice to add.. > > Which patch do we favour? webrev-01 or -02 ? > > Neither, there should be no change to the AbstractStringBuilder > constructor > and the change should be done in the subclass constructors. > > Roger > > > 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_ > > > > > > From: Roger Riggs __ > > To: _core-libs-dev at openjdk.java.net_ > > Date: 26/03/2019 15:24 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > Sent by: "core-libs-dev" __ > > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Sorry to be late to the review. > > For symmetry with the constructors StringBuffer(String), and > StringBuilder(String) > the determine the coder based on the input argument, I would recommend > using the getCharSequenceCoder added in the -01 webrev and calling > it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) > constructors. > > It would be symmetric with the getCoder() method (line 1635) > and select the appropriate coder base on the input value (if known.) > > Thanks, Roger > > > > On 03/26/2019 10:57 AM, Andrew Leonard wrote: > > Hi Ivan, > > Yes, i'm happy with that, as you say the simple constructor change fixes > > the immediate issue, but not necessarily the extended issue of a > > non-compactable CharSequence in COMPACT_STRINGS mode, but that's > probably > > an enhanced issue to cover in a separate bug... > > I've created a new webrev.02 with just the constructor change and the > > testcase: > > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/_ > > > > > 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_ > > > > > > > > > > > From: ? Ivan Gerasimov __ > > > To: ? ? Andrew Leonard __ > > > Cc: _core-libs-dev at openjdk.java.net_ > > > Date: ? 26/03/2019 01:18 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Thanks Andrew! > > Introducing getCharSequenceCoder() is actually an enhancement, which may > > improve pre-allocation in certain cases. > > It's not actually required to restore correctness of > StringBuilder/Buffer > > constructors. > > I recommend to separate it from this bug fix, so it can be discussed > > separately, and determined if this is the best approach to this > > enhancement. > > If you agree, I can adjust your latest patch accordingly, run it through > > the Mach5 test systems and push it on your behalf. > > With kind regards, > > Ivan > > > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > > Hi Ivan, > > Here is my updated webrev: > > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ > > > > > 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_ > > > > > > > > > > > From: ? ? ? ?Ivan Gerasimov __ > > > To: ? ? ? ?Andrew Leonard __ > > > Cc: _core-libs-dev at openjdk.java.net_ > > > Date: ? ? ? ?25/03/2019 22:55 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > I was thinking of organizing code similar to what is done in > > AbstractStringBuilder(int): > > > > if (COMPACT_STRINGS && coderHint == LATIN1) { > > ? ? ?value = new byte[capacity]; > > ? ? ?coder = LATIN1; > > } else { > > ? ? ?value = StringUTF16.newBytesFor(capacity); > > ? ? ?coder = UTF16; > > } > > > > With kind regards, > > Ivan > > > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > > Hi Ivan, > > I think I see what you're saying, you mean we also need to correct this > > line in AbstractStringBuilder > > constructor: > > value = (coder == LATIN1) > > ? ? ? ? ? ? ? ? ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > to be maybe: > > value = (COMPACT_STRINGS && coder == LATIN1) > > ? ? ? ? ? ? ? ? ? new byte[capacity] : > StringUTF16.newBytesFor(capacity); > > > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS > > a string could be UTF16 if > > it cannot be compacted, so it's more than just a hint isn't it? > > > > 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_ > > > > > > > > > > > From: ? ? ? ?Ivan Gerasimov __ > > > To: ? ? ? ?Andrew Leonard __ > , > > _core-libs-dev at openjdk.java.net_ > > Date: ? ? ? ?25/03/2019 22:20 > > Subject: ? ? ? ?Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Hi Andrew! > > > > Thanks for finding this bug! > > > > Your fix solves the problem. > > > > However, I think the main issue is that the constructor > > AbstractStringBuilder(byte,int,int) is now broken: ?as you discovered, > > it allows to create a string buffer with the coder LATIN1 when > > COMPACT_STRINGS is false. > > > > Wouldn't it make sense to rename the argument of the constructor to, > > say, coderHint, and then either use it as the coder if > > COMPACT_STRINGS==true, or discard it otherwise. > > > > What do you think? > > > > With kind regards, > > Ivan > > > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > >> Hi, > >> Please can I request a sponsor for this fix to a JDK-13 regression? > >> > >> Patch with jtreg testcase here: > >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ > > >> > >> bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ > >> > >> Many 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 > > > > 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 andy.herrick at oracle.com Tue Mar 26 19:53:42 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Mar 2019 15:53:42 -0400 Subject: RFR: JDK-8221256: Fix create-installer specific options on MAC Message-ID: <3194981f-5ec3-6429-2cfb-8ce835594823@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8221256 [2] http://cr.openjdk.java.net/~herrick/8221256/ /Andy From ivan.gerasimov at oracle.com Tue Mar 26 20:04:49 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 26 Mar 2019 13:04:49 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> Message-ID: <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> From the design point of view, I believe it is better to have the constructor AbstractStringBuilder(int, int, int) to check if the coder argument makes sense with respect to the value of COMPACT_STRING, so it won't be possible to create a StringBuilder with the coder==LATIN1, when it is not supported. For calculating the coderHint then, it is not necessary to check COMPACT_STRING: If the CharSequence argument is in fact String or AbstractStringBuilder, the coder is known, otherwise LATIN1 can be passed in as a hint (for an arbitrary CharSequence it is not 100% accurate anyway). The constructor AbstractStringBuilder(int, int, int) will then either use the provided coder, or adjust it if necessary. Will we agree on something like following? http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/ With kind regards, Ivan On 3/26/19 12:14 PM, Roger Riggs wrote: > Hi, > > We've got the subject open and its fresh, there's no need for a > separate review cycle. > > The first fix (-01) does not seem to be consistent with the original > design > and handling of the coder. The StringBuilder(String) and > StringBuffer(String) > constructors are the pattern that should be followed for determining > the coder for the new instance. > > Checking for COMPACT_STRING in two places (the AbstractStringBuilder and > the sub classes) is unnecessary and distributes the information about the > correct coder across two classes where determining what it should be > in the subclass has more complete information and can correctly > determine > the coder once. > > We can likely find a reviewer to be a tie-breaker if Ivan sees it as > desirable. > > Thanks, Roger > > > On 03/26/2019 02:38 PM, Andrew Leonard wrote: >> Sorry chaps, I think my brain is getting confused!, I think we have >> conflicting reviews here? >> >> Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so >> it was only defined in one place.. >> I agree with this being called in StringBuffer/Builder then we don't >> need the change to AbstractStringBuild() constuctor, however Ivan >> wants getCharSequenceCoder() that done as a separate "bug". >> >> So I think it comes down to do we do this as 2 "bugs" or 1 ? >> >> 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 >> >> >> >> >> From: Roger Riggs >> To: Andrew Leonard , Ivan Gerasimov >> >> Cc: core-libs-dev at openjdk.java.net >> Date: 26/03/2019 18:19 >> Subject: Re: Request for sponsor: JDK-8221430: >> StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings specified >> ------------------------------------------------------------------------ >> >> >> >> Hi Andrew, >> >> You are going to have to change the same code twice >> because the changes should be the StringBuffer and StringBuilder >> constructors and would remove the code that is added to >> the AbstractStringBuilder constructor. That's a waste of review cycles. >> >> >> On 03/26/2019 11:45 AM, Andrew Leonard wrote: >> Hi Roger, >> No worries, the more the merrier! >> So that was one of my reasoning for adding getCharSequenceCode() was, >> I think what you're suggesting is my webrev.01, >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ >> >> Ivan's view is that behaviour was an extended issue, which it is, but >> I thought it was nice to add.. >> >> Which patch do we favour? webrev-01 or -02 ? >> >> Neither, there should be no change to the AbstractStringBuilder >> constructor >> and the change should be done in the subclass constructors. >> >> Roger >> >> >> 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_ >> >> >> >> >> >> From: Roger Riggs __ >> >> To: _core-libs-dev at openjdk.java.net_ >> >> Date: 26/03/2019 15:24 >> Subject: Re: Request for sponsor: JDK-8221430: >> StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings specified >> Sent by: "core-libs-dev" __ >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Andrew, >> >> Sorry to be late to the review. >> >> For symmetry with the constructors StringBuffer(String), and >> StringBuilder(String) >> the determine the coder based on the input argument, I would recommend >> using the getCharSequenceCoder added in the -01 webrev and calling >> it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) >> constructors. >> >> It would be symmetric with the getCoder() method (line 1635) >> and select the appropriate coder base on the input value (if known.) >> >> Thanks, Roger >> >> >> >> On 03/26/2019 10:57 AM, Andrew Leonard wrote: >> > Hi Ivan, >> > Yes, i'm happy with that, as you say the simple constructor change >> fixes >> > the immediate issue, but not necessarily the extended issue of a >> > non-compactable CharSequence in COMPACT_STRINGS mode, but that's >> probably >> > an enhanced issue to cover in a separate bug... >> > I've created a new webrev.02 with just the constructor change and the >> > testcase: >> > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/_ >> >> > >> > 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_ >> >> > >> > >> > >> > >> > From: Ivan Gerasimov __ >> >> > To: Andrew Leonard __ >> >> > Cc: _core-libs-dev at openjdk.java.net_ >> >> > Date: 26/03/2019 01:18 >> > Subject: Re: Request for sponsor: JDK-8221430: >> > StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings >> > specified >> > >> > >> > >> > Thanks Andrew! >> > Introducing getCharSequenceCoder() is actually an enhancement, >> which may >> > improve pre-allocation in certain cases. >> > It's not actually required to restore correctness of >> StringBuilder/Buffer >> > constructors. >> > I recommend to separate it from this bug fix, so it can be discussed >> > separately, and determined if this is the best approach to this >> > enhancement. >> > If you agree, I can adjust your latest patch accordingly, run it >> through >> > the Mach5 test systems and push it on your behalf. >> > With kind regards, >> > Ivan >> > >> > On 3/25/19 5:00 PM, Andrew Leonard wrote: >> > Hi Ivan, >> > Here is my updated webrev: >> > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ >> >> > >> > 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_ >> >> > >> > >> > >> > >> > From: Ivan Gerasimov __ >> >> > To: Andrew Leonard __ >> >> > Cc: _core-libs-dev at openjdk.java.net_ >> >> > Date: 25/03/2019 22:55 >> > Subject: Re: Request for sponsor: JDK-8221430: >> > StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings >> > specified >> > >> > >> > >> > I was thinking of organizing code similar to what is done in >> > AbstractStringBuilder(int): >> > >> > if (COMPACT_STRINGS && coderHint == LATIN1) { >> > value = new byte[capacity]; >> > coder = LATIN1; >> > } else { >> > value = StringUTF16.newBytesFor(capacity); >> > coder = UTF16; >> > } >> > >> > With kind regards, >> > Ivan >> > >> > On 3/25/19 3:45 PM, Andrew Leonard wrote: >> > Hi Ivan, >> > I think I see what you're saying, you mean we also need to correct this >> > line in AbstractStringBuilder >> > constructor: >> > value = (coder == LATIN1) >> > ? new byte[capacity] : >> StringUTF16.newBytesFor(capacity); >> > to be maybe: >> > value = (COMPACT_STRINGS && coder == LATIN1) >> > ? new byte[capacity] : >> StringUTF16.newBytesFor(capacity); >> > >> > The passed in coder stills need to be correct, since with >> COMPACT_STRINGS >> > a string could be UTF16 if >> > it cannot be compacted, so it's more than just a hint isn't it? >> > >> > 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_ >> >> > >> > >> > >> > >> > From: Ivan Gerasimov __ >> >> > To: Andrew Leonard __ >> , >> > _core-libs-dev at openjdk.java.net_ >> >> > Date: 25/03/2019 22:20 >> > Subject: Re: Request for sponsor: JDK-8221430: >> > StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings >> > specified >> > >> > >> > >> > Hi Andrew! >> > >> > Thanks for finding this bug! >> > >> > Your fix solves the problem. >> > >> > However, I think the main issue is that the constructor >> > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, >> > it allows to create a string buffer with the coder LATIN1 when >> > COMPACT_STRINGS is false. >> > >> > Wouldn't it make sense to rename the argument of the constructor to, >> > say, coderHint, and then either use it as the coder if >> > COMPACT_STRINGS==true, or discard it otherwise. >> > >> > What do you think? >> > >> > With kind regards, >> > Ivan >> > >> > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> >> Hi, >> >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> >> >> Patch with jtreg testcase here: >> >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ >> >> >> >> >> bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ >> >> >> >> Many 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 >> >> >> >> 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 > -- With kind regards, Ivan Gerasimov From sergei.tsypanov at yandex.ru Tue Mar 26 20:15:40 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 26 Mar 2019 22:15:40 +0200 Subject: [PATCH] Some improvements for java.lang.Class In-Reply-To: <1a181b47-e392-c1f7-1ecc-2cf1ab5cd4d2@gmail.com> References: <2796501552936166@myt6-add70abb4f02.qloud-c.yandex.net> <352521553106953@myt5-184376c2d7f8.qloud-c.yandex.net> <1a181b47-e392-c1f7-1ecc-2cf1ab5cd4d2@gmail.com> Message-ID: <10151351553631340@myt6-fe24916a5562.qloud-c.yandex.net> Hello Peter, I was unaware of mentioned detail (thank you a lot for pointing that out, it made me read the whole JEP280 again) so I've rebenchmarked my changes compiled with -XDstringConcat=inline. 1) as of Class::getTypeName for Object[] it turned out, that String::repeat performs slightly better: Benchmark Mode Cnt Score Error Units getTypeName_patched avgt 25 36,676 ? 3,559 ns/op getTypeName avgt 25 39,083 ? 1,737 ns/op getTypeName_patched:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op But for Object[][] situation is the opposite: Mode Cnt Score Error Units getTypeName_patched avgt 50 47,045 ? 0,455 ns/op getTypeName avgt 50 40,536 ? 0,196 ns/op getTypeName_patched:?gc.alloc.rate.norm avgt 50 176,000 ? 0,001 B/op getTypeName:?gc.alloc.rate.norm avgt 50 152,000 ? 0,001 B/op 2) as of Class::methodToString patched version clearly wins: methodToString_1arg avgt 50 238,476 ? 1,641 ns/op methodToString_1arg_patched avgt 50 197,900 ? 5,824 ns/op methodToString_1arg:?gc.alloc.rate.norm avgt 50 1209,600 ? 6,401 B/op methodToString_1arg_patched:?gc.alloc.rate.norm avgt 50 936,000 ? 0,001 B/op methodToString_noArgs avgt 50 224,054 ? 1,840 ns/op methodToString_noArgs_patched avgt 50 78,195 ? 0,418 ns/op methodToString_noArgs:?gc.alloc.rate.norm avgt 50 1131,200 ? 7,839 B/op methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 50 408,000 ? 0,001 B/op As Brian suggested I've separated the changes. The patch attached contains only the changes for Class::methodToString. They are obviously helpful as they rid concatenation as argument of StringBuilder::append call (obvious antipattern to me) and skip Stream creation for empty array. String::repeat obviously requires more investigation, it might turn out we don't need it in java.base in majority of use cases or in all of them. Regards, Sergei Tsypanov 21.03.2019, 00:56, "Peter Levart" : > Hi Sergei, > > I don't know if you are aware that the new invokedynamic based > translation of string concatenation expressions introduced in JDK 9 > (http://openjdk.java.net/jeps/280) only applies to code outside > java.base module. java.base module is still compiled with old-style > StringBuilder based translation of string concatenation expressions > because of bootstraping issues. > > If your benchmarks bellow are compiled with option > -XDstringConcat=inline to disable JEP280 translation (as java.base > module is), then it's OK. Else you are not benchmarking the right > translation of the code as you intend to change the code in java.base > module. > > Regards, Peter > > On 3/20/19 7:35 PM, ?????? ??????? wrote: >> ?I had a brief conversation with Brian Goetz which has left off the mailing list for some reason. Here's the text: >> ?--------------------------- >> ?Brian: >> >> ?These enhancements seem reasonable; these are exactly the cases that String::repeat was intended for. (This is a ?is this a reasonable idea? review, not a code review.). >> ?Have you looked for other places where similar transformations could be done? >> >> ?--------------------------- >> ?Me: >> >> ?Hello, >> ?after I had realized that looped StringBuilder::append calls can sometimes be replaced with String::repeat I requested corresponding inspection in IDEA issue tracker. >> ?Using the inspection I?ve found 129 similar warnings in jdk13 repo. >> ?Some of them are very promising, e.g. BigDecimal:: toPlainString where currently we have >> >>> ?int trailingZeros = checkScaleNonZero((-(long)scale)); >>> ?StringBuilder buf; >>> ?if(intCompact!=INFLATED) { >>> ??????buf = new StringBuilder(20+trailingZeros); >>> ??????buf.append(intCompact); >>> ?} else { >>> ??????String str = intVal.toString(); >>> ??????buf = new StringBuilder(str.length()+trailingZeros); >>> ??????buf.append(str); >>> ?} >>> ?for (int i = 0; i < trailingZeros; i++) { >>> ??????buf.append('0'); >>> ?} >>> ?return buf.toString(); >> ?which in fact can be simplified to >> >>> ?int trailingZeros = checkScaleNonZero((-(long)scale)); >>> ?if(intCompact!=INFLATED) { >>> ??????return intCompact + "0".repeat(trailingZeros); >>> ?} else { >>> ??????return intVal.toString() + "0".repeat(trailingZeros); >>> ?} >> ?The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. >> ?BTW, your reply to original message for some reason is missing from web-view. >> >> ?--------------------------- >> ?Brian: >> >> ?Cool. Note that replacing append() calls with repeat is not necessarily a win for anything other than code compactness; String::repeat will create a new string, which will then get appended to another StrinBuilder. So when used correctly (such as presized StringBuilders) appending in a loop is probably just as fast (look at the implementation of String::repeat.). >> >>> ?if(intCompact!=INFLATED) { >>> ??????return intCompact + "0".repeat(trailingZeros); >>> ?} else { >>> ??????return intVal.toString() + "0".repeat(trailingZeros); >>> ?} >> ?Which can be further simplified to >> >>> ?????((intCompact != INFLATED) ? intCompact : intVal.toString) + ?0?.repeat(trailingZeros); >> >> ?The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. >> ?I like short and simple. I am questioning the ?faster and memory saving.? That should be validated. >> >> ?--------------------------- >> ?Me: >> >> ?I think optimizations provided by JEP 280 allow compiler to optimize String concatenation executed with '+' by using StringBuilder of exact size (when the size of all components is known, like in our case). >> >> ?I've checked this with benchmark >> >>> ?@State(Scope.Thread) >>> ?@BenchmarkMode(Mode.AverageTime) >>> ?@OutputTimeUnit(TimeUnit.NANOSECONDS) >>> ?@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >>> ?public class ConcatBenchmark { >>> >>> ??????@Param({"1", "2", "5", "8"}) >>> ??????private int trailingZeros; >>> >>> ??????private final long intCompact = 1L; >>> >>> ??????@Benchmark >>> ??????public String stringBuilder() { >>> ??????????StringBuilder buf; >>> ??????????buf = new StringBuilder(20 + trailingZeros); >>> ??????????buf.append(intCompact); >>> ??????????for (int i = 0; i < trailingZeros; i++) { >>> ??????????????buf.append('0'); >>> ??????????} >>> ??????????return buf.toString(); >>> ??????} >>> ??????@Benchmark >>> ??????public String stringRepeat() { >>> ??????????return intCompact + "0".repeat(trailingZeros); >>> ??????} >>> ?} >> ?Results: >> ??????????????????????????????????????????trailingZeros Mode Cnt Score Error Units >> ?stringBuilder 1 avgt 15 17,683 ? 0,664 ns/op >> ?stringRepeat 1 avgt 15 9,052 ? 0,042 ns/op >> >> ?stringBuilder 2 avgt 15 19,053 ? 1,206 ns/op >> ?stringRepeat 2 avgt 15 15,864 ? 1,331 ns/op >> >> ?stringBuilder 5 avgt 15 25,839 ? 2,256 ns/op >> ?stringRepeat 5 avgt 15 19,290 ? 1,685 ns/op >> >> ?stringBuilder 8 avgt 15 26,488 ? 0,371 ns/op >> ?stringRepeat 8 avgt 15 19,420 ? 1,593 ns/op >> >> ?stringBuilder:?gc.alloc.rate.norm 1 avgt 15 88,000 ? 0,001 B/op >> ?stringRepeat:?gc.alloc.rate.norm 1 avgt 15 48,000 ? 0,001 B/op >> >> ?stringBuilder:?gc.alloc.rate.norm 2 avgt 15 88,000 ? 0,001 B/op >> ?stringRepeat:?gc.alloc.rate.norm 2 avgt 15 72,000 ? 0,001 B/op >> >> ?stringBuilder:?gc.alloc.rate.norm 5 avgt 15 96,000 ? 0,001 B/op >> ?stringRepeat:?gc.alloc.rate.norm 5 avgt 15 72,000 ? 0,001 B/op >> >> ?stringBuilder:?gc.alloc.rate.norm 8 avgt 15 104,000 ? 0,001 B/op >> ?stringRepeat:?gc.alloc.rate.norm 8 avgt 15 80,000 ? 0,001 B/op >> >> ?I think this is a useful optimization, so we should use String::repeat where possible. >> >> ?--------------------------- >> ?Brian: >> >> ?My recommendation is to split your patch into two. The first is the straightforward ?replace loop with repeat? refactoring, which can be mechanically generated by the IDE. Here, you should examine each site to ensure that the transform seems sensible given the context. The second can then be additional hand-refactoring opportunities exposed by the first. The benefit of splitting it this way is that reviewing the first is far easier when you can say all the changes are mechanical. >> >> ?(Somehow this fell off the list; feel free to bring it back.) >> >> ?18.03.2019, 21:13, "?????? ???????" : >>> ?Hi, >>> >>> ?I have an enhancement proposal for java.lang.Class.methodToString and java.lang.Class.getTypeName. >>> >>> ?First one is used when NoSuchMethodException is thrown from Class::getMethod which is in turn widely used in Spring Framework and often throws. >>> >>> ?In current implementation we have 2 major problems: >>> >>> ?- we create stream for the case when argTypes is not null but empty (which happens e. g. when Class::getMethod is called without vararg and throws) >>> ?- we have torn StringBuilder::append chain >>> >>> ?I?ve modified the method to skip creation of Stream for empty array and used separate StringBuilder for each case. Latter allowed to rid SB completely and use invokedynamic-based concatenation. >>> >>> ?I?ve compared both approaches for 2 cases: >>> >>> ?1) argTypes is empty >>> ?2) argTypes.length == 1 >>> >>> ?Benchmark Mode Cnt Score Error Units >>> >>> ?methodToString_noArgs avgt 25 170,986 ? 5,708 ns/op >>> ?methodToString_noArgs_patched avgt 25 26,883 ? 2,906 ns/op >>> >>> ?methodToString_1arg avgt 25 183,012 ? 0,701 ns/op >>> ?methodToString_1arg_patched avgt 25 112,784 ? 0,920 ns/op >>> >>> ?methodToString_noArgs:?gc.alloc.rate.norm avgt 25 881,600 ? 9,786 B/op >>> ?methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 25 128,000 ? 0,001 B/op >>> >>> ?methodToString_1arg:?gc.alloc.rate.norm avgt 25 960,000 ? 0,001 B/op >>> ?methodToString_1arg_patched:?gc.alloc.rate.norm avgt 25 552,000 ? 0,001 B/op >>> >>> ?We have the same problem regarding misusage of StringBuilder in Class:: getTypeName: >>> >>> ?StringBuilder sb = new StringBuilder(); >>> ?sb.append(cl.getName()); >>> ?for (int i = 0; i < dimensions; i++) { >>> ????? sb.append("[]"); >>> ?} >>> ?return sb.toString(); >>> >>> ?I suggest to use String::repeat instead of the loop: this again allows to get rid of StringBuilder and replace mentioned code with >>> >>> ?return cl.getName() + "[]".repeat(dimensions); >>> >>> ?Here are benchmark results executed for type Object[].class: >>> >>> ????????????????????????????????????????????Mode Cnt Score Error Units >>> ?getTypeName_patched avgt 25 16,037 ? 0,431 ns/op >>> ?getTypeName_patched:?gc.alloc.rate.norm avgt 25 64,000 ? 0,001 B/op >>> >>> ?getTypeName avgt 25 34,274 ? 1,432 ns/op >>> ?getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op >>> >>> ?Regards, >>> ?Sergei Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: klass.txt Type: text/x-diff Size: 1149 bytes Desc: not available URL: From alexey.semenyuk at oracle.com Tue Mar 26 20:56:24 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 26 Mar 2019 16:56:24 -0400 Subject: jpackage Proposal to replace Inno Setup in exe installers for Windows Message-ID: <70b6f235-2187-8b87-3ce2-b3f50fadab16@oracle.com> Hi, RFE for jpackage to replace Inno Setup in exe installers for Windows was filed recently and available at https://bugs.openjdk.java.net/browse/JDK-8221333. RFE was filed based on an assumption it will not have a major impact on users of jpackage. Please let us know in the comments to the RFE if there are any objections against the change. - Alexey From andrew_m_leonard at uk.ibm.com Tue Mar 26 21:00:21 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Mar 2019 21:00:21 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> Message-ID: Roger, sorry I missunderstood you, yes I agree with what you're saying. Ivan, I see your view on the constructor, which prevents coder being set to LATIN1 in the case of !COMPACT_STRINGS. So if Roger is happy with your webrev, i'll go with that. 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 From: Ivan Gerasimov To: Roger Riggs , Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 20:07 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified >From the design point of view, I believe it is better to have the constructor AbstractStringBuilder(int, int, int) to check if the coder argument makes sense with respect to the value of COMPACT_STRING, so it won't be possible to create a StringBuilder with the coder==LATIN1, when it is not supported. For calculating the coderHint then, it is not necessary to check COMPACT_STRING: If the CharSequence argument is in fact String or AbstractStringBuilder, the coder is known, otherwise LATIN1 can be passed in as a hint (for an arbitrary CharSequence it is not 100% accurate anyway). The constructor AbstractStringBuilder(int, int, int) will then either use the provided coder, or adjust it if necessary. Will we agree on something like following? http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/ With kind regards, Ivan On 3/26/19 12:14 PM, Roger Riggs wrote: Hi, We've got the subject open and its fresh, there's no need for a separate review cycle. The first fix (-01) does not seem to be consistent with the original design and handling of the coder. The StringBuilder(String) and StringBuffer(String) constructors are the pattern that should be followed for determining the coder for the new instance. Checking for COMPACT_STRING in two places (the AbstractStringBuilder and the sub classes) is unnecessary and distributes the information about the correct coder across two classes where determining what it should be in the subclass has more complete information and can correctly determine the coder once. We can likely find a reviewer to be a tie-breaker if Ivan sees it as desirable. Thanks, Roger On 03/26/2019 02:38 PM, Andrew Leonard wrote: Sorry chaps, I think my brain is getting confused!, I think we have conflicting reviews here? Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so it was only defined in one place.. I agree with this being called in StringBuffer/Builder then we don't need the change to AbstractStringBuild() constuctor, however Ivan wants getCharSequenceCoder() that done as a separate "bug". So I think it comes down to do we do this as 2 "bugs" or 1 ? 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 From: Roger Riggs To: Andrew Leonard , Ivan Gerasimov Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 18:19 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Andrew, You are going to have to change the same code twice because the changes should be the StringBuffer and StringBuilder constructors and would remove the code that is added to the AbstractStringBuilder constructor. That's a waste of review cycles. On 03/26/2019 11:45 AM, Andrew Leonard wrote: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Ivan's view is that behaviour was an extended issue, which it is, but I thought it was nice to add.. Which patch do we favour? webrev-01 or -02 ? Neither, there should be no change to the AbstractStringBuilder constructor and the change should be done in the subclass constructors. Roger 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 From: Roger Riggs To: core-libs-dev at openjdk.java.net Date: 26/03/2019 15:24 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Sent by: "core-libs-dev" Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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 > > > > > From: Ivan Gerasimov > To: Andrew Leonard , > core-libs-dev at openjdk.java.net > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221430 >> >> Many 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 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 -- With kind regards, Ivan Gerasimov 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 alexander.matveev at oracle.com Tue Mar 26 21:23:44 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 26 Mar 2019 14:23:44 -0700 Subject: RFR: JDK-8221256: Fix create-installer specific options on MAC In-Reply-To: <3194981f-5ec3-6429-2cfb-8ce835594823@oracle.com> References: <3194981f-5ec3-6429-2cfb-8ce835594823@oracle.com> Message-ID: <5abb9523-2a61-e2a2-f29e-9823147a0062@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 3/26/2019 12:53 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] https://bugs.openjdk.java.net/browse/JDK-8221256 > > [2] http://cr.openjdk.java.net/~herrick/8221256/ > > /Andy > From mandy.chung at oracle.com Tue Mar 26 21:44:56 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Mar 2019 14:44:56 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> Message-ID: <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> On 3/26/19 4:57 AM, Lindenmaier, Goetz wrote: >> and also the cases when it requires to look at its caller frame. > Never. Only the method that was executed when the exception is > thrown is needed. I only mention the backtrace because it happens to > store the top method and the corresponding bytecode position in the > top method. That explains why I don't see an example of: ???? getNull().m(); ???? public void m() {}; ???? static NPE getNull() { ???????? return null; ???? } For a compiler expert or one who study the data flow analysis paper, is this example very clear to them that it won't be supported? This is related to my comment w.r.t. the data flow analysis comes from.? I was looking for some level of information be spelled out in the JEP that can sufficiently give a non-compiler expert an idea but of course no point to replicate the paper here. It's good to know that this proposal needs the top frame only. Please make it clear in the JEP.??? The JEP can take out `StackWalker` but instead talks about `StackFrame` since doing it in Java means that it only needs to get back a `StackFrame` instance representing the top frame stored in `Throwable::backtrace` This will avoid the confusion on calling StackWalker in the NPE constructor and constructing many StackFrame and many ResolvedMethodName.? That was part of the code review discussion. > >> "Computing either part of these messages can fail due to insufficient >> information." >> What are the cases that it fails to obtain the information? It'd be useful >> to list some examples if not all. > (a ? b : c).d > You can not know whether the ?-expression yielded b or c, thus > you don't know why the access .d failed. There is a corresponding example > in [1]. Please describe in the JEP the known cases that this proposal doesn't cover.?? Conditional expression is one and null receiver if it's the return value from a caller frame (I think this would help the readers). >> The "Different bytecode variants of a method" section >> >> This section raises the case when a method representing an execution stack >> frame throwing NPE becomes obsolete, it does not have the information >> to compute the message lazily. So this falls into the "insufficient >> information" category and no improved NPE message can be generated. > Yes, note this also only addresses the method in which the exception was raised. This should also go to the list of known cases that this proposal does not cover. >> The "computation overhead" section >> >> I agree with the requirement to have minimal performance overhead to >> the NPE construction cost. >> >> "NullPointerExceptions are thrown frequently." >> "Fortunately, most Exceptions are discarded without looking at the message." >> >> This is interesting. Do you have any statistic on the number of NPE thrown >> and swallowed on certain application/environment that you have gathered? > No, I can try to generate some numbers, though. But this assumption was made by > several others that commented on the previous review thread. For Throwable > in general, it is also the assumption why the intermediate backtrace data > structure is implemented instead of generating the stackFrames right away. > Since the JEP quotes that NullPointerExceptions are thrown frequently and swallowed, it would help if you can generate some numbers. This JEP will help the discussion on the proposed feature and design and avoid any confusion/assumption of the implementation. >> "If the message is printed based on the backtrace, it must be omitted >> if the top frame was dropped from the backtrace." >> >> If NPE includes the hidden frames, `Throwable::getStackTrace` and >> `Throwable::toString` and the VM printing of NPE stack trace needs to >> filter the hidden frames. I think it's appropriate for this JEP to >> cover rather than in a separate JBS issue. > Hmm, I don't completely understand what you want to say, please > excuse, I'm a foreign speaker :). I'll give a comprehensive answer: > To my understanding this is a consequence of the existing JVM/class file > implementation that calls methods that should be hidden to the user. > The implementation drops these frames when the backtrace datastructure > is computed. If this happens, the information needed to compute the > message is lost, and it can not be printed. Yes I am familiar with that. > The fact that this happened must be remembered in the VM > so that printing the message can be suppressed. Else a message for > a completely wrong bytecode is printed. Yup. > I think the JEP should mention that this is happening. How this is > implemented and then pushed to the repo is not subject to a JEP, > is it? I think this is related to this JEP.??? The question would be: - should it include all hidden frames? - should it include the top frame if it's a hidden frame since this feature only requires the top frame? This JEP requires the hidden frame to be recorded in the backtrace. This has impact to the printing of stack trace that needs to know about hidden frames and decide if it should be filtered or included when printing. > I made a webrev of its own for this problem, so that the code > can be looked at isolated of other, orthogonal issues. > http://cr.openjdk.java.net/~goetz/wr19/8221077-hidden_to_frame/ I don't need the webrev as we are discussing the proposed feature and design. >> The "Message persistance" section >> >> I read this section like an implementation details > Yes, I had the feeling that I was talking too much about implementation details, > but mostly in the "Basic algorithm" section. > This section discusses characteristics of NPE that differ from other exceptions > and that were proposed in the course of the review of my > original webrev. They are visible to the Java implementor. > So I think this is just the basic information needed in a JEP. This is a good start that allows us to start the discussion.? This JEP will probably need several iterations of improvement.? I'm writing a JEP that I have iterated many times already and it makes the JEP and proposed feature better.?? Just to share with you that it's part of the process. >> I think this section >> intends to call out that the message of NPE if constructed by user code >> i.e. via public constructor, should not be altered including no-arg >> constructor or pass a null message to 1-arg constructor. The enhanced >> NPE message is proposed only when NPE is thrown due to null dereference >> when executing bytecode. > Yes. > >> I don't understand what you tried to say about "npe.getMessage() == >> npe.getMessage()". >> Throwable::getMessage does not guarantee to return same String object for >> each invocation. > It does not guarantee so, but it's the case for most exceptions. Usually, > one calls super(msg) in an Exception constructor. > It is a design decision to implement it that way, my original proposal > was different. I'm fine with this design, but it should be mentioned I think. I think the JEP should be made clearer? what you intend to say. >> When deserializing the class bytes may be of a different version, so >> StackTraceElements >> are serialized with its string form. Serializing NPE with a computed message >> seems to be the only viable solution. > I think implementing writeReplace() is a good idea, too. But > Roger does not like it: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058513.html > The JEP should record this either if this is an open issue or makes it a clear proposal to compute the message when NPE is serialized and what the client would do (that may be running in a different version) >> The "Message content" section >> >> I think this section can break down into clear scenarios >> 1. debug information is present >> 2. debug information is absent >> 3. the matching version of bytecode is not available >> >> I agree that the message should be easy for Java developers including the >> beginners to understand the error. > Hmm, only printing local variable names is affected by the debug information. > So I don't think a section of its own is necessary. > > If the matching bytecode is not available, nothing can be printed. See my suggestion above to list all known cases that this proposed feature will not cover, i.e. no improved message. > So it does not affect the content of the message. Should I call this > section "Message wording"? I think this is closer to what I want to > discuss in this paragraph. > >> You bring up a good question about the exception message format e.g. >> whether with >> quotation (none vs single quote vs double quote). It's good to have a guideline >> on that while this is out of scope of this JEP. IAE was updated to include >> module name, loader name and improve the error message for the developers >> to understand the exception which is a good improvement. > IAE quotes the names, which are user defined strings. It does not quote class names, method names etc. > Here, I was asked to quote these, which is inconsistent with IAE. But there are other > examples where method names are quoted ... So there is no clear line followed > yet. In the end, I don't care, but want advice how to do it. (I would not quote ...). > You can add it to the open issues section. >> "Alternatives" section >> >> "The current proposal is to implement this in the Java runtime in C++ accessing >> directly the available datastructures in the metaspace." >> >> "Also, ASM and StackWalker do not support the full functionality needed. >> StackWalker must be called in the NullPointerException constructor." >> This is not true as you wrote in the subsequent sentence. If we choose >> the implementation to Java, StackWalker will need to be extended to >> read Throwable's backtrace. > The senctence above describes the status quo. The current implementation > of StackWalker must be called in the constructor. I just called out the confusion this section could cause.? I think it should be updated or rephase. >> Such specialized form can provide the >> ability to fetch the bytecode in Method* if appropriate. This is >> the implementation details. As discussed in the email thread, another >> implementation choice could be a hybrid of native in the VM and Java >> to accomplish this task (for example fetching the bytecode of the >> current version could be done in the VM if we agree supporting >> the redefinition case). > Yes, obviously we can implement a lot of solutions. Instead of changing > StackWalker, we could simply expose [2] java_lang_Throwable::get_method_and_bci() > to Java in NPE. After all, we only need the method which happens to be stored > as top frame in backtrace. > That's easy but implementation-detail. >> For logic that is not strictly needed to be done in the VM, doing it >> in Java and library is a good option to consider (putting aside the >> amount of new code you have to write). Looks like you can't evaluate >> the alternatives since existing library code requires work in order to >> prototype this in Java. So I'd say more investigation needs to be done >> to decide on alternative implementation approaches. > >> "Testing" section >> >> "The basic implementation is in use in SAP's internal Java virtual machine since >> 2006." >> >> This is good information. This assumes if the same implementation goes into >> JDK. >> So this is subject to the discussion and code review. I think it's adequate to say >> unit tests will need to be developed. > There is a unit test in the webrev. Please point out test cases you think > are missing. [1] stems from this test. I am not commenting on [1] but the content of this section. Please refer to the JEP template (http://openjdk.java.net/jeps/2) about the Testing section. |// What kinds of test development and execution will be required in order // to validate this enhancement, beyond the usual mandatory unit tests? // Be sure to list any special platform or hardware requirements. | > >> I think this feature should not impact much of the existing VM code >> and so running existing jtreg tests, jck tests and other existing test suites should >> provide adequate coverage. >> >> I found [1] is quite useful to understand the scenarios this JEP considers. I >> think it >> would be useful to include them in the JEP perhaps as examples when >> describing >> the data flow analysis. > I thought I picked out the most obvious example, pointer chasing, and used it > in the motivation and the description of the basic algorithm. > >> [1] can be grouped into several categories and the JEP >> can >> just talk about the worthnoting groups and does not need to list all messages >> such as >> dereference a null receive on getfield, null array element vs null array > Yes, I think it makes sense to put more messages into the JEP. To be clear: What I was suggesting is to describe the scenarios this proposed feature will improve the message but *not* to cut-n-paste the messages from [1].? So this is not tied to what the message will be printed from the implementation. Writing the scenario in English can help discussing the NPE messages should be implemented that will be easy for Joe developer to understand. Mandy > But I would > like to do that once it is agreed on the messages, so I don't need to > edit the JEP all the time. > The file referenced is simply generated by the test, so it's easy to update > and sure to reflect the implementation. > >> This JEP includes a few links to the C++ functions in the current webrev. I >> appreciate that and I assume they will be taken out at some point. > Yes, sure, I can remove that. > > Best regards, > Goetz. > From mandy.chung at oracle.com Tue Mar 26 22:56:23 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Mar 2019 15:56:23 -0700 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <7349dda7-2a1a-18fc-24d1-ba21dad46355@oracle.com> <6c038379-ce2d-cb8d-73c4-9a204e49c11c@oracle.com> <25b49f18-70bd-8230-6d29-4538e821d897@oracle.com> <44b7ea40-5091-293d-ce8f-b0739ffe59c0@oracle.com> Message-ID: <3a6a3adb-b15b-13eb-5d7d-9a752ad6efe9@oracle.com> On 3/26/19 10:24 AM, Adam Farley8 wrote: > Hiya Mandy, > > I've updated the webrev with your proposal, plus a few tweaks for > formatting. > > http://cr.openjdk.java.net/~afarley/8216558.2/webrev > > Let me know what you think. > This looks okay.? I took the liberty to take out the comment line (229-230) that I left out from my suggested fix. It's pushed.? Thanks for the contribution. Mandy From shade at redhat.com Tue Mar 26 23:00:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Mar 2019 00:00:00 +0100 Subject: RFR (XS) 8221524: java/util/Base64/TestEncodingDecodingLength.java should be disabled on 32-bit platforms Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8221524 It currently requests -Xmx8g, which is above the max representable memory for 32-bit VM. The test allocates byte[Integer.MAX_VALUE - C], which means we cannot trim the heap size. Therefore, we have to disable the test on 32-bit. Fix: diff -r 35cb5d1c5881 test/jdk/java/util/Base64/TestEncodingDecodingLength.java --- a/test/jdk/java/util/Base64/TestEncodingDecodingLength.java Tue Mar 26 22:29:54 2019 +0100 +++ b/test/jdk/java/util/Base64/TestEncodingDecodingLength.java Tue Mar 26 23:57:45 2019 +0100 @@ -28,11 +28,11 @@ /** * @test * @bug 8210583 8217969 8218265 * @summary Tests Base64.Encoder.encode and Base64.Decoder.decode * with the large size of input array/buffer - * @requires os.maxMemory >= 10g + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 10g) * @run main/othervm -Xms6g -Xmx8g TestEncodingDecodingLength * */ Testing: Linux {x86_64, x86_32} fastdebug, affected test -- Thanks, -Aleksey From ivan.gerasimov at oracle.com Tue Mar 26 23:30:04 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 26 Mar 2019 16:30:04 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> Message-ID: The main source of confusion here seems to be due to that the coder is passed in as an argument, so it either needs to be trusted or has to be verified in the constructor. So, let's instead introduce AbstractStringBuilder(CharSequence) and make it do all manipulations. http://cr.openjdk.java.net/~igerasim/8221430/01/webrev/ Note that the common case of StringBuilder(String) already gets intrinsified by hotspot. What do you think? With kind regards, Ivan On 3/26/19 1:04 PM, Ivan Gerasimov wrote: > From the design point of view, I believe it is better to have the > constructor AbstractStringBuilder(int, int, int) to check if the coder > argument makes sense with respect to the value of COMPACT_STRING, so > it won't be possible to create a StringBuilder with the coder==LATIN1, > when it is not supported. > > For calculating the coderHint then, it is not necessary to check > COMPACT_STRING: If the CharSequence argument is in fact String or > AbstractStringBuilder, the coder is known, otherwise LATIN1 can be > passed in as a hint (for an arbitrary CharSequence it is not 100% > accurate anyway). > The constructor AbstractStringBuilder(int, int, int) will then either > use the provided coder, or adjust it if necessary. > > Will we agree on something like following? > > http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/ > > With kind regards, > > Ivan > > > On 3/26/19 12:14 PM, Roger Riggs wrote: >> Hi, >> >> We've got the subject open and its fresh, there's no need for a >> separate review cycle. >> >> The first fix (-01) does not seem to be consistent with the original >> design >> and handling of the coder. The StringBuilder(String) and >> StringBuffer(String) >> constructors are the pattern that should be followed for determining >> the coder for the new instance. >> >> Checking for COMPACT_STRING in two places (the AbstractStringBuilder and >> the sub classes) is unnecessary and distributes the information about >> the >> correct coder across two classes where determining what it should be >> in the subclass has more complete information and can correctly >> determine >> the coder once. >> >> We can likely find a reviewer to be a tie-breaker if Ivan sees it as >> desirable. >> >> Thanks, Roger >> >> >> On 03/26/2019 02:38 PM, Andrew Leonard wrote: >>> Sorry chaps, I think my brain is getting confused!, I think we have >>> conflicting reviews here? >>> >>> Roger, I added the getCharSequenceCoder() to AbstractStringBuilder >>> so it was only defined in one place.. >>> I agree with this being called in StringBuffer/Builder then we don't >>> need the change to AbstractStringBuild() constuctor, however Ivan >>> wants getCharSequenceCoder() that done as a separate "bug". >>> >>> So I think it comes down to do we do this as 2 "bugs" or 1 ? >>> >>> 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 >>> >>> >>> >>> >>> From: Roger Riggs >>> To: Andrew Leonard , Ivan Gerasimov >>> >>> Cc: core-libs-dev at openjdk.java.net >>> Date: 26/03/2019 18:19 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Andrew, >>> >>> You are going to have to change the same code twice >>> because the changes should be the StringBuffer and StringBuilder >>> constructors and would remove the code that is added to >>> the AbstractStringBuilder constructor. That's a waste of review >>> cycles. >>> >>> >>> On 03/26/2019 11:45 AM, Andrew Leonard wrote: >>> Hi Roger, >>> No worries, the more the merrier! >>> So that was one of my reasoning for adding getCharSequenceCode() >>> was, I think what you're suggesting is my webrev.01, >>> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ >>> >>> Ivan's view is that behaviour was an extended issue, which it is, >>> but I thought it was nice to add.. >>> >>> Which patch do we favour? webrev-01 or -02 ? >>> >>> Neither, there should be no change to the AbstractStringBuilder >>> constructor >>> and the change should be done in the subclass constructors. >>> >>> Roger >>> >>> >>> 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_ >>> >>> >>> >>> >>> >>> From: Roger Riggs __ >>> >>> To: _core-libs-dev at openjdk.java.net_ >>> >>> Date: 26/03/2019 15:24 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> Sent by: "core-libs-dev" __ >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Andrew, >>> >>> Sorry to be late to the review. >>> >>> For symmetry with the constructors StringBuffer(String), and >>> StringBuilder(String) >>> the determine the coder based on the input argument, I would recommend >>> using the getCharSequenceCoder added in the -01 webrev and calling >>> it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) >>> constructors. >>> >>> It would be symmetric with the getCoder() method (line 1635) >>> and select the appropriate coder base on the input value (if known.) >>> >>> Thanks, Roger >>> >>> >>> >>> On 03/26/2019 10:57 AM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > Yes, i'm happy with that, as you say the simple constructor change >>> fixes >>> > the immediate issue, but not necessarily the extended issue of a >>> > non-compactable CharSequence in COMPACT_STRINGS mode, but that's >>> probably >>> > an enhanced issue to cover in a separate bug... >>> > I've created a new webrev.02 with just the constructor change and the >>> > testcase: >>> > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/_ >>> >>> > >>> > 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_ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov __ >>> >>> > To: Andrew Leonard __ >>> >>> > Cc: _core-libs-dev at openjdk.java.net_ >>> >>> > Date: 26/03/2019 01:18 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > Thanks Andrew! >>> > Introducing getCharSequenceCoder() is actually an enhancement, >>> which may >>> > improve pre-allocation in certain cases. >>> > It's not actually required to restore correctness of >>> StringBuilder/Buffer >>> > constructors. >>> > I recommend to separate it from this bug fix, so it can be discussed >>> > separately, and determined if this is the best approach to this >>> > enhancement. >>> > If you agree, I can adjust your latest patch accordingly, run it >>> through >>> > the Mach5 test systems and push it on your behalf. >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 5:00 PM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > Here is my updated webrev: >>> > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ >>> >>> > >>> > 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_ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov __ >>> >>> > To: Andrew Leonard __ >>> >>> > Cc: _core-libs-dev at openjdk.java.net_ >>> >>> > Date: 25/03/2019 22:55 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > I was thinking of organizing code similar to what is done in >>> > AbstractStringBuilder(int): >>> > >>> > if (COMPACT_STRINGS && coderHint == LATIN1) { >>> > value = new byte[capacity]; >>> > coder = LATIN1; >>> > } else { >>> > value = StringUTF16.newBytesFor(capacity); >>> > coder = UTF16; >>> > } >>> > >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 3:45 PM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > I think I see what you're saying, you mean we also need to correct >>> this >>> > line in AbstractStringBuilder >>> > constructor: >>> > value = (coder == LATIN1) >>> > ? new byte[capacity] : >>> StringUTF16.newBytesFor(capacity); >>> > to be maybe: >>> > value = (COMPACT_STRINGS && coder == LATIN1) >>> > ? new byte[capacity] : >>> StringUTF16.newBytesFor(capacity); >>> > >>> > The passed in coder stills need to be correct, since with >>> COMPACT_STRINGS >>> > a string could be UTF16 if >>> > it cannot be compacted, so it's more than just a hint isn't it? >>> > >>> > 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_ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov __ >>> >>> > To: Andrew Leonard __ >>> , >>> > _core-libs-dev at openjdk.java.net_ >>> >>> > Date: 25/03/2019 22:20 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > Hi Andrew! >>> > >>> > Thanks for finding this bug! >>> > >>> > Your fix solves the problem. >>> > >>> > However, I think the main issue is that the constructor >>> > AbstractStringBuilder(byte,int,int) is now broken: as you >>> discovered, >>> > it allows to create a string buffer with the coder LATIN1 when >>> > COMPACT_STRINGS is false. >>> > >>> > Wouldn't it make sense to rename the argument of the constructor to, >>> > say, coderHint, and then either use it as the coder if >>> > COMPACT_STRINGS==true, or discard it otherwise. >>> > >>> > What do you think? >>> > >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 12:45 PM, Andrew Leonard wrote: >>> >> Hi, >>> >> Please can I request a sponsor for this fix to a JDK-13 regression? >>> >> >>> >> Patch with jtreg testcase here: >>> >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ >>> >>> >> >>> >> bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ >>> >> >>> >> Many 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 >>> >>> >>> >>> 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 >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Wed Mar 27 01:48:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2019 11:48:36 +1000 Subject: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap In-Reply-To: <06d34271-8c77-2f0f-8bd0-f30c399d72ee@redhat.com> References: <586d7bf0-bf44-5db4-0598-c9cf8fec4a21@redhat.com> <203c2fb0-35e4-f144-c1f7-5916d47eea0a@redhat.com> <5780df56-67ac-bfcd-04fd-cbd2941375b8@oracle.com> <9a787261-6ddf-8245-8904-22ed05508683@redhat.com> <58077756-f793-5769-7ea9-4188fe25f5ab@oracle.com> <06d34271-8c77-2f0f-8bd0-f30c399d72ee@redhat.com> Message-ID: <845d96f2-c929-e139-a281-7cd171895059@oracle.com> On 26/03/2019 11:56 pm, Aleksey Shipilev wrote: > On 3/26/19 2:28 PM, Alan Bateman wrote: >>> Also, are we not doing "[TESTBUG]" prefixes in >>> synopsis anymore? I see you changed it in JIRA. >>> >> The "testbug" label is used to tag test only issues, encoding in the bug description/commit message >> isn't really reliable. Yes, some areas have used "[TESTBUG]", there was a time when some people put >> a "TEST-BUG" prefix. There isn't a JDK-wide convention (at least not to my knowledge). > > Understood, dropped "[TESTBUG]" from the other issue I have around. Given labels are not evident in emails I much prefer to see TESTBUG in the bug synopsis so it's evident in the RFR. David ----- > Thanks, > -Aleksey > > From mandy.chung at oracle.com Wed Mar 27 02:58:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Mar 2019 19:58:20 -0700 Subject: Review Request: JDK-8220282 Add MethodHandle tests on accessing final fields In-Reply-To: <8fb939e4-afbc-6711-1d16-b0c7f34d0a10@oracle.com> References: <8fb939e4-afbc-6711-1d16-b0c7f34d0a10@oracle.com> Message-ID: This is a new version of the patch: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8220282/webrev.01 I made further clean up to this new test. It extends MethodHandlesTest.HasFields class to include the test cases for instance final fields.? HasFields is used to test findGetter/findStaticGetter, findSetter/findStaticSetter, and unreflectSetter/unreflectGetter. A new HasFields::testCasesFor(int testMode) method is added to return the test cases where c[1] == Error.class indicates a negative test case. For getters, all HasFields except bogus_xx fields are positive test cases, i.e. no exception is expected. For findSetter/findStaticSetter, a final field has no write access and setting on a final field is a negative test case. For unreflectSetter, non-final fields and instance final fields whose accessible flag is true have write access and hence they are positive test cases whereas static final fields are negative test cases. thanks Mandy From alexander.matveev at oracle.com Wed Mar 27 02:57:36 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 26 Mar 2019 19:57:36 -0700 Subject: RFR: JDK-8221525: jpackage fails with non-ASCII characters in --copyright Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - .properties file was written in default encoding (file.encoding=Cp1252). Native code was expecting UTF-8 and thus was not able to read non-ASCII characters correctly. Fixed by writing file using UTF-8. [1] https://bugs.openjdk.java.net/browse/JDK-8221525 [2] http://cr.openjdk.java.net/~almatvee/8221525/webrev.00/ Thanks, Alexander From fujie at loongson.cn Wed Mar 27 04:44:57 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 27 Mar 2019 12:44:57 +0800 Subject: Fwd: Re: [Request for help] Questions about make test TEST="micro" failures In-Reply-To: <57cf05cb-38bd-43b2-f7d5-bc80ee087c03@oracle.com> References: <57cf05cb-38bd-43b2-f7d5-bc80ee087c03@oracle.com> Message-ID: <4f848336-dea5-c0e2-2e16-b7fd981a2181@loongson.cn> Thanks David. Forward it to core-libs-dev. -------- Forwarded Message -------- Subject: Re: [Request for help] Questions about make test TEST="micro" failures Date: Wed, 27 Mar 2019 14:12:55 +1000 From: David Holmes Organisation: Oracle Corporation To: Jie Fu , hotspot-dev at openjdk.java.net Hi Jie, These aren't hotspot tests. Maybe ask on core-libs-dev? Also I thought "make test ..." was no longer supported? David On 27/03/2019 1:47 pm, Jie Fu wrote: > Hi all, > > Following benchmarks failed when I do 'make test TEST="micro"'. > ---------------------------------------------- > org.openjdk.bench.java.lang.invoke.CallSiteSetTarget.testMutable > org.openjdk.bench.java.lang.invoke.CallSiteSetTarget.testVolatile > org.openjdk.bench.java.lang.invoke.CallSiteSetTargetSelf.testMutable > org.openjdk.bench.java.lang.invoke.CallSiteSetTargetSelf.testVolatile > org.openjdk.bench.java.lang.invoke.CallSiteStable.testConstant > org.openjdk.bench.java.lang.invoke.CallSiteStable.testMutable > org.openjdk.bench.java.lang.invoke.CallSiteStable.testVolatile > ---------------------------------------------- > > These failures can also be reproduced by a single run of each > benchmark, e.g. > ? make test > TEST="micro:org.openjdk.bench.java.lang.invoke.CallSiteSetTarget.testMutable" > > > Questions: why there are so many shouldNotCallThis() in > CallSiteSetTarget.java/CallSiteSetTargetSelf.java/CallSiteStable.java? > ?????????? How can I run these benchmarks properly? > > Thanks a lot. > > > Best regards, > Jie > > From martijnverburg at gmail.com Wed Mar 27 10:07:59 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 27 Mar 2019 10:07:59 +0000 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: Hi Thomas, Release only (we've only created debug builds for x64), we do use the treat errors as warnings flag. You can look at all of our build configurations and build histories at ci.adoptopenjdk.net - and I've copied in Ali Ince who's working for jClarity on Windows 32/64 builds amongst other things. Cheers, Martijn On Tue, 26 Mar 2019 at 06:04, Thomas St?fe wrote: > > > On Mon, Mar 25, 2019 at 10:49 PM Martijn Verburg > wrote: > >> Hi all, >> >> Snipping much, but commenting on one statement inline below. >> >> On Mon, 25 Mar 2019 at 01:58, David Holmes >> wrote: >> >>> Hi Thomas, >>> >>> A few queries, comments and concerns ... >>> >>> On 25/03/2019 6:58 am, Thomas St?fe wrote: >>> > Hi all, >>> > >>> > After a long time I tried to build a Windows 32bit VM (VS2017) and >>> failed; >>> >>> I'm somewhat surprised as I thought someone was actively doing Windows >>> 32-bit builds out there, plus there are shared code changes that should >>> also have been caught by non-Windows 32-bit builds. :( >>> >> >> AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 to >> do so and have hit the same issues (Thomas beat us to reporting!). >> >> > Still curious what you actually build, since I believe not all of the > issues are related to vs2017. > > Do you build release only or also debug? Do you build with > warnings-as-errors disabled? > > >> Hopefully, we'll have that nightly warning system in place for you going >> forward soon. >> >> > That would be helpful. > > Cheers, Thomas > > >> Cheers, >> Martijn >> > From thomas.stuefe at gmail.com Wed Mar 27 10:12:01 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 27 Mar 2019 11:12:01 +0100 Subject: RFR (XS) 8221524: java/util/Base64/TestEncodingDecodingLength.java should be disabled on 32-bit platforms In-Reply-To: References: Message-ID: Good & trivial. ..Thomas On Wed, Mar 27, 2019 at 12:00 AM Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221524 > > It currently requests -Xmx8g, which is above the max representable memory > for 32-bit VM. The test > allocates byte[Integer.MAX_VALUE - C], which means we cannot trim the heap > size. Therefore, we have > to disable the test on 32-bit. > > Fix: > > diff -r 35cb5d1c5881 > test/jdk/java/util/Base64/TestEncodingDecodingLength.java > --- a/test/jdk/java/util/Base64/TestEncodingDecodingLength.java Tue Mar 26 > 22:29:54 2019 +0100 > +++ b/test/jdk/java/util/Base64/TestEncodingDecodingLength.java Tue Mar 26 > 23:57:45 2019 +0100 > @@ -28,11 +28,11 @@ > /** > * @test > * @bug 8210583 8217969 8218265 > * @summary Tests Base64.Encoder.encode and Base64.Decoder.decode > * with the large size of input array/buffer > - * @requires os.maxMemory >= 10g > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 10g) > * @run main/othervm -Xms6g -Xmx8g TestEncodingDecodingLength > * > */ > > Testing: Linux {x86_64, x86_32} fastdebug, affected test > > -- > Thanks, > -Aleksey > > > From Alan.Bateman at oracle.com Wed Mar 27 10:15:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Mar 2019 10:15:47 +0000 Subject: RFR (XS) 8221524: java/util/Base64/TestEncodingDecodingLength.java should be disabled on 32-bit platforms In-Reply-To: References: Message-ID: <72d19ee8-027b-4882-c73f-447803c8a728@oracle.com> On 26/03/2019 23:00, Aleksey Shipilev wrote: > - * @requires os.maxMemory >= 10g > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 10g) > Looks okay to me. -Alan From thomas.stuefe at gmail.com Wed Mar 27 11:13:46 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 27 Mar 2019 12:13:46 +0100 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: On Wed, Mar 27, 2019 at 11:08 AM Martijn Verburg wrote: > Hi Thomas, > > Release only (we've only created debug builds for x64), > Okay. A number of those errors were debug only. > we do use the treat errors as warnings flag. > Other way around, I hope ;) > > You can look at all of our build configurations and build histories at > ci.adoptopenjdk.net - and I've copied in Ali Ince who's working for > jClarity on Windows 32/64 builds amongst other things. > > Okay, that's useful. JDK changes have been pushed (JDK-8221405 , JDK-8221406 , JDK-8221407 , first one in jdk/client since awt maintainers asked me to). Hotspot changes still under review, we ponder the best way to deal with a supposed vc++ bug here ( JDK-8221408 ). Feel free to test or review. Note that I do not plan to keep windows 32 bit alive, this was just a weekend thing because I needed a 32bit VM on windows for some comparisons. So I'd be happy that you guys are regularly building it (if possible fastdebug too). Please report any build breaks. When reported promptly, with the offending change linked in JBS, the authors will often try to fix it themselves. Cheers, Thomas > Cheers, > Martijn > > > On Tue, 26 Mar 2019 at 06:04, Thomas St?fe > wrote: > >> >> >> On Mon, Mar 25, 2019 at 10:49 PM Martijn Verburg < >> martijnverburg at gmail.com> wrote: >> >>> Hi all, >>> >>> Snipping much, but commenting on one statement inline below. >>> >>> On Mon, 25 Mar 2019 at 01:58, David Holmes >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> A few queries, comments and concerns ... >>>> >>>> On 25/03/2019 6:58 am, Thomas St?fe wrote: >>>> > Hi all, >>>> > >>>> > After a long time I tried to build a Windows 32bit VM (VS2017) and >>>> failed; >>>> >>>> I'm somewhat surprised as I thought someone was actively doing Windows >>>> 32-bit builds out there, plus there are shared code changes that should >>>> also have been caught by non-Windows 32-bit builds. :( >>>> >>> >>> AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 >>> to do so and have hit the same issues (Thomas beat us to reporting!). >>> >>> >> Still curious what you actually build, since I believe not all of the >> issues are related to vs2017. >> >> Do you build release only or also debug? Do you build with >> warnings-as-errors disabled? >> >> >>> Hopefully, we'll have that nightly warning system in place for you going >>> forward soon. >>> >>> >> That would be helpful. >> >> Cheers, Thomas >> >> >>> Cheers, >>> Martijn >>> >> From peter.levart at gmail.com Wed Mar 27 11:25:04 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Mar 2019 12:25:04 +0100 Subject: RFR: 8221473: Configuration::reads can use Set.copyOf In-Reply-To: <741d52ce-931d-2e51-1806-bdc45d4cca30@oracle.com> References: <5cf2028b-e7b9-74e8-bb74-139c109b1459@oracle.com> <741d52ce-931d-2e51-1806-bdc45d4cca30@oracle.com> Message-ID: <0e551d13-8b18-babd-20b4-8c98a32dd171@gmail.com> Hi, On 3/26/19 7:44 PM, Daniel Fuchs wrote: > Hi Peter, > > On 26/03/2019 18:01, Peter Levart wrote: >> Would such method addition be worth it? > > Here is the impl of Set.copyOf: > > ??? static Set copyOf(Collection coll) { > ??????? if (coll instanceof ImmutableCollections.AbstractImmutableSet) { > ??????????? return (Set)coll; > ??????? } else { > ??????????? return (Set)Set.of(new HashSet<>(coll).toArray()); > ??????? } > ??? } > Yes, and that method is suitable for situations where there is a chance of one or the other case and the user is aware of performance implications of either case. There are other situations where the code guarantees that the Set at hand is already immutable and programmer might just want to verify that as a post-condition before returning it. In that case the non-immutability would be considered an error. I'm thinking of the following implementation: ??? static Set requireImmutable(Set set) { ??????? if (set instanceof ImmutableCollections.AbstractImmutableSet) { ??????????? return set; ??????? } else { ??????????? throw new IllegalStateException("Not an immutable Set"); ??????? } ??? } Currently the immutable implementation classes are package-private so there's no way for 3rd party code (short of introspecting the class hierarchy of the implementation class against the FQN of the AbstractImmutableSet class, which might be costly and fragile) to implement a helper method like this. Regards, Peter > Best regards, > > -- daniel From andrew_m_leonard at uk.ibm.com Wed Mar 27 11:26:50 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 27 Mar 2019 11:26:50 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle Message-ID: I like your change Ivan, i've just reviewed it all and it works nicely for me, it puts all the key logic in one place. Roger what do you think? 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 From: Ivan Gerasimov To: Roger Riggs , Andrew Leonard , Roger Riggs Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 23:32 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified The main source of confusion here seems to be due to that the coder is passed in as an argument, so it either needs to be trusted or has to be verified in the constructor. So, let's instead introduce AbstractStringBuilder(CharSequence) and make it do all manipulations. https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eigerasim_8221430_01_webrev_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=j-sj2TN_BPxc56godShkZiyhX_3m_a1rw1TERHfpIwQ&e= Note that the common case of StringBuilder(String) already gets intrinsified by hotspot. What do you think? With kind regards, Ivan On 3/26/19 1:04 PM, Ivan Gerasimov wrote: > From the design point of view, I believe it is better to have the > constructor AbstractStringBuilder(int, int, int) to check if the coder > argument makes sense with respect to the value of COMPACT_STRING, so > it won't be possible to create a StringBuilder with the coder==LATIN1, > when it is not supported. > > For calculating the coderHint then, it is not necessary to check > COMPACT_STRING: If the CharSequence argument is in fact String or > AbstractStringBuilder, the coder is known, otherwise LATIN1 can be > passed in as a hint (for an arbitrary CharSequence it is not 100% > accurate anyway). > The constructor AbstractStringBuilder(int, int, int) will then either > use the provided coder, or adjust it if necessary. > > Will we agree on something like following? > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eigerasim_8221430_00_webrev_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=ZbLXiATpnDRMbb66KK6lsr6rdglh7N7ld_x10JKKa9Q&e= > > With kind regards, > > Ivan > > > On 3/26/19 12:14 PM, Roger Riggs wrote: >> Hi, >> >> We've got the subject open and its fresh, there's no need for a >> separate review cycle. >> >> The first fix (-01) does not seem to be consistent with the original >> design >> and handling of the coder. The StringBuilder(String) and >> StringBuffer(String) >> constructors are the pattern that should be followed for determining >> the coder for the new instance. >> >> Checking for COMPACT_STRING in two places (the AbstractStringBuilder and >> the sub classes) is unnecessary and distributes the information about >> the >> correct coder across two classes where determining what it should be >> in the subclass has more complete information and can correctly >> determine >> the coder once. >> >> We can likely find a reviewer to be a tie-breaker if Ivan sees it as >> desirable. >> >> Thanks, Roger >> >> >> On 03/26/2019 02:38 PM, Andrew Leonard wrote: >>> Sorry chaps, I think my brain is getting confused!, I think we have >>> conflicting reviews here? >>> >>> Roger, I added the getCharSequenceCoder() to AbstractStringBuilder >>> so it was only defined in one place.. >>> I agree with this being called in StringBuffer/Builder then we don't >>> need the change to AbstractStringBuild() constuctor, however Ivan >>> wants getCharSequenceCoder() that done as a separate "bug". >>> >>> So I think it comes down to do we do this as 2 "bugs" or 1 ? >>> >>> 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 >>> >>> >>> >>> >>> From: Roger Riggs >>> To: Andrew Leonard , Ivan Gerasimov >>> >>> Cc: core-libs-dev at openjdk.java.net >>> Date: 26/03/2019 18:19 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Andrew, >>> >>> You are going to have to change the same code twice >>> because the changes should be the StringBuffer and StringBuilder >>> constructors and would remove the code that is added to >>> the AbstractStringBuilder constructor. That's a waste of review >>> cycles. >>> >>> >>> On 03/26/2019 11:45 AM, Andrew Leonard wrote: >>> Hi Roger, >>> No worries, the more the merrier! >>> So that was one of my reasoning for adding getCharSequenceCode() >>> was, I think what you're suggesting is my webrev.01, >>> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=543BQB-5xKgumIqQPLCVXdvIa08hLzYqPQ7VhkwjQ_s&e= >>> < https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Ealeonard_8221430_webrev.01_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=oTI4fqd43zB2CYOnKVTx_wYeT8cVmclfqN1QEp7X5Yk&e= > >>> Ivan's view is that behaviour was an extended issue, which it is, >>> but I thought it was nice to add.. >>> >>> Which patch do we favour? webrev-01 or -02 ? >>> >>> Neither, there should be no change to the AbstractStringBuilder >>> constructor >>> and the change should be done in the subclass constructors. >>> >>> Roger >>> >>> >>> 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_ >>> >>> >>> >>> >>> >>> From: Roger Riggs __ >>> >>> To: _core-libs-dev at openjdk.java.net_ >>> >>> Date: 26/03/2019 15:24 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> Sent by: "core-libs-dev" __ >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Andrew, >>> >>> Sorry to be late to the review. >>> >>> For symmetry with the constructors StringBuffer(String), and >>> StringBuilder(String) >>> the determine the coder based on the input argument, I would recommend >>> using the getCharSequenceCoder added in the -01 webrev and calling >>> it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) >>> constructors. >>> >>> It would be symmetric with the getCoder() method (line 1635) >>> and select the appropriate coder base on the input value (if known.) >>> >>> Thanks, Roger >>> >>> >>> >>> On 03/26/2019 10:57 AM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > Yes, i'm happy with that, as you say the simple constructor change >>> fixes >>> > the immediate issue, but not necessarily the extended issue of a >>> > non-compactable CharSequence in COMPACT_STRINGS mode, but that's >>> probably >>> > an enhanced issue to cover in a separate bug... >>> > I've created a new webrev.02 with just the constructor change and the >>> > testcase: >>> > _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.02_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=zGPiATDtwaA40szuIORFfC512W67j2th6sfyifhdoQk&e= >>> < https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Ealeonard_8221430_webrev.02_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=krrUTKfJ09bzO4h-26OgGStBCeeRnQSjuENIyHsvzgg&e= > >>> > >>> > 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_ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov __ >>> >>> > To: Andrew Leonard __ >>> >>> > Cc: _core-libs-dev at openjdk.java.net_ >>> >>> > Date: 26/03/2019 01:18 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > Thanks Andrew! >>> > Introducing getCharSequenceCoder() is actually an enhancement, >>> which may >>> > improve pre-allocation in certain cases. >>> > It's not actually required to restore correctness of >>> StringBuilder/Buffer >>> > constructors. >>> > I recommend to separate it from this bug fix, so it can be discussed >>> > separately, and determined if this is the best approach to this >>> > enhancement. >>> > If you agree, I can adjust your latest patch accordingly, run it >>> through >>> > the Mach5 test systems and push it on your behalf. >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 5:00 PM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > Here is my updated webrev: >>> > _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=543BQB-5xKgumIqQPLCVXdvIa08hLzYqPQ7VhkwjQ_s&e= >>> < https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Ealeonard_8221430_webrev.01_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=oTI4fqd43zB2CYOnKVTx_wYeT8cVmclfqN1QEp7X5Yk&e= > >>> > >>> > 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_ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov __ >>> >>> > To: Andrew Leonard __ >>> >>> > Cc: _core-libs-dev at openjdk.java.net_ >>> >>> > Date: 25/03/2019 22:55 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > I was thinking of organizing code similar to what is done in >>> > AbstractStringBuilder(int): >>> > >>> > if (COMPACT_STRINGS && coderHint == LATIN1) { >>> > value = new byte[capacity]; >>> > coder = LATIN1; >>> > } else { >>> > value = StringUTF16.newBytesFor(capacity); >>> > coder = UTF16; >>> > } >>> > >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 3:45 PM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > I think I see what you're saying, you mean we also need to correct >>> this >>> > line in AbstractStringBuilder >>> > constructor: >>> > value = (coder == LATIN1) >>> > ? new byte[capacity] : >>> StringUTF16.newBytesFor(capacity); >>> > to be maybe: >>> > value = (COMPACT_STRINGS && coder == LATIN1) >>> > ? new byte[capacity] : >>> StringUTF16.newBytesFor(capacity); >>> > >>> > The passed in coder stills need to be correct, since with >>> COMPACT_STRINGS >>> > a string could be UTF16 if >>> > it cannot be compacted, so it's more than just a hint isn't it? >>> > >>> > 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_ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov __ >>> >>> > To: Andrew Leonard __ >>> , >>> > _core-libs-dev at openjdk.java.net_ >>> >>> > Date: 25/03/2019 22:20 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > Hi Andrew! >>> > >>> > Thanks for finding this bug! >>> > >>> > Your fix solves the problem. >>> > >>> > However, I think the main issue is that the constructor >>> > AbstractStringBuilder(byte,int,int) is now broken: as you >>> discovered, >>> > it allows to create a string buffer with the coder LATIN1 when >>> > COMPACT_STRINGS is false. >>> > >>> > Wouldn't it make sense to rename the argument of the constructor to, >>> > say, coderHint, and then either use it as the coder if >>> > COMPACT_STRINGS==true, or discard it otherwise. >>> > >>> > What do you think? >>> > >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 12:45 PM, Andrew Leonard wrote: >>> >> Hi, >>> >> Please can I request a sponsor for this fix to a JDK-13 regression? >>> >> >>> >> Patch with jtreg testcase here: >>> >> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8221430_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=rFZRWjU8DdEqg3A4ggFmgRVswA8M823V2aFN8lx03ds&e= >>> < https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-257Ealeonard_8221430_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=_y1EXmJ9bt31898FZhwrtmEp563fGbcocLpO8VAkBnc&e= > >>> >> >>> >> bug: _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221430-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pE0lO6dslRWLLCEXQmHn9OPe4VOGzmjvtUfoAHAi1fQ&s=aZ8dTqDGIN2qhn1i-O5xHRfwFfhPJGRryiCHTLTRqjU&e= >>> >> >>> >> Many 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 >>> >>> >>> >>> 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 >> > -- With kind regards, Ivan Gerasimov 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 andy.herrick at oracle.com Wed Mar 27 11:32:54 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Mar 2019 07:32:54 -0400 Subject: RFR: JDK-8221525: jpackage fails with non-ASCII characters in --copyright In-Reply-To: References: Message-ID: <6fe6aad6-bf38-49d9-f22e-35f2961d7b4b@oracle.com> change looks good. /Andy On 3/26/2019 10:57 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - .properties file was written in default encoding > (file.encoding=Cp1252). Native code was expecting UTF-8 and thus was > not able to read non-ASCII characters correctly. Fixed by writing file > using UTF-8. > > [1] https://bugs.openjdk.java.net/browse/JDK-8221525 > > [2] http://cr.openjdk.java.net/~almatvee/8221525/webrev.00/ > > Thanks, > Alexander From Roger.Riggs at oracle.com Wed Mar 27 13:35:47 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 27 Mar 2019 09:35:47 -0400 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> Message-ID: Hi Ivan, On 03/26/2019 07:30 PM, Ivan Gerasimov wrote: > The main source of confusion here seems to be due to that the coder is > passed in as an argument, so it either needs to be trusted or has to > be verified in the constructor. The design for coder is that it *is* trusted in all internal/implementation APIs. Subsequent changes should not weaken this invariant, it will cause doubt in the code and cast doubt on all of the performance work that has been done to optimize its use. > > So, let's instead introduce AbstractStringBuilder(CharSequence) and > make it do all manipulations. > > http://cr.openjdk.java.net/~igerasim/8221430/01/webrev/ > > Note that the common case of StringBuilder(String) already gets > intrinsified by hotspot. > > What do you think? This looks good, the logic is in one place. Since StringBuilder(String) is an intrinsic, my doubt about a slight performance impact is unwarranted in that specific case. Are there any StringBuffer/Builder jmh tests than be easily rerun to compare? Thanks, Roger > > With kind regards, > Ivan > > On 3/26/19 1:04 PM, Ivan Gerasimov wrote: >> From the design point of view, I believe it is better to have the >> constructor AbstractStringBuilder(int, int, int) to check if the >> coder argument makes sense with respect to the value of >> COMPACT_STRING, so it won't be possible to create a StringBuilder >> with the coder==LATIN1, when it is not supported. >> >> For calculating the coderHint then, it is not necessary to check >> COMPACT_STRING:? If the CharSequence argument is in fact String or >> AbstractStringBuilder, the coder is known, otherwise LATIN1 can be >> passed in as a hint (for an arbitrary CharSequence it is not 100% >> accurate anyway). >> The constructor AbstractStringBuilder(int, int, int) will then either >> use the provided coder, or adjust it if necessary. >> >> Will we agree on something like following? >> >> http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/ >> >> With kind regards, >> >> Ivan >> >> >> On 3/26/19 12:14 PM, Roger Riggs wrote: >>> Hi, >>> >>> We've got the subject open and its fresh, there's no need for a >>> separate review cycle. >>> >>> The first fix (-01) does not seem to be consistent with the original >>> design >>> and handling of the coder.? The StringBuilder(String) and >>> StringBuffer(String) >>> constructors are the pattern that should be followed for determining >>> the coder for the new instance. >>> >>> Checking for COMPACT_STRING in two places (the AbstractStringBuilder >>> and >>> the sub classes) is unnecessary and distributes the information >>> about the >>> correct coder across two classes where determining what it should be >>> in the subclass has more complete? information and can correctly >>> determine >>> the coder once. >>> >>> We can likely find a reviewer to be a tie-breaker if Ivan sees it as >>> desirable. >>> >>> Thanks, Roger >>> >>> >>> On 03/26/2019 02:38 PM, Andrew Leonard wrote: >>>> Sorry chaps, I think my brain is getting confused!, I think we have >>>> conflicting reviews here? >>>> >>>> Roger, I added the getCharSequenceCoder() to AbstractStringBuilder >>>> so it was only defined in one place.. >>>> I agree with this being called in StringBuffer/Builder then we >>>> don't need the change to AbstractStringBuild() constuctor, however >>>> Ivan wants getCharSequenceCoder() that done as a separate "bug". >>>> >>>> So I think it comes down to do we do this as 2 "bugs" or 1 ? >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> From: Roger Riggs >>>> To: Andrew Leonard , Ivan Gerasimov >>>> >>>> Cc: core-libs-dev at openjdk.java.net >>>> Date: 26/03/2019 18:19 >>>> Subject: Re: Request for sponsor: JDK-8221430: >>>> StringBuffer(CharSequence) constructor truncates when >>>> -XX:-CompactStrings specified >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> Hi Andrew, >>>> >>>> You are going to have to change the same code twice >>>> because the changes should be the StringBuffer and StringBuilder >>>> constructors and would remove the code that is added to >>>> the AbstractStringBuilder constructor.? That's a waste of review >>>> cycles. >>>> >>>> >>>> On 03/26/2019 11:45 AM, Andrew Leonard wrote: >>>> Hi Roger, >>>> No worries, the more the merrier! >>>> So that was one of my reasoning for adding getCharSequenceCode() >>>> was, I think what you're suggesting is my webrev.01, >>>> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ >>>> >>>> Ivan's view is that behaviour was an extended issue, which it is, >>>> but I thought it was nice to add.. >>>> >>>> Which patch do we favour? webrev-01 or -02 ? >>>> >>>> Neither, there should be no change to the AbstractStringBuilder >>>> constructor >>>> and the change should be done in the subclass constructors. >>>> >>>> Roger >>>> >>>> >>>> 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_ >>>> >>>> >>>> >>>> >>>> >>>> From: Roger Riggs __ >>>> >>>> To: _core-libs-dev at openjdk.java.net_ >>>> >>>> Date: 26/03/2019 15:24 >>>> Subject: Re: Request for sponsor: JDK-8221430: >>>> StringBuffer(CharSequence) constructor truncates when >>>> -XX:-CompactStrings specified >>>> Sent by: "core-libs-dev" __ >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> Hi Andrew, >>>> >>>> Sorry to be late to the review. >>>> >>>> For symmetry with the constructors StringBuffer(String), and >>>> StringBuilder(String) >>>> the determine the coder based on the input argument, I would recommend >>>> using the getCharSequenceCoder added in the -01 webrev and calling >>>> it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) >>>> constructors. >>>> >>>> It would be symmetric with the getCoder() method (line 1635) >>>> and select the appropriate coder base on the input value (if known.) >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> On 03/26/2019 10:57 AM, Andrew Leonard wrote: >>>> > Hi Ivan, >>>> > Yes, i'm happy with that, as you say the simple constructor >>>> change fixes >>>> > the immediate issue, but not necessarily the extended issue of a >>>> > non-compactable CharSequence in COMPACT_STRINGS mode, but that's >>>> probably >>>> > an enhanced issue to cover in a separate bug... >>>> > I've created a new webrev.02 with just the constructor change and >>>> the >>>> > testcase: >>>> > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/_ >>>> >>>> > >>>> > 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_ >>>> >>>> > >>>> > >>>> > >>>> > >>>> > From:?? Ivan Gerasimov __ >>>> >>>> > To:???? Andrew Leonard __ >>>> >>>> > Cc: _core-libs-dev at openjdk.java.net_ >>>> >>>> > Date:?? 26/03/2019 01:18 >>>> > Subject:??????? Re: Request for sponsor: JDK-8221430: >>>> > StringBuffer(CharSequence) constructor truncates when >>>> -XX:-CompactStrings >>>> > specified >>>> > >>>> > >>>> > >>>> > Thanks Andrew! >>>> > Introducing getCharSequenceCoder() is actually an enhancement, >>>> which may >>>> > improve pre-allocation in certain cases. >>>> > It's not actually required to restore correctness of >>>> StringBuilder/Buffer >>>> > constructors. >>>> > I recommend to separate it from this bug fix, so it can be discussed >>>> > separately, and determined if this is the best approach to this >>>> > enhancement. >>>> > If you agree, I can adjust your latest patch accordingly, run it >>>> through >>>> > the Mach5 test systems and push it on your behalf. >>>> > With kind regards, >>>> > Ivan >>>> > >>>> > On 3/25/19 5:00 PM, Andrew Leonard wrote: >>>> > Hi Ivan, >>>> > Here is my updated webrev: >>>> > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ >>>> >>>> > >>>> > 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_ >>>> >>>> > >>>> > >>>> > >>>> > >>>> > From:??????? Ivan Gerasimov __ >>>> >>>> > To:??????? Andrew Leonard __ >>>> >>>> > Cc: _core-libs-dev at openjdk.java.net_ >>>> >>>> > Date:??????? 25/03/2019 22:55 >>>> > Subject:??????? Re: Request for sponsor: JDK-8221430: >>>> > StringBuffer(CharSequence) constructor truncates when >>>> -XX:-CompactStrings >>>> > specified >>>> > >>>> > >>>> > >>>> > I was thinking of organizing code similar to what is done in >>>> > AbstractStringBuilder(int): >>>> > >>>> > if (COMPACT_STRINGS && coderHint == LATIN1) { >>>> >????? value = new byte[capacity]; >>>> >????? coder = LATIN1; >>>> > } else { >>>> >????? value = StringUTF16.newBytesFor(capacity); >>>> >????? coder = UTF16; >>>> > } >>>> > >>>> > With kind regards, >>>> > Ivan >>>> > >>>> > On 3/25/19 3:45 PM, Andrew Leonard wrote: >>>> > Hi Ivan, >>>> > I think I see what you're saying, you mean we also need to >>>> correct this >>>> > line in AbstractStringBuilder >>>> > constructor: >>>> > value = (coder == LATIN1) >>>> >???????????????? ? new byte[capacity] : >>>> StringUTF16.newBytesFor(capacity); >>>> > to be maybe: >>>> > value = (COMPACT_STRINGS && coder == LATIN1) >>>> >???????????????? ? new byte[capacity] : >>>> StringUTF16.newBytesFor(capacity); >>>> > >>>> > The passed in coder stills need to be correct, since with >>>> COMPACT_STRINGS >>>> > a string could be UTF16 if >>>> > it cannot be compacted, so it's more than just a hint isn't it? >>>> > >>>> > 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_ >>>> >>>> > >>>> > >>>> > >>>> > >>>> > From:??????? Ivan Gerasimov __ >>>> >>>> > To:??????? Andrew Leonard __ >>>> , >>>> > _core-libs-dev at openjdk.java.net_ >>>> >>>> > Date:??????? 25/03/2019 22:20 >>>> > Subject:??????? Re: Request for sponsor: JDK-8221430: >>>> > StringBuffer(CharSequence) constructor truncates when >>>> -XX:-CompactStrings >>>> > specified >>>> > >>>> > >>>> > >>>> > Hi Andrew! >>>> > >>>> > Thanks for finding this bug! >>>> > >>>> > Your fix solves the problem. >>>> > >>>> > However, I think the main issue is that the constructor >>>> > AbstractStringBuilder(byte,int,int) is now broken:? as you >>>> discovered, >>>> > it allows to create a string buffer with the coder LATIN1 when >>>> > COMPACT_STRINGS is false. >>>> > >>>> > Wouldn't it make sense to rename the argument of the constructor to, >>>> > say, coderHint, and then either use it as the coder if >>>> > COMPACT_STRINGS==true, or discard it otherwise. >>>> > >>>> > What do you think? >>>> > >>>> > With kind regards, >>>> > Ivan >>>> > >>>> > On 3/25/19 12:45 PM, Andrew Leonard wrote: >>>> >> Hi, >>>> >> Please can I request a sponsor for this fix to a JDK-13 regression? >>>> >> >>>> >> Patch with jtreg testcase here: >>>> >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ >>>> >>>> >> >>>> >> bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ >>>> >> >>>> >> Many 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 >>>> >>>> >>>> >>>> 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 Wed Mar 27 14:18:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Mar 2019 14:18:15 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> Message-ID: Hi Mandy, > and also the cases when it requires to look at its caller frame. > > Never. Only the method that was executed when the exception is > thrown is needed. I only mention the backtrace because it happens to > store the top method and the corresponding bytecode position in the > top method. > > > That explains why I don't see an example of: > getNull().m(); > > public void m() {}; > > static NPE getNull() { > return null; > } > > For a compiler expert or one who study the data flow analysis paper Yes, I think compiler people should understand this. > , is this example very clear to them that it won't be supported? The example for your code is supported, see[1], examples 11-14. (I should enumerate them) For your code, it will print "The return value of 'MyClass.getNULL()LNPE;' is null. Can not invoke method 'MyOtherClass.m()V'". getNull().m() are not nested calls, but subsequent ones. Therefore you will not find them on the call stack. The byte code index of the invoke bytecode invoking m() is known from the backtrace or StackWalker/StackFrame. Looking at the bytecode the part "Can not invoke method 'MyOtherClass.m()V" is printed. With the result of the data flow analysis it is possible to find the bytecode that produced the reference on which m() is invoked. This is another invoke bytecode in the method. Looking at this other bytecode, " The return value of 'MyClass.getNULL()LNPE;' is null." is printed. You probably meant that for n().getNull().m() it is not printed that getNull() was called on the result of n()? This is a design decision not to make the printout too complex. > This is related to my comment w.r.t. the data flow analysis comes from. I was > looking for some level of information be spelled out in the JEP that can > sufficiently give a non-compiler expert an idea but of course no point to > replicate the paper here. "The simulated stack" ... contains ..."information about which bytecode pushed the value to the stack." That's all. > It's good to know that this proposal needs the top frame only. Please make it > clear in the JEP. I tried to point out more precisely why and when I need the top frame. I pushed this down a bit in the text in "basic algorithm". > The JEP can take out `StackWalker` but instead talks about > `StackFrame` since doing it in Java means that it only needs to get back a `StackFrame` > instance representing the top frame stored in `Throwable::backtrace` Yes. I tried to make the text more precise. > This will avoid the confusion on calling StackWalker in the NPE constructor and > constructing many StackFrame and many ResolvedMethodName. That was > part of the code review discussion. Yes, only the top StackFrame is needed. > "Computing either part of these messages can fail due to > insufficient > information." > What are the cases that it fails to obtain the information? It'd > be useful > to list some examples if not all. > > (a ? b : c).d > You can not know whether the ?-expression yielded b or c, thus > you don't know why the access .d failed. There is a corresponding > example > in [1]. > > > Please describe in the JEP the known cases that this proposal doesn't cover. > Conditional expression is one and The algorithm looks at a lot of bytecodes to print the method. I can not enumerate all combinations of bytecodes, it's millions. I will add a per-bytecode table to the "Message content" section describing what is printed for which bytecode. >null receiver if it's the return value from a caller frame (I think this would help the readers). ... this is supported, see above. > The "Different bytecode variants of a method" section > > This section raises the case when a method representing an > execution stack > frame throwing NPE becomes obsolete, it does not have the > information > to compute the message lazily. So this falls into the > "insufficient > information" category and no improved NPE message can be > generated. > > Yes, note this also only addresses the method in which the exception > was raised. > > This should also go to the list of known cases that this proposal does not cover. This paragraph lists a possible problem -- multiple variants of methods with the same name and class name -- and how this is solved. I added a section "Cases not covered by this JEP" and mention it there, too. > Since the JEP quotes that NullPointerExceptions are thrown frequently > and swallowed, it would help if you can generate some numbers. > This JEP will help the discussion on the proposed feature and design and avoid > any > confusion/assumption of the implementation. I'll generate some numbers. Is running jvm2008 fine? > I think this is related to this JEP. The question would be: > - should it include all hidden frames? > - should it include the top frame if it's a hidden frame since this feature only > requires the top frame? > > This JEP requires the hidden frame to be recorded in the backtrace. This has > impact to the printing of stack trace that needs to know about hidden frames > and decide if it should be filtered or included when printing. No. I propose to remember that the frame was hidden. I do not propose to remember the hidden frame. I now mention in the JEP that the message is not printed for hidden frames in the new "cases not covered" section. > I made a webrev of its own for this problem, so that the code > can be looked at isolated of other, orthogonal issues. > http://cr.openjdk.java.net/~goetz/wr19/8221077-hidden_to_frame/ > I don't need the webrev as we are discussing the proposed feature and design. Well, sometimes code is more precise than language ... > The "Message persistance" section > > I read this section like an implementation details > > Yes, I had the feeling that I was talking too much about > implementation details, > but mostly in the "Basic algorithm" section. > This section discusses characteristics of NPE that differ from other > exceptions > and that were proposed in the course of the review of my > original webrev. They are visible to the Java implementor. > So I think this is just the basic information needed in a JEP. > > > This is a good start that allows us to start the discussion. This JEP will probably > need several iterations of improvement. I'm writing a JEP that I have iterated > many times already and it makes the JEP and proposed feature better. Just to > share with you that it's part of the process. > > > > > I think this section > intends to call out that the message of NPE if constructed by > user code > i.e. via public constructor, should not be altered including no- > arg > constructor or pass a null message to 1-arg constructor. The > enhanced > NPE message is proposed only when NPE is thrown due to null > dereference > when executing bytecode. > > Yes. > > > I don't understand what you tried to say about > "npe.getMessage() == > npe.getMessage()". > Throwable::getMessage does not guarantee to return same > String object for > each invocation. > > It does not guarantee so, but it's the case for most exceptions. Usually, > one calls super(msg) in an Exception constructor. > It is a design decision to implement it that way, my original proposal > was different. I'm fine with this design, but it should be mentioned I > think. > > > I think the JEP should be made clearer what you intend to say. > > When deserializing the class bytes may be of a different > version, so > StackTraceElements > are serialized with its string form. Serializing NPE with a > computed message > seems to be the only viable solution. > > I think implementing writeReplace() is a good idea, too. But > Roger does not like it: http://mail.openjdk.java.net/pipermail/core- > libs-dev/2019-February/058513.html > > > > The JEP should record this either if this is an open issue or makes it a clear > proposal to compute the message when NPE is serialized and what the client > would do (that may be running in a different version) Ah, OK, I understand. Here, I should simply state that persistence is not intended. In the Alternatives section, I can then point out how to implement persistence? I changed the text accordingly. > IAE quotes the names, which are user defined strings. It does not quote > class names, method names etc. > Here, I was asked to quote these, which is inconsistent with IAE. But > there are other > examples where method names are quoted ... So there is no clear line > followed > yet. In the end, I don't care, but want advice how to do it. (I would not > quote ...). > > You can add it to the open issues section. I'll just state they are quoted. This was the opinion of basically everybody who commented on this. The text currently more reads like I want to reflect the past discussions in the JEP, better be clear here... > "Alternatives" section > > "The current proposal is to implement this in the Java runtime > in C++ accessing > directly the available datastructures in the metaspace." > > "Also, ASM and StackWalker do not support the full > functionality needed. > StackWalker must be called in the NullPointerException > constructor." > > > > This is not true as you wrote in the subsequent sentence. If we > choose > the implementation to Java, StackWalker will need to be > extended to > read Throwable's backtrace. > > The senctence above describes the status quo. The current > implementation > of StackWalker must be called in the constructor. > > > I just called out the confusion this section could cause. I think it should be > updated or rephase. I tried to rephrase it. > Please refer to the JEP template (http://openjdk.java.net/jeps/2) about the > Testing section. > > // What kinds of test development and execution will be required in order > // to validate this enhancement, beyond the usual mandatory unit tests? > // Be sure to list any special platform or hardware requirements. I tried to improve it. > To be clear: > > What I was suggesting is to describe the scenarios this proposed feature will > improve the message > but *not* to cut-n-paste the messages from [1]. So this is not tied to what the > message will be > printed from the implementation. > > Writing the scenario in English can help discussing the NPE messages should be > implemented > that will be easy for Joe developer to understand. NPEs are a very basic thing in Java. They can happen in any Java code running in any application, toy program ... etc. I think the message should help in all cases. It's more to the person implementing the call to getMessage() that knows the scenario. I really don't know what to write here. Thanks a lot for your detailed comments, I think it already improved the text considerably! I'll run the experiment to count the NPEs and write the "message content" section about what is printed and what not. Best regards, Goetz. > > Mandy > > > > But I would > like to do that once it is agreed on the messages, so I don't need to > edit the JEP all the time. > The file referenced is simply generated by the test, so it's easy to > update > and sure to reflect the implementation. > > > This JEP includes a few links to the C++ functions in the current > webrev. I > appreciate that and I assume they will be taken out at some > point. > > Yes, sure, I can remove that. > > Best regards, > Goetz. > > From martinrb at google.com Wed Mar 27 16:26:25 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Mar 2019 09:26:25 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle.com> <6dda46bb-e925-5910-7b11-59c7cae1fef8@oracle.com> Message-ID: Anyone who does String coder hacking should meditate on the wisdom at: https://shipilev.net/#string-catechism From mark.reinhold at oracle.com Wed Mar 27 16:45:25 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 27 Mar 2019 09:45:25 -0700 Subject: Formatting rules for exception messages In-Reply-To: <87o95zm9a2.fsf@mid.deneb.enyo.de> References: <87o95zm9a2.fsf@mid.deneb.enyo.de> Message-ID: <20190327094525.87527075@eggemoggin.niobe.net> 2019/3/25 5:24:37 -0700, Florian Weimer : > Are there any guidelines for formatting exception messages? > > In particular, I'm interested in the case when the exception message > is a (clipped) sentence. Is it supposed to start with a capital > letter? > > If the message refers to a parameter name, the spelling should reflect > the name exactly, of course. There seems to be a slight bias towards > capitalization, based on a few greps. ... The first word of any exception message in code that I?ve written, or reviewed, is always capitalized unless that word conveys case-sensitive technical information (e.g., a parameter name, as you mentioned). This improves readability, especially in longer exception messages that contain additional punctuation characters. - Mark From matthias.baesken at sap.com Wed Mar 27 17:05:05 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 27 Mar 2019 17:05:05 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hello could you please look into it ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 25. M?rz 2019 18:05 > To: Langer, Christoph > Cc: 'core-libs-dev at openjdk.java.net' ; > 'Alan Bateman' > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hello here is an updated webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > > > > > In JLI_Open(const char* name, int flags), you should remove ret and only > > > use fd, I think. > > > I removed ret and adjusted some comments. > > Additionally I added a test that uses (on Windows) JLI_Open on a jar file > with a "long" path (> 260 chars). > [ JLI_Open is currently called from parse_manifest.c with jarfile as > parameter ] > From martijnverburg at gmail.com Wed Mar 27 19:18:05 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 27 Mar 2019 19:18:05 +0000 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: Hi Thomas, Will do and appreciate the support! Cheers, Martijn On Wed, 27 Mar 2019 at 11:13, Thomas St?fe wrote: > > > On Wed, Mar 27, 2019 at 11:08 AM Martijn Verburg > wrote: > >> Hi Thomas, >> >> Release only (we've only created debug builds for x64), >> > > Okay. A number of those errors were debug only. > > >> we do use the treat errors as warnings flag. >> > > Other way around, I hope ;) > > >> >> You can look at all of our build configurations and build histories at >> ci.adoptopenjdk.net - and I've copied in Ali Ince who's working for >> jClarity on Windows 32/64 builds amongst other things. >> >> Okay, that's useful. > > JDK changes have been pushed (JDK-8221405 > , JDK-8221406 > , JDK-8221407 > , first one in > jdk/client since awt maintainers asked me to). Hotspot changes still under > review, we ponder the best way to deal with a supposed vc++ bug here ( > JDK-8221408 ). Feel > free to test or review. > > Note that I do not plan to keep windows 32 bit alive, this was just a > weekend thing because I needed a 32bit VM on windows for some comparisons. > So I'd be happy that you guys are regularly building it (if possible > fastdebug too). Please report any build breaks. When reported promptly, > with the offending change linked in JBS, the authors will often try to fix > it themselves. > > Cheers, Thomas > > >> Cheers, >> Martijn >> >> >> On Tue, 26 Mar 2019 at 06:04, Thomas St?fe >> wrote: >> >>> >>> >>> On Mon, Mar 25, 2019 at 10:49 PM Martijn Verburg < >>> martijnverburg at gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> Snipping much, but commenting on one statement inline below. >>>> >>>> On Mon, 25 Mar 2019 at 01:58, David Holmes >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> A few queries, comments and concerns ... >>>>> >>>>> On 25/03/2019 6:58 am, Thomas St?fe wrote: >>>>> > Hi all, >>>>> > >>>>> > After a long time I tried to build a Windows 32bit VM (VS2017) and >>>>> failed; >>>>> >>>>> I'm somewhat surprised as I thought someone was actively doing Windows >>>>> 32-bit builds out there, plus there are shared code changes that >>>>> should >>>>> also have been caught by non-Windows 32-bit builds. :( >>>>> >>>> >>>> AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 >>>> to do so and have hit the same issues (Thomas beat us to reporting!). >>>> >>>> >>> Still curious what you actually build, since I believe not all of the >>> issues are related to vs2017. >>> >>> Do you build release only or also debug? Do you build with >>> warnings-as-errors disabled? >>> >>> >>>> Hopefully, we'll have that nightly warning system in place for you >>>> going forward soon. >>>> >>>> >>> That would be helpful. >>> >>> Cheers, Thomas >>> >>> >>>> Cheers, >>>> Martijn >>>> >>> From andy.herrick at oracle.com Wed Mar 27 19:33:09 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Mar 2019 15:33:09 -0400 Subject: RFR: JDK-8221565: Linux build broken after merge with default branch Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] - https://bugs.openjdk.java.net/browse/JDK-8221565 [2] - http://cr.openjdk.java.net/~herrick/8221565 /Andy From huizhe.wang at oracle.com Wed Mar 27 19:51:07 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 27 Mar 2019 12:51:07 -0700 Subject: RFR (JDK 13) 8221533: Incorrect copyright header in DurationDayTimeImpl.java, DurationYearMonthImpl.java and XMLStreamException.java Message-ID: <5C9BD42B.9080608@oracle.com> Please review a trivial fix for the missing commas in three class files. hg diff diff --git a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java --- a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java +++ b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2017, 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 diff --git a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java --- a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java +++ b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 2017, 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 diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java b/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java --- a/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java +++ b/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2017, 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 Thanks, Joe From brian.burkhalter at oracle.com Wed Mar 27 19:56:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Mar 2019 12:56:30 -0700 Subject: RFR (JDK 13) 8221533: Incorrect copyright header in DurationDayTimeImpl.java, DurationYearMonthImpl.java and XMLStreamException.java In-Reply-To: <5C9BD42B.9080608@oracle.com> References: <5C9BD42B.9080608@oracle.com> Message-ID: <3FABC440-01A8-49D4-B9DF-E2DDD458560D@oracle.com> +1 , > On Mar 27, 2019, at 12:51 PM, Joe Wang wrote: > > Please review a trivial fix for the missing commas in three class files. From lance.andersen at oracle.com Wed Mar 27 20:37:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 Mar 2019 16:37:38 -0400 Subject: RFR (JDK 13) 8221533: Incorrect copyright header in DurationDayTimeImpl.java, DurationYearMonthImpl.java and XMLStreamException.java In-Reply-To: <5C9BD42B.9080608@oracle.com> References: <5C9BD42B.9080608@oracle.com> Message-ID: +1 > On Mar 27, 2019, at 3:51 PM, Joe Wang wrote: > > Please review a trivial fix for the missing commas in three class files. > > hg diff > diff --git a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java > --- a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java > +++ b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2017, 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 > diff --git a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java > --- a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java > +++ b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2010, 2017, 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 > diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java b/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java > --- a/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java > +++ b/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2017, 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 > > Thanks, > Joe > 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 semyon.sadetsky at oracle.com Wed Mar 27 20:43:50 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Wed, 27 Mar 2019 13:43:50 -0700 Subject: RFR: JDK-8215241: Permissions are not set correctly on sub-folders in /Applications Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8215241 webrev: http://cr.openjdk.java.net/~ssadetsky/8215241/webrev.00/ The fix adds preinstall/postinstall scripts to the created package which ensure that installation dir is created and got proper permissions to guarantee the application is available to run after installing it. --Semyon From lance.andersen at oracle.com Wed Mar 27 20:55:28 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 Mar 2019 16:55:28 -0400 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out Message-ID: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> Hi all , Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8216539 which increases the timeout value for this test which fails once in a blue moon on windows. ??????? $ hg diff diff -r dc66ada06693 test/jdk/tools/jar/modularJar/Basic.java --- a/test/jdk/tools/jar/modularJar/Basic.java Tue Mar 26 15:36:19 2019 -0700 +++ b/test/jdk/tools/jar/modularJar/Basic.java Wed Mar 27 16:50:53 2019 -0400 @@ -54,7 +54,7 @@ * jdk.test.lib.util.FileUtils * jdk.test.lib.JDKToolFinder * @compile Basic.java - * @run testng Basic + * @run testng/timeout=300 Basic * @summary Tests for plain Modular jars & Multi-Release Modular jars */ ?????????? Best Lance 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 brian.burkhalter at oracle.com Wed Mar 27 21:01:14 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Mar 2019 14:01:14 -0700 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> Message-ID: <1367A035-2B79-401F-8660-BF5C2E04EBB5@oracle.com> Seems reasonable. [1] Brian > On Mar 27, 2019, at 1:55 PM, Lance Andersen wrote: > > Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8216539 which increases the timeout value for this test which fails once in a blue moon on windows. [1] https://www.timeanddate.com/astronomy/moon/blue-moon.html From brian.burkhalter at oracle.com Wed Mar 27 21:17:00 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Mar 2019 14:17:00 -0700 Subject: 8221568: DataOutputStream/WriteUTF.java fails due to "OutOfMemoryError: Java heap space" Message-ID: <3611BFCE-BF8A-405D-A8A6-AB75FC25B141@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8221568 Require 64-bit arch and increase heap size to 3 GB [0]. Without this patch, the test failed on macosx-x64 and solaris-sparcv9. With the patch, it passed on those systems as well as linux-x64 and windows-x64. Thanks, Brian [0] Patch --- a/test/jdk/java/io/DataOutputStream/WriteUTF.java +++ b/test/jdk/java/io/DataOutputStream/WriteUTF.java @@ -24,7 +24,8 @@ /* @test * @bug 4260284 8219196 * @summary Test if DataOutputStream will overcount written field. - * @run testng/othervm -Xmx2g WriteUTF + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 3g) + * @run testng/othervm -Xmx3g WriteUTF */ import java.io.ByteArrayOutputStream; @@ -59,7 +60,7 @@ } // Without 8219196 fix, throws ArrayIndexOutOfBoundsException instead of - // expected UTFDataFormatException. Requires 2GB of heap (-Xmx2g) to run + // expected UTFDataFormatException. Requires 3GB of heap (-Xmx3g) to run // without throwing an OutOfMemoryError. @Test(expectedExceptions = UTFDataFormatException.class) public void arrayIndexOutOfBoundsException() throws IOException { From shade at redhat.com Wed Mar 27 21:30:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Mar 2019 22:30:13 +0100 Subject: 8221568: DataOutputStream/WriteUTF.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: <3611BFCE-BF8A-405D-A8A6-AB75FC25B141@oracle.com> References: <3611BFCE-BF8A-405D-A8A6-AB75FC25B141@oracle.com> Message-ID: On 3/27/19 10:17 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8221568 > > Require 64-bit arch and increase heap size to 3 GB [0]. Without this patch, the test failed on macosx-x64 and solaris-sparcv9. With the patch, it passed on those systems as well as linux-x64 and windows-x64. > > Thanks, > > Brian > > [0] Patch > > --- a/test/jdk/java/io/DataOutputStream/WriteUTF.java > +++ b/test/jdk/java/io/DataOutputStream/WriteUTF.java > @@ -24,7 +24,8 @@ > /* @test > * @bug 4260284 8219196 > * @summary Test if DataOutputStream will overcount written field. > - * @run testng/othervm -Xmx2g WriteUTF > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 3g) > + * @run testng/othervm -Xmx3g WriteUTF > */ > > import java.io.ByteArrayOutputStream; > @@ -59,7 +60,7 @@ > } > > // Without 8219196 fix, throws ArrayIndexOutOfBoundsException instead of > - // expected UTFDataFormatException. Requires 2GB of heap (-Xmx2g) to run > + // expected UTFDataFormatException. Requires 3GB of heap (-Xmx3g) to run > // without throwing an OutOfMemoryError. > @Test(expectedExceptions = UTFDataFormatException.class) > public void arrayIndexOutOfBoundsException() throws IOException { Looks good. Thanks for caring about 32-bit. -Aleksey From huizhe.wang at oracle.com Wed Mar 27 21:42:03 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 27 Mar 2019 14:42:03 -0700 Subject: RFR (JDK 13) 8221533: Incorrect copyright header in DurationDayTimeImpl.java, DurationYearMonthImpl.java and XMLStreamException.java In-Reply-To: References: <5C9BD42B.9080608@oracle.com> Message-ID: <5C9BEE2B.6090805@oracle.com> Thanks Lance, Brian! -Joe On 3/27/19, 1:37 PM, Lance Andersen wrote: > +1 >> On Mar 27, 2019, at 3:51 PM, Joe Wang > > wrote: >> >> Please review a trivial fix for the missing commas in three class files. >> >> hg diff >> diff --git >> a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java >> b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java >> --- >> a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java >> +++ >> b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2009, 2017, 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 >> diff --git >> a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java >> b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java >> --- >> a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java >> +++ >> b/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2010, 2017 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2010, 2017, 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 >> diff --git >> a/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java >> b/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java >> --- a/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java >> +++ b/src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2009, 2017, 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 >> >> Thanks, >> Joe >> > > > > 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 alexander.matveev at oracle.com Wed Mar 27 21:50:17 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 27 Mar 2019 14:50:17 -0700 Subject: RFR: JDK-8221565: Linux build broken after merge with default branch In-Reply-To: References: Message-ID: <1f16b34a-44e5-3a0d-4734-231f42f664e3@oracle.com> Hi Andy, Changes looks fine, but do we really need such try/catch block? I think this code needs to be modify, so we do not need such try/catch or handle this error as real error. Probably another bug can be filed to do this. Thanks, Alexander On 3/27/2019 12:33 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] - https://bugs.openjdk.java.net/browse/JDK-8221565 > > [2] - http://cr.openjdk.java.net/~herrick/8221565 > > /Andy From alexander.matveev at oracle.com Wed Mar 27 22:21:30 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 27 Mar 2019 15:21:30 -0700 Subject: RFR: JDK-8215241: Permissions are not set correctly on sub-folders in /Applications In-Reply-To: References: Message-ID: <2bd5e7f8-e06d-01ab-cac1-06b7c2c47844@oracle.com> Hi Semyon, Looks good. Thanks, Alexander On 3/27/2019 1:43 PM, semyon.sadetsky at oracle.com wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8215241 > webrev: http://cr.openjdk.java.net/~ssadetsky/8215241/webrev.00/ > > > The fix adds preinstall/postinstall scripts to the created package > which ensure that installation dir is created and got proper permissions > to guarantee the application is available to run after installing it. > > --Semyon From mandy.chung at oracle.com Wed Mar 27 23:17:04 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 Mar 2019 16:17:04 -0700 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack Message-ID: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> This is to fix a regression introduced in JDK 12 by JDK-8206240. This impacts only native application that creates JVM via JNI and also invokes Field::getField (or other reflection API) via JNI that triggers reflection access check against the caller class. The regression happens only when there is no caller frame, i.e. when a native thread attaches to JVM e.g. custom launcher. It's unclear why the native code invokes Field::getField via JNI to get the value of `java.lang.Integer::TYPE`.? Alternatively it could call GetFieldID to get jfieldID of that field and then GetObjectField if this has to be done in JNI (perhaps bypass encapsulation?). There is no clear semantics what reflection should behave when there is no caller frame.?? Previously, JNI call to access `java.lang.Integer.TYPE` field happens to work since it is called very early at runtime and AccessibleObject::cache is null and happens that cache == caller == null. The proposed fix is to perform proper access check.? When there is no caller frame, it only allows to access to public members of a public type in an unconditional exported API package. If a native thread attaches to the VM and attempts to access a non-public member or a public member in a non-exported type e.g. jdk.internal.misc.Unsafe, it will throw IAE whereas the access check succeeds in JDK 11. It is illegal to access a non-exported type.?? I think the compatibility risk should be low as this only happens to a native code creating its VM and calling reflection to access a member in a non-exported type. There is no change to the behavior of JNI GetFieldID and GetObjectField. Webrev: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.00/ I will create a CSR. Thanks Mandy From andy.herrick at oracle.com Wed Mar 27 23:22:06 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Mar 2019 19:22:06 -0400 Subject: RFR: JDK-8215241: Permissions are not set correctly on sub-folders in /Applications In-Reply-To: References: Message-ID: <7e4e3635-889d-e6e6-0067-cf0a0c1add6f@oracle.com> fix looks good /Andy On 3/27/2019 4:43 PM, semyon.sadetsky at oracle.com wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8215241 > webrev: http://cr.openjdk.java.net/~ssadetsky/8215241/webrev.00/ > > > The fix adds preinstall/postinstall scripts to the created package > which ensure that installation dir is created and got proper permissions > to guarantee the application is available to run after installing it. > > --Semyon From mandy.chung at oracle.com Wed Mar 27 23:23:36 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 Mar 2019 16:23:36 -0700 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> Message-ID: <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> Hi Lance, Do you understand what takes so long for this test to run? Is it running fastdebug and -Xcomp or other flag? Mandy On 3/27/19 1:55 PM, Lance Andersen wrote: > Hi all , > > Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8216539 which increases the timeout value for this test which fails once in a blue moon on windows. > > > ??????? > $ hg diff > diff -r dc66ada06693 test/jdk/tools/jar/modularJar/Basic.java > --- a/test/jdk/tools/jar/modularJar/Basic.java Tue Mar 26 15:36:19 2019 -0700 > +++ b/test/jdk/tools/jar/modularJar/Basic.java Wed Mar 27 16:50:53 2019 -0400 > @@ -54,7 +54,7 @@ > * jdk.test.lib.util.FileUtils > * jdk.test.lib.JDKToolFinder > * @compile Basic.java > - * @run testng Basic > + * @run testng/timeout=300 Basic > * @summary Tests for plain Modular jars & Multi-Release Modular jars > */ > > > ?????????? > > Best > Lance > > > 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 joe.darcy at oracle.com Wed Mar 27 23:55:33 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 Mar 2019 16:55:33 -0700 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> Message-ID: Hello, I agree it would be preferable to understand why the test times out rather than just upping its timeout value. Thanks, -Joe On 3/27/2019 4:23 PM, Mandy Chung wrote: > Hi Lance, > > Do you understand what takes so long for this test to run? > Is it running fastdebug and -Xcomp or other flag? > > Mandy > > On 3/27/19 1:55 PM, Lance Andersen wrote: >> Hi all , >> >> Please review this fix for >> https://bugs.openjdk.java.net/browse/JDK-8216539 which increases the >> timeout value for this test which fails once in a blue moon on windows. >> >> >> ??????? >> $ hg diff >> diff -r dc66ada06693 test/jdk/tools/jar/modularJar/Basic.java >> --- a/test/jdk/tools/jar/modularJar/Basic.java??? Tue Mar 26 15:36:19 >> 2019 -0700 >> +++ b/test/jdk/tools/jar/modularJar/Basic.java??? Wed Mar 27 16:50:53 >> 2019 -0400 >> @@ -54,7 +54,7 @@ >> ?? *??????? jdk.test.lib.util.FileUtils >> ?? *??????? jdk.test.lib.JDKToolFinder >> ?? * @compile Basic.java >> - * @run testng Basic >> + * @run testng/timeout=300 Basic >> ?? * @summary Tests for plain Modular jars & Multi-Release Modular jars >> ?? */ >> >> ?????????? >> >> Best >> Lance >> >> >> >> 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 lance.andersen at oracle.com Wed Mar 27 23:56:42 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 Mar 2019 19:56:42 -0400 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> Message-ID: <2084129B-A859-44C6-BBC4-7C8DD9EB7C81@oracle.com> Hi Mandy, > On Mar 27, 2019, at 7:23 PM, Mandy Chung wrote: > > Hi Lance, > > Do you understand what takes so long for this test to run? Well it is executing a lot of jar commands. I did not see anything that sticks out in the failed logs that point to anything obvious. > Is it running fastdebug and -Xcomp or other flag? It is just a standard windows run. > > Mandy > > On 3/27/19 1:55 PM, Lance Andersen wrote: >> Hi all , >> >> Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8216539 which increases the timeout value for this test which fails once in a blue moon on windows. >> >> >> ??????? >> $ hg diff >> diff -r dc66ada06693 test/jdk/tools/jar/modularJar/Basic.java >> --- a/test/jdk/tools/jar/modularJar/Basic.java Tue Mar 26 15:36:19 2019 -0700 >> +++ b/test/jdk/tools/jar/modularJar/Basic.java Wed Mar 27 16:50:53 2019 -0400 >> @@ -54,7 +54,7 @@ >> * jdk.test.lib.util.FileUtils >> * jdk.test.lib.JDKToolFinder >> * @compile Basic.java >> - * @run testng Basic >> + * @run testng/timeout=300 Basic >> * @summary Tests for plain Modular jars & Multi-Release Modular jars >> */ >> >> >> ?????????? >> >> Best >> Lance >> >> >> 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 >> >> >> > 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 sundararajan.athijegannathan at oracle.com Thu Mar 28 00:22:02 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 28 Mar 2019 05:52:02 +0530 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> Message-ID: <5C9C13AA.8010200@oracle.com> Looks good. -Sundar On 28/03/19, 4:47 AM, Mandy Chung wrote: > This is to fix a regression introduced in JDK 12 by JDK-8206240. > This impacts only native application that creates JVM via JNI > and also invokes Field::getField (or other reflection API) via > JNI that triggers reflection access check against the caller class. > The regression happens only when there is no caller frame, i.e. > when a native thread attaches to JVM e.g. custom launcher. > > It's unclear why the native code invokes Field::getField via JNI > to get the value of `java.lang.Integer::TYPE`. Alternatively it could > call GetFieldID to get jfieldID of that field and then GetObjectField > if this has to be done in JNI (perhaps bypass encapsulation?). > > There is no clear semantics what reflection should behave when there > is no caller frame. Previously, JNI call to access > `java.lang.Integer.TYPE` > field happens to work since it is called very early at runtime and > AccessibleObject::cache is null and happens that cache == caller == null. > > The proposed fix is to perform proper access check. When there is no > caller frame, it only allows to access to public members of a public type > in an unconditional exported API package. > > If a native thread attaches to the VM and attempts to access a non-public > member or a public member in a non-exported type e.g. > jdk.internal.misc.Unsafe, > it will throw IAE whereas the access check succeeds in JDK 11. It is > illegal to access a non-exported type. I think the compatibility risk > should be low as this only happens to a native code creating its VM and > calling reflection to access a member in a non-exported type. There is > no change to the behavior of JNI GetFieldID and GetObjectField. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.00/ > > I will create a CSR. > > Thanks > Mandy From mandy.chung at oracle.com Thu Mar 28 00:23:48 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 Mar 2019 17:23:48 -0700 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <2084129B-A859-44C6-BBC4-7C8DD9EB7C81@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> <2084129B-A859-44C6-BBC4-7C8DD9EB7C81@oracle.com> Message-ID: <832172a3-28e7-40ee-79d4-aa63be7b94ae@oracle.com> On 3/27/19 4:56 PM, Lance Andersen wrote: > Hi Mandy, > > >> On Mar 27, 2019, at 7:23 PM, Mandy Chung > > wrote: >> >> Hi Lance, >> >> Do you understand what takes so long for this test to run? > > Well it is executing a lot of jar commands. ?I did not see anything > that sticks out in the failed logs that point to anything obvious. One thing you could do is to instrument the test to gather the timing statistics. >> Is it running fastdebug and -Xcomp or other flag? > > It is just a standard windows run. This is even strange if it's running normal product build. Mandy >> >> Mandy >> >> On 3/27/19 1:55 PM, Lance Andersen wrote: >>> Hi all , >>> >>> Please review this fix forhttps://bugs.openjdk.java.net/browse/JDK-8216539 which increases the timeout value for this test which fails once in a blue moon on windows. >>> >>> >>> ??????? >>> $ hg diff >>> diff -r dc66ada06693 test/jdk/tools/jar/modularJar/Basic.java >>> --- a/test/jdk/tools/jar/modularJar/Basic.java Tue Mar 26 15:36:19 2019 -0700 >>> +++ b/test/jdk/tools/jar/modularJar/Basic.java Wed Mar 27 16:50:53 2019 -0400 >>> @@ -54,7 +54,7 @@ >>> * jdk.test.lib.util.FileUtils >>> * jdk.test.lib.JDKToolFinder >>> * @compile Basic.java >>> - * @run testng Basic >>> + * @run testng/timeout=300 Basic >>> * @summary Tests for plain Modular jars & Multi-Release Modular jars >>> */ >>> >>> >>> ?????????? >>> >>> Best >>> Lance >>> >>> >>> 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 >>> >>> >>> >> > > > > 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 david.holmes at oracle.com Thu Mar 28 01:31:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 11:31:28 +1000 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> Message-ID: <604ae119-eec4-34a8-22f2-57d5388b862d@oracle.com> Hi Mandy, This sounds quite reasonable to me. If there is no calling context then only public entities of publicly accessible packages should be accessible. JNI itself does not apply access checks so JNI code should be using direct field access, and not core reflection, if it needs to bypass access checks. David On 28/03/2019 9:17 am, Mandy Chung wrote: > This is to fix a regression introduced in JDK 12 by JDK-8206240. > This impacts only native application that creates JVM via JNI > and also invokes Field::getField (or other reflection API) via > JNI that triggers reflection access check against the caller class. > The regression happens only when there is no caller frame, i.e. > when a native thread attaches to JVM e.g. custom launcher. > > It's unclear why the native code invokes Field::getField via JNI > to get the value of `java.lang.Integer::TYPE`.? Alternatively it could > call GetFieldID to get jfieldID of that field and then GetObjectField > if this has to be done in JNI (perhaps bypass encapsulation?). > > There is no clear semantics what reflection should behave when there > is no caller frame.?? Previously, JNI call to access > `java.lang.Integer.TYPE` > field happens to work since it is called very early at runtime and > AccessibleObject::cache is null and happens that cache == caller == null. > > The proposed fix is to perform proper access check.? When there is no > caller frame, it only allows to access to public members of a public type > in an unconditional exported API package. > > If a native thread attaches to the VM and attempts to access a non-public > member or a public member in a non-exported type e.g. > jdk.internal.misc.Unsafe, > it will throw IAE whereas the access check succeeds in JDK 11. It is > illegal to access a non-exported type.?? I think the compatibility risk > should be low as this only happens to a native code creating its VM and > calling reflection to access a member in a non-exported type. There is > no change to the behavior of JNI GetFieldID and GetObjectField. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.00/ > > I will create a CSR. > > Thanks > Mandy From david.holmes at oracle.com Thu Mar 28 05:47:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 15:47:06 +1000 Subject: RFC: Make test failed because of the locale LANG In-Reply-To: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn> References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn> Message-ID: <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com> Hi Jing, On 28/03/2019 3:22 pm, Jing Tian wrote: > Hi, > > When I am doing the 'make test'.If the local LANG is set as > 'zh_CN.UTF-8', Test cases will have a lot of error messages. > > ============================== > Test summary > ============================== > ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL > ERROR > >> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2???? 0 << > >> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7???? 0 << > >> jtreg:test/langtools:tier1???????????????????????? 3922 2470 > 1450???? 2 << > ?? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0 > ?? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0 > >> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 > 0 << > >> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 << > ?? jtreg:test/nashorn:tier2???????????????????????????? 35 35???? 0???? 0 > >> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1???? 0 << > >> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 > 0 << > ?? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0 > ?? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0 > ?? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0 > ============================== Given most of these are not hotspot issues and given the number of failures, I think this is something that would need to be discussed much more broadly. So I've cc'd core-libs-dev and compiler-dev. I recall there was a very recent discussion regarding some tests failing for the same reason, but don't recall the outcome. David ----- > On the same machine,when i set LANG=en_US.UTF-8. > > ============================== > Test summary > ============================== > ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL > ERROR > >> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2???? 0 << > >> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 > 5 << > ?? jtreg:test/langtools:tier1???????????????????????? 3920 3920 0???? 0 > ?? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0 > ?? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0 > >> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 > 7 << > ?? jtreg:test/langtools:tier2?????????????????????????? 11 11???? 0???? 0 > ?? jtreg:test/nashorn:tier2???????????????????????????? 35 35???? 0???? 0 > ?? jtreg:test/jaxp:tier2?????????????????????????????? 438 438???? 0???? 0 > >> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 > 0 << > ?? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0 > ?? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0 > ?? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0 > > > By comparison we can find, lots of(1000+) langtools tests will get fail, > and other(about 30+, exclude some X11 and sanity that > > result problem) test cases will also fail because of local LANG. > > > such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java, > > shouldContain("Error: Could not find or load main class " + CLASSNAME) > > > When in the zh_CN.UTF-8 environment, because some of the output > information is changed to Chinese by some properties file, > > the English cannot be matched, which will result in an fail. > > When I set? LANG=en_US/LC_ALL=C, this test will pass. > > > I think there are some possible solutions. > > > 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this modification > is more violent because he will affect all test cases. > > > 2.We modify each individual test?E.g > test/hotspot/jtreg/compiler/c2/Test8062950.java > > diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java > ?package compiler.c2; > ?import jdk.test.lib.process.ProcessTools; > +import java.util.Map; > +import jdk.test.lib.process.OutputAnalyzer; > > ?public class Test8062950 { > ???? private static final String CLASSNAME = "DoesNotExist"; > ???? public static void main(String[] args) throws Exception { > - ProcessTools.executeTestJvm("-Xcomp", > - "-XX:-TieredCompilation", > - "-XX:-UseOptoBiasInlining", > - CLASSNAME) > - .shouldHaveExitValue(1) > -??????????????????? .shouldContain("Error: Could not find or load main > class " + CLASSNAME) > -??????????????????? .shouldNotContain("A fatal error has been detected") > -??????????????????? .shouldNotContain("Internal Error") > -??????????????????? .shouldNotContain("HotSpot Virtual Machine Error"); > +??????? final ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(true, > + "-Xcomp", > + "-XX:-TieredCompilation", > + "-XX:-UseOptoBiasInlining", > + CLASSNAME); > +??????? final Map env = pb.environment(); > +??????? env.put("LC_ALL", "en_US.UTF-8"); > +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start()); > + output.shouldHaveExitValue(1); > +??????? output.shouldContain("Error: Could not find or load main class > " + CLASSNAME); > +??????? output.shouldNotContain("A fatal error has been detected"); > +??????? output.shouldNotContain("Internal Error"); > +??????? output.shouldNotContain("HotSpot Virtual Machine Error"); > } > ?} > > But I don't know if this will change the test program too much, because > the related problems are a lot in langtools tests. > > > 3.And i find that there is a function can judge the locale > > ?if (!isEnglishLocale()) { // only english version > return; > ?} > > But in this case, I think in many test cases, we may not be able to > return so directly, because some test cases may have other test purposes. > > > So I don't know if you have any ideas or some suggestions to solve the > problem that the output information and English do not match in this > > non-English environment. > > > Cheers, > > Jing Tian > > > > From Alan.Bateman at oracle.com Thu Mar 28 07:19:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 07:19:05 +0000 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <832172a3-28e7-40ee-79d4-aa63be7b94ae@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> <2084129B-A859-44C6-BBC4-7C8DD9EB7C81@oracle.com> <832172a3-28e7-40ee-79d4-aa63be7b94ae@oracle.com> Message-ID: <7f1868aa-0f12-52d9-49fd-2d4236205c2a@oracle.com> On 28/03/2019 00:23, Mandy Chung wrote: > > > On 3/27/19 4:56 PM, Lance Andersen wrote: >> Hi Mandy, >> >> >>> On Mar 27, 2019, at 7:23 PM, Mandy Chung >> > wrote: >>> >>> Hi Lance, >>> >>> Do you understand what takes so long for this test to run? >> >> Well it is executing a lot of jar commands. ?I did not see anything >> that sticks out in the failed logs that point to anything obvious. > > One thing you could do is to instrument the test to gather the timing > statistics. This test runs the jar command at least 50 times and I/O tends to be slower on Windows. Lance can use the test infrastructure to run it many times and gather timings from a range of Windows hosts to get an idea on how long it takes. I can well believe that it's close to the timeout on some systems so increasing the timeout should help. As regards gathering stats then it is a TestNG test with ~25 tests so we could use @Before/@AfterMethod to get data if needed. It will clutter the output but okay although trying to see what the timeout this test needs. -Alan From Alan.Bateman at oracle.com Thu Mar 28 08:40:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 08:40:54 +0000 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> Message-ID: On 27/03/2019 23:17, Mandy Chung wrote: > : > > The proposed fix is to perform proper access check.? When there is no > caller frame, it only allows to access to public members of a public type > in an unconditional exported API package. > The approach seems reasonable to me and we should, at some point, try to align the other @CS methods with this behavior. As Mandy knows, this is unspecified behavior and we aren't consistent in the JDK on how to handle "no caller frame" case. Some @CS methods will throw NPE if invoked directly, others detect the caller is null and throw or treat it as Object.class. In the patch, shouldn't slowVerifyAccess check that memberClass is public? -Alan From adinn at redhat.com Thu Mar 28 10:44:17 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Mar 2019 10:44:17 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM Message-ID: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> Could I please have reviews for this patch which changes the initialization of four os/cpu-specific static final constants used by class Unsafe. The patch injects values during JVM startup (along similar lines to how String field COMPACT_STRINGS is initialized) rather than retrieving them via native method calls. This localizes the computation of the assigned values in one place, relocates the constants into a separate final, static-only Java class and avoids the need to maintain four separate native methods. A further motive for making this change is to pave the way for adding the writeback cache line size/address mask as Unsafe constants for use by the JEP proposed in JDK-8207851. JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.01 Testing: submit repo tests passed 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 christoph.langer at sap.com Thu Mar 28 10:58:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 28 Mar 2019 10:58:35 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hi Matthias, the change to src/java.base/windows/native/libjli/java_md.c looks good to me now. As for the test, I think you could also check a jar in a short path to exercise both cases in JLI_Open. And a few nits: Line 506: better do: Path pelp = pcreated.resolve(elp.jar); Line 507: 2 spaces are one too much after elp Line 508: Insert 2 additional spaces in the source code string, a space between "){" and another in the end after the ; of the System.out.println statement, like this: createJar(elp, new File("Foo"), "public static void main(String[] args) { System.out.println(\"Hello from ELP\"); }"); You could also do a little cleanup: Remove method private static String removeExtraQuotes(String in) { from line 64. It seems, it is not needed. Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 27. M?rz 2019 18:05 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hello could you please look into it ? > > Best regards, Matthias > > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Montag, 25. M?rz 2019 18:05 > > To: Langer, Christoph > > Cc: 'core-libs-dev at openjdk.java.net' ; > > 'Alan Bateman' > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hello here is an updated webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > > > > > > > > > In JLI_Open(const char* name, int flags), you should remove ret and > only > > > > use fd, I think. > > > > > > I removed ret and adjusted some comments. > > > > Additionally I added a test that uses (on Windows) JLI_Open on a jar > file > > with a "long" path (> 260 chars). > > [ JLI_Open is currently called from parse_manifest.c with jarfile as > > parameter ] > > From andy.herrick at oracle.com Thu Mar 28 11:07:44 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 28 Mar 2019 07:07:44 -0400 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options Message-ID: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> RFR: JDK-8221582: Rename jvm-args option to java-options Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 [2] - http://cr.openjdk.java.net/~herrick/8221582/ /Andy From matthias.baesken at sap.com Thu Mar 28 11:38:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 28 Mar 2019 11:38:49 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hello here is another webrev , I adjusted test/jdk/tools/launcher/Arrrghs.java a bit taking your suggestions into account . Can I have a second review please ? http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.2/webrev/ > As for the test, I think you could also check a jar in a short path There exist already quite a few tests using "-jar some.jar" with "normal" / shorter paths in test/jdk/tools/launcher/Arrrghs.java . Regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 28. M?rz 2019 11:59 > To: Baesken, Matthias > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > the change to src/java.base/windows/native/libjli/java_md.c looks good to > me now. > > As for the test, I think you could also check a jar in a short path to exercise > both cases in JLI_Open. > > And a few nits: > Line 506: better do: > Path pelp = pcreated.resolve(elp.jar); > > Line 507: > 2 spaces are one too much after elp > > Line 508: > Insert 2 additional spaces in the source code string, a space between "){" and > another in the end after the ; of the System.out.println statement, like this: > createJar(elp, new File("Foo"), "public static void main(String[] args) { > System.out.println(\"Hello from ELP\"); }"); > > You could also do a little cleanup: Remove method private static String > removeExtraQuotes(String in) { from line 64. It seems, it is not needed. > > Best regards > Christoph > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Mittwoch, 27. M?rz 2019 18:05 > > To: Langer, Christoph > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hello could you please look into it ? > > > > Best regards, Matthias > > > > > > > > > -----Original Message----- > > > From: Baesken, Matthias > > > Sent: Montag, 25. M?rz 2019 18:05 > > > To: Langer, Christoph > > > Cc: 'core-libs-dev at openjdk.java.net' ; > > > 'Alan Bateman' > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > parse_manifest.c on windows > > > > > > Hello here is an updated webrev : > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > > > > > > > > > > > > > In JLI_Open(const char* name, int flags), you should remove ret and > > only > > > > > use fd, I think. > > > > > > > > > I removed ret and adjusted some comments. > > > > > > Additionally I added a test that uses (on Windows) JLI_Open on a jar > > file > > > with a "long" path (> 260 chars). > > > [ JLI_Open is currently called from parse_manifest.c with jarfile as > > > parameter ] > > > From christoph.langer at sap.com Thu Mar 28 11:41:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 28 Mar 2019 11:41:29 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Hi Matthias, this looks good to me now. Let's wait for another review then. Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Donnerstag, 28. M?rz 2019 12:39 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hello here is another webrev , I adjusted > test/jdk/tools/launcher/Arrrghs.java a bit taking your suggestions into > account . > Can I have a second review please ? > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.2/webrev/ > > > As for the test, I think you could also check a jar in a short path > > There exist already quite a few tests using "-jar some.jar" with "normal" / > shorter paths in test/jdk/tools/launcher/Arrrghs.java . > > > Regards, Matthias > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Donnerstag, 28. M?rz 2019 11:59 > > To: Baesken, Matthias > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hi Matthias, > > > > the change to src/java.base/windows/native/libjli/java_md.c looks good to > > me now. > > > > As for the test, I think you could also check a jar in a short path to exercise > > both cases in JLI_Open. > > > > And a few nits: > > Line 506: better do: > > Path pelp = pcreated.resolve(elp.jar); > > > > Line 507: > > 2 spaces are one too much after elp > > > > Line 508: > > Insert 2 additional spaces in the source code string, a space between "){" > and > > another in the end after the ; of the System.out.println statement, like this: > > createJar(elp, new File("Foo"), "public static void main(String[] args) { > > System.out.println(\"Hello from ELP\"); }"); > > > > You could also do a little cleanup: Remove method private static String > > removeExtraQuotes(String in) { from line 64. It seems, it is not needed. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Baesken, Matthias > > > Sent: Mittwoch, 27. M?rz 2019 18:05 > > > To: Langer, Christoph > > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > parse_manifest.c on windows > > > > > > Hello could you please look into it ? > > > > > > Best regards, Matthias > > > > > > > > > > > > > -----Original Message----- > > > > From: Baesken, Matthias > > > > Sent: Montag, 25. M?rz 2019 18:05 > > > > To: Langer, Christoph > > > > Cc: 'core-libs-dev at openjdk.java.net' dev at openjdk.java.net>; > > > > 'Alan Bateman' > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > > parse_manifest.c on windows > > > > > > > > Hello here is an updated webrev : > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > > > > > > > > > > > > > > > > > In JLI_Open(const char* name, int flags), you should remove ret > and > > > only > > > > > > use fd, I think. > > > > > > > > > > > > I removed ret and adjusted some comments. > > > > > > > > Additionally I added a test that uses (on Windows) JLI_Open on a > jar > > > file > > > > with a "long" path (> 260 chars). > > > > [ JLI_Open is currently called from parse_manifest.c with jarfile as > > > > parameter ] > > > > From thomas.stuefe at gmail.com Thu Mar 28 12:17:26 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 13:17:26 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> Message-ID: Hi, this looks fine, nits only: UnsafeConstantsFixup::do_field() you could shrink that coding a bit by factoring out the checks, e.g.: static oop mirror_with_checks_from_field_descriptor(fieldDescriptor* fd) { oop mirror = fd->field_holder()->java_mirror(); assert(fd->field_holder() == SystemDictionary::UnsafeConstants_klass(), "Should be UnsafeConstants"); assert(mirror != NULL, "UnsafeConstants must have mirror already"); return oop; } Also, is there a reason that code from thread.cpp: jint address_size = sizeof(void*); jint page_size = os::vm_page_size(); jboolean is_big_endian = LITTLE_ENDIAN_ONLY(false) BIG_ENDIAN_ONLY(true); jint use_unaligned_access = UseUnalignedAccesses; could not just happen right in UnsafeConstantsFixup::do_field()? You would not have to pass all these arguments around, param list could be empty. src/hotspot/share/classfile/vmSymbols.hpp Alignment of trailing '\' broken src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java s/intitialize/initialize s/iff/if Cheers, Thomas On Thu, Mar 28, 2019 at 11:44 AM Andrew Dinn wrote: > Could I please have reviews for this patch which changes the > initialization of four os/cpu-specific static final constants used by > class Unsafe. The patch injects values during JVM startup (along similar > lines to how String field COMPACT_STRINGS is initialized) rather than > retrieving them via native method calls. This localizes the computation > of the assigned values in one place, relocates the constants into a > separate final, static-only Java class and avoids the need to maintain > four separate native methods. > > A further motive for making this change is to pave the way for adding > the writeback cache line size/address mask as Unsafe constants for use > by the JEP proposed in JDK-8207851. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.01 > > Testing: > submit repo tests passed > > 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 adinn at redhat.com Thu Mar 28 14:41:12 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Mar 2019 14:41:12 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> Message-ID: <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> On 28/03/2019 12:17, Thomas St?fe wrote: > this looks fine, nits only: Thank you for the review, Thomas. I'll post a follow up webrev to address the comments. Responses are inline. > UnsafeConstantsFixup::do_field() > > you could shrink that coding a bit by factoring out the checks, e.g.: > . . . Yes, that was egregious cut-and-paste coding. Actually, the idea is that all fields of the class are final static and all of them are expected to be injected (which is why the final else clause asserts). So, I could just move the asserts up to precede the if-elseif cascade and also include checks that the field is final and static. void do_field(fieldDescriptor* fd) { oop mirror = fd->field_holder()->java_mirror(); assert(mirror != NULL, "UnsafeConstants must have mirror already"); assert(fd->field_holder() == SystemDictionary::UnsafeConstants_klass(), "Should be UnsafeConstants"); assert(fd->is_final(), "fields of UnsafeConstants must be final"); assert(fd->is_static() "fields of UnsafeConstants must be static"); if (fd->name() == vmSymbols::address_size_name()) { mirror->int_field_put(fd->offset(), _address_size); } else if (fd->name() == vmSymbols::page_size_name()) { mirror->int_field_put(fd->offset(), _page_size); } else if (fd->name() == vmSymbols::big_endian_name()) { . . . } else { assert(false, "unexpected UnsafeConstants field"); } > Also, is there a reason that code from thread.cpp: > > ? ? jint address_size = sizeof(void*); > ? ? jint page_size = os::vm_page_size(); > ? ? jboolean is_big_endian = LITTLE_ENDIAN_ONLY(false) > BIG_ENDIAN_ONLY(true); > ? ? jint use_unaligned_access = UseUnalignedAccesses; > > could not just happen right in UnsafeConstantsFixup::do_field()? You > would not have to pass all these arguments around, param list could be > empty. No good reason. Your suggestion is better. > src/hotspot/share/classfile/vmSymbols.hpp > > Alignment of trailing '\' broken Oops! > src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java > > s/intitialize/initialize > s/iff/if The second of those was actually intended to be iff. This is a common abbreviation used by English/US mathematicians and logicians to write 'if and only if' (it is also sometimes written as <=>). Since you didn't recognize it I guess I really need to write it out in full. 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 peter.levart at gmail.com Thu Mar 28 14:48:04 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 Mar 2019 15:48:04 +0100 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> Message-ID: <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> Hi, On 3/28/19 9:40 AM, Alan Bateman wrote: > On 27/03/2019 23:17, Mandy Chung wrote: >> : >> >> The proposed fix is to perform proper access check.? When there is no >> caller frame, it only allows to access to public members of a public >> type >> in an unconditional exported API package. >> > The approach seems reasonable to me and we should, at some point, try > to align the other @CS methods with this behavior. As Mandy knows, > this is unspecified behavior and we aren't consistent in the JDK on > how to handle "no caller frame" case. Some @CS methods will throw NPE > if invoked directly, others detect the caller is null and throw or > treat it as Object.class. > > In the patch, shouldn't slowVerifyAccess check that memberClass is > public? I think it should. If we pretend that the check should be equivalent as if performed from an unrelated class in an unrelated module, then the check for public member class should be included. In addition, if access from null caller is granted and it is performed to a member in a "concealed" package, there's no warning displayed (the further logic in the AccessibleObject is skipped). What would it look like if AccessibleObject was left intact and only Reflection was modified to accommodate for null currentClass - caller/accessor. Like the in the following patch: Index: src/java.base/share/classes/jdk/internal/reflect/Reflection.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/jdk/internal/reflect/Reflection.java (revision 54324:9d5c84b0a59862859081e2477f8069a2149c4063) +++ src/java.base/share/classes/jdk/internal/reflect/Reflection.java (revision 54324+:9d5c84b0a598+) @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, 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 @@ -108,7 +108,10 @@ ???? /** ????? * Verify access to a member and return {@code true} if it is granted. ????? * -???? * @param currentClass the class performing the access +???? * @param currentClass the class performing the access or null if +???? *???????????????????? access is to be verified for an unknown caller/accessor +???? *???????????????????? for example if access is performed via JNI and there's no +???? *???????????????????? Java frame on caller stack (custom JVM launchers) ????? * @param memberClass the declaring class of the member being accessed ????? * @param targetClass the class of target object if accessing instance ????? *??????????????????? field or method; @@ -122,6 +125,13 @@ ????????????????????????????????????????????? Class targetClass, ????????????????????????????????????????????? int modifiers) ???? { +??????? Objects.requireNonNull(memberClass); + +??????? if (currentClass == null) { +??????????? // verify access for an unknown caller/accessor +??????????? return verifyGeneralMemberAccess(memberClass, modifiers); +??????? } + ???????? if (currentClass == memberClass) { ???????????? // Always succeeds ???????????? return true; @@ -201,6 +211,17 @@ ???????? return true; ???? } +??? /** +???? * @param memberClass the member's declaring class +???? * @param modifiers the member's modifiers +???? * @return {@code true} if the member can be accessed from anywhere +???? */ +??? private static boolean verifyGeneralMemberAccess(Class memberClass, int modifiers) { +??????? return Modifier.isPublic(getClassAccessFlags(memberClass)) && +?????????????? Modifier.isPublic(modifiers) && + memberClass.getModule().isExported(memberClass.getPackageName()); +??? } + ???? /** ????? * Returns {@code true} if memberClass's module exports memberClass's ????? * package to currentModule. @@ -327,6 +348,9 @@ int modifiers) ???????? throws IllegalAccessException ???? { +??????? if (currentClass == null) +??????????? return newIllegalAccessException(memberClass, modifiers); + ???????? String currentSuffix = ""; ???????? String memberSuffix = ""; ???????? Module m1 = currentClass.getModule(); @@ -352,6 +376,37 @@ ???????????? if (m2.isNamed()) msg += " to " + m1; ???????? } +??????? return new IllegalAccessException(msg); +??? } + +??? /** +???? * Returns an IllegalAccessException with an exception message where +???? * there is no caller frame. +???? */ +??? public static IllegalAccessException newIllegalAccessException(Class memberClass, + int modifiers) +??????? throws IllegalAccessException +??? { +??????? String memberSuffix = ""; +??????? Module m2 = memberClass.getModule(); +??????? if (m2.isNamed()) +??????????? memberSuffix = " (in " + m2 + ")"; + +??????? String memberPackageName = memberClass.getPackageName(); + +??????? String msg = "JNI attached native thread (null caller frame) cannot access "; +??????? if (m2.isExported(memberPackageName)) { + +??????????? // module access okay so include the modifiers in the message +??????????? msg += "a member of " + memberClass + memberSuffix + +??????????????? " with modifiers \"" + Modifier.toString(modifiers) + "\""; + +??????? } else { +??????????? // module access failed +??????????? msg += memberClass + memberSuffix+ " because " +??????????????? + m2 + " does not export " + memberPackageName; +??????? } + ???????? return new IllegalAccessException(msg); ???? } Regards, Peter From peter.levart at gmail.com Thu Mar 28 15:01:30 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 Mar 2019 16:01:30 +0100 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> Message-ID: <487d7c3c-1652-f844-6b35-5d11a4110b15@gmail.com> On 3/28/19 3:48 PM, Peter Levart wrote: > In addition, if access from null caller is granted and it is performed > to a member in a "concealed" package, there's no warning displayed > (the further logic in the AccessibleObject is skipped). > > What would it look like if AccessibleObject was left intact and only > Reflection was modified to accommodate for null currentClass - > caller/accessor.... Note that this would also require modifications to: java.lang.reflect.AccessibleObject#logIfExportedForIllegalAccess ...to accommodate for null caller. Currently this always throws NPE if such access is granted to a null caller regardless of whether it is made to a concealed package or not. Peter From mark.reinhold at oracle.com Thu Mar 28 15:03:29 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 Mar 2019 08:03:29 -0700 (PDT) Subject: New candidate JEP: 352: Non-Volatile Mapped Byte Buffers Message-ID: <20190328150329.DE08526DE20@eggemoggin.niobe.net> https://openjdk.java.net/jeps/352 - Mark From Alan.Bateman at oracle.com Thu Mar 28 15:08:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 15:08:26 +0000 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> Message-ID: <9ec267f2-6d82-8cd7-a818-fa5696f599fb@oracle.com> On 28/03/2019 14:48, Peter Levart wrote: > : > > In addition, if access from null caller is granted and it is performed > to a member in a "concealed" package, there's no warning displayed The proposed check is that the package is exported unconditionally so it will fail, no warning needed. I think that is okay. I could imagine someone trying to argue that they run with `--add-exports java.base/=ALL-UNNAMED` and they expect their JNI code to be able to reflect on the public members of public classes in that package but it hardly seems wroth it as JNI doesn't do access checks so it's pointless writing JNI code to use reflection. -Alan From thomas.stuefe at gmail.com Thu Mar 28 15:22:19 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 16:22:19 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> Message-ID: On Thu, Mar 28, 2019 at 3:41 PM Andrew Dinn wrote: > On 28/03/2019 12:17, Thomas St?fe wrote: > > this looks fine, nits only: > > Thank you for the review, Thomas. I'll post a follow up webrev to > address the comments. Responses are inline. > > > UnsafeConstantsFixup::do_field() > > > > you could shrink that coding a bit by factoring out the checks, e.g.: > > . . . > > Yes, that was egregious cut-and-paste coding. > > Actually, the idea is that all fields of the class are final static and > all of them are expected to be injected (which is why the final else > clause asserts). > > So, I could just move the asserts up to precede the if-elseif cascade > and also include checks that the field is final and static. > > void do_field(fieldDescriptor* fd) { > oop mirror = fd->field_holder()->java_mirror(); > assert(mirror != NULL, "UnsafeConstants must have mirror already"); > assert(fd->field_holder() == > SystemDictionary::UnsafeConstants_klass(), "Should be UnsafeConstants"); > assert(fd->is_final(), "fields of UnsafeConstants must be final"); > assert(fd->is_static() "fields of UnsafeConstants must be static"); > if (fd->name() == vmSymbols::address_size_name()) { > mirror->int_field_put(fd->offset(), _address_size); > } else if (fd->name() == vmSymbols::page_size_name()) { > mirror->int_field_put(fd->offset(), _page_size); > } else if (fd->name() == vmSymbols::big_endian_name()) { > . . . > } else { > assert(false, "unexpected UnsafeConstants field"); > } > > > Also, is there a reason that code from thread.cpp: > > > > jint address_size = sizeof(void*); > > jint page_size = os::vm_page_size(); > > jboolean is_big_endian = LITTLE_ENDIAN_ONLY(false) > > BIG_ENDIAN_ONLY(true); > > jint use_unaligned_access = UseUnalignedAccesses; > > > > could not just happen right in UnsafeConstantsFixup::do_field()? You > > would not have to pass all these arguments around, param list could be > > empty. > > No good reason. Your suggestion is better. > > > src/hotspot/share/classfile/vmSymbols.hpp > > > > Alignment of trailing '\' broken > > Oops! > > > src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java > > > > s/intitialize/initialize > > s/iff/if > The second of those was actually intended to be iff. This is a common > abbreviation used by English/US mathematicians and logicians to write > 'if and only if' (it is also sometimes written as <=>). Since you didn't > recognize it I guess I really need to write it out in full. > Oh, don't worry on my account. I am not a native speaker nor a mathematician. You could leave iff and add [sic] to make everyone curious and start googling "iff" :) ..Thomas > > 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 thomas.stuefe at gmail.com Thu Mar 28 15:32:22 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 16:32:22 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> Message-ID: Btw congrats for finally getting JEP 352 to move on. That really took a while. Cheers, Thomas On Thu, Mar 28, 2019 at 4:22 PM Thomas St?fe wrote: > > > On Thu, Mar 28, 2019 at 3:41 PM Andrew Dinn wrote: > >> On 28/03/2019 12:17, Thomas St?fe wrote: >> > this looks fine, nits only: >> >> Thank you for the review, Thomas. I'll post a follow up webrev to >> address the comments. Responses are inline. >> >> > UnsafeConstantsFixup::do_field() >> > >> > you could shrink that coding a bit by factoring out the checks, e.g.: >> > . . . >> >> Yes, that was egregious cut-and-paste coding. >> >> Actually, the idea is that all fields of the class are final static and >> all of them are expected to be injected (which is why the final else >> clause asserts). >> >> So, I could just move the asserts up to precede the if-elseif cascade >> and also include checks that the field is final and static. >> >> void do_field(fieldDescriptor* fd) { >> oop mirror = fd->field_holder()->java_mirror(); >> assert(mirror != NULL, "UnsafeConstants must have mirror already"); >> assert(fd->field_holder() == >> SystemDictionary::UnsafeConstants_klass(), "Should be UnsafeConstants"); >> assert(fd->is_final(), "fields of UnsafeConstants must be final"); >> assert(fd->is_static() "fields of UnsafeConstants must be static"); >> if (fd->name() == vmSymbols::address_size_name()) { >> mirror->int_field_put(fd->offset(), _address_size); >> } else if (fd->name() == vmSymbols::page_size_name()) { >> mirror->int_field_put(fd->offset(), _page_size); >> } else if (fd->name() == vmSymbols::big_endian_name()) { >> . . . >> } else { >> assert(false, "unexpected UnsafeConstants field"); >> } >> >> > Also, is there a reason that code from thread.cpp: >> > >> > jint address_size = sizeof(void*); >> > jint page_size = os::vm_page_size(); >> > jboolean is_big_endian = LITTLE_ENDIAN_ONLY(false) >> > BIG_ENDIAN_ONLY(true); >> > jint use_unaligned_access = UseUnalignedAccesses; >> > >> > could not just happen right in UnsafeConstantsFixup::do_field()? You >> > would not have to pass all these arguments around, param list could be >> > empty. >> >> No good reason. Your suggestion is better. >> >> > src/hotspot/share/classfile/vmSymbols.hpp >> > >> > Alignment of trailing '\' broken >> >> Oops! >> >> > src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java >> > >> > s/intitialize/initialize >> > s/iff/if >> The second of those was actually intended to be iff. This is a common >> abbreviation used by English/US mathematicians and logicians to write >> 'if and only if' (it is also sometimes written as <=>). Since you didn't >> recognize it I guess I really need to write it out in full. >> > > Oh, don't worry on my account. I am not a native speaker nor a > mathematician. You could leave iff and add [sic] to make everyone curious > and start googling "iff" :) > > ..Thomas > > >> >> 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 bob.vandette at oracle.com Thu Mar 28 15:37:53 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 28 Mar 2019 11:37:53 -0400 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> Message-ID: <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> Sorry for the delay. The update looks good. Bob. > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: >> Could you maybe combine subsystem_file_contents with subsystem_file_line_contents >> by adding an additional argument? > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > Thanks, > Severin > From mandy.chung at oracle.com Thu Mar 28 15:44:51 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2019 08:44:51 -0700 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> Message-ID: <6817ea36-d546-e248-c2e5-615296a61d49@oracle.com> On 3/28/19 1:40 AM, Alan Bateman wrote: > On 27/03/2019 23:17, Mandy Chung wrote: >> : >> >> The proposed fix is to perform proper access check.? When there is no >> caller frame, it only allows to access to public members of a public >> type >> in an unconditional exported API package. >> > The approach seems reasonable to me and we should, at some point, try > to align the other @CS methods with this behavior. As Mandy knows, > this is unspecified behavior and we aren't consistent in the JDK on > how to handle "no caller frame" case. Some @CS methods will throw NPE > if invoked directly, others detect the caller is null and throw or > treat it as Object.class. > Yup and tracked by JDK-8177155.? I hope to look into a different way to reliably bind the caller to @CSM. > In the patch, shouldn't slowVerifyAccess check that memberClass is > public? Good catch.?? Will fix it. Mandy From peter.levart at gmail.com Thu Mar 28 15:46:00 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 Mar 2019 16:46:00 +0100 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <9ec267f2-6d82-8cd7-a818-fa5696f599fb@oracle.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> <9ec267f2-6d82-8cd7-a818-fa5696f599fb@oracle.com> Message-ID: <4d49f85d-ad49-b37c-0e00-39247d32fe09@gmail.com> On 3/28/19 4:08 PM, Alan Bateman wrote: > On 28/03/2019 14:48, Peter Levart wrote: >> : >> >> In addition, if access from null caller is granted and it is >> performed to a member in a "concealed" package, there's no warning >> displayed > The proposed check is that the package is exported unconditionally so > it will fail, no warning needed. I think that is okay. I could imagine > someone trying to argue that they run with `--add-exports > java.base/=ALL-UNNAMED` and they expect their JNI > code to be able to reflect on the public members of public classes in > that package but it hardly seems wroth it as JNI doesn't do access > checks so it's pointless writing JNI code to use reflection. Right, and it would require deep changes to AccessibleObject#logIfExportedForIllegalAccess too, since it assumes the presence of non-null caller... Nevertheless the access checking logic could be encapsulated entirely in the Reflection class (for null caller too) and then in AccessibleObject, the logIfExportedForIllegalAccess call just skipped for null caller... Else the logic is scattered between two classes and would have to be repeated for other similar cases. Reflection.verifyMemberAccess() is called not only from AccessibleObject.slowVerifyAccess() but from elsewhere too. For example, from ReflectUtil.ensureMemberAccess which is used in @CS AtomicXxxFieldUpdater(s), or from @CS java.util.ServiceLoader.load... By encapsulating it in the common Reflection.verifyMemberAccess() method, all those usages get handled at the same time. Regards, Peter > > -Alan From sgehwolf at redhat.com Thu Mar 28 15:59:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Mar 2019 16:59:22 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> Message-ID: <014ebe0ced3e94cd5563e19e87a337f686338248.camel@redhat.com> On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > Sorry for the delay. The update looks good. Thanks for the review, Bob. Any other Reviewer(s)? Thanks, Severin > Bob. > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > by adding an additional argument? > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > Thanks, > > Severin > > From naoto.sato at oracle.com Thu Mar 28 15:59:28 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 28 Mar 2019 08:59:28 -0700 Subject: RFC: Make test failed because of the locale LANG In-Reply-To: <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com> References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn> <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com> Message-ID: Hi, I don't think there is any *official* rule for the regression tests to succeed in any locale, but if the test case is locale sensitive such as in this case, I'd suggest it should correctly specify the locale beforehand, or quit gracefully in general. For this specific case, I'd suggest not set the environment variable (as it won't work with Windows), using runtime system properties (user.language/user.country) would help. Naoto On 3/27/19 10:47 PM, David Holmes wrote: > Hi Jing, > > On 28/03/2019 3:22 pm, Jing Tian wrote: >> Hi, >> >> When I am doing the 'make test'.If the local LANG is set as >> 'zh_CN.UTF-8', Test cases will have a lot of error messages. >> >> ============================== >> Test summary >> ============================== >> ??? TEST????????????????????????????????????????????? TOTAL? PASS FAIL >> ERROR >> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 >> 0 << >> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 >> 0 << >> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 >> 1450???? 2 << >> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0 >> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 0 << >> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 << >> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 >> 0???? 0 >> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 >> 0 << >> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 0 << >> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0 >> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0 >> ============================== > > Given most of these are not hotspot issues and given the number of > failures, I think this is something that would need to be discussed much > more broadly. So I've cc'd core-libs-dev and compiler-dev. I recall > there was a very recent discussion regarding some tests failing for the > same reason, but don't recall the outcome. > > David > ----- > >> On the same machine,when i set LANG=en_US.UTF-8. >> >> ============================== >> Test summary >> ============================== >> ??? TEST????????????????????????????????????????????? TOTAL? PASS FAIL >> ERROR >> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 >> 0 << >> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 5 << >> ??? jtreg:test/langtools:tier1???????????????????????? 3920 3920 0???? 0 >> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0 >> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 7 << >> ??? jtreg:test/langtools:tier2?????????????????????????? 11 11 >> 0???? 0 >> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 >> 0???? 0 >> ??? jtreg:test/jaxp:tier2?????????????????????????????? 438 438 >> 0???? 0 >> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 0 << >> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0 >> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0 >> >> >> By comparison we can find, lots of(1000+) langtools tests will get >> fail, and other(about 30+, exclude some X11 and sanity that >> >> result problem) test cases will also fail because of local LANG. >> >> >> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java, >> >> shouldContain("Error: Could not find or load main class " + CLASSNAME) >> >> >> When in the zh_CN.UTF-8 environment, because some of the output >> information is changed to Chinese by some properties file, >> >> the English cannot be matched, which will result in an fail. >> >> When I set? LANG=en_US/LC_ALL=C, this test will pass. >> >> >> I think there are some possible solutions. >> >> >> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this >> modification is more violent because he will affect all test cases. >> >> >> 2.We modify each individual test?E.g >> test/hotspot/jtreg/compiler/c2/Test8062950.java >> >> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java >> ??package compiler.c2; >> ??import jdk.test.lib.process.ProcessTools; >> +import java.util.Map; >> +import jdk.test.lib.process.OutputAnalyzer; >> >> ??public class Test8062950 { >> ????? private static final String CLASSNAME = "DoesNotExist"; >> ????? public static void main(String[] args) throws Exception { >> - ProcessTools.executeTestJvm("-Xcomp", >> - "-XX:-TieredCompilation", >> - "-XX:-UseOptoBiasInlining", >> - CLASSNAME) >> - .shouldHaveExitValue(1) >> -??????????????????? .shouldContain("Error: Could not find or load >> main class " + CLASSNAME) >> -??????????????????? .shouldNotContain("A fatal error has been detected") >> -??????????????????? .shouldNotContain("Internal Error") >> -??????????????????? .shouldNotContain("HotSpot Virtual Machine Error"); >> +??????? final ProcessBuilder pb = >> ProcessTools.createJavaProcessBuilder(true, >> + "-Xcomp", >> + "-XX:-TieredCompilation", >> + "-XX:-UseOptoBiasInlining", >> + CLASSNAME); >> +??????? final Map env = pb.environment(); >> +??????? env.put("LC_ALL", "en_US.UTF-8"); >> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start()); >> + output.shouldHaveExitValue(1); >> +??????? output.shouldContain("Error: Could not find or load main >> class " + CLASSNAME); >> +??????? output.shouldNotContain("A fatal error has been detected"); >> +??????? output.shouldNotContain("Internal Error"); >> +??????? output.shouldNotContain("HotSpot Virtual Machine Error"); >> } >> ??} >> >> But I don't know if this will change the test program too much, >> because the related problems are a lot in langtools tests. >> >> >> 3.And i find that there is a function can judge the locale >> >> ??if (!isEnglishLocale()) { // only english version >> return; >> ??} >> >> But in this case, I think in many test cases, we may not be able to >> return so directly, because some test cases may have other test purposes. >> >> >> So I don't know if you have any ideas or some suggestions to solve the >> problem that the output information and English do not match in this >> >> non-English environment. >> >> >> Cheers, >> >> Jing Tian >> >> >> >> From andrew_m_leonard at uk.ibm.com Thu Mar 28 16:13:41 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 28 Mar 2019 16:13:41 +0000 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle Message-ID: Roger, Ivan, thanks for your help discussing this issue. Fyi, I am off on leave for the next week, so I +1 Ivan's last webrev if that's the way you decide to go.. 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 From: Roger Riggs To: Ivan Gerasimov , Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 27/03/2019 13:39 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Hi Ivan, On 03/26/2019 07:30 PM, Ivan Gerasimov wrote: The main source of confusion here seems to be due to that the coder is passed in as an argument, so it either needs to be trusted or has to be verified in the constructor. The design for coder is that it *is* trusted in all internal/implementation APIs. Subsequent changes should not weaken this invariant, it will cause doubt in the code and cast doubt on all of the performance work that has been done to optimize its use. So, let's instead introduce AbstractStringBuilder(CharSequence) and make it do all manipulations. http://cr.openjdk.java.net/~igerasim/8221430/01/webrev/ Note that the common case of StringBuilder(String) already gets intrinsified by hotspot. What do you think? This looks good, the logic is in one place. Since StringBuilder(String) is an intrinsic, my doubt about a slight performance impact is unwarranted in that specific case. Are there any StringBuffer/Builder jmh tests than be easily rerun to compare? Thanks, Roger With kind regards, Ivan On 3/26/19 1:04 PM, Ivan Gerasimov wrote: >From the design point of view, I believe it is better to have the constructor AbstractStringBuilder(int, int, int) to check if the coder argument makes sense with respect to the value of COMPACT_STRING, so it won't be possible to create a StringBuilder with the coder==LATIN1, when it is not supported. For calculating the coderHint then, it is not necessary to check COMPACT_STRING: If the CharSequence argument is in fact String or AbstractStringBuilder, the coder is known, otherwise LATIN1 can be passed in as a hint (for an arbitrary CharSequence it is not 100% accurate anyway). The constructor AbstractStringBuilder(int, int, int) will then either use the provided coder, or adjust it if necessary. Will we agree on something like following? http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/ With kind regards, Ivan On 3/26/19 12:14 PM, Roger Riggs wrote: Hi, We've got the subject open and its fresh, there's no need for a separate review cycle. The first fix (-01) does not seem to be consistent with the original design and handling of the coder. The StringBuilder(String) and StringBuffer(String) constructors are the pattern that should be followed for determining the coder for the new instance. Checking for COMPACT_STRING in two places (the AbstractStringBuilder and the sub classes) is unnecessary and distributes the information about the correct coder across two classes where determining what it should be in the subclass has more complete information and can correctly determine the coder once. We can likely find a reviewer to be a tie-breaker if Ivan sees it as desirable. Thanks, Roger On 03/26/2019 02:38 PM, Andrew Leonard wrote: Sorry chaps, I think my brain is getting confused!, I think we have conflicting reviews here? Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so it was only defined in one place.. I agree with this being called in StringBuffer/Builder then we don't need the change to AbstractStringBuild() constuctor, however Ivan wants getCharSequenceCoder() that done as a separate "bug". So I think it comes down to do we do this as 2 "bugs" or 1 ? 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 From: Roger Riggs To: Andrew Leonard , Ivan Gerasimov Cc: core-libs-dev at openjdk.java.net Date: 26/03/2019 18:19 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified ------------------------------------------------------------------------ Hi Andrew, You are going to have to change the same code twice because the changes should be the StringBuffer and StringBuilder constructors and would remove the code that is added to the AbstractStringBuilder constructor. That's a waste of review cycles. On 03/26/2019 11:45 AM, Andrew Leonard wrote: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, _ http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ Ivan's view is that behaviour was an extended issue, which it is, but I thought it was nice to add.. Which patch do we favour? webrev-01 or -02 ? Neither, there should be no change to the AbstractStringBuilder constructor and the change should be done in the subclass constructors. Roger 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_ From: Roger Riggs __ To: _core-libs-dev at openjdk.java.net_ Date: 26/03/2019 15:24 Subject: Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Sent by: "core-libs-dev" __ ------------------------------------------------------------------------ Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) constructors. It would be symmetric with the getCoder() method (line 1635) and select the appropriate coder base on the input value (if known.) Thanks, Roger On 03/26/2019 10:57 AM, Andrew Leonard wrote: > Hi Ivan, > Yes, i'm happy with that, as you say the simple constructor change fixes > the immediate issue, but not necessarily the extended issue of a > non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably > an enhanced issue to cover in a separate bug... > I've created a new webrev.02 with just the constructor change and the > testcase: > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/_ > > 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_ > > > > > From: Ivan Gerasimov __ > To: Andrew Leonard __ > Cc: _core-libs-dev at openjdk.java.net_ > Date: 26/03/2019 01:18 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Thanks Andrew! > Introducing getCharSequenceCoder() is actually an enhancement, which may > improve pre-allocation in certain cases. > It's not actually required to restore correctness of StringBuilder/Buffer > constructors. > I recommend to separate it from this bug fix, so it can be discussed > separately, and determined if this is the best approach to this > enhancement. > If you agree, I can adjust your latest patch accordingly, run it through > the Mach5 test systems and push it on your behalf. > With kind regards, > Ivan > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > Hi Ivan, > Here is my updated webrev: > _http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/_ > > 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_ > > > > > From: Ivan Gerasimov __ > To: Andrew Leonard __ > Cc: _core-libs-dev at openjdk.java.net_ > Date: 25/03/2019 22:55 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > I was thinking of organizing code similar to what is done in > AbstractStringBuilder(int): > > if (COMPACT_STRINGS && coderHint == LATIN1) { > value = new byte[capacity]; > coder = LATIN1; > } else { > value = StringUTF16.newBytesFor(capacity); > coder = UTF16; > } > > With kind regards, > Ivan > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > Hi Ivan, > I think I see what you're saying, you mean we also need to correct this > line in AbstractStringBuilder > constructor: > value = (coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > to be maybe: > value = (COMPACT_STRINGS && coder == LATIN1) > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > The passed in coder stills need to be correct, since with COMPACT_STRINGS > a string could be UTF16 if > it cannot be compacted, so it's more than just a hint isn't it? > > 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_ > > > > > From: Ivan Gerasimov __ > To: Andrew Leonard __ , > _core-libs-dev at openjdk.java.net_ > Date: 25/03/2019 22:20 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings > specified > > > > Hi Andrew! > > Thanks for finding this bug! > > Your fix solves the problem. > > However, I think the main issue is that the constructor > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, > it allows to create a string buffer with the coder LATIN1 when > COMPACT_STRINGS is false. > > Wouldn't it make sense to rename the argument of the constructor to, > say, coderHint, and then either use it as the coder if > COMPACT_STRINGS==true, or discard it otherwise. > > What do you think? > > With kind regards, > Ivan > > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> Patch with jtreg testcase here: >> _http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/_ >> >> bug: _https://bugs.openjdk.java.net/browse/JDK-8221430_ >> >> Many 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 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 Thu Mar 28 16:23:29 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 Mar 2019 17:23:29 +0100 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <4d49f85d-ad49-b37c-0e00-39247d32fe09@gmail.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> <9ec267f2-6d82-8cd7-a818-fa5696f599fb@oracle.com> <4d49f85d-ad49-b37c-0e00-39247d32fe09@gmail.com> Message-ID: <69304297-712e-9cb2-b25b-fd6404ba0c99@gmail.com> On 3/28/19 4:46 PM, Peter Levart wrote: > Reflection.verifyMemberAccess() is called not only from > AccessibleObject.slowVerifyAccess() but from elsewhere too. > > For example, from ReflectUtil.ensureMemberAccess which is used in @CS > AtomicXxxFieldUpdater(s), or from @CS java.util.ServiceLoader.load... Well, it seems that it is not so easy. Those two usages need caller for other purposes too. So they couldn't function without caller even if the access check was granted... Regards, Peter From aph at redhat.com Thu Mar 28 16:23:07 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Mar 2019 16:23:07 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> Message-ID: <1c95a02c-2660-097a-4e98-3f6d674f7a34@redhat.com> On 3/28/19 3:22 PM, Thomas St?fe wrote: > On Thu, Mar 28, 2019 at 3:41 PM Andrew Dinn wrote: > >> s/iff/if >> The second of those was actually intended to be iff. This is a common >> abbreviation used by English/US mathematicians and logicians to write >> 'if and only if' (it is also sometimes written as <=>). Since you didn't >> recognize it I guess I really need to write it out in full. > > Oh, don't worry on my account. I am not a native speaker nor a > mathematician. You could leave iff and add [sic] to make everyone curious > and start googling "iff" :) Dijkstra: The notation iff is used for "if and only if". A few years ago, while lecturing in Denmark, I used Fif instead, reasoning that since "if and only if" was a symmetric concept its notation should be symmetric also. Without knowing it, I had punned in Danish and the audience laughed, for fif in Danish means "a little trick". I resolved thereafter to use fif so I could tell my joke, but my colleagues talked me out of it. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 28 16:26:04 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Mar 2019 16:26:04 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <1c95a02c-2660-097a-4e98-3f6d674f7a34@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <1c95a02c-2660-097a-4e98-3f6d674f7a34@redhat.com> Message-ID: <708cf75c-5e0c-13da-b6b3-c252bda8579a@redhat.com> On 3/28/19 4:23 PM, Andrew Haley wrote: > Dijkstra: > > The notation iff is used for "if and only if". A few years ago, > while lecturing in Denmark, I used Fif instead, reasoning that since > "if and only if" was a symmetric concept its notation should be > symmetric also. Without knowing it, I had punned in Danish and the > audience laughed, for fif in Danish means "a little trick". I > resolved thereafter to use fif so I could tell my joke, but my > colleagues talked me out of it. Arggh! Sorry, that was Gries, not Dijkstra. I misremembered. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mandy.chung at oracle.com Thu Mar 28 16:25:25 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2019 09:25:25 -0700 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <4d49f85d-ad49-b37c-0e00-39247d32fe09@gmail.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> <9ec267f2-6d82-8cd7-a818-fa5696f599fb@oracle.com> <4d49f85d-ad49-b37c-0e00-39247d32fe09@gmail.com> Message-ID: <973d641b-7f89-65c2-9890-241410041c1f@oracle.com> On 3/28/19 8:46 AM, Peter Levart wrote: > > > On 3/28/19 4:08 PM, Alan Bateman wrote: >> On 28/03/2019 14:48, Peter Levart wrote: >>> : >>> >>> In addition, if access from null caller is granted and it is >>> performed to a member in a "concealed" package, there's no warning >>> displayed >> The proposed check is that the package is exported unconditionally so >> it will fail, no warning needed. I think that is okay. I could >> imagine someone trying to argue that they run with `--add-exports >> java.base/=ALL-UNNAMED` and they expect their JNI >> code to be able to reflect on the public members of public classes in >> that package but it hardly seems wroth it as JNI doesn't do access >> checks so it's pointless writing JNI code to use reflection. > > Right, and it would require deep changes to > AccessibleObject#logIfExportedForIllegalAccess too, since it assumes > the presence of non-null caller... > Yes it assumes the non-null caller in the current implementation. There are several options addressing this.? I would prefer to throw IllegalCallerException if AccessibleObject::setAccessible or trySetAccessible is called from null caller but this needs to have a careful investigation. ? As Alan mentions, we should also do an audit on all @CS methods and handles them. My intent is to keep JDK-8221530 to fix the regression w.r.t. existing member access check.? I realized the synopsis implies a bigger scope on other @CS methods.?? So I have considered other @CS methods besides reflective member access check is a separate issue. > Nevertheless the access checking logic could be encapsulated entirely > in the Reflection class (for null caller too) and then in > AccessibleObject, the logIfExportedForIllegalAccess call just skipped > for null caller... Else the logic is scattered between two classes and > would have to be repeated for other similar cases. > > Reflection.verifyMemberAccess() is called not only from > AccessibleObject.slowVerifyAccess() but from elsewhere too. > As you see from the webrev, Reflection.verifyMemberAccess requires Objects.requiresNonNull(currentClass) and Objects.requiresNonNull(memberClass). If caller is null, it should not call Reflection.verifyMemberAccess since the caller does not necessarily allow publicly accessible member and NPE forces the author to think through it.? If needed later, we > For example, from ReflectUtil.ensureMemberAccess which is used in @CS > AtomicXxxFieldUpdater(s), or from @CS java.util.ServiceLoader.load... > ServiceLoader does not support null caller. > By encapsulating it in the common Reflection.verifyMemberAccess() > method, all those usages get handled at the same time. > The API calling Reflection.verifyMemberAccess() should clearly decide what behavior it wants when there is no caller.? Maybe the same behavior as Field::get or maybe not. Mandy From mandy.chung at oracle.com Thu Mar 28 16:28:04 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2019 09:28:04 -0700 Subject: RFR: 8216539: tools/jar/modularJar/Basic.java timed out In-Reply-To: <7f1868aa-0f12-52d9-49fd-2d4236205c2a@oracle.com> References: <238DBE20-3974-4900-81BB-1AE8A4E3021B@oracle.com> <554f9e31-e9bc-7a26-ad17-ccb3df910983@oracle.com> <2084129B-A859-44C6-BBC4-7C8DD9EB7C81@oracle.com> <832172a3-28e7-40ee-79d4-aa63be7b94ae@oracle.com> <7f1868aa-0f12-52d9-49fd-2d4236205c2a@oracle.com> Message-ID: <45b124a6-ff2d-9f01-eb43-4fb0a8c9618c@oracle.com> On 3/28/19 12:19 AM, Alan Bateman wrote: > On 28/03/2019 00:23, Mandy Chung wrote: >> >> >> On 3/27/19 4:56 PM, Lance Andersen wrote: >>> Hi Mandy, >>> >>> >>>> On Mar 27, 2019, at 7:23 PM, Mandy Chung >>> > wrote: >>>> >>>> Hi Lance, >>>> >>>> Do you understand what takes so long for this test to run? >>> >>> Well it is executing a lot of jar commands. ?I did not see anything >>> that sticks out in the failed logs that point to anything obvious. >> >> One thing you could do is to instrument the test to gather the timing >> statistics. > This test runs the jar command at least 50 times and I/O tends to be > slower on Windows. Lance can use the test infrastructure to run it > many times and gather timings from a range of Windows hosts to get an > idea on how long it takes. I can well believe that it's close to the > timeout on some systems so increasing the timeout should help. As > regards gathering stats then it is a TestNG test with ~25 tests so we > could use @Before/@AfterMethod to get data if needed. It will clutter > the output but okay although trying to see what the timeout this test > needs. I am okay if this test is divided into multiple tests or multiple @runs if appropriate.? That's another approach to fix it. Mandy From Roger.Riggs at oracle.com Thu Mar 28 16:41:21 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 28 Mar 2019 12:41:21 -0400 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle Message-ID: Hi Andrew, I'm fine with Ivan's version too. Roger On 03/28/2019 12:13 PM, Andrew Leonard wrote: > Roger, Ivan, thanks for your help discussing this issue. Fyi, I am off > on leave for the next week, so I +1 Ivan's last webrev if that's the > way you decide to go.. > 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 > > > > > From: Roger Riggs > To: Ivan Gerasimov , Andrew Leonard > > Cc: core-libs-dev at openjdk.java.net > Date: 27/03/2019 13:39 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi Ivan, > > On 03/26/2019 07:30 PM, Ivan Gerasimov wrote: > The main source of confusion here seems to be due to that the coder is > passed in as an argument, so it either needs to be trusted or has to > be verified in the constructor. > > The design for coder is that it *is* trusted in all > internal/implementation APIs. > Subsequent changes should not weaken this invariant, it will cause doubt > in the code and cast doubt on all of the performance work that has > been done to optimize its use. > > So, let's instead introduce AbstractStringBuilder(CharSequence) and > make it do all manipulations. > _ > __http://cr.openjdk.java.net/~igerasim/8221430/01/webrev/_ > > > Note that the common case of StringBuilder(String) already gets > intrinsified by hotspot. > > What do you think? > > This looks good, the logic is in one place. > > Since StringBuilder(String) is an intrinsic, my doubt about a slight > performance > impact is unwarranted in that specific case. > > Are there any StringBuffer/Builder jmh tests than be easily rerun to > compare? > > Thanks, Roger > > > With kind regards, > Ivan > > On 3/26/19 1:04 PM, Ivan Gerasimov wrote: > From the design point of view, I believe it is better to have the > constructor AbstractStringBuilder(int, int, int) to check if the coder > argument makes sense with respect to the value of COMPACT_STRING, so > it won't be possible to create a StringBuilder with the coder==LATIN1, > when it is not supported. > > For calculating the coderHint then, it is not necessary to check > COMPACT_STRING: If the CharSequence argument is in fact String or > AbstractStringBuilder, the coder is known, otherwise LATIN1 can be > passed in as a hint (for an arbitrary CharSequence it is not 100% > accurate anyway). > The constructor AbstractStringBuilder(int, int, int) will then either > use the provided coder, or adjust it if necessary. > > Will we agree on something like following? > _ > __http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/_ > > > With kind regards, > > Ivan > > > On 3/26/19 12:14 PM, Roger Riggs wrote: > Hi, > > We've got the subject open and its fresh, there's no need for a > separate review cycle. > > The first fix (-01) does not seem to be consistent with the original > design > and handling of the coder.? The StringBuilder(String) and > StringBuffer(String) > constructors are the pattern that should be followed for determining > the coder for the new instance. > > Checking for COMPACT_STRING in two places (the AbstractStringBuilder and > the sub classes) is unnecessary and distributes the information about the > correct coder across two classes where determining what it should be > in the subclass has more complete? information and can correctly > determine > the coder once. > > We can likely find a reviewer to be a tie-breaker if Ivan sees it as > desirable. > > Thanks, Roger > > > On 03/26/2019 02:38 PM, Andrew Leonard wrote: > Sorry chaps, I think my brain is getting confused!, I think we have > conflicting reviews here? > > Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so > it was only defined in one place.. > I agree with this being called in StringBuffer/Builder then we don't > need the change to AbstractStringBuild() constuctor, however Ivan > wants getCharSequenceCoder() that done as a separate "bug". > > So I think it comes down to do we do this as 2 "bugs" or 1 ? > > 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_ > > > > > > From: Roger Riggs __ > > To: Andrew Leonard __ > , Ivan Gerasimov > __ > Cc: _core-libs-dev at openjdk.java.net_ > > Date: 26/03/2019 18:19 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > ------------------------------------------------------------------------ > > > > Hi Andrew, > > You are going to have to change the same code twice > because the changes should be the StringBuffer and StringBuilder > constructors and would remove the code that is added to > the AbstractStringBuilder constructor.? That's a waste of review cycles. > > > On 03/26/2019 11:45 AM, Andrew Leonard wrote: > Hi Roger, > No worries, the more the merrier! > So that was one of my reasoning for adding getCharSequenceCode() was, > I think what you're suggesting is my webrev.01, > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/__ > __ > > Ivan's view is that behaviour was an extended issue, which it is, but > I thought it was nice to add.. > > Which patch do we favour? webrev-01 or -02 ? > > Neither, there should be no change to the AbstractStringBuilder > constructor > and the change should be done in the subclass constructors. > > Roger > > > 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_ > __ > > > > > > From: Roger Riggs ___ > _ __ > > To: _core-libs-dev at openjdk.java.net_ > __ > > Date: 26/03/2019 15:24 > Subject: Re: Request for sponsor: JDK-8221430: > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings specified > Sent by: "core-libs-dev" ___ > _ > __ > > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Sorry to be late to the review. > > For symmetry with the constructors StringBuffer(String), and > StringBuilder(String) > the determine the coder based on the input argument, I would recommend > using the getCharSequenceCoder added in the -01 webrev and calling > it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) > constructors. > > It would be symmetric with the getCoder() method (line 1635) > and select the appropriate coder base on the input value (if known.) > > Thanks, Roger > > > > On 03/26/2019 10:57 AM, Andrew Leonard wrote: > > Hi Ivan, > > Yes, i'm happy with that, as you say the simple constructor change > fixes > > the immediate issue, but not necessarily the extended issue of a > > non-compactable CharSequence in COMPACT_STRINGS mode, but that's > probably > > an enhanced issue to cover in a separate bug... > > I've created a new webrev.02 with just the constructor change and the > > testcase: > > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/__ > __ > > > > > 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_ > __ > > > > > > > > > > > From:?? Ivan Gerasimov ___ > _ > __ > > To:???? Andrew Leonard ___ > _ > __ > > > Cc: _core-libs-dev at openjdk.java.net_ > __ > > > Date:?? 26/03/2019 01:18 > > Subject:??????? Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Thanks Andrew! > > Introducing getCharSequenceCoder() is actually an enhancement, which > may > > improve pre-allocation in certain cases. > > It's not actually required to restore correctness of > StringBuilder/Buffer > > constructors. > > I recommend to separate it from this bug fix, so it can be discussed > > separately, and determined if this is the best approach to this > > enhancement. > > If you agree, I can adjust your latest patch accordingly, run it > through > > the Mach5 test systems and push it on your behalf. > > With kind regards, > > Ivan > > > > On 3/25/19 5:00 PM, Andrew Leonard wrote: > > Hi Ivan, > > Here is my updated webrev: > > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/__ > __ > > > > > 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_ > __ > > > > > > > > > > > From:??????? Ivan Gerasimov ___ > _ > __ > > To:??????? Andrew Leonard ___ > _ > __ > > > Cc: _core-libs-dev at openjdk.java.net_ > __ > > > Date:??????? 25/03/2019 22:55 > > Subject:??????? Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > I was thinking of organizing code similar to what is done in > > AbstractStringBuilder(int): > > > > if (COMPACT_STRINGS && coderHint == LATIN1) { > >????? value = new byte[capacity]; > >????? coder = LATIN1; > > } else { > >????? value = StringUTF16.newBytesFor(capacity); > >????? coder = UTF16; > > } > > > > With kind regards, > > Ivan > > > > On 3/25/19 3:45 PM, Andrew Leonard wrote: > > Hi Ivan, > > I think I see what you're saying, you mean we also need to correct this > > line in AbstractStringBuilder > > constructor: > > value = (coder == LATIN1) > > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > to be maybe: > > value = (COMPACT_STRINGS && coder == LATIN1) > > ? new byte[capacity] : StringUTF16.newBytesFor(capacity); > > > > The passed in coder stills need to be correct, since with > COMPACT_STRINGS > > a string could be UTF16 if > > it cannot be compacted, so it's more than just a hint isn't it? > > > > 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_ > __ > > > > > > > > > > > From:??????? Ivan Gerasimov ___ > _ > __ > > To:??????? Andrew Leonard ___ > _ > __ > , > > _core-libs-dev at openjdk.java.net_ > __ > > > Date:??????? 25/03/2019 22:20 > > Subject:??????? Re: Request for sponsor: JDK-8221430: > > StringBuffer(CharSequence) constructor truncates when > -XX:-CompactStrings > > specified > > > > > > > > Hi Andrew! > > > > Thanks for finding this bug! > > > > Your fix solves the problem. > > > > However, I think the main issue is that the constructor > > AbstractStringBuilder(byte,int,int) is now broken:? as you discovered, > > it allows to create a string buffer with the coder LATIN1 when > > COMPACT_STRINGS is false. > > > > Wouldn't it make sense to rename the argument of the constructor to, > > say, coderHint, and then either use it as the coder if > > COMPACT_STRINGS==true, or discard it otherwise. > > > > What do you think? > > > > With kind regards, > > Ivan > > > > On 3/25/19 12:45 PM, Andrew Leonard wrote: > >> Hi, > >> Please can I request a sponsor for this fix to a JDK-13 regression? > >> > >> Patch with jtreg testcase here: > >> __http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/__ > __ > > >> > >> bug: __https://bugs.openjdk.java.net/browse/JDK-8221430__ > >> > >> Many 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 > > > > 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 Thu Mar 28 16:43:18 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2019 09:43:18 -0700 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> Message-ID: <0d2dff53-84dc-1dc9-187a-ee6b5f7f6a23@oracle.com> On 3/28/19 7:48 AM, Peter Levart wrote: > Hi, > > On 3/28/19 9:40 AM, Alan Bateman wrote: >> On 27/03/2019 23:17, Mandy Chung wrote: >>> : >>> >>> The proposed fix is to perform proper access check.? When there is no >>> caller frame, it only allows to access to public members of a public >>> type >>> in an unconditional exported API package. >>> >> The approach seems reasonable to me and we should, at some point, try >> to align the other @CS methods with this behavior. As Mandy knows, >> this is unspecified behavior and we aren't consistent in the JDK on >> how to handle "no caller frame" case. Some @CS methods will throw NPE >> if invoked directly, others detect the caller is null and throw or >> treat it as Object.class. >> >> In the patch, shouldn't slowVerifyAccess check that memberClass is >> public? > > I think it should. If we pretend that the check should be equivalent > as if performed from an unrelated class in an unrelated module, then > the check for public member class should be included. > > In addition, if access from null caller is granted and it is performed > to a member in a "concealed" package, there's no warning displayed > (the further logic in the AccessibleObject is skipped). > > What would it look like if AccessibleObject was left intact and only > Reflection was modified to accommodate for null currentClass - > caller/accessor. Like the in the following patch: > I intentionally do not change Reflection::verifyMemberAccess to accept null caller and see the patch: 125 Objects.requireNonNull(currentClass); 126 Objects.requireNonNull(memberClass); Although it is a reasonable default for a null caller to allow access public member in a public type of an unconditional exported API package, the caller should carefully consider how it behaves in this edge case.??? This forces the caller to address it properly rather than falling through.? I'm okay to add a new Reflection::verifyPublicMemberAccess which can be called by other if appropriate. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.01 Mandy From adinn at redhat.com Thu Mar 28 16:56:06 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Mar 2019 16:56:06 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> Message-ID: <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> On 28/03/2019 15:22, Thomas St?fe wrote: > The second of those was actually intended to be iff. This is a common > abbreviation used by English/US mathematicians and logicians to write > 'if and only if' (it is also sometimes written as <=>). Since you didn't > recognize it I guess I really need to write it out in full. > > > Oh, don't worry on my account. I am not a native speaker nor a > mathematician. You could leave iff and add [sic] to make everyone > curious and start googling "iff" :) I changed it nevertheless. It would be remiss to presume readers need be conversant with elliptical, English logico-mathematical parlance (I'm explaining this in as plain English as I can ... no, wait! ;-). Anyway, I addressed this and your other concerns in a new webrev. JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.02 Input from a second reviewer would be welcome ... 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 semyon.sadetsky at oracle.com Thu Mar 28 17:00:51 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Thu, 28 Mar 2019 10:00:51 -0700 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: <3c8f95b3-847e-f566-d208-fe1cd4b60649@oracle.com> References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> <3c8f95b3-847e-f566-d208-fe1cd4b60649@oracle.com> Message-ID: It looks like one was missed: src/demo/share/jpackage/JNLPConverter/src/jnlp/converter/JNLPConverter.java 609 launchArgs.add("--jvm-args"); --Semyon On 3/28/19 8:59 AM, Victor D'yakov wrote: > > Alexander, Semyon, please review. > > Victor > > > > -------- Forwarded Message -------- > Subject: RFR: JDK-8221582: Rename jvm-args option to java-options > Date: Thu, 28 Mar 2019 07:07:44 -0400 > From: Andy Herrick > Organization: Oracle Corporation > To: core-libs-dev > > > > RFR: JDK-8221582: Rename jvm-args option to java-options > > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 > > [2] - http://cr.openjdk.java.net/~herrick/8221582/ > > /Andy From thomas.stuefe at gmail.com Thu Mar 28 17:09:22 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 18:09:22 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> Message-ID: On Thu, Mar 28, 2019 at 5:56 PM Andrew Dinn wrote: > On 28/03/2019 15:22, Thomas St?fe wrote: > > The second of those was actually intended to be iff. This is a common > > abbreviation used by English/US mathematicians and logicians to write > > 'if and only if' (it is also sometimes written as <=>). Since you > didn't > > recognize it I guess I really need to write it out in full. > > > > > > Oh, don't worry on my account. I am not a native speaker nor a > > mathematician. You could leave iff and add [sic] to make everyone > > curious and start googling "iff" :) > I changed it nevertheless. It would be remiss to presume readers need be > conversant with elliptical, English logico-mathematical parlance (I'm > explaining this in as plain English as I can ... no, wait! ;-). > > Anyway, I addressed this and your other concerns in a new webrev. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.02 > > src/hotspot/share/classfile/javaClasses.cpp Pure nitpicking, but you could remove the member variables too and just set the Unsafe members directly, e.g.: if (fd->name() == vmSymbols::address_size_name()) { mirror->int_field_put(fd->offset(), (jint)sizeof(void*)); } else if (fd->name() == vmSymbols::page_size_name()) { mirror->int_field_put(fd->offset(), (jint) os::vm_page_size()); .. and so on. But I leave this up to you. This is already better than before. + }else { space missing before else -- src/hotspot/share/classfile/vmSymbols.hpp "UNALIGNED_ACCESS" off by one space --- src/java.base/share/classes/java/nio/channels/FileChannel.java This may have creeped in from another change. --- Good otherwise. Cheers, Thomas > Input from a second reviewer would be welcome ... > > 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 kevin.rushforth at oracle.com Thu Mar 28 17:11:49 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 28 Mar 2019 10:11:49 -0700 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> <3c8f95b3-847e-f566-d208-fe1cd4b60649@oracle.com> Message-ID: <85d38106-0138-5343-4d20-a6e7f62ce983@oracle.com> Other than that one, the rest looks good to me. I also tested it and it works as expected. +1 (pending the change Semyon noted) -- Kevin On 3/28/2019 10:00 AM, semyon.sadetsky at oracle.com wrote: > It looks like one was missed: > > src/demo/share/jpackage/JNLPConverter/src/jnlp/converter/JNLPConverter.java > > > > 609??????? launchArgs.add("--jvm-args"); > > --Semyon > > On 3/28/19 8:59 AM, Victor D'yakov wrote: >> >> Alexander, Semyon, please review. >> >> Victor >> >> >> >> -------- Forwarded Message -------- >> Subject:???? RFR: JDK-8221582: Rename jvm-args option to java-options >> Date:???? Thu, 28 Mar 2019 07:07:44 -0400 >> From:???? Andy Herrick >> Organization:???? Oracle Corporation >> To:???? core-libs-dev >> >> >> >> RFR: JDK-8221582: Rename jvm-args option to java-options >> >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 >> >> [2] - http://cr.openjdk.java.net/~herrick/8221582/ >> >> /Andy > From mandy.chung at oracle.com Thu Mar 28 17:27:58 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2019 10:27:58 -0700 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> Message-ID: <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> On 3/27/19 7:18 AM, Lindenmaier, Goetz wrote: >> , is this example very clear to them that it won't be supported? > > You probably meant that for > n().getNull().m() > it is not printed that getNull() was called on the result of n()? Yes, I caught my error after I sent my example. > This is a design decision not to make the printout too complex. > This is fine.?? The JEP should call this out. > > The algorithm looks at a lot of bytecodes to print the method. I can not > enumerate all combinations of bytecodes, it's millions. I will add a per-bytecode table to > the "Message content" section describing what is printed for which bytecode. This is not what I am suggesting to do. The JEP can describe the known cases or pattern (if enumerating these cases is not possible) to help the readers understand the proposed feature and what is not covered. > This paragraph lists a possible problem -- multiple variants of methods > with the same name and class name -- and how this is solved. > I added a section "Cases not covered by this JEP" and mention it there, too. Sounds good. >> Since the JEP quotes that NullPointerExceptions are thrown frequently >> and swallowed, it would help if you can generate some numbers. >> This JEP will help the discussion on the proposed feature and design and avoid >> any >> confusion/assumption of the implementation. > I'll generate some numbers. Is running jvm2008 fine? A benchmark may not be a good representative.? I'd be interested in a real application to support the claim. OTOH, we are in agreement that this change should not incur any significant overhead to the construction cost of throwable.? I asked the data because of the claim of many NPE thrown get swallowed. Mandy From alexey.semenyuk at oracle.com Thu Mar 28 17:50:33 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 28 Mar 2019 13:50:33 -0400 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> Message-ID: Andy, IMHO if you are renaming defines in C++ code, it makes sense to rename variables/functions too: JVMArgs -> JavaArgs in http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html Package::ReadJVMArgs -> Package::ReadJavaArgs in http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html In general it would make sense to rename JVMArgs in JavaArgs: --- ASEMENYU-LAP+asemenyu at ASEMENYU-LAP /cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage $ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs ./share/native/libapplauncher/Helpers.cpp: Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) { ./share/native/libapplauncher/Helpers.cpp: OrderedMap JVMArgs = ./share/native/libapplauncher/Helpers.cpp: Helpers::GetJVMArgsFromConfig(&propertyFile); ./share/native/libapplauncher/Helpers.cpp: Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs); ./share/native/libapplauncher/Helpers.h: GetJVMArgsFromConfig(IPropertyContainer* config); ./share/native/libapplauncher/JavaVirtualMachine.cpp: options.AppendValues(package.GetJVMArgs()); ./share/native/libapplauncher/Package.cpp:??? ReadJVMArgs(config); ./share/native/libapplauncher/Package.cpp:void Package::ReadJVMArgs(ISectionalPropertyContainer* Config) { ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); ./share/native/libapplauncher/Package.cpp:OrderedMap Package::GetJVMArgs() { ./share/native/libapplauncher/Package.cpp:??? return FBootFields->FJVMArgs; ./share/native/libapplauncher/Package.h:??? OrderedMap FJVMArgs; ./share/native/libapplauncher/Package.h:??? void ReadJVMArgs(ISectionalPropertyContainer* Config); ./share/native/libapplauncher/Package.h:??? OrderedMap GetJVMArgs(); --- - Alexey On 3/28/2019 7:07 AM, Andy Herrick wrote: > RFR: JDK-8221582: Rename jvm-args option to java-options > > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 > > [2] - http://cr.openjdk.java.net/~herrick/8221582/ > > /Andy From kevin.rushforth at oracle.com Thu Mar 28 17:54:02 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 28 Mar 2019 10:54:02 -0700 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> Message-ID: <4235996a-41a7-cacc-a72d-b73eed4cf5a0@oracle.com> That seems like a good cleanup. It could be done in a follow-on bug depending on what Andy wants to do. -- Kevin On 3/28/2019 10:50 AM, Alexey Semenyuk wrote: > Andy, > > IMHO if you are renaming defines in C++ code, it makes sense to rename > variables/functions too: > JVMArgs -> JavaArgs in > http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html > Package::ReadJVMArgs -> Package::ReadJavaArgs in > http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html > > In general it would make sense to rename JVMArgs in JavaArgs: > --- > ASEMENYU-LAP+asemenyu at ASEMENYU-LAP > /cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage > $ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs > ./share/native/libapplauncher/Helpers.cpp: > Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) { > ./share/native/libapplauncher/Helpers.cpp: OrderedMap TString> JVMArgs = > ./share/native/libapplauncher/Helpers.cpp: > Helpers::GetJVMArgsFromConfig(&propertyFile); > ./share/native/libapplauncher/Helpers.cpp: > Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs); > ./share/native/libapplauncher/Helpers.h: > GetJVMArgsFromConfig(IPropertyContainer* config); > ./share/native/libapplauncher/JavaVirtualMachine.cpp: > options.AppendValues(package.GetJVMArgs()); > ./share/native/libapplauncher/Package.cpp:??? ReadJVMArgs(config); > ./share/native/libapplauncher/Package.cpp:void > Package::ReadJVMArgs(ISectionalPropertyContainer* Config) { > ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); > ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); > ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); > ./share/native/libapplauncher/Package.cpp:OrderedMap > Package::GetJVMArgs() { > ./share/native/libapplauncher/Package.cpp:??? return > FBootFields->FJVMArgs; > ./share/native/libapplauncher/Package.h:??? OrderedMap TString> FJVMArgs; > ./share/native/libapplauncher/Package.h:??? void > ReadJVMArgs(ISectionalPropertyContainer* Config); > ./share/native/libapplauncher/Package.h:??? OrderedMap TString> GetJVMArgs(); > --- > > - Alexey > > On 3/28/2019 7:07 AM, Andy Herrick wrote: >> RFR: JDK-8221582: Rename jvm-args option to java-options >> >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 >> >> [2] - http://cr.openjdk.java.net/~herrick/8221582/ >> >> /Andy > From andy.herrick at oracle.com Thu Mar 28 18:01:35 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 28 Mar 2019 14:01:35 -0400 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: <4235996a-41a7-cacc-a72d-b73eed4cf5a0@oracle.com> References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> <4235996a-41a7-cacc-a72d-b73eed4cf5a0@oracle.com> Message-ID: On 3/28/2019 1:54 PM, Kevin Rushforth wrote: > That seems like a good cleanup. It could be done in a follow-on bug > depending on what Andy wants to do. > Yes - I think we should file this as a follow on fix. My main concern first was the public facing names, but as with other modified options, it would be best to go back and clean all internal names to reflect the current naming. /Andy > -- Kevin > > > On 3/28/2019 10:50 AM, Alexey Semenyuk wrote: >> Andy, >> >> IMHO if you are renaming defines in C++ code, it makes sense to >> rename variables/functions too: >> JVMArgs -> JavaArgs in >> http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html >> Package::ReadJVMArgs -> Package::ReadJavaArgs in >> http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html >> >> In general it would make sense to rename JVMArgs in JavaArgs: >> --- >> ASEMENYU-LAP+asemenyu at ASEMENYU-LAP >> /cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage >> $ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs >> ./share/native/libapplauncher/Helpers.cpp: >> Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) { >> ./share/native/libapplauncher/Helpers.cpp: OrderedMap> TString> JVMArgs = >> ./share/native/libapplauncher/Helpers.cpp: >> Helpers::GetJVMArgsFromConfig(&propertyFile); >> ./share/native/libapplauncher/Helpers.cpp: >> Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs); >> ./share/native/libapplauncher/Helpers.h: >> GetJVMArgsFromConfig(IPropertyContainer* config); >> ./share/native/libapplauncher/JavaVirtualMachine.cpp: >> options.AppendValues(package.GetJVMArgs()); >> ./share/native/libapplauncher/Package.cpp: ReadJVMArgs(config); >> ./share/native/libapplauncher/Package.cpp:void >> Package::ReadJVMArgs(ISectionalPropertyContainer* Config) { >> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >> ./share/native/libapplauncher/Package.cpp:OrderedMap> TString> Package::GetJVMArgs() { >> ./share/native/libapplauncher/Package.cpp:??? return >> FBootFields->FJVMArgs; >> ./share/native/libapplauncher/Package.h: OrderedMap >> FJVMArgs; >> ./share/native/libapplauncher/Package.h:??? void >> ReadJVMArgs(ISectionalPropertyContainer* Config); >> ./share/native/libapplauncher/Package.h: OrderedMap >> GetJVMArgs(); >> --- >> >> - Alexey >> >> On 3/28/2019 7:07 AM, Andy Herrick wrote: >>> RFR: JDK-8221582: Rename jvm-args option to java-options >>> >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 >>> >>> [2] - http://cr.openjdk.java.net/~herrick/8221582/ >>> >>> /Andy >> > From alexey.semenyuk at oracle.com Thu Mar 28 18:20:05 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 28 Mar 2019 14:20:05 -0400 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> <4235996a-41a7-cacc-a72d-b73eed4cf5a0@oracle.com> Message-ID: Agreed. Would you like me to create a record to track this follow up clean up? - Alexey On 3/28/2019 2:01 PM, Andy Herrick wrote: > > > On 3/28/2019 1:54 PM, Kevin Rushforth wrote: >> That seems like a good cleanup. It could be done in a follow-on bug >> depending on what Andy wants to do. >> > Yes - I think we should file this as a follow on fix. > My main concern first was the public facing names, but as with other > modified options, it would be best to go back and clean all internal > names to reflect the current naming. > > /Andy > >> -- Kevin >> >> >> On 3/28/2019 10:50 AM, Alexey Semenyuk wrote: >>> Andy, >>> >>> IMHO if you are renaming defines in C++ code, it makes sense to >>> rename variables/functions too: >>> JVMArgs -> JavaArgs in >>> http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html >>> Package::ReadJVMArgs -> Package::ReadJavaArgs in >>> http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html >>> >>> In general it would make sense to rename JVMArgs in JavaArgs: >>> --- >>> ASEMENYU-LAP+asemenyu at ASEMENYU-LAP >>> /cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage >>> $ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs >>> ./share/native/libapplauncher/Helpers.cpp: >>> Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) { >>> ./share/native/libapplauncher/Helpers.cpp: OrderedMap>> TString> JVMArgs = >>> ./share/native/libapplauncher/Helpers.cpp: >>> Helpers::GetJVMArgsFromConfig(&propertyFile); >>> ./share/native/libapplauncher/Helpers.cpp: >>> Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs); >>> ./share/native/libapplauncher/Helpers.h: >>> GetJVMArgsFromConfig(IPropertyContainer* config); >>> ./share/native/libapplauncher/JavaVirtualMachine.cpp: >>> options.AppendValues(package.GetJVMArgs()); >>> ./share/native/libapplauncher/Package.cpp: ReadJVMArgs(config); >>> ./share/native/libapplauncher/Package.cpp:void >>> Package::ReadJVMArgs(ISectionalPropertyContainer* Config) { >>> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >>> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >>> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >>> ./share/native/libapplauncher/Package.cpp:OrderedMap>> TString> Package::GetJVMArgs() { >>> ./share/native/libapplauncher/Package.cpp:??? return >>> FBootFields->FJVMArgs; >>> ./share/native/libapplauncher/Package.h: OrderedMap>> TString> FJVMArgs; >>> ./share/native/libapplauncher/Package.h:??? void >>> ReadJVMArgs(ISectionalPropertyContainer* Config); >>> ./share/native/libapplauncher/Package.h: OrderedMap>> TString> GetJVMArgs(); >>> --- >>> >>> - Alexey >>> >>> On 3/28/2019 7:07 AM, Andy Herrick wrote: >>>> RFR: JDK-8221582: Rename jvm-args option to java-options >>>> >>>> Please review the jpackage fix for bug [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 >>>> >>>> [2] - http://cr.openjdk.java.net/~herrick/8221582/ >>>> >>>> /Andy >>> >> > From Alan.Bateman at oracle.com Thu Mar 28 20:39:01 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 20:39:01 +0000 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <0d2dff53-84dc-1dc9-187a-ee6b5f7f6a23@oracle.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> <0d2dff53-84dc-1dc9-187a-ee6b5f7f6a23@oracle.com> Message-ID: <803b3611-9d67-7a59-548a-34d0e07b1295@oracle.com> On 28/03/2019 16:43, Mandy Chung wrote: > : > > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.01 > I think this looks okay. One minor nit is that newIllegalAccessException doesn't throw IAE. -Alan From alexander.matveev at oracle.com Thu Mar 28 21:26:24 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 28 Mar 2019 14:26:24 -0700 Subject: RFR: JDK-8221582: Rename jvm-args option to java-options In-Reply-To: References: <728d0990-d1f2-5da8-a342-ea1310af113c@oracle.com> <4235996a-41a7-cacc-a72d-b73eed4cf5a0@oracle.com> Message-ID: <49c824a4-e9e3-852a-f0db-6a826a18001e@oracle.com> Hi Andy, webrev.02 looks fine. Thanks, Alexander On 3/28/2019 11:20 AM, Alexey Semenyuk wrote: > Agreed. Would you like me to create a record to track this follow up > clean up? > > - Alexey > > On 3/28/2019 2:01 PM, Andy Herrick wrote: >> >> >> On 3/28/2019 1:54 PM, Kevin Rushforth wrote: >>> That seems like a good cleanup. It could be done in a follow-on bug >>> depending on what Andy wants to do. >>> >> Yes - I think we should file this as a follow on fix. >> My main concern first was the public facing names, but as with other >> modified options, it would be best to go back and clean all internal >> names to reflect the current naming. >> >> /Andy >> >>> -- Kevin >>> >>> >>> On 3/28/2019 10:50 AM, Alexey Semenyuk wrote: >>>> Andy, >>>> >>>> IMHO if you are renaming defines in C++ code, it makes sense to >>>> rename variables/functions too: >>>> JVMArgs -> JavaArgs in >>>> http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html >>>> Package::ReadJVMArgs -> Package::ReadJavaArgs in >>>> http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html >>>> >>>> In general it would make sense to rename JVMArgs in JavaArgs: >>>> --- >>>> ASEMENYU-LAP+asemenyu at ASEMENYU-LAP >>>> /cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage >>>> >>>> $ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs >>>> ./share/native/libapplauncher/Helpers.cpp: >>>> Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) { >>>> ./share/native/libapplauncher/Helpers.cpp: OrderedMap>>> TString> JVMArgs = >>>> ./share/native/libapplauncher/Helpers.cpp: >>>> Helpers::GetJVMArgsFromConfig(&propertyFile); >>>> ./share/native/libapplauncher/Helpers.cpp: >>>> Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs); >>>> ./share/native/libapplauncher/Helpers.h: >>>> GetJVMArgsFromConfig(IPropertyContainer* config); >>>> ./share/native/libapplauncher/JavaVirtualMachine.cpp: >>>> options.AppendValues(package.GetJVMArgs()); >>>> ./share/native/libapplauncher/Package.cpp: ReadJVMArgs(config); >>>> ./share/native/libapplauncher/Package.cpp:void >>>> Package::ReadJVMArgs(ISectionalPropertyContainer* Config) { >>>> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >>>> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >>>> ./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs); >>>> ./share/native/libapplauncher/Package.cpp:OrderedMap>>> TString> Package::GetJVMArgs() { >>>> ./share/native/libapplauncher/Package.cpp:??? return >>>> FBootFields->FJVMArgs; >>>> ./share/native/libapplauncher/Package.h: OrderedMap>>> TString> FJVMArgs; >>>> ./share/native/libapplauncher/Package.h:??? void >>>> ReadJVMArgs(ISectionalPropertyContainer* Config); >>>> ./share/native/libapplauncher/Package.h: OrderedMap>>> TString> GetJVMArgs(); >>>> --- >>>> >>>> - Alexey >>>> >>>> On 3/28/2019 7:07 AM, Andy Herrick wrote: >>>>> RFR: JDK-8221582: Rename jvm-args option to java-options >>>>> >>>>> Please review the jpackage fix for bug [1] at [2]. >>>>> >>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>> sandbox repository (jpackage). >>>>> >>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 >>>>> >>>>> [2] - http://cr.openjdk.java.net/~herrick/8221582/ >>>>> >>>>> /Andy >>>> >>> >> > From ivan.gerasimov at oracle.com Thu Mar 28 21:24:55 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 28 Mar 2019 14:24:55 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle Message-ID: Apologize for the delay, got distracted by other urgent things. I've got some surprising micro-benchmark results, and need to understand them before pushing the fix. I'll verify the results and then share details. With kind regards, Ivan On 3/28/19 9:41 AM, Roger Riggs wrote: > Hi Andrew, > > I'm fine with Ivan's version too. > > Roger > > > On 03/28/2019 12:13 PM, Andrew Leonard wrote: >> Roger, Ivan, thanks for your help discussing this issue. Fyi, I am >> off on leave for the next week, so I +1 Ivan's last webrev if that's >> the way you decide to go.. >> 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 >> >> >> >> >> From: Roger Riggs >> To: Ivan Gerasimov , Andrew Leonard >> >> Cc: core-libs-dev at openjdk.java.net >> Date: 27/03/2019 13:39 >> Subject: Re: Request for sponsor: JDK-8221430: >> StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings specified >> ------------------------------------------------------------------------ >> >> >> >> Hi Ivan, >> >> On 03/26/2019 07:30 PM, Ivan Gerasimov wrote: >> The main source of confusion here seems to be due to that the coder >> is passed in as an argument, so it either needs to be trusted or has >> to be verified in the constructor. >> >> The design for coder is that it *is* trusted in all >> internal/implementation APIs. >> Subsequent changes should not weaken this invariant, it will cause doubt >> in the code and cast doubt on all of the performance work that has >> been done to optimize its use. >> >> So, let's instead introduce AbstractStringBuilder(CharSequence) and >> make it do all manipulations. >> _ >> __http://cr.openjdk.java.net/~igerasim/8221430/01/webrev/_ >> >> >> Note that the common case of StringBuilder(String) already gets >> intrinsified by hotspot. >> >> What do you think? >> >> This looks good, the logic is in one place. >> >> Since StringBuilder(String) is an intrinsic, my doubt about a slight >> performance >> impact is unwarranted in that specific case. >> >> Are there any StringBuffer/Builder jmh tests than be easily rerun to >> compare? >> >> Thanks, Roger >> >> >> With kind regards, >> Ivan >> >> On 3/26/19 1:04 PM, Ivan Gerasimov wrote: >> From the design point of view, I believe it is better to have the >> constructor AbstractStringBuilder(int, int, int) to check if the >> coder argument makes sense with respect to the value of >> COMPACT_STRING, so it won't be possible to create a StringBuilder >> with the coder==LATIN1, when it is not supported. >> >> For calculating the coderHint then, it is not necessary to check >> COMPACT_STRING: If the CharSequence argument is in fact String or >> AbstractStringBuilder, the coder is known, otherwise LATIN1 can be >> passed in as a hint (for an arbitrary CharSequence it is not 100% >> accurate anyway). >> The constructor AbstractStringBuilder(int, int, int) will then either >> use the provided coder, or adjust it if necessary. >> >> Will we agree on something like following? >> _ >> __http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/_ >> >> >> With kind regards, >> >> Ivan >> >> >> On 3/26/19 12:14 PM, Roger Riggs wrote: >> Hi, >> >> We've got the subject open and its fresh, there's no need for a >> separate review cycle. >> >> The first fix (-01) does not seem to be consistent with the original >> design >> and handling of the coder. The StringBuilder(String) and >> StringBuffer(String) >> constructors are the pattern that should be followed for determining >> the coder for the new instance. >> >> Checking for COMPACT_STRING in two places (the AbstractStringBuilder and >> the sub classes) is unnecessary and distributes the information about >> the >> correct coder across two classes where determining what it should be >> in the subclass has more complete information and can correctly >> determine >> the coder once. >> >> We can likely find a reviewer to be a tie-breaker if Ivan sees it as >> desirable. >> >> Thanks, Roger >> >> >> On 03/26/2019 02:38 PM, Andrew Leonard wrote: >> Sorry chaps, I think my brain is getting confused!, I think we have >> conflicting reviews here? >> >> Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so >> it was only defined in one place.. >> I agree with this being called in StringBuffer/Builder then we don't >> need the change to AbstractStringBuild() constuctor, however Ivan >> wants getCharSequenceCoder() that done as a separate "bug". >> >> So I think it comes down to do we do this as 2 "bugs" or 1 ? >> >> 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_ >> >> >> >> >> >> From: Roger Riggs __ >> >> To: Andrew Leonard __ >> , Ivan Gerasimov >> __ >> Cc: _core-libs-dev at openjdk.java.net_ >> >> Date: 26/03/2019 18:19 >> Subject: Re: Request for sponsor: JDK-8221430: >> StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings specified >> ------------------------------------------------------------------------ >> >> >> >> Hi Andrew, >> >> You are going to have to change the same code twice >> because the changes should be the StringBuffer and StringBuilder >> constructors and would remove the code that is added to >> the AbstractStringBuilder constructor. That's a waste of review cycles. >> >> >> On 03/26/2019 11:45 AM, Andrew Leonard wrote: >> Hi Roger, >> No worries, the more the merrier! >> So that was one of my reasoning for adding getCharSequenceCode() was, >> I think what you're suggesting is my webrev.01, >> __http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/__ >> __ >> >> Ivan's view is that behaviour was an extended issue, which it is, but >> I thought it was nice to add.. >> >> Which patch do we favour? webrev-01 or -02 ? >> >> Neither, there should be no change to the AbstractStringBuilder >> constructor >> and the change should be done in the subclass constructors. >> >> Roger >> >> >> 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_ >> __ >> >> >> >> >> >> From: Roger Riggs ___ >> _ __ >> >> To: _core-libs-dev at openjdk.java.net_ >> __ >> >> Date: 26/03/2019 15:24 >> Subject: Re: Request for sponsor: JDK-8221430: >> StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings specified >> Sent by: "core-libs-dev" ___ >> _ >> __ >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Andrew, >> >> Sorry to be late to the review. >> >> For symmetry with the constructors StringBuffer(String), and >> StringBuilder(String) >> the determine the coder based on the input argument, I would recommend >> using the getCharSequenceCoder added in the -01 webrev and calling >> it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) >> constructors. >> >> It would be symmetric with the getCoder() method (line 1635) >> and select the appropriate coder base on the input value (if known.) >> >> Thanks, Roger >> >> >> >> On 03/26/2019 10:57 AM, Andrew Leonard wrote: >> > Hi Ivan, >> > Yes, i'm happy with that, as you say the simple constructor change >> fixes >> > the immediate issue, but not necessarily the extended issue of a >> > non-compactable CharSequence in COMPACT_STRINGS mode, but that's >> probably >> > an enhanced issue to cover in a separate bug... >> > I've created a new webrev.02 with just the constructor change and the >> > testcase: >> > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/__ >> __ >> >> > >> > 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_ >> __ >> >> > >> > >> > >> > >> > From: Ivan Gerasimov ___ >> _ >> __ >> > To: Andrew Leonard ___ >> _ >> __ >> >> > Cc: _core-libs-dev at openjdk.java.net_ >> __ >> >> > Date: 26/03/2019 01:18 >> > Subject: Re: Request for sponsor: JDK-8221430: >> > StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings >> > specified >> > >> > >> > >> > Thanks Andrew! >> > Introducing getCharSequenceCoder() is actually an enhancement, >> which may >> > improve pre-allocation in certain cases. >> > It's not actually required to restore correctness of >> StringBuilder/Buffer >> > constructors. >> > I recommend to separate it from this bug fix, so it can be discussed >> > separately, and determined if this is the best approach to this >> > enhancement. >> > If you agree, I can adjust your latest patch accordingly, run it >> through >> > the Mach5 test systems and push it on your behalf. >> > With kind regards, >> > Ivan >> > >> > On 3/25/19 5:00 PM, Andrew Leonard wrote: >> > Hi Ivan, >> > Here is my updated webrev: >> > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/__ >> __ >> >> > >> > 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_ >> __ >> >> > >> > >> > >> > >> > From: Ivan Gerasimov ___ >> _ >> __ >> > To: Andrew Leonard ___ >> _ >> __ >> >> > Cc: _core-libs-dev at openjdk.java.net_ >> __ >> >> > Date: 25/03/2019 22:55 >> > Subject: Re: Request for sponsor: JDK-8221430: >> > StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings >> > specified >> > >> > >> > >> > I was thinking of organizing code similar to what is done in >> > AbstractStringBuilder(int): >> > >> > if (COMPACT_STRINGS && coderHint == LATIN1) { >> > value = new byte[capacity]; >> > coder = LATIN1; >> > } else { >> > value = StringUTF16.newBytesFor(capacity); >> > coder = UTF16; >> > } >> > >> > With kind regards, >> > Ivan >> > >> > On 3/25/19 3:45 PM, Andrew Leonard wrote: >> > Hi Ivan, >> > I think I see what you're saying, you mean we also need to correct >> this >> > line in AbstractStringBuilder >> > constructor: >> > value = (coder == LATIN1) >> > ? new byte[capacity] : >> StringUTF16.newBytesFor(capacity); >> > to be maybe: >> > value = (COMPACT_STRINGS && coder == LATIN1) >> > ? new byte[capacity] : >> StringUTF16.newBytesFor(capacity); >> > >> > The passed in coder stills need to be correct, since with >> COMPACT_STRINGS >> > a string could be UTF16 if >> > it cannot be compacted, so it's more than just a hint isn't it? >> > >> > 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_ >> __ >> >> > >> > >> > >> > >> > From: Ivan Gerasimov ___ >> _ >> __ >> > To: Andrew Leonard ___ >> _ >> __ >> , >> > _core-libs-dev at openjdk.java.net_ >> __ >> >> > Date: 25/03/2019 22:20 >> > Subject: Re: Request for sponsor: JDK-8221430: >> > StringBuffer(CharSequence) constructor truncates when >> -XX:-CompactStrings >> > specified >> > >> > >> > >> > Hi Andrew! >> > >> > Thanks for finding this bug! >> > >> > Your fix solves the problem. >> > >> > However, I think the main issue is that the constructor >> > AbstractStringBuilder(byte,int,int) is now broken: as you discovered, >> > it allows to create a string buffer with the coder LATIN1 when >> > COMPACT_STRINGS is false. >> > >> > Wouldn't it make sense to rename the argument of the constructor to, >> > say, coderHint, and then either use it as the coder if >> > COMPACT_STRINGS==true, or discard it otherwise. >> > >> > What do you think? >> > >> > With kind regards, >> > Ivan >> > >> > On 3/25/19 12:45 PM, Andrew Leonard wrote: >> >> Hi, >> >> Please can I request a sponsor for this fix to a JDK-13 regression? >> >> >> >> Patch with jtreg testcase here: >> >> __http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/__ >> __ >> >> >> >> >> bug: __https://bugs.openjdk.java.net/browse/JDK-8221430__ >> >> >> >> Many 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 >> >> >> >> 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 > -- With kind regards, Ivan Gerasimov From huizhe.wang at oracle.com Thu Mar 28 21:47:33 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 28 Mar 2019 14:47:33 -0700 Subject: RFR (JDK 13) 8220254: fix headings in java.xml Message-ID: <5C9D40F5.6020006@oracle.com> Please review a patch for the wrong headings. This patch passed build with the new doclint enabled and doccheck (thanks Jon!) JBS: https://bugs.openjdk.java.net/browse/JDK-8220254 webrev: http://cr.openjdk.java.net/~joehw/jdk13/8220254/webrev/ Thanks, Joe From lance.andersen at oracle.com Thu Mar 28 22:14:42 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 28 Mar 2019 18:14:42 -0400 Subject: RFR (JDK 13) 8220254: fix headings in java.xml In-Reply-To: <5C9D40F5.6020006@oracle.com> References: <5C9D40F5.6020006@oracle.com> Message-ID: <00634D8C-E96A-450B-B637-E1A2F8797DDC@oracle.com> +1 > On Mar 28, 2019, at 5:47 PM, Joe Wang > wrote: > > Please review a patch for the wrong headings. This patch passed build with the new doclint enabled and doccheck (thanks Jon!) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220254 > > webrev: http://cr.openjdk.java.net/~joehw/jdk13/8220254/webrev/ > > Thanks, > Joe > 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 david.holmes at oracle.com Thu Mar 28 23:54:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Mar 2019 09:54:06 +1000 Subject: RFC: Make test failed because of the locale LANG In-Reply-To: References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn> <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com> Message-ID: On 29/03/2019 1:59 am, Naoto Sato wrote: > Hi, > > I don't think there is any *official* rule for the regression tests to > succeed in any locale, but if the test case is locale sensitive such as > in this case, I'd suggest it should correctly specify the locale > beforehand, or quit gracefully in general. > > For this specific case, I'd suggest not set the environment variable (as > it won't work with Windows), using runtime system properties > (user.language/user.country) would help. Which specific case are you referring to? :) Given there are well over a thousand failures in total I think we need to set a reasonable initial locale as part of the test setup. Many of the hotspot tests check actual and expected output and we, in general, have no idea what kinds of output may be subject to locale specific changes. Cheers, David > Naoto > > On 3/27/19 10:47 PM, David Holmes wrote: >> Hi Jing, >> >> On 28/03/2019 3:22 pm, Jing Tian wrote: >>> Hi, >>> >>> When I am doing the 'make test'.If the local LANG is set as >>> 'zh_CN.UTF-8', Test cases will have a lot of error messages. >>> >>> ============================== >>> Test summary >>> ============================== >>> ??? TEST????????????????????????????????????????????? TOTAL? PASS >>> FAIL ERROR >>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 0 << >>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 0 << >>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 >>> 1450???? 2 << >>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0 >>> 0???? 0 >>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0 >>> 0???? 0 >>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 0 << >>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 << >>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0 >>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 0 << >>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 0 << >>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0 >>> 0???? 0 >>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0 >>> 0???? 0 >>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0 >>> 0???? 0 >>> ============================== >> >> Given most of these are not hotspot issues and given the number of >> failures, I think this is something that would need to be discussed >> much more broadly. So I've cc'd core-libs-dev and compiler-dev. I >> recall there was a very recent discussion regarding some tests failing >> for the same reason, but don't recall the outcome. >> >> David >> ----- >> >>> On the same machine,when i set LANG=en_US.UTF-8. >>> >>> ============================== >>> Test summary >>> ============================== >>> ??? TEST????????????????????????????????????????????? TOTAL? PASS >>> FAIL ERROR >>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 0 << >>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 5 << >>> ??? jtreg:test/langtools:tier1???????????????????????? 3920 3920 0???? 0 >>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0 >>> 0???? 0 >>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0 >>> 0???? 0 >>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 7 << >>> ??? jtreg:test/langtools:tier2?????????????????????????? 11 11 0???? 0 >>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0 >>> ??? jtreg:test/jaxp:tier2?????????????????????????????? 438 438 0???? 0 >>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 0 << >>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0 >>> 0???? 0 >>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0 >>> 0???? 0 >>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0 >>> 0???? 0 >>> >>> >>> By comparison we can find, lots of(1000+) langtools tests will get >>> fail, and other(about 30+, exclude some X11 and sanity that >>> >>> result problem) test cases will also fail because of local LANG. >>> >>> >>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java, >>> >>> shouldContain("Error: Could not find or load main class " + CLASSNAME) >>> >>> >>> When in the zh_CN.UTF-8 environment, because some of the output >>> information is changed to Chinese by some properties file, >>> >>> the English cannot be matched, which will result in an fail. >>> >>> When I set? LANG=en_US/LC_ALL=C, this test will pass. >>> >>> >>> I think there are some possible solutions. >>> >>> >>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this >>> modification is more violent because he will affect all test cases. >>> >>> >>> 2.We modify each individual test?E.g >>> test/hotspot/jtreg/compiler/c2/Test8062950.java >>> >>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java >>> ??package compiler.c2; >>> ??import jdk.test.lib.process.ProcessTools; >>> +import java.util.Map; >>> +import jdk.test.lib.process.OutputAnalyzer; >>> >>> ??public class Test8062950 { >>> ????? private static final String CLASSNAME = "DoesNotExist"; >>> ????? public static void main(String[] args) throws Exception { >>> - ProcessTools.executeTestJvm("-Xcomp", >>> - "-XX:-TieredCompilation", >>> - "-XX:-UseOptoBiasInlining", >>> - CLASSNAME) >>> - .shouldHaveExitValue(1) >>> -??????????????????? .shouldContain("Error: Could not find or load >>> main class " + CLASSNAME) >>> -??????????????????? .shouldNotContain("A fatal error has been >>> detected") >>> -??????????????????? .shouldNotContain("Internal Error") >>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine Error"); >>> +??????? final ProcessBuilder pb = >>> ProcessTools.createJavaProcessBuilder(true, >>> + "-Xcomp", >>> + "-XX:-TieredCompilation", >>> + "-XX:-UseOptoBiasInlining", >>> + CLASSNAME); >>> +??????? final Map env = pb.environment(); >>> +??????? env.put("LC_ALL", "en_US.UTF-8"); >>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start()); >>> + output.shouldHaveExitValue(1); >>> +??????? output.shouldContain("Error: Could not find or load main >>> class " + CLASSNAME); >>> +??????? output.shouldNotContain("A fatal error has been detected"); >>> +??????? output.shouldNotContain("Internal Error"); >>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error"); >>> } >>> ??} >>> >>> But I don't know if this will change the test program too much, >>> because the related problems are a lot in langtools tests. >>> >>> >>> 3.And i find that there is a function can judge the locale >>> >>> ??if (!isEnglishLocale()) { // only english version >>> return; >>> ??} >>> >>> But in this case, I think in many test cases, we may not be able to >>> return so directly, because some test cases may have other test >>> purposes. >>> >>> >>> So I don't know if you have any ideas or some suggestions to solve >>> the problem that the output information and English do not match in this >>> >>> non-English environment. >>> >>> >>> Cheers, >>> >>> Jing Tian >>> >>> >>> >>> From naoto.sato at oracle.com Fri Mar 29 01:23:29 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 28 Mar 2019 18:23:29 -0700 Subject: RFC: Make test failed because of the locale LANG In-Reply-To: References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn> <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com> Message-ID: <794486e3-0a12-7605-2be4-abd3916d030f@oracle.com> On 3/28/19 4:54 PM, David Holmes wrote: > On 29/03/2019 1:59 am, Naoto Sato wrote: >> Hi, >> >> I don't think there is any *official* rule for the regression tests to >> succeed in any locale, but if the test case is locale sensitive such >> as in this case, I'd suggest it should correctly specify the locale >> beforehand, or quit gracefully in general. >> >> For this specific case, I'd suggest not set the environment variable >> (as it won't work with Windows), using runtime system properties >> (user.language/user.country) would help. > > Which specific case are you referring to? :) I was referring to the test case below, Test8062950.java, where it issues "env.put("LC_ALL", "en_US.UTF-8")". Instead I would recommend "-Duser.language=en -Duser.country=US" runtime system property. > > Given there are well over a thousand failures in total I think we need > to set a reasonable initial locale as part of the test setup. Many of > the hotspot tests check actual and expected output and we, in general, > have no idea what kinds of output may be subject to locale specific > changes. Agree. Specifying a reasonable default locale would not be a bad idea. Naoto > > Cheers, > David > >> Naoto >> >> On 3/27/19 10:47 PM, David Holmes wrote: >>> Hi Jing, >>> >>> On 28/03/2019 3:22 pm, Jing Tian wrote: >>>> Hi, >>>> >>>> When I am doing the 'make test'.If the local LANG is set as >>>> 'zh_CN.UTF-8', Test cases will have a lot of error messages. >>>> >>>> ============================== >>>> Test summary >>>> ============================== >>>> ??? TEST????????????????????????????????????????????? TOTAL? PASS >>>> FAIL ERROR >>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 0 << >>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 0 << >>>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 >>>> 1450???? 2 << >>>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0 0???? 0 >>>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0 0???? 0 >>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 >>>> 0 << >>>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 << >>>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0 >>>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 0 << >>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 >>>> 0 << >>>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0 0???? 0 >>>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0 0???? 0 >>>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0 0???? 0 >>>> ============================== >>> >>> Given most of these are not hotspot issues and given the number of >>> failures, I think this is something that would need to be discussed >>> much more broadly. So I've cc'd core-libs-dev and compiler-dev. I >>> recall there was a very recent discussion regarding some tests >>> failing for the same reason, but don't recall the outcome. >>> >>> David >>> ----- >>> >>>> On the same machine,when i set LANG=en_US.UTF-8. >>>> >>>> ============================== >>>> Test summary >>>> ============================== >>>> ??? TEST????????????????????????????????????????????? TOTAL? PASS >>>> FAIL ERROR >>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 0 << >>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 >>>> 5 << >>>> ??? jtreg:test/langtools:tier1???????????????????????? 3920 3920 >>>> 0???? 0 >>>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0 0???? 0 >>>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0 0???? 0 >>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 >>>> 7 << >>>> ??? jtreg:test/langtools:tier2?????????????????????????? 11 11 0???? 0 >>>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0 >>>> ??? jtreg:test/jaxp:tier2?????????????????????????????? 438 438 0???? 0 >>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 >>>> 0 << >>>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0 0???? 0 >>>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0 0???? 0 >>>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0 0???? 0 >>>> >>>> >>>> By comparison we can find, lots of(1000+) langtools tests will get >>>> fail, and other(about 30+, exclude some X11 and sanity that >>>> >>>> result problem) test cases will also fail because of local LANG. >>>> >>>> >>>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java, >>>> >>>> shouldContain("Error: Could not find or load main class " + CLASSNAME) >>>> >>>> >>>> When in the zh_CN.UTF-8 environment, because some of the output >>>> information is changed to Chinese by some properties file, >>>> >>>> the English cannot be matched, which will result in an fail. >>>> >>>> When I set? LANG=en_US/LC_ALL=C, this test will pass. >>>> >>>> >>>> I think there are some possible solutions. >>>> >>>> >>>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this >>>> modification is more violent because he will affect all test cases. >>>> >>>> >>>> 2.We modify each individual test?E.g >>>> test/hotspot/jtreg/compiler/c2/Test8062950.java >>>> >>>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java >>>> ??package compiler.c2; >>>> ??import jdk.test.lib.process.ProcessTools; >>>> +import java.util.Map; >>>> +import jdk.test.lib.process.OutputAnalyzer; >>>> >>>> ??public class Test8062950 { >>>> ????? private static final String CLASSNAME = "DoesNotExist"; >>>> ????? public static void main(String[] args) throws Exception { >>>> - ProcessTools.executeTestJvm("-Xcomp", >>>> - "-XX:-TieredCompilation", >>>> - "-XX:-UseOptoBiasInlining", >>>> - CLASSNAME) >>>> - .shouldHaveExitValue(1) >>>> -??????????????????? .shouldContain("Error: Could not find or load >>>> main class " + CLASSNAME) >>>> -??????????????????? .shouldNotContain("A fatal error has been >>>> detected") >>>> -??????????????????? .shouldNotContain("Internal Error") >>>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine >>>> Error"); >>>> +??????? final ProcessBuilder pb = >>>> ProcessTools.createJavaProcessBuilder(true, >>>> + "-Xcomp", >>>> + "-XX:-TieredCompilation", >>>> + "-XX:-UseOptoBiasInlining", >>>> + CLASSNAME); >>>> +??????? final Map env = pb.environment(); >>>> +??????? env.put("LC_ALL", "en_US.UTF-8"); >>>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start()); >>>> + output.shouldHaveExitValue(1); >>>> +??????? output.shouldContain("Error: Could not find or load main >>>> class " + CLASSNAME); >>>> +??????? output.shouldNotContain("A fatal error has been detected"); >>>> +??????? output.shouldNotContain("Internal Error"); >>>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error"); >>>> } >>>> ??} >>>> >>>> But I don't know if this will change the test program too much, >>>> because the related problems are a lot in langtools tests. >>>> >>>> >>>> 3.And i find that there is a function can judge the locale >>>> >>>> ??if (!isEnglishLocale()) { // only english version >>>> return; >>>> ??} >>>> >>>> But in this case, I think in many test cases, we may not be able to >>>> return so directly, because some test cases may have other test >>>> purposes. >>>> >>>> >>>> So I don't know if you have any ideas or some suggestions to solve >>>> the problem that the output information and English do not match in >>>> this >>>> >>>> non-English environment. >>>> >>>> >>>> Cheers, >>>> >>>> Jing Tian >>>> >>>> >>>> >>>> From david.holmes at oracle.com Fri Mar 29 01:25:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Mar 2019 11:25:00 +1000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> Message-ID: <945d9546-5195-ab33-0e20-57871c2f1ef9@oracle.com> Hi Andrew, This seems fine in general but I have a few queries on some details: src/hotspot/share/classfile/javaClasses.hpp f(java_lang_Thread) \ + f(jdk_internal_misc_UnsafeConstants) \ f(java_lang_ThreadGroup) \ Is there a reason this needs to be shoved in there? Similarly with src/hotspot/share/classfile/systemDictionary.hpp: do_klass(Thread_klass, java_lang_Thread ) \ + do_klass(UnsafeConstants_klass, jdk_internal_misc_UnsafeConstants ) \ do_klass(ThreadGroup_klass, java_lang_ThreadGroup ) \ ? --- src/hotspot/share/runtime/thread.cpp main_thread->set_threadObj(thread_object); + + // initialize the hardware-specific constants needed by Unsafe + initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), CHECK); + jdk_internal_misc_UnsafeConstants::set_unsafe_constants(); + // Set thread status to running since main thread has // been started and running. java_lang_Thread::set_thread_status(thread_object, That seems a very odd place to insert the new initialization. I can't see any reason you'd need to split the Thread object initialization like that. ?? More generally exactly when do you need to initialize this new class by and how does the initialization order change before/after this fix? (I'm expecting only to see the new class inserted where needed without any other perturbations.) --- src/hotspot/share/classfile/vmSymbols.hpp + template(big_endian_name, "BIG_ENDIAN") \ + template(use_unaligned_access_name, "UNALIGNED_ACCESS") \ Nit: There's an extra space before "UNALIGNED... --- src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java 31 * package-protected ... s/protected/private/ 37 * The JVM injects values into all the static fields of this class ... 43 * hardware-specific constants installed by the JVM. I get this gist of this note but still found it rather difficult to intepret. There are I think two key points: 1. The fields must not be constant variables, hence the need for the static initialization block. 2. The true value of each field is injected by the VM. How about: * The JVM injects hardware-specific values into all the static fields * of this class during JVM initialization. The static initialization * block exists to prevent the fields from being considered constant * variables, so the field values will be not be compiled directly into * any class that uses them. 60 * @implNote 61 * The actual value for this field is injected by JVM. A static 62 * initialization block is used to set the value here to 63 * communicate that this static final field is not statically 64 * foldable, and to avoid any possible circular dependency during 65 * vm initialization. I think all you need for each field is just: * @implNote * The actual value for this field is injected by _the_ JVM. 85 * flag whose value ... 92 * flag whose value ... s/flag/Flag/ Thanks, David On 29/03/2019 2:56 am, Andrew Dinn wrote: > On 28/03/2019 15:22, Thomas St?fe wrote: >> The second of those was actually intended to be iff. This is a common >> abbreviation used by English/US mathematicians and logicians to write >> 'if and only if' (it is also sometimes written as <=>). Since you didn't >> recognize it I guess I really need to write it out in full. >> >> >> Oh, don't worry on my account. I am not a native speaker nor a >> mathematician. You could leave iff and add [sic] to make everyone >> curious and start googling "iff" :) > I changed it nevertheless. It would be remiss to presume readers need be > conversant with elliptical, English logico-mathematical parlance (I'm > explaining this in as plain English as I can ... no, wait! ;-). > > Anyway, I addressed this and your other concerns in a new webrev. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.02 > > Input from a second reviewer would be welcome ... > > 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 jingtian at loongson.cn Fri Mar 29 02:20:29 2019 From: jingtian at loongson.cn (Jing Tian) Date: Fri, 29 Mar 2019 10:20:29 +0800 Subject: RFC: Make test failed because of the locale LANG In-Reply-To: <794486e3-0a12-7605-2be4-abd3916d030f@oracle.com> References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn> <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com> <794486e3-0a12-7605-2be4-abd3916d030f@oracle.com> Message-ID: Hi, First of all, I want to say sorry . Because of the problems with my mail client, this typography looks bad.I found the typography so bad on the webpage today. T_T These suggestions I just want to show some ideas. We can't make changes in each test case, because it is too much, and the changes I made are not good. The following is the fail test cases because of the locale(exclude some X11 fail and sanity fail, because some of fails are in the list because of them): java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java java/util/logging/LocalizedLevelName.java java/util/logging/SimpleFormatterFormat.java sun/util/logging/SourceClassName.java tools/pack200/DeprecatePack200.java java/security/KeyStore/PKCS12/KeytoolReaderP12Test.java java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java javax/security/auth/login/JAASConfigSyntaxCheck/JAASConfigSyntaxTest.java javax/security/auth/login/LoginContext/DynamicConfigurationTest.java jdk/security/logging/TestSecurityPropertyModificationLog.java jdk/security/logging/TestTLSHandshakeLog.java jdk/security/logging/TestX509CertificateLog.java jdk/security/logging/TestX509ValidationLog.java tools/jar/DeprecateOptionN.java tools/jar/compat/CLICompatibility.java tools/jar/mmrjar/Basic.java tools/jar/modularJar/Basic.java tools/jar/multiRelease/ApiValidatorTest.java tools/jar/multiRelease/Basic.java tools/jar/multiRelease/Basic1.java tools/jlink/JLinkNegativeTest.java tools/jlink/JLinkOptionsTest.java tools/jlink/JLinkPluginsTest.java tools/jlink/JLinkTest.java tools/jlink/bindservices/SuggestProviders.java tools/jlink/plugins/LegalFilePluginTest.java tools/jmod/JmodNegativeTest.java tools/jmod/JmodTest.java tools/launcher/FXLauncherTest.java tools/launcher/InfoStreams.java tools/launcher/SourceMode.java tools/launcher/TestSpecialArgs.java javax/xml/jaxp/functional/org/xml/sax/ptests/EHFatalTest.java test/hotspot/jtreg/compiler/c2/Test8062950.java test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java The following is the langtools fail test cases.(1450/3922) jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java jdk/javadoc/doclet/AuthorDD/AuthorDD.java jdk/javadoc/doclet/MetaTag/MetaTag.java jdk/javadoc/doclet/WindowTitles/WindowTitles.java jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java jdk/javadoc/doclet/testAuthor/TestAuthor.java jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java jdk/javadoc/doclet/testCharsetDocencodingOptions/TestCharsetDocencodingOptions.java jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java .......... I don't know how to solve this problem is a better solution. ? 2019/3/29 9:23, naoto.sato at oracle.com ??: > On 3/28/19 4:54 PM, David Holmes wrote: >> On 29/03/2019 1:59 am, Naoto Sato wrote: >>> Hi, >>> >>> I don't think there is any *official* rule for the regression tests >>> to succeed in any locale, but if the test case is locale sensitive >>> such as in this case, I'd suggest it should correctly specify the >>> locale beforehand, or quit gracefully in general. >>> >>> For this specific case, I'd suggest not set the environment variable >>> (as it won't work with Windows), using runtime system properties >>> (user.language/user.country) would help. >> >> Which specific case are you referring to? :) > > I was referring to the test case below, Test8062950.java, where it > issues "env.put("LC_ALL", "en_US.UTF-8")". Instead I would recommend > "-Duser.language=en -Duser.country=US" runtime system property. > >> >> Given there are well over a thousand failures in total I think we >> need to set a reasonable initial locale as part of the test setup. >> Many of the hotspot tests check actual and expected output and we, in >> general, have no idea what kinds of output may be subject to locale >> specific > changes. > > Agree. Specifying a reasonable default locale would not be a bad idea. > > Naoto > >> >> Cheers, >> David >> >>> Naoto >>> >>> On 3/27/19 10:47 PM, David Holmes wrote: >>>> Hi Jing, >>>> >>>> On 28/03/2019 3:22 pm, Jing Tian wrote: >>>>> Hi, >>>>> >>>>> When I am doing the 'make test'.If the local LANG is set as >>>>> 'zh_CN.UTF-8', Test cases will have a lot of error messages. >>>>> >>>>> ============================== >>>>> Test summary >>>>> ============================== >>>>> ??? TEST TOTAL? PASS FAIL ERROR >>>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 >>>>> 0 << >>>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 >>>>> 0 << >>>>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 >>>>> 1450???? 2 << >>>>> ??? jtreg:test/nashorn:tier1 0 0 0???? 0 >>>>> ??? jtreg:test/jaxp:tier1 0 0 0???? 0 >>>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 >>>>> 29 0 << >>>>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 << >>>>> ??? jtreg:test/nashorn:tier2 35 35 0???? 0 >>>>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 >>>>> 0 << >>>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 >>>>> 36 0 << >>>>> ??? jtreg:test/langtools:tier3 0 0 0???? 0 >>>>> ??? jtreg:test/nashorn:tier3 0 0 0???? 0 >>>>> ??? jtreg:test/jaxp:tier3 0 0 0???? 0 >>>>> ============================== >>>> >>>> Given most of these are not hotspot issues and given the number of >>>> failures, I think this is something that would need to be discussed >>>> much more broadly. So I've cc'd core-libs-dev and compiler-dev. I >>>> recall there was a very recent discussion regarding some tests >>>> failing for the same reason, but don't recall the outcome. >>>> >>>> David >>>> ----- >>>> >>>>> On the same machine,when i set LANG=en_US.UTF-8. >>>>> >>>>> ============================== >>>>> Test summary >>>>> ============================== >>>>> ??? TEST TOTAL? PASS FAIL ERROR >>>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 >>>>> 0 << >>>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 >>>>> 19 5 << >>>>> ??? jtreg:test/langtools:tier1 3920 3920 0???? 0 >>>>> ??? jtreg:test/nashorn:tier1 0 0 0???? 0 >>>>> ??? jtreg:test/jaxp:tier1 0 0 0???? 0 >>>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 >>>>> 31 7 << >>>>> ??? jtreg:test/langtools:tier2 11 11 0???? 0 >>>>> ??? jtreg:test/nashorn:tier2 35 35 0???? 0 >>>>> ??? jtreg:test/jaxp:tier2 438 438 0???? 0 >>>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 >>>>> 37 0 << >>>>> ??? jtreg:test/langtools:tier3 0 0 0???? 0 >>>>> ??? jtreg:test/nashorn:tier3 0 0 0???? 0 >>>>> ??? jtreg:test/jaxp:tier3 0 0 0???? 0 >>>>> >>>>> >>>>> By comparison we can find, lots of(1000+) langtools tests will get >>>>> fail, and other(about 30+, exclude some X11 and sanity that >>>>> >>>>> result problem) test cases will also fail because of local LANG. >>>>> >>>>> >>>>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java, >>>>> >>>>> shouldContain("Error: Could not find or load main class " + >>>>> CLASSNAME) >>>>> >>>>> >>>>> When in the zh_CN.UTF-8 environment, because some of the output >>>>> information is changed to Chinese by some properties file, >>>>> >>>>> the English cannot be matched, which will result in an fail. >>>>> >>>>> When I set? LANG=en_US/LC_ALL=C, this test will pass. >>>>> >>>>> >>>>> I think there are some possible solutions. >>>>> >>>>> >>>>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this >>>>> modification is more violent because he will affect all test cases. >>>>> >>>>> >>>>> 2.We modify each individual test?E.g >>>>> test/hotspot/jtreg/compiler/c2/Test8062950.java >>>>> >>>>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java >>>>> ??package compiler.c2; >>>>> ??import jdk.test.lib.process.ProcessTools; >>>>> +import java.util.Map; >>>>> +import jdk.test.lib.process.OutputAnalyzer; >>>>> >>>>> ??public class Test8062950 { >>>>> ????? private static final String CLASSNAME = "DoesNotExist"; >>>>> ????? public static void main(String[] args) throws Exception { >>>>> - ProcessTools.executeTestJvm("-Xcomp", >>>>> - "-XX:-TieredCompilation", >>>>> - "-XX:-UseOptoBiasInlining", >>>>> - CLASSNAME) >>>>> - .shouldHaveExitValue(1) >>>>> -??????????????????? .shouldContain("Error: Could not find or load >>>>> main class " + CLASSNAME) >>>>> -??????????????????? .shouldNotContain("A fatal error has been >>>>> detected") >>>>> -??????????????????? .shouldNotContain("Internal Error") >>>>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine >>>>> Error"); >>>>> +??????? final ProcessBuilder pb = >>>>> ProcessTools.createJavaProcessBuilder(true, >>>>> + "-Xcomp", >>>>> + "-XX:-TieredCompilation", >>>>> + "-XX:-UseOptoBiasInlining", >>>>> + CLASSNAME); >>>>> +??????? final Map env = pb.environment(); >>>>> +??????? env.put("LC_ALL", "en_US.UTF-8"); >>>>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start()); >>>>> + output.shouldHaveExitValue(1); >>>>> +??????? output.shouldContain("Error: Could not find or load main >>>>> class " + CLASSNAME); >>>>> +??????? output.shouldNotContain("A fatal error has been detected"); >>>>> +??????? output.shouldNotContain("Internal Error"); >>>>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error"); >>>>> } >>>>> ??} >>>>> >>>>> But I don't know if this will change the test program too much, >>>>> because the related problems are a lot in langtools tests. >>>>> >>>>> >>>>> 3.And i find that there is a function can judge the locale >>>>> >>>>> ??if (!isEnglishLocale()) { // only english version >>>>> return; >>>>> ??} >>>>> >>>>> But in this case, I think in many test cases, we may not be able >>>>> to return so directly, because some test cases may have other test >>>>> purposes. >>>>> >>>>> >>>>> So I don't know if you have any ideas or some suggestions to solve >>>>> the problem that the output information and English do not match >>>>> in this >>>>> >>>>> non-English environment. >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Jing Tian >>>>> >>>>> >>>>> >>>>> From goetz.lindenmaier at sap.com Fri Mar 29 07:49:40 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 29 Mar 2019 07:49:40 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> Message-ID: Hi Mandy, The JBS is offline, so I'll just reply on this item for now: > > > Since the JEP quotes that NullPointerExceptions are thrown frequently > > > and swallowed, it would help if you can generate some numbers. > > > This JEP will help the discussion on the proposed feature and design and avoid > > > any confusion/assumption of the implementation. > > I'll generate some numbers. Is running jvm2008 fine? > A benchmark may not be a good representative.? I'd be interested in a real application > to support the claim.? I ran the following applications: Jbb2005: 15 NPE raised Jvm2008: 5 NPE raised, only in 'check' benchmark SAP application: 16138 NPE raised. None of these called NPE.getMessage(). This SAP application is known to us for bad NPE behavior ?? and runs a few hours. It's from our GC stress tests. I think 16000 is still a small number given the runtime of the test. So I want to withdraw my claim that NPEs are thrown frequently. Probably I was biased by my compiler construction background, remembering NPE checks are all over the place in the code. But I think I can still keep the claim that the message is printed rarely. I'll adapt the JEP saying something like this: "While exceptions are supposed to be thrown rarely, i.e., only In exceptional situations, most are swallowed without ever looking at the message. Thus, overhead in getMessage() will not fall into account." Best regards, Goetz. From adinn at redhat.com Fri Mar 29 08:43:10 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 Mar 2019 08:43:10 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> Message-ID: <7eb52b3a-bd9b-62ba-9451-54cb42871ce0@redhat.com> On 28/03/2019 17:09, Thomas St?fe wrote: > src/hotspot/share/classfile/javaClasses.cpp > > Pure nitpicking, but you could remove the member variables too and just > set the Unsafe members directly, e.g.: > > ? ? if (fd->name() == vmSymbols::address_size_name()) { > ? ? ? mirror->int_field_put(fd->offset(), (jint)sizeof(void*)); > ? ? } else if (fd->name() == vmSymbols::page_size_name()) { > ? ? ? mirror->int_field_put(fd->offset(), (jint) os::vm_page_size()); > .. > > and so on. But I leave this up to you. This is already better than before. I thought about that but it seemed to me to be better for clarity and readability to init all the members in a single block in the constructor rather than spread the computations of the field values through the code that updates the fields. I think it's easier that way to see where all the values are coming from and align them up with the fields in the target class. > +? ? }else { > space missing before else Yes. > src/hotspot/share/classfile/vmSymbols.hpp > "UNALIGNED_ACCESS" off by one space Yes. > src/java.base/share/classes/java/nio/channels/FileChannel.java > > This may have creeped in from another change. Ah, yes. That was the next patch that I forgot to back out. I have updated the webrev in place to remove it and also fix the whitespace & alignment issues. > Good otherwise. Thanks. 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 thomas.stuefe at gmail.com Fri Mar 29 08:47:57 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 29 Mar 2019 09:47:57 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <7eb52b3a-bd9b-62ba-9451-54cb42871ce0@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <7eb52b3a-bd9b-62ba-9451-54cb42871ce0@redhat.com> Message-ID: Thanks Andrew. Looks all good to me now. Cheers, Thomas On Fri, Mar 29, 2019 at 9:43 AM Andrew Dinn wrote: > On 28/03/2019 17:09, Thomas St?fe wrote: > > src/hotspot/share/classfile/javaClasses.cpp > > > > Pure nitpicking, but you could remove the member variables too and just > > set the Unsafe members directly, e.g.: > > > > if (fd->name() == vmSymbols::address_size_name()) { > > mirror->int_field_put(fd->offset(), (jint)sizeof(void*)); > > } else if (fd->name() == vmSymbols::page_size_name()) { > > mirror->int_field_put(fd->offset(), (jint) os::vm_page_size()); > > .. > > > > and so on. But I leave this up to you. This is already better than > before. > > I thought about that but it seemed to me to be better for clarity and > readability to init all the members in a single block in the constructor > rather than spread the computations of the field values through the code > that updates the fields. I think it's easier that way to see where all > the values are coming from and align them up with the fields in the > target class. > > > + }else { > > space missing before else > Yes. > > > src/hotspot/share/classfile/vmSymbols.hpp > > "UNALIGNED_ACCESS" off by one space > > Yes. > > > src/java.base/share/classes/java/nio/channels/FileChannel.java > > > > This may have creeped in from another change. > > Ah, yes. That was the next patch that I forgot to back out. I have > updated the webrev in place to remove it and also fix the whitespace & > alignment issues. > > > Good otherwise. > Thanks. > > 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 adinn at redhat.com Fri Mar 29 10:40:06 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 Mar 2019 10:40:06 +0000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <945d9546-5195-ab33-0e20-57871c2f1ef9@oracle.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <945d9546-5195-ab33-0e20-57871c2f1ef9@oracle.com> Message-ID: <2a26715f-fa64-9de4-1071-b18d07c05511@redhat.com> Hi David, Thanks very much for reviewing this patch. On 29/03/2019 01:25, David Holmes wrote: > This seems fine in general but I have a few queries on some details: > > src/hotspot/share/classfile/javaClasses.hpp > > ??? f(java_lang_Thread) \ > +?? f(jdk_internal_misc_UnsafeConstants) \ > ??? f(java_lang_ThreadGroup) \ > > Is there a reason this needs to be shoved in there? Similarly with > src/hotspot/share/classfile/systemDictionary.hpp: > > ?? do_klass(Thread_klass, > java_lang_Thread????????????????????????????????????? ) \ > +?? do_klass(UnsafeConstants_klass, > jdk_internal_misc_UnsafeConstants???????????????????? ) \ > ??? do_klass(ThreadGroup_klass, > java_lang_ThreadGroup???????????????????????????????? ) \ > > ? I'm not sure what you are asking here. Are you talking about the positioning of these entries? If so then the reason for choosing those positions was because they match the position of the corresponding class initialization calls in the file thread.cpp. As to that choice ... see below. > src/hotspot/share/runtime/thread.cpp > > ??? main_thread->set_threadObj(thread_object); > + > +?? // initialize the hardware-specific constants needed by Unsafe > +?? initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), > CHECK); > +?? jdk_internal_misc_UnsafeConstants::set_unsafe_constants(); > + > ??? // Set thread status to running since main thread has > ??? // been started and running. > ??? java_lang_Thread::set_thread_status(thread_object, > > That seems a very odd place to insert the new initialization. I can't > see any reason you'd need to split the Thread object initialization like > that. ?? Well, yes, indeed :-). I was not sure where this init needed to go so I simply put it in as early as I thought was safe. Clearly, it is an interloper into intitialise_java_lang_classes() but I was not sure where else was more appropriate. I don't think it matters too much where this init happens so long as it is early enough to precede any clinit dependencies on Unsafe (see below). I'm very happy to take advice on this (indeed I was hoping/ expecting it would be brought up at review) and also on where the entries in the headers would best be placed. > More generally exactly when do you need to initialize this new class by > and how does the initialization order change before/after this fix? (I'm > expecting only to see the new class inserted where needed without any > other perturbations.) As I said, I put the class initialization in at this early point simply to guarantee that the constants are available before Unsafe or any class which might recursively initialize Unsafe could end up needing them. I am sure they could move later and also earlier, although the latter would probably not make any sense. The important thing is that they don't really have any hard dependencies on other class inits apart, perhaps, from 'magic' classes like Object, Class etc which need to exist in order to init /any/ other class. I deliberately factored these constants out of Unsafe into a separate all static class UnsafeConstants so as to decouple this init from any current or future dependencies on Unsafe (and also to make them more clearly visible). Since the fields only hold os/hw specific constants they can be set any time after VM_Version/CPU-specific init and OS-specific init has completed. > src/hotspot/share/classfile/vmSymbols.hpp > > +?? template(big_endian_name,?????????????????????????? "BIG_ENDIAN") > ?????????????????????????? \ > +?? template(use_unaligned_access_name, > "UNALIGNED_ACCESS")??????????????????????? \ > > Nit: There's an extra space before "UNALIGNED... Thanks. Thomas Stuefe already spotted that and I have updated the webrev in place to fix it. > src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java > > 31? * package-protected? ... > > s/protected/private/ Thanks, will correct it. > ?37? * The JVM injects values into all the static fields of this class > ?... > ?43? * hardware-specific constants installed by the JVM. > > I get this gist of this note but still found it rather difficult to > intepret. There are I think two key points: > > 1. The fields must not be constant variables, hence the need for the > static initialization block. > 2. The true value of each field is injected by the VM. > > How about: > > * The JVM injects hardware-specific values into all the static fields > * of this class during JVM initialization. The static initialization > * block exists to prevent the fields from being considered constant > * variables, so the field values will be not be compiled directly into > * any class that uses them. Yes, I agree that is clearer. > 60????? * @implNote > 61????? * The actual value for this field is injected by JVM. A static > 62????? * initialization block is used to set the value here to > 63????? * communicate that this static final field is not statically > 64????? * foldable, and to avoid any possible circular dependency during > 65????? * vm initialization. > > I think all you need for each field is just: > > * @implNote > * The actual value for this field is injected by _the_ JVM. Yes, also better. > 85????? * flag whose value ... > 92????? * flag whose value ... > > s/flag/Flag/ Thanks, will correct this. 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 lenborje at gmail.com Fri Mar 29 11:13:11 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Fri, 29 Mar 2019 12:13:11 +0100 Subject: jdk.packager.services.UserJvmOptionsService replacement? Message-ID: <33223DD4-55D6-4960-BA2F-87F27B0EFEA4@gmail.com> I'm sorely missing the jdk.packager.services.UserJvmOptionsService in the current jpackage EA. I've asked before and received the answer that the UserJvmOptionsService was removed together JavaFX, and that no replacement was planned. May I plead for a reincarnation with the new jpackage tool? Before Java 11, I used the UserJvmOptionsService to give my end users a way to configure the JVM options of my application. If the UserJvmOptionsService cannot be revived, I would like to get some recommendations for a work-around. (I've not been able to come up with anything easy and portable, mostly since any work-around would be dependent on how jpackage implements the application launcher.) Best regards, /Lennart B?rjeson From matthias.baesken at sap.com Fri Mar 29 12:36:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 29 Mar 2019 12:36:35 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: Thanks. Alan, are you fine with the current webrev, if yes may I add you as reviewer ? Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 28. M?rz 2019 12:41 > To: Baesken, Matthias > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > this looks good to me now. Let's wait for another review then. > > Best regards > Christoph > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Donnerstag, 28. M?rz 2019 12:39 > > To: Langer, Christoph > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hello here is another webrev , I adjusted > > test/jdk/tools/launcher/Arrrghs.java a bit taking your suggestions into > > account . > > Can I have a second review please ? > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.2/webrev/ > > > > > As for the test, I think you could also check a jar in a short path > > > > There exist already quite a few tests using "-jar some.jar" with "normal" > / > > shorter paths in test/jdk/tools/launcher/Arrrghs.java . > > > > > > Regards, Matthias > > > > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Donnerstag, 28. M?rz 2019 11:59 > > > To: Baesken, Matthias > > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > parse_manifest.c on windows > > > > > > Hi Matthias, > > > > > > the change to src/java.base/windows/native/libjli/java_md.c looks good > to > > > me now. > > > > > > As for the test, I think you could also check a jar in a short path to exercise > > > both cases in JLI_Open. > > > > > > And a few nits: > > > Line 506: better do: > > > Path pelp = pcreated.resolve(elp.jar); > > > > > > Line 507: > > > 2 spaces are one too much after elp > > > > > > Line 508: > > > Insert 2 additional spaces in the source code string, a space between "){" > > and > > > another in the end after the ; of the System.out.println statement, like > this: > > > createJar(elp, new File("Foo"), "public static void main(String[] args) { > > > System.out.println(\"Hello from ELP\"); }"); > > > > > > You could also do a little cleanup: Remove method private static String > > > removeExtraQuotes(String in) { from line 64. It seems, it is not needed. > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: Baesken, Matthias > > > > Sent: Mittwoch, 27. M?rz 2019 18:05 > > > > To: Langer, Christoph > > > > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > > > > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code > > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > > parse_manifest.c on windows > > > > > > > > Hello could you please look into it ? > > > > > > > > Best regards, Matthias > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Baesken, Matthias > > > > > Sent: Montag, 25. M?rz 2019 18:05 > > > > > To: Langer, Christoph > > > > > Cc: 'core-libs-dev at openjdk.java.net' > dev at openjdk.java.net>; > > > > > 'Alan Bateman' > > > > > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native > code > > > > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in > > > > > parse_manifest.c on windows > > > > > > > > > > Hello here is an updated webrev : > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > > > > > > > > > > > > > > > > > > > > > In JLI_Open(const char* name, int flags), you should remove ret > > and > > > > only > > > > > > > use fd, I think. > > > > > > > > > > > > > > > I removed ret and adjusted some comments. > > > > > > > > > > Additionally I added a test that uses (on Windows) JLI_Open on a > > jar > > > > file > > > > > with a "long" path (> 260 chars). > > > > > [ JLI_Open is currently called from parse_manifest.c with jarfile as > > > > > parameter ] > > > > > From claes.redestad at oracle.com Fri Mar 29 13:38:13 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 Mar 2019 14:38:13 +0100 Subject: RFR: 8221687: Deprecated j.u.jar.Attributes.Name attributes accidentally set to null Message-ID: <2051bcbc-29a5-85ab-8daa-511149f151ea@oracle.com> Hi, JDK-8214712 accidentally omitted three deprecated Names from being properly archived. Bug: https://bugs.openjdk.java.net/browse/JDK-8221687 Patch: diff -r d9f6d16299b1 src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Fri Mar 29 08:36:33 2019 +0100 +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Fri Mar 29 14:32:28 2019 +0100 @@ -703,9 +703,12 @@ addName(names, SEALED); addName(names, EXTENSION_LIST); addName(names, EXTENSION_NAME); + addName(names, EXTENSION_INSTALLATION); addName(names, IMPLEMENTATION_TITLE); addName(names, IMPLEMENTATION_VERSION); addName(names, IMPLEMENTATION_VENDOR); + addName(names, IMPLEMENTATION_VENDOR_ID); + addName(names, IMPLEMENTATION_URL); addName(names, SPECIFICATION_TITLE); addName(names, SPECIFICATION_VERSION); addName(names, SPECIFICATION_VENDOR); Thanks! /Claes From Alan.Bateman at oracle.com Fri Mar 29 13:44:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Mar 2019 13:44:36 +0000 Subject: RFR: 8221687: Deprecated j.u.jar.Attributes.Name attributes accidentally set to null In-Reply-To: <2051bcbc-29a5-85ab-8daa-511149f151ea@oracle.com> References: <2051bcbc-29a5-85ab-8daa-511149f151ea@oracle.com> Message-ID: On 29/03/2019 13:38, Claes Redestad wrote: > Hi, > > JDK-8214712 accidentally omitted three deprecated Names from being > properly archived. Looks okay. -Alan From claes.redestad at oracle.com Fri Mar 29 13:45:44 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 Mar 2019 14:45:44 +0100 Subject: RFR: 8221687: Deprecated j.u.jar.Attributes.Name attributes accidentally set to null In-Reply-To: References: <2051bcbc-29a5-85ab-8daa-511149f151ea@oracle.com> Message-ID: <6c17292d-1dea-cbb1-1edf-a1a3c5b3897c@oracle.com> On 2019-03-29 14:44, Alan Bateman wrote: > On 29/03/2019 13:38, Claes Redestad wrote: >> Hi, >> >> JDK-8214712 accidentally omitted three deprecated Names from being >> properly archived. > > Looks okay. Thanks, Alan! /Claes From goetz.lindenmaier at sap.com Fri Mar 29 14:06:56 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 29 Mar 2019 14:06:56 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> Message-ID: Hi Mandy, I could access the JBS now, so part 2 of my reply. Yesterday, I added tables to the JEP describing what is printed for which bytecode. If this is too verbose for the JEP, it might be nice in the bug implementing it. > > This is a design decision not to make the printout too complex. > This is fine.?? The JEP should call this out. I added this to the table entry for invokes. > > The algorithm looks at a lot of bytecodes to print the method. I can not > > enumerate all combinations of bytecodes, it's millions. I will add a per-bytecode table to > > the "Message content" section describing what is printed for which bytecode. > This is not what I am suggesting to do. > The JEP can describe the known cases or pattern (if enumerating these cases is not possible) > to help the readers understand the proposed feature and what is not covered. I added the tables to describe this before I got your mail, see above. Best regards, Goetz. From peter.levart at gmail.com Fri Mar 29 15:36:54 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 29 Mar 2019 16:36:54 +0100 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> Message-ID: <850cce9d-619c-b6c0-495c-eebbfff801cc@gmail.com> On 3/29/19 8:49 AM, Lindenmaier, Goetz wrote: > So I want to withdraw my claim that NPEs are thrown frequently. > Probably I was biased by my compiler construction background, > remembering NPE checks are all over the place in the code. > > But I think I can still keep the claim that the message is > printed rarely. > > I'll adapt the JEP saying something like this: > "While exceptions are supposed to be thrown rarely, i.e., only > In exceptional situations, most are swallowed without ever > looking at the message. Thus, overhead in getMessage() will > not fall into account." Is this really a realistic assumption? That NPE exceptions are mostly swallowed in most programs despite the fact that swallowing exceptions (and throwing them to control the flow) is an anti-pattern? Is majority of code really so badly written? I would expect that most programs contain an exception handler of some kind that at least logs all unexpected exceptions. I think JDK should assume that NPEs are not frequent in most well written programs. Because in well written programs all unexpected exceptions are at least logged somewhere and this alone guarantees that programs are eventually "fixed" to not throw them frequently... Regards, Peter > > Best regards, > Goetz. From peter.levart at gmail.com Fri Mar 29 15:43:57 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 29 Mar 2019 16:43:57 +0100 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <850cce9d-619c-b6c0-495c-eebbfff801cc@gmail.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <440e685b-b528-056d-385f-9dc010d65e97@oracle.com> <7189ff5f-a73f-5109-1d6b-aa8a2635543a@oracle.com> <20190314143804.400279193@eggemoggin.niobe.net> <172abe6c-e95d-515b-9e8c-8cfa402f4a7c@oracle.com> <3265336b-b483-dc69-b8f7-787139a44183@oracle.com> <33a092ca-9949-bac0-3160-6d018b5e27c4@oracle.com> <850cce9d-619c-b6c0-495c-eebbfff801cc@gmail.com> Message-ID: <342a394b-9798-cd83-3c18-cb7f24da712e@gmail.com> On 3/29/19 4:36 PM, Peter Levart wrote: > > > On 3/29/19 8:49 AM, Lindenmaier, Goetz wrote: >> So I want to withdraw my claim that NPEs are thrown frequently. >> Probably I was biased by my compiler construction background, >> remembering NPE checks are all over the place in the code. >> >> But I think I can still keep the claim that the message is >> printed rarely. >> >> I'll adapt the JEP saying something like this: >> "While exceptions are supposed to be thrown rarely, i.e., only >> In exceptional situations, most are swallowed without ever >> looking at the message. Thus, overhead in getMessage() will >> not fall into account." > > Is this really a realistic assumption? That NPE exceptions are mostly > swallowed in most programs despite the fact that swallowing exceptions > (and throwing them to control the flow) is an anti-pattern? Is > majority of code really so badly written? I would expect that most > programs contain an exception handler of some kind that at least logs > all unexpected exceptions. > > I think JDK should assume that NPEs are not frequent in most well > written programs. Because in well written programs all unexpected > exceptions are at least logged somewhere and this alone guarantees > that programs are eventually "fixed" to not throw them frequently... > > Regards, Peter So I would say that there are two kinds of programs (which kind is in majority doesn't matter): a - programs that throw and catch exceptions for exceptional situations only (i.e. non frequently) - they also print the exceptions' messages b - programs that throw and swallow exceptions frequently, but they mostly don't print their messages In either case .getMessage() is not called frequently for kind (a) and hopefully also for kind (b). Regards, Peter From mandy.chung at oracle.com Fri Mar 29 15:48:23 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 29 Mar 2019 08:48:23 -0700 Subject: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack In-Reply-To: <803b3611-9d67-7a59-548a-34d0e07b1295@oracle.com> References: <6f913e2b-9c9a-87c5-d895-6ae593a8e18a@oracle.com> <6875930d-f875-4931-cf68-f6960c6fb5f3@gmail.com> <0d2dff53-84dc-1dc9-187a-ee6b5f7f6a23@oracle.com> <803b3611-9d67-7a59-548a-34d0e07b1295@oracle.com> Message-ID: <0b56dc2b-2424-5f65-3dd9-3828bab8916f@oracle.com> On 3/28/19 1:39 PM, Alan Bateman wrote: > On 28/03/2019 16:43, Mandy Chung wrote: >> : >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.01 >> > I think this looks okay. One minor nit is that > newIllegalAccessException doesn't throw IAE. > Thanks Alan. CSR:? https://bugs.openjdk.java.net/browse/JDK-8221618 webrev.02 has a revised class spec in AccessibleObject but no other change : http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.02 Mandy From vicente.romero at oracle.com Fri Mar 29 17:02:31 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 29 Mar 2019 13:02:31 -0400 Subject: [PATCH] Some improvements for java.lang.Class In-Reply-To: <10151351553631340@myt6-fe24916a5562.qloud-c.yandex.net> References: <2796501552936166@myt6-add70abb4f02.qloud-c.yandex.net> <352521553106953@myt5-184376c2d7f8.qloud-c.yandex.net> <1a181b47-e392-c1f7-1ecc-2cf1ab5cd4d2@gmail.com> <10151351553631340@myt6-fe24916a5562.qloud-c.yandex.net> Message-ID: <4190ef01-b7ac-ab81-b7d4-2032ad47335f@oracle.com> Hi, From the benchmark data, it seems that the patched code is not a lot much faster than the original code, plus as Peter mentioned java.base is not compiled with the -XDstringConcat=inline option, so there is no way the compiler will generate any indy for the patched code. The new code is more compact though, that's its main benefit Vicente On 3/26/19 4:15 PM, ?????? ??????? wrote: > Hello Peter, > > I was unaware of mentioned detail (thank you a lot for pointing that out, it made me read the whole JEP280 again) so I've rebenchmarked my changes compiled with -XDstringConcat=inline. > > 1) as of Class::getTypeName for Object[] it turned out, that String::repeat performs slightly better: > > Benchmark Mode Cnt Score Error Units > > getTypeName_patched avgt 25 36,676 ? 3,559 ns/op > getTypeName avgt 25 39,083 ? 1,737 ns/op > > getTypeName_patched:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op > getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op > > > But for Object[][] situation is the opposite: > > Mode Cnt Score Error Units > > getTypeName_patched avgt 50 47,045 ? 0,455 ns/op > getTypeName avgt 50 40,536 ? 0,196 ns/op > > getTypeName_patched:?gc.alloc.rate.norm avgt 50 176,000 ? 0,001 B/op > getTypeName:?gc.alloc.rate.norm avgt 50 152,000 ? 0,001 B/op > > > 2) as of Class::methodToString patched version clearly wins: > > methodToString_1arg avgt 50 238,476 ? 1,641 ns/op > methodToString_1arg_patched avgt 50 197,900 ? 5,824 ns/op > > methodToString_1arg:?gc.alloc.rate.norm avgt 50 1209,600 ? 6,401 B/op > methodToString_1arg_patched:?gc.alloc.rate.norm avgt 50 936,000 ? 0,001 B/op > > methodToString_noArgs avgt 50 224,054 ? 1,840 ns/op > methodToString_noArgs_patched avgt 50 78,195 ? 0,418 ns/op > > methodToString_noArgs:?gc.alloc.rate.norm avgt 50 1131,200 ? 7,839 B/op > methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 50 408,000 ? 0,001 B/op > > > As Brian suggested I've separated the changes. The patch attached contains only the changes for Class::methodToString. They are obviously helpful as they rid concatenation as argument of StringBuilder::append call (obvious antipattern to me) and skip Stream creation for empty array. > > String::repeat obviously requires more investigation, it might turn out we don't need it in java.base in majority of use cases or in all of them. > > Regards, > Sergei Tsypanov > > > > 21.03.2019, 00:56, "Peter Levart" : >> Hi Sergei, >> >> I don't know if you are aware that the new invokedynamic based >> translation of string concatenation expressions introduced in JDK 9 >> (http://openjdk.java.net/jeps/280) only applies to code outside >> java.base module. java.base module is still compiled with old-style >> StringBuilder based translation of string concatenation expressions >> because of bootstraping issues. >> >> If your benchmarks bellow are compiled with option >> -XDstringConcat=inline to disable JEP280 translation (as java.base >> module is), then it's OK. Else you are not benchmarking the right >> translation of the code as you intend to change the code in java.base >> module. >> >> Regards, Peter >> >> On 3/20/19 7:35 PM, ?????? ??????? wrote: >>> ?I had a brief conversation with Brian Goetz which has left off the mailing list for some reason. Here's the text: >>> ?--------------------------- >>> ?Brian: >>> >>> ?These enhancements seem reasonable; these are exactly the cases that String::repeat was intended for. (This is a ?is this a reasonable idea? review, not a code review.). >>> ?Have you looked for other places where similar transformations could be done? >>> >>> ?--------------------------- >>> ?Me: >>> >>> ?Hello, >>> ?after I had realized that looped StringBuilder::append calls can sometimes be replaced with String::repeat I requested corresponding inspection in IDEA issue tracker. >>> ?Using the inspection I?ve found 129 similar warnings in jdk13 repo. >>> ?Some of them are very promising, e.g. BigDecimal:: toPlainString where currently we have >>> >>>> ?int trailingZeros = checkScaleNonZero((-(long)scale)); >>>> ?StringBuilder buf; >>>> ?if(intCompact!=INFLATED) { >>>> ??????buf = new StringBuilder(20+trailingZeros); >>>> ??????buf.append(intCompact); >>>> ?} else { >>>> ??????String str = intVal.toString(); >>>> ??????buf = new StringBuilder(str.length()+trailingZeros); >>>> ??????buf.append(str); >>>> ?} >>>> ?for (int i = 0; i < trailingZeros; i++) { >>>> ??????buf.append('0'); >>>> ?} >>>> ?return buf.toString(); >>> ?which in fact can be simplified to >>> >>>> ?int trailingZeros = checkScaleNonZero((-(long)scale)); >>>> ?if(intCompact!=INFLATED) { >>>> ??????return intCompact + "0".repeat(trailingZeros); >>>> ?} else { >>>> ??????return intVal.toString() + "0".repeat(trailingZeros); >>>> ?} >>> ?The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. >>> ?BTW, your reply to original message for some reason is missing from web-view. >>> >>> ?--------------------------- >>> ?Brian: >>> >>> ?Cool. Note that replacing append() calls with repeat is not necessarily a win for anything other than code compactness; String::repeat will create a new string, which will then get appended to another StrinBuilder. So when used correctly (such as presized StringBuilders) appending in a loop is probably just as fast (look at the implementation of String::repeat.). >>> >>>> ?if(intCompact!=INFLATED) { >>>> ??????return intCompact + "0".repeat(trailingZeros); >>>> ?} else { >>>> ??????return intVal.toString() + "0".repeat(trailingZeros); >>>> ?} >>> ?Which can be further simplified to >>> >>>> ?????((intCompact != INFLATED) ? intCompact : intVal.toString) + ?0?.repeat(trailingZeros); >>> ?The second solution is not only shorter and more simple but it likely to be significantly faster and memory-saving. >>> ?I like short and simple. I am questioning the ?faster and memory saving.? That should be validated. >>> >>> ?--------------------------- >>> ?Me: >>> >>> ?I think optimizations provided by JEP 280 allow compiler to optimize String concatenation executed with '+' by using StringBuilder of exact size (when the size of all components is known, like in our case). >>> >>> ?I've checked this with benchmark >>> >>>> ?@State(Scope.Thread) >>>> ?@BenchmarkMode(Mode.AverageTime) >>>> ?@OutputTimeUnit(TimeUnit.NANOSECONDS) >>>> ?@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >>>> ?public class ConcatBenchmark { >>>> >>>> ??????@Param({"1", "2", "5", "8"}) >>>> ??????private int trailingZeros; >>>> >>>> ??????private final long intCompact = 1L; >>>> >>>> ??????@Benchmark >>>> ??????public String stringBuilder() { >>>> ??????????StringBuilder buf; >>>> ??????????buf = new StringBuilder(20 + trailingZeros); >>>> ??????????buf.append(intCompact); >>>> ??????????for (int i = 0; i < trailingZeros; i++) { >>>> ??????????????buf.append('0'); >>>> ??????????} >>>> ??????????return buf.toString(); >>>> ??????} >>>> ??????@Benchmark >>>> ??????public String stringRepeat() { >>>> ??????????return intCompact + "0".repeat(trailingZeros); >>>> ??????} >>>> ?} >>> ?Results: >>> ??????????????????????????????????????????trailingZeros Mode Cnt Score Error Units >>> ?stringBuilder 1 avgt 15 17,683 ? 0,664 ns/op >>> ?stringRepeat 1 avgt 15 9,052 ? 0,042 ns/op >>> >>> ?stringBuilder 2 avgt 15 19,053 ? 1,206 ns/op >>> ?stringRepeat 2 avgt 15 15,864 ? 1,331 ns/op >>> >>> ?stringBuilder 5 avgt 15 25,839 ? 2,256 ns/op >>> ?stringRepeat 5 avgt 15 19,290 ? 1,685 ns/op >>> >>> ?stringBuilder 8 avgt 15 26,488 ? 0,371 ns/op >>> ?stringRepeat 8 avgt 15 19,420 ? 1,593 ns/op >>> >>> ?stringBuilder:?gc.alloc.rate.norm 1 avgt 15 88,000 ? 0,001 B/op >>> ?stringRepeat:?gc.alloc.rate.norm 1 avgt 15 48,000 ? 0,001 B/op >>> >>> ?stringBuilder:?gc.alloc.rate.norm 2 avgt 15 88,000 ? 0,001 B/op >>> ?stringRepeat:?gc.alloc.rate.norm 2 avgt 15 72,000 ? 0,001 B/op >>> >>> ?stringBuilder:?gc.alloc.rate.norm 5 avgt 15 96,000 ? 0,001 B/op >>> ?stringRepeat:?gc.alloc.rate.norm 5 avgt 15 72,000 ? 0,001 B/op >>> >>> ?stringBuilder:?gc.alloc.rate.norm 8 avgt 15 104,000 ? 0,001 B/op >>> ?stringRepeat:?gc.alloc.rate.norm 8 avgt 15 80,000 ? 0,001 B/op >>> >>> ?I think this is a useful optimization, so we should use String::repeat where possible. >>> >>> ?--------------------------- >>> ?Brian: >>> >>> ?My recommendation is to split your patch into two. The first is the straightforward ?replace loop with repeat? refactoring, which can be mechanically generated by the IDE. Here, you should examine each site to ensure that the transform seems sensible given the context. The second can then be additional hand-refactoring opportunities exposed by the first. The benefit of splitting it this way is that reviewing the first is far easier when you can say all the changes are mechanical. >>> >>> ?(Somehow this fell off the list; feel free to bring it back.) >>> >>> ?18.03.2019, 21:13, "?????? ???????" : >>>> ?Hi, >>>> >>>> ?I have an enhancement proposal for java.lang.Class.methodToString and java.lang.Class.getTypeName. >>>> >>>> ?First one is used when NoSuchMethodException is thrown from Class::getMethod which is in turn widely used in Spring Framework and often throws. >>>> >>>> ?In current implementation we have 2 major problems: >>>> >>>> ?- we create stream for the case when argTypes is not null but empty (which happens e. g. when Class::getMethod is called without vararg and throws) >>>> ?- we have torn StringBuilder::append chain >>>> >>>> ?I?ve modified the method to skip creation of Stream for empty array and used separate StringBuilder for each case. Latter allowed to rid SB completely and use invokedynamic-based concatenation. >>>> >>>> ?I?ve compared both approaches for 2 cases: >>>> >>>> ?1) argTypes is empty >>>> ?2) argTypes.length == 1 >>>> >>>> ?Benchmark Mode Cnt Score Error Units >>>> >>>> ?methodToString_noArgs avgt 25 170,986 ? 5,708 ns/op >>>> ?methodToString_noArgs_patched avgt 25 26,883 ? 2,906 ns/op >>>> >>>> ?methodToString_1arg avgt 25 183,012 ? 0,701 ns/op >>>> ?methodToString_1arg_patched avgt 25 112,784 ? 0,920 ns/op >>>> >>>> ?methodToString_noArgs:?gc.alloc.rate.norm avgt 25 881,600 ? 9,786 B/op >>>> ?methodToString_noArgs_patched:?gc.alloc.rate.norm avgt 25 128,000 ? 0,001 B/op >>>> >>>> ?methodToString_1arg:?gc.alloc.rate.norm avgt 25 960,000 ? 0,001 B/op >>>> ?methodToString_1arg_patched:?gc.alloc.rate.norm avgt 25 552,000 ? 0,001 B/op >>>> >>>> ?We have the same problem regarding misusage of StringBuilder in Class:: getTypeName: >>>> >>>> ?StringBuilder sb = new StringBuilder(); >>>> ?sb.append(cl.getName()); >>>> ?for (int i = 0; i < dimensions; i++) { >>>> ????? sb.append("[]"); >>>> ?} >>>> ?return sb.toString(); >>>> >>>> ?I suggest to use String::repeat instead of the loop: this again allows to get rid of StringBuilder and replace mentioned code with >>>> >>>> ?return cl.getName() + "[]".repeat(dimensions); >>>> >>>> ?Here are benchmark results executed for type Object[].class: >>>> >>>> ????????????????????????????????????????????Mode Cnt Score Error Units >>>> ?getTypeName_patched avgt 25 16,037 ? 0,431 ns/op >>>> ?getTypeName_patched:?gc.alloc.rate.norm avgt 25 64,000 ? 0,001 B/op >>>> >>>> ?getTypeName avgt 25 34,274 ? 1,432 ns/op >>>> ?getTypeName:?gc.alloc.rate.norm avgt 25 152,000 ? 0,001 B/op >>>> >>>> ?Regards, >>>> ?Sergei Tsypanov From andy.herrick at oracle.com Fri Mar 29 19:41:34 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 29 Mar 2019 15:41:34 -0400 Subject: jpackage EA 5 Build 36 (2019/3/28) Message-ID: <564523a0-f9ef-be0f-dfd2-7c67c8a7f7a4@oracle.com> A fifth EA build (Build 36) of jpackage tool is available at https://jdk.java.net/jpackage/ This release contains fixes to the following: JDK-8221256 Fix create-installer specific options on MAC JDK-8215241 Permissions are not set correctly on sub-folders in /Applications JDK-8221525 jpackage fails with non-ASCII characters in --copyright JDK-8215019 Allow --install-dir on windows JDK-8220804 Help message for @ argfile option is printed in the wrong place please send feedback to core-libs-dev at openjdk.java.net /Andy Herrick From patrick at os.amperecomputing.com Sat Mar 30 05:34:26 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Sat, 30 Mar 2019 05:34:26 +0000 Subject: ConcurrentModificationException thrown by HashMap.compute() operating on an empty Map, expected/unexpected? Message-ID: Hi, Here I have a case simplified from a practical issue that throws ConcurrentModificationException (CME) unexpectedly (I think). [0] creates a HashMap, keeps it empty, and calls m.computeIfAbsent() or m.compute(), in which a "sneaky" m.clear() occurs, some of the test cases throw CME although there were no "structural" changes in fact. (A structural modification is defined as "any operation that adds or deletes one or more mappings..."). This case cannot be reproduced with jdk8u, while jdk9 and beyond can, after the bug [1] got fixed for computeIfAbsent() concurrent co-modification issues. A couple of test cases [2] were introduced at that time, and the focus was to verify the behaviors at resizing, while empty maps were not tested. A possible "fix" for this issue is to move the unconditional "modCount++" [3] into the if-clause, which indicates that a "structural" change would be happening indeed. public void clear() { Node[] tab; - modCount++; if ((tab = table) != null && size > 0) { + modCount++; size = 0; for (int i = 0; i < tab.length; ++i) tab[i] = null; } } Therefore, a dilemma here is "modCount++ before-if-clause but overkills some cases" vs. "modCount++ into-if-clause but weakens the CME checking potentially". I want to make balance regarding how to "throw CME on a best-effort basis" more appropriately. Any suggestion? I understand that CME here in HashMap.java cannot guarantee much and may be only for debugging purpose, any concurrent modification needs to be typically accomplished by synchronizing on some object that naturally encapsulates the map. So the mentioned issue is a just a tricky case. [0]http://cr.openjdk.java.net/~qpzhang/map.clear/webrev.01/test/jdk/java/util/concurrent/ConcurrentMap/ConcurrentModification.java.udiff.html [1]https://bugs.openjdk.java.net/browse/JDK-8071667 [2]http://hg.openjdk.java.net/jdk/jdk/file/5a9d780eb9dd/test/jdk/java/util/Map/FunctionalCMEs.java [3]http://hg.openjdk.java.net/jdk/jdk/file/1042cac8bc2a/src/java.base/share/classes/java/util/HashMap.java#l860 Regards Patrick From ivan.gerasimov at oracle.com Sat Mar 30 06:29:29 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 29 Mar 2019 23:29:29 -0700 Subject: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified In-Reply-To: References: <755e2c2a-943b-562f-e10c-e2ae29e8ba8a@oracle.com> <08ffa0f7-4cbd-c946-2250-ddcb8bed612f@oracle.com> <64ea5dc1-990f-f772-d970-1b0b24f3dc9b@oracle.com> <5160cae7-d4d7-3edd-5045-e09c0a52ad71@oracle Message-ID: <257e94c4-2429-89a0-50df-ed020c0093d2@oracle.com> It was a good suggestion to run micro benchmarks! First, it turned out that (at least in some scenarios) StringBuilder(String) is not intrinsified. I.e., running benchmarks with/without '-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_StringBuilder_String' led to the same numbers. Here they are prior the fix: Benchmark Mode Cnt Score Error Units StringBuilders.fromLatin1String avgt 18 16.378 ? 0.378 ns/op StringBuilders.fromLatin1StringBuilder avgt 18 19.975 ? 0.195 ns/op StringBuilders.fromUtf8String avgt 18 19.946 ? 2.774 ns/op StringBuilders.fromUtf8StringBuilder avgt 18 34.317 ? 0.415 ns/op Second, with the fix from the webrev.01, the performance has degraded: Benchmark Mode Cnt Score Error Units StringBuilders.fromLatin1String avgt 18 24.517 ? 0.965 ns/op StringBuilders.fromLatin1StringBuilder avgt 18 20.025 ? 0.678 ns/op StringBuilders.fromUtf8String avgt 18 26.102 ? 0.627 ns/op StringBuilders.fromUtf8StringBuilder avgt 18 23.141 ? 0.394 ns/op So, it appears to be necessary to handle the case StringBuilder(String) separately from the general case. And here there is the new webrev: http://cr.openjdk.java.net/~igerasim/8221430/02/webrev/ This variant restores the performance, and shows some improvement in a case of StringBuilder(StringBuilder-with-UTF8-content): Benchmark Mode Cnt Score Error Units StringBuilders.fromLatin1String avgt 18 15.742 ? 0.189 ns/op StringBuilders.fromLatin1StringBuilder avgt 18 18.671 ? 0.109 ns/op StringBuilders.fromUtf8String avgt 18 17.172 ? 0.100 ns/op StringBuilders.fromUtf8StringBuilder avgt 18 21.885 ? 0.138 ns/op With kind regards, Ivan On 3/28/19 2:24 PM, Ivan Gerasimov wrote: > Apologize for the delay, got distracted by other urgent things. > > I've got some surprising micro-benchmark results, and need to > understand them before pushing the fix. > > I'll verify the results and then share details. > > With kind regards, > Ivan > > > On 3/28/19 9:41 AM, Roger Riggs wrote: >> Hi Andrew, >> >> I'm fine with Ivan's version too. >> >> Roger >> >> >> On 03/28/2019 12:13 PM, Andrew Leonard wrote: >>> Roger, Ivan, thanks for your help discussing this issue. Fyi, I am >>> off on leave for the next week, so I +1 Ivan's last webrev if that's >>> the way you decide to go.. >>> 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 >>> >>> >>> >>> >>> From: Roger Riggs >>> To: Ivan Gerasimov , Andrew Leonard >>> >>> Cc: core-libs-dev at openjdk.java.net >>> Date: 27/03/2019 13:39 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Ivan, >>> >>> On 03/26/2019 07:30 PM, Ivan Gerasimov wrote: >>> The main source of confusion here seems to be due to that the coder >>> is passed in as an argument, so it either needs to be trusted or has >>> to be verified in the constructor. >>> >>> The design for coder is that it *is* trusted in all >>> internal/implementation APIs. >>> Subsequent changes should not weaken this invariant, it will cause >>> doubt >>> in the code and cast doubt on all of the performance work that has >>> been done to optimize its use. >>> >>> So, let's instead introduce AbstractStringBuilder(CharSequence) and >>> make it do all manipulations. >>> _ >>> __http://cr.openjdk.java.net/~igerasim/8221430/01/webrev/_ >>> >>> >>> Note that the common case of StringBuilder(String) already gets >>> intrinsified by hotspot. >>> >>> What do you think? >>> >>> This looks good, the logic is in one place. >>> >>> Since StringBuilder(String) is an intrinsic, my doubt about a slight >>> performance >>> impact is unwarranted in that specific case. >>> >>> Are there any StringBuffer/Builder jmh tests than be easily rerun to >>> compare? >>> >>> Thanks, Roger >>> >>> >>> With kind regards, >>> Ivan >>> >>> On 3/26/19 1:04 PM, Ivan Gerasimov wrote: >>> From the design point of view, I believe it is better to have the >>> constructor AbstractStringBuilder(int, int, int) to check if the >>> coder argument makes sense with respect to the value of >>> COMPACT_STRING, so it won't be possible to create a StringBuilder >>> with the coder==LATIN1, when it is not supported. >>> >>> For calculating the coderHint then, it is not necessary to check >>> COMPACT_STRING: If the CharSequence argument is in fact String or >>> AbstractStringBuilder, the coder is known, otherwise LATIN1 can be >>> passed in as a hint (for an arbitrary CharSequence it is not 100% >>> accurate anyway). >>> The constructor AbstractStringBuilder(int, int, int) will then >>> either use the provided coder, or adjust it if necessary. >>> >>> Will we agree on something like following? >>> _ >>> __http://cr.openjdk.java.net/~igerasim/8221430/00/webrev/_ >>> >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 3/26/19 12:14 PM, Roger Riggs wrote: >>> Hi, >>> >>> We've got the subject open and its fresh, there's no need for a >>> separate review cycle. >>> >>> The first fix (-01) does not seem to be consistent with the original >>> design >>> and handling of the coder. The StringBuilder(String) and >>> StringBuffer(String) >>> constructors are the pattern that should be followed for determining >>> the coder for the new instance. >>> >>> Checking for COMPACT_STRING in two places (the AbstractStringBuilder >>> and >>> the sub classes) is unnecessary and distributes the information >>> about the >>> correct coder across two classes where determining what it should be >>> in the subclass has more complete information and can correctly >>> determine >>> the coder once. >>> >>> We can likely find a reviewer to be a tie-breaker if Ivan sees it as >>> desirable. >>> >>> Thanks, Roger >>> >>> >>> On 03/26/2019 02:38 PM, Andrew Leonard wrote: >>> Sorry chaps, I think my brain is getting confused!, I think we have >>> conflicting reviews here? >>> >>> Roger, I added the getCharSequenceCoder() to AbstractStringBuilder >>> so it was only defined in one place.. >>> I agree with this being called in StringBuffer/Builder then we don't >>> need the change to AbstractStringBuild() constuctor, however Ivan >>> wants getCharSequenceCoder() that done as a separate "bug". >>> >>> So I think it comes down to do we do this as 2 "bugs" or 1 ? >>> >>> 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_ >>> >>> >>> >>> >>> >>> From: Roger Riggs __ >>> >>> To: Andrew Leonard __ >>> , Ivan Gerasimov >>> __ >>> Cc: _core-libs-dev at openjdk.java.net_ >>> >>> Date: 26/03/2019 18:19 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Andrew, >>> >>> You are going to have to change the same code twice >>> because the changes should be the StringBuffer and StringBuilder >>> constructors and would remove the code that is added to >>> the AbstractStringBuilder constructor. That's a waste of review >>> cycles. >>> >>> >>> On 03/26/2019 11:45 AM, Andrew Leonard wrote: >>> Hi Roger, >>> No worries, the more the merrier! >>> So that was one of my reasoning for adding getCharSequenceCode() >>> was, I think what you're suggesting is my webrev.01, >>> __http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/__ >>> __ >>> >>> Ivan's view is that behaviour was an extended issue, which it is, >>> but I thought it was nice to add.. >>> >>> Which patch do we favour? webrev-01 or -02 ? >>> >>> Neither, there should be no change to the AbstractStringBuilder >>> constructor >>> and the change should be done in the subclass constructors. >>> >>> Roger >>> >>> >>> 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_ >>> __ >>> >>> >>> >>> >>> >>> From: Roger Riggs ___ >>> _ __ >>> >>> To: _core-libs-dev at openjdk.java.net_ >>> __ >>> >>> Date: 26/03/2019 15:24 >>> Subject: Re: Request for sponsor: JDK-8221430: >>> StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings specified >>> Sent by: "core-libs-dev" ___ >>> _ >>> __ >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Hi Andrew, >>> >>> Sorry to be late to the review. >>> >>> For symmetry with the constructors StringBuffer(String), and >>> StringBuilder(String) >>> the determine the coder based on the input argument, I would recommend >>> using the getCharSequenceCoder added in the -01 webrev and calling >>> it from the StringBuffer(CharSeq...), and StringBuilder(CharSeq...) >>> constructors. >>> >>> It would be symmetric with the getCoder() method (line 1635) >>> and select the appropriate coder base on the input value (if known.) >>> >>> Thanks, Roger >>> >>> >>> >>> On 03/26/2019 10:57 AM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > Yes, i'm happy with that, as you say the simple constructor change >>> fixes >>> > the immediate issue, but not necessarily the extended issue of a >>> > non-compactable CharSequence in COMPACT_STRINGS mode, but that's >>> probably >>> > an enhanced issue to cover in a separate bug... >>> > I've created a new webrev.02 with just the constructor change and the >>> > testcase: >>> > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.02/__ >>> __ >>> >>> > >>> > 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_ >>> __ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov ___ >>> _ >>> __ >>> > To: Andrew Leonard ___ >>> _ >>> __ >>> >>> > Cc: _core-libs-dev at openjdk.java.net_ >>> __ >>> >>> > Date: 26/03/2019 01:18 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > Thanks Andrew! >>> > Introducing getCharSequenceCoder() is actually an enhancement, >>> which may >>> > improve pre-allocation in certain cases. >>> > It's not actually required to restore correctness of >>> StringBuilder/Buffer >>> > constructors. >>> > I recommend to separate it from this bug fix, so it can be discussed >>> > separately, and determined if this is the best approach to this >>> > enhancement. >>> > If you agree, I can adjust your latest patch accordingly, run it >>> through >>> > the Mach5 test systems and push it on your behalf. >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 5:00 PM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > Here is my updated webrev: >>> > __http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/__ >>> __ >>> >>> > >>> > 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_ >>> __ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov ___ >>> _ >>> __ >>> > To: Andrew Leonard ___ >>> _ >>> __ >>> >>> > Cc: _core-libs-dev at openjdk.java.net_ >>> __ >>> >>> > Date: 25/03/2019 22:55 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > I was thinking of organizing code similar to what is done in >>> > AbstractStringBuilder(int): >>> > >>> > if (COMPACT_STRINGS && coderHint == LATIN1) { >>> > value = new byte[capacity]; >>> > coder = LATIN1; >>> > } else { >>> > value = StringUTF16.newBytesFor(capacity); >>> > coder = UTF16; >>> > } >>> > >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 3:45 PM, Andrew Leonard wrote: >>> > Hi Ivan, >>> > I think I see what you're saying, you mean we also need to correct >>> this >>> > line in AbstractStringBuilder >>> > constructor: >>> > value = (coder == LATIN1) >>> > ? new byte[capacity] : >>> StringUTF16.newBytesFor(capacity); >>> > to be maybe: >>> > value = (COMPACT_STRINGS && coder == LATIN1) >>> > ? new byte[capacity] : >>> StringUTF16.newBytesFor(capacity); >>> > >>> > The passed in coder stills need to be correct, since with >>> COMPACT_STRINGS >>> > a string could be UTF16 if >>> > it cannot be compacted, so it's more than just a hint isn't it? >>> > >>> > 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_ >>> __ >>> >>> > >>> > >>> > >>> > >>> > From: Ivan Gerasimov ___ >>> _ >>> __ >>> > To: Andrew Leonard ___ >>> _ >>> __ >>> , >>> > _core-libs-dev at openjdk.java.net_ >>> __ >>> >>> > Date: 25/03/2019 22:20 >>> > Subject: Re: Request for sponsor: JDK-8221430: >>> > StringBuffer(CharSequence) constructor truncates when >>> -XX:-CompactStrings >>> > specified >>> > >>> > >>> > >>> > Hi Andrew! >>> > >>> > Thanks for finding this bug! >>> > >>> > Your fix solves the problem. >>> > >>> > However, I think the main issue is that the constructor >>> > AbstractStringBuilder(byte,int,int) is now broken: as you >>> discovered, >>> > it allows to create a string buffer with the coder LATIN1 when >>> > COMPACT_STRINGS is false. >>> > >>> > Wouldn't it make sense to rename the argument of the constructor to, >>> > say, coderHint, and then either use it as the coder if >>> > COMPACT_STRINGS==true, or discard it otherwise. >>> > >>> > What do you think? >>> > >>> > With kind regards, >>> > Ivan >>> > >>> > On 3/25/19 12:45 PM, Andrew Leonard wrote: >>> >> Hi, >>> >> Please can I request a sponsor for this fix to a JDK-13 regression? >>> >> >>> >> Patch with jtreg testcase here: >>> >> __http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/__ >>> __ >>> >>> >> >>> >> bug: __https://bugs.openjdk.java.net/browse/JDK-8221430__ >>> >> >>> >> Many 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 >>> >>> >>> >>> 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 >> > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Sat Mar 30 09:03:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 30 Mar 2019 09:03:41 +0000 Subject: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: References: <758af3c4-c59f-ea25-8491-2dcdab7bda17@oracle.com> Message-ID: <43304634-d902-b006-3159-3537433d9f67@oracle.com> On 29/03/2019 12:36, Baesken, Matthias wrote: > Thanks. Alan, are you fine with the current webrev, if yes may I add you as reviewer ? > The update to java_md.c looks okay, I probably would re-format the comment to void the line longs but it is otherwise okay. I think the new test needs a of bit clean-up, L490 is the main issue. One suggest is to rename pLong to longPath and build up ots value in a loop to avoid having a 340+ character line? The other variables names are very strange too but I can you can eliminate some of them by changing L491-492 to: ???? Path jarPath = Files.createDirectories(longPah).resolve("foo.jar"); -Alan From Alan.Bateman at oracle.com Sun Mar 31 15:29:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 31 Mar 2019 16:29:19 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> Message-ID: On 20/03/2019 16:25, Langer, Christoph wrote: > Hi Alan, > > I now found time to get back to the POSIX file permissions in zipfs. The goal would be to get it done for JDK13 ?? > > : > > Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.8/ > > What's next? > I skimmed through the updated webrev and read your latest comments/replies and I think we are close. One thing that is puzzling is that ZipFileAttributeView/ZipFileAttributes extend PosixFileAttributeView/PosixFileAttributes. I don't think that will work because the "zip" view is supported by default whereas "posix" view needs the file system to be created with enablePosixFileAttributes=true. I saw your comment about naming the file permissions attribute "storedPermissions" in the zip view but if the zip and posix view are separated then I think it would be clearer to name it "permissions" in the zip view. If code is using Files.getAttribute then it will need the view name so they won't get mixed up. You asked about the fallback when defaultOwner/defaultGroup aren't set. If getOwner fails with an IOException then I think that exception should be propagated. The UOE case will fallback to the value of "user.name". I think the fallback for the group owner should be the file owner rather than " "". The default.policy file will need to be updated to grant jdk.zipfs RuntimePermission("accessUserInfo") so that you won't need to deal with security exceptions. As regards next steps then I think we need to agree the spec changes, as in the the javadoc in module-info.java. Once we have the spec agreed then the CSR can be updated and finalized. The code review can be done in parallel of course. I think Lance is going to help review the changes. -Alan