From leventov.ru at gmail.com Wed Jan 1 15:43:22 2020 From: leventov.ru at gmail.com (Roman Leventov) Date: Wed, 1 Jan 2020 18:43:22 +0300 Subject: Note bulk methods in Javadocs for Collections.synchronizedXxx() In-Reply-To: References: Message-ID: Maybe it also makes sense to modify common JDK's impls of addAll(), remove all(), and putAll() to make use of forEach() on the argument collection? On Sat, 28 Dec 2019, 18:23 Pavel Rappo, wrote: > If we were to add something like that to the documentation, it would > probably go > under @apiNote (section "pitfalls", hehe). > > As you said, the spec says just enough to infer that. So, strictly > speaking, > there's no need to add that note. After all, there are infinite ways to use > these, synchronized, collections incorrectly and only one way to use them > right. > > Maybe we could tackle this (and similar requests in the future) by adding, > once > and for all, something like: > > Consider using concurrent collections instead, such as those that can > be > found in the java.util.concurrent package. > > -Pavel > > > On 28 Dec 2019, at 09:50, Roman Leventov wrote: > > > > I think Javadocs for Collections.synchronizedXxx() should mention not > > only "traversing it via Iterator, Spliterator or Stream" as something > that > > must be synchronized externally, but also cases when a synchronized > > collection is an argument to a bulk collection method, including: > > - new ArrayList(syncList), new HashSet(syncSet), etc. > > - List.copyOf(syncList) > > - otherColl.addAll(syncList), otherColl.removeAll(syncList), > > otherMap.putAll(syncMap). > > > > Though this is logically inferable, this is far from being obvious and > > apparent. > > From pavel.rappo at oracle.com Wed Jan 1 17:35:02 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 1 Jan 2020 17:35:02 +0000 Subject: Note bulk methods in Javadocs for Collections.synchronizedXxx() In-Reply-To: References: Message-ID: <3B7058A4-E90F-46EC-8F78-FD7D810BDB62@oracle.com> What would the reasons for that be? Mind you, this is a separate issue. > On 1 Jan 2020, at 15:43, Roman Leventov wrote: > > Maybe it also makes sense to modify common JDK's impls of addAll(), remove all(), and putAll() to make use of forEach() on the argument collection? > > On Sat, 28 Dec 2019, 18:23 Pavel Rappo, wrote: > If we were to add something like that to the documentation, it would probably go > under @apiNote (section "pitfalls", hehe). > > As you said, the spec says just enough to infer that. So, strictly speaking, > there's no need to add that note. After all, there are infinite ways to use > these, synchronized, collections incorrectly and only one way to use them right. > > Maybe we could tackle this (and similar requests in the future) by adding, once > and for all, something like: > > Consider using concurrent collections instead, such as those that can be > found in the java.util.concurrent package. > > -Pavel > > > On 28 Dec 2019, at 09:50, Roman Leventov wrote: > > > > I think Javadocs for Collections.synchronizedXxx() should mention not > > only "traversing it via Iterator, Spliterator or Stream" as something that > > must be synchronized externally, but also cases when a synchronized > > collection is an argument to a bulk collection method, including: > > - new ArrayList(syncList), new HashSet(syncSet), etc. > > - List.copyOf(syncList) > > - otherColl.addAll(syncList), otherColl.removeAll(syncList), > > otherMap.putAll(syncMap). > > > > Though this is logically inferable, this is far from being obvious and > > apparent. > From forax at univ-mlv.fr Wed Jan 1 17:58:47 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 1 Jan 2020 18:58:47 +0100 (CET) Subject: Note bulk methods in Javadocs for Collections.synchronizedXxx() In-Reply-To: References: Message-ID: <1529712970.279832.1577901527900.JavaMail.zimbra@u-pem.fr> Hi Roman, addAll() returns a boolean that will be not easy to compute given that forEach() takes a lambda (that can only capture local values and not change them). and the javadoc of AbstractCollection clearly states that addAll has to use an iterator if implemented https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/AbstractCollection.html#addAll(java.util.Collection) regards, R?mi ----- Mail original ----- > De: "Roman Leventov" > ?: "Pavel Rappo" > Cc: "core-libs-dev" > Envoy?: Mercredi 1 Janvier 2020 16:43:22 > Objet: Re: Note bulk methods in Javadocs for Collections.synchronizedXxx() > Maybe it also makes sense to modify common JDK's impls of addAll(), remove > all(), and putAll() to make use of forEach() on the argument collection? > > On Sat, 28 Dec 2019, 18:23 Pavel Rappo, wrote: > >> If we were to add something like that to the documentation, it would >> probably go >> under @apiNote (section "pitfalls", hehe). >> >> As you said, the spec says just enough to infer that. So, strictly >> speaking, >> there's no need to add that note. After all, there are infinite ways to use >> these, synchronized, collections incorrectly and only one way to use them >> right. >> >> Maybe we could tackle this (and similar requests in the future) by adding, >> once >> and for all, something like: >> >> Consider using concurrent collections instead, such as those that can >> be >> found in the java.util.concurrent package. >> >> -Pavel >> >> > On 28 Dec 2019, at 09:50, Roman Leventov wrote: >> > >> > I think Javadocs for Collections.synchronizedXxx() should mention not >> > only "traversing it via Iterator, Spliterator or Stream" as something >> that >> > must be synchronized externally, but also cases when a synchronized >> > collection is an argument to a bulk collection method, including: >> > - new ArrayList(syncList), new HashSet(syncSet), etc. >> > - List.copyOf(syncList) >> > - otherColl.addAll(syncList), otherColl.removeAll(syncList), >> > otherMap.putAll(syncMap). >> > >> > Though this is logically inferable, this is far from being obvious and >> > apparent. >> From mandy.chung at oracle.com Thu Jan 2 00:41:38 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Jan 2020 16:41:38 -0800 Subject: RFR(S) : 8234309:LFGarbageCollectedTest.java fails with parse Exception In-Reply-To: <8088e817-efe9-4191-9c75-74093376556d@default> References: <37c6ccee-8cbe-458b-aa09-2c93289e0d8f@default> <8088e817-efe9-4191-9c75-74093376556d@default> Message-ID: Looks okay. Mandy On 12/16/19 1:00 AM, Sureshkumar Mahaliswamy wrote: > Gentle Remainder . > > > > Kindly review , this is just a small patch. > > > > > > Thanks, > > Suresh. > > > > From: Sureshkumar Mahaliswamy > Sent: Wednesday, November 27, 2019 1:16 PM > To: core-libs-dev at openjdk.java.net > Subject: RFR(S) : 8234309:LFGarbageCollectedTest.java fails with parse Exception > > > > Hi All, > > > > Kindly review the small patch. > > Moved @library /lib/testlibrary /java/lang/invokGene/common to the top to avoid the parse exception and report as Test ignored. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234309 > > Webrev: http://cr.openjdk.java.net/~vagarwal/8234309/webrev.0/ > > > > Testing: tested with jtreg. > > > > Thanks, > > Suresh. > > From erik.joelsson at oracle.com Thu Jan 2 07:57:07 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Jan 2020 08:57:07 +0100 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> Message-ID: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com> Build files look good. /Erik On 2019-12-24 19:22, Sergey Bylokhov wrote: > Hello. > > Here is an updated version: > ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 > ? Patch (2 Mb): > http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch > ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/ > > ?- "jdk.internal.vm.compiler" is removed from the patch. > ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" > > On 12/22/19 11:24 pm, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 15. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 >> Patch (2 Mb): >> http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch >> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 >> >> I have updated the source code copyrights by the >> "update_copyright_year.sh" >> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 >> because of: "JDK-8187443: Forest Consolidation: Move files to unified >> layout" >> which touched all files. >> >> > > From Sergey.Bylokhov at oracle.com Thu Jan 2 12:02:14 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Jan 2020 15:02:14 +0300 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com> Message-ID: <0caab700-28e3-16e7-db00-b698557443f0@oracle.com> I guess it is too late to fix it, will need to update the files at the end of 2020. On 1/2/20 10:57 am, Erik Joelsson wrote: > Build files look good. > > /Erik > > On 2019-12-24 19:22, Sergey Bylokhov wrote: >> Hello. >> >> Here is an updated version: >> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 >> ? Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch >> ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/ >> >> ?- "jdk.internal.vm.compiler" is removed from the patch. >> ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" >> >> On 12/22/19 11:24 pm, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for JDK 15. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 >>> Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch >>> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 >>> >>> I have updated the source code copyrights by the "update_copyright_year.sh" >>> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 >>> because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" >>> which touched all files. >>> >>> >> >> -- Best regards, Sergey. From simonisv at amazon.de Thu Jan 2 13:26:28 2020 From: simonisv at amazon.de (Volker Simonis) Date: Thu, 2 Jan 2020 14:26:28 +0100 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <6d674d42-32e5-2abc-ef2f-d3dd1fe0c3d8@oracle.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> <6d674d42-32e5-2abc-ef2f-d3dd1fe0c3d8@oracle.com> Message-ID: On 31.12.19 18:06, Alan Bateman wrote: > On 31/12/2019 16:54, Verghese, Clive wrote: >> Hi Volker, >> >> Thank you for reviewing the changes and approving. >> > Do you know if there is any test coverage for this method? The builder > is package-private and I think your original mail said that it was > uncovered when invoking the toString from the debugger so I assume > not. I think we should at least try to add a test. > OK, I've added a test now: http://cr.openjdk.java.net/~simonis/webrevs/2020/8235699.02/ Ready to push? > -Alan Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From adam.farley at uk.ibm.com Thu Jan 2 16:21:13 2020 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 2 Jan 2020 16:21:13 +0000 Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes In-Reply-To: References: <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com> <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com> <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com> Message-ID: Bump :) Hi Mandy, Sorry for the delay in responding. Mandy Chung wrote on 29/10/2019 19:30:55: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 29/10/2019 19:31 > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > for Specific Classes > > Hi Adam, > > It'd be useful to provide a few typical scenarios that customers run into. > > That would give better understanding on the problem "hard to diagnose > why a given class was not loaded" and help the consideration on > alternatives. I'm happy to provide some hypothetical example scenarios, which I've included below. We should note that this is not limited to customers, and that this sort of diagnostic output is also extremely useful for people helping customers to resolve issues. I've also included the way the webrev's debug output aids people trying to reproduce this problem. Scenario 1: A user gets a ClassNotFoundException because the location of the class is not on the classpath used by the ClassLoader/s that attempted to load it, despite the fact that one ClassLoader definitely has the location of the class on its classpath. Aid: This webrev's debug output tells the user, or the tech support aiding the user: - If the ClassLoader with the classpath location for that class is ever tasked with trying to load that class. - If the ClassLoader with the classpath location for that class actually tries to load that class from the classpath (vs a module). - If the ClassLoader with the classpath location actually checks that location at all. - What other ClassLoaders are used to attempt to load that class, allowing the user/support agent to adjust the classpath for another ClassLoader if needed. Scenario 2: A program uses the wrong version of a class. Aid: This webrev's debug output tells the user, or the tech support aiding the user: - Which classpath was used by the ClassLoader that loaded the class at the time that the class was loaded. - Which locations were checked by that ClassLoader before finding the wrong version of the class. This, among other things, helps identify access issues for the location of the correct class. - Which ClassLoaders attempted to load the class, and in which order, (increasingly useful in the current "nested" ClassLoading model). Scenario 3: A program is unable to find a class because none of the ClassLoaders could find it, and you lack both familiarity with the ClassLoader code, and the time to figure out how all of the different ones work. Aid: This webrev's debug output tells the user, or the tech support aiding the user: - Which ClassLoaders were involved in each attempt to load the class. - What the logic path was for each ClassLoader asked to load the class. - Which module/s, if any, were identified by the ClassLoader as the potential owner/s of the class, and how that worked out in each case. > The debug output could produce lots of trace output but > the output does not clearly indicate the initiating class is. Correct. The scope of my debug output was limited to the actions of the ClassLoader/s attempting to load a class that matches a specific regex. > I wonder > if the problem you are looking at is related to JDK-6747450 [1] or > really tracing the class loader delegation and search path. The latter. If I implied that I was interested in the initiating class, then I was wrong. Also, though I am not fundamentally opposed to expanding the scope to incorporate JDK-6747450, the fact that it's been drifting for nine years tells me I'd just be adding complexity without adding anything that would support the inclusion of the change. Short version: I think this issue's scope should not include details of the initiating class. > Or maybe > Java Flight Recorder is a better candidate? I don't know much about Java Flight Recorder, as it currently only supports one of the VMs I work with. > Without knowing specific > of the problems customers have, perhaps VM logging can be enhanced to > trace the initiating class and class loader? > > Mandy It's possible. I wouldn't know where to start with that. The simplest, and most straight-forward approach (in my mind) is to add the debug code directly to the code we're debugging. Plus, using a Class Library -based approach ensures that the debug output is available regardless of the VM being used, or the user's familiarity with Flight Recorder. Though this might just be a "me" problem. ;) What do you think? Best Regards Adam Farley > [1] https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6747450&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i- > YQhYV5AAXM&s=CRaeo9i-X27ZxNvgxD0IOJVROj6VpmLk5YINn7iJaVA&e= > > On 10/29/19 5:08 AM, Adam Farley8 wrote: > > Hey All, > > > > To restart (and re-centre) the chat on this: > > > > The issue I'm trying to solve is that it's hard to determine why a given > > class was not loaded by OpenJDK. > > > > The solution I proposed was additional (optional) debug output from the > > different classloaders. > > > > This way we can find out: > > > > - Whether any classloaders tried to load the class from your class' > > location (by displaying all locations they try to load the class from). > > - Which type of ClassLoaders tried to find your class. > > - Which classpath each ClassLoader tried to use. > > - Which modules were consulted. > > etc etc. > > > > Currently, it seems the only debug information available in this regard > > centres around: > > > > - Classes that were successfully loaded > > and > > - Exceptions when the class couldn't be loaded. > > > > So my questions are: > > > > 1) Am I trying to solve the right problem here? > > > > 2) Is there any support for this solution in principle, despite the fact > > that the webrev in its current form is...unrefined? > > > > 3) Is there a better way to get this information, with or without a code > > change? > > > > Advice or opinions are appreciated. > > > > > > Bug:https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i- > YQhYV5AAXM&s=2uCIP9fqdKT2SmB0pjQXfhMGlAyZ9F-xdaW4Xp9elo4&e= > > > > Rough example webrev:https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i- > YQhYV5AAXM&s=Il7T1mpLjlE5s1Yvy4qteJTKQ3l6o7THfwH6RaEuzF8&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > > > > > From: David Holmes > > To: Martin Buchholz > > Cc: Ioi Lam, core-libs-dev > > , Adam Farley8 > > Date: 24/10/2019 05:22 > > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > > for Specific Classes > > > > > > > > Hi Martin, > > > > This is going a bit OT I think ... > > > > On 24/10/2019 1:24 pm, Martin Buchholz wrote: > >> On Tue, Oct 22, 2019 at 3:58 PM David Holmes >> > wrote: > >> > >> > >> Perhaps one aspect of the class loading/resolution/initialization > >> process that can lead to confusion here is that if a class fails to > >> execute its static initialization then it is marked as Erroneous and > >> all > >> subsequent attempts to use that class result in NoClassDefFoundError > >> being thrown. If the original ExceptionInInitializerError got > > swallowed > >> somewhere then that can cause great confusion as to why the later > > NCDFE > >> occurs. The VM logging should help in that case - though I'd have to > >> confirm that (if it doesn't that should be fixed). > >> > >> > >> I had a need to debug an error in a this week and was again > >> frustrated by the difficulty. > >> Classes falling into Erroneous state are rare so it seems reasonable to > >> save the exception as a cause for the subsequent NCDFE (probably can't > >> fix the misleading name of the exception) > > So as you know such a request existed: > > > > https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8048190&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=AfL8IyQ5gm4a9cA4orx0EnUwiGqvG6rei- > DuA8gA0jQ&s=pzILDarpf9cN_MvQFqk1u3YZqFzSCRbBZVoRdFw4lS4&e= > > > > > > and was closed as it was considered that TraceExceptions (now > > -Xlog:exceptions) would provide the additional information. As noted in > > that bug there are also semantic issues about recording the cause of an > > exception in thread B, with an exception object that was thrown in > > thread A. So unless someone comes up with a very convincing argument, or > > else it prepared to do the work, I don't see that being re-opened. > > > >> I couldn't find a way to get hotspot to report the stack trace of all > >> exceptions that are thrown; -Xlog:exceptions=trace does not . > > -Xlog:exceptions shows where the exception is thrown and how it proceeds > > up the stack. It doesn't print the full stacktrace. That seems like a > > logging request for the Throwable constructor, or fillInStackTrace, to > > me, rather than trying to have the VM do it. IIRC we store minimal VM > > information in the backTrace which is expanded when needed into the full > > StacktraceElements array. > >> I was also frustrated that a StackOverflowError failed to report the > >> name of the thread and the stack size that was exceeded. But > >> -Xlog:threads*=trace helped there. > > The issue there is that SOE instances are allocated natively without > > executing any Java code (as we have run out of the Java stack) so we > > can't (easily) create a String message for the exception. However > > -Xlog:exceptions could be expanded to report that information at the > > point we throw the SOE. I filed - JDK-8232923. > > > > Cheers, > > David > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Thu Jan 2 17:39:22 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Jan 2020 17:39:22 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> <6d674d42-32e5-2abc-ef2f-d3dd1fe0c3d8@oracle.com> Message-ID: <563a785e-e121-86ae-6f72-2e30f3a4a65f@oracle.com> On 02/01/2020 13:26, Volker Simonis wrote: > : > http://cr.openjdk.java.net/~simonis/webrevs/2020/8235699.02/ > > Ready to push? > You shouldn't need to use core reflection here. Instead you can create the test so that it is compiled and runs as if part of the java.text package, e.g. @build java.base/java.text.CalendarBuilderToStringTest @main Driver Do you really want the @author tag? We try to avoid them if possible because they are so hard to remove, even when code/tests are changed significantly. -Alan From simonisv at amazon.de Thu Jan 2 19:19:31 2020 From: simonisv at amazon.de (Volker Simonis) Date: Thu, 2 Jan 2020 20:19:31 +0100 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <563a785e-e121-86ae-6f72-2e30f3a4a65f@oracle.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> <6d674d42-32e5-2abc-ef2f-d3dd1fe0c3d8@oracle.com> <563a785e-e121-86ae-6f72-2e30f3a4a65f@oracle.com> Message-ID: On 02.01.20 18:39, Alan Bateman wrote: > On 02/01/2020 13:26, Volker Simonis wrote: >> : >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8235699.02/ >> >> Ready to push? >> > You shouldn't need to use core reflection here. Instead you can create > the test so that it is compiled and runs as if part of the java.text > package, e.g. > > @build java.base/java.text.CalendarBuilderToStringTest > @main Driver > Thanks for the hint. I wasn't aware of this possibility. I think Clive will rewrite the test. > Do you really want the @author tag? We try to avoid them if possible > because they are so hard to remove, even when code/tests are changed > significantly. No not really. It was just a part of the template I used :) @Clive: please feel free to remove the author tag. > -Alan Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From naoto.sato at oracle.com Thu Jan 2 20:50:35 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 2 Jan 2020 12:50:35 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> References: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> Message-ID: <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> Hi Joe, Happy new year and thanks for your comments. Please see my replies below: On 12/23/19 5:20 PM, Joe Wang wrote: > Hi Naoto, > > Is there a need for an APINote to note the relationship between the new > get/setMonetaryGroupingSeparator and get/setGroupingSeparator methods. > The new method did state it "May be different from {@code grouping > separator} in some locales", but that may be insufficient. For example, > does setting one method affects the other (seems it should since the > monetaryGroupingSeparator may be initialized by the groupingSeparator as > the impl shows)? If yes, how it's affected? Setting the custom monetary grouping separator will not affect the existing normal grouping separator. I added the explanation in the method description. > > If no, is there a compatibility concern? In the current impl, the new > get method is used when "isCurrencyFormat" is true while the new set > method doesn't affect the existing 'groupingSeparator'. For existing > applications that have a custom grouping separator set through > setGroupingSeparator, it seems to me the custom separator won't be used > moving onto the new JDK impl. Good point. Modified the compatibility risk from minimum to low with the explanation. > > > A minor comment about the definition statement in the following: > > ??? Add the following new serializable field > in|java.text.DecimalFormatSymbols|class: > > |/** * The grouping separator used when formatting currency values. * * > @serial * @since 15 */ private char monetaryGroupingSeparator;| > > > and that for the new get method: > ??????? Gets the character used for thousands separator for currencies. > > > While the meanings are clear, they were not as consistent as that > between the existing groupingSeparator and its get method, that is: > ??????? Character used for thousands separator. > > ?? and then the get method states: > > ??????? Gets the character used for thousands separator. > > > But this is minor, your call whether to change it or not. Consistency is important. I replaced all occurrences of "thousands separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping separator(s)." Here are the modified changeset: http://cr.openjdk.java.net/~naoto/8227313/webrev.01/ as well as the modified CSR at the same URL. Naoto > > Best,? and have a great Christmas! :-) > Joe > > On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8227313 >> >> The proposed CSR and changeset are located at: >> >> https://bugs.openjdk.java.net/browse/JDK-8235942 >> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ >> >> The change introduces the new monetary grouping separator in >> DecimalFormatSymbols, and it is used if a DecimalFormat instance >> designates currency formatting where its pattern includes the currency >> symbol (U+00A5). The change makes use of the CLDR data which provides >> two distinct grouping separators (one for generic, the other for >> currency) in some locales. It also addresses the similar cases for the >> decimal separator. >> >> Naoto > From Roger.Riggs at oracle.com Thu Jan 2 20:58:02 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 2 Jan 2020 15:58:02 -0500 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> Message-ID: <4d3e7759-8856-ecd2-96a3-0618e3cbd063@oracle.com> The core lib changes look ok. Roger On 12/23/19 11:13 PM, Igor Ignatyev wrote: > Thanks David. > > core-libs folks, could you please review jdk part of this patch? > > Thanks, > -- Igor > >> On Dec 23, 2019, at 1:33 PM, David Holmes wrote: >> >> Hi Igor, >> >> Hotspot changes seem fine. Can't comment on jdk tests. >> >> Thanks, >> David >> >> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>> ping? >>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>> Hi all, >>>> >>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>>> >>>> from JBS: >>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>>> >>>> testing: tier1-5 >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>> >>>> Thanks, >>>> -- Igor From fw at deneb.enyo.de Thu Jan 2 21:08:10 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 02 Jan 2020 22:08:10 +0100 Subject: Note about Manifest Header Names starting with "From" In-Reply-To: <05762d129dc795beb21d44d5e13dfc1c1cd60c3d.camel@paratix.ch> (Philipp Kunz's message of "Thu, 26 Dec 2019 18:06:19 +0100") References: <05762d129dc795beb21d44d5e13dfc1c1cd60c3d.camel@paratix.ch> Message-ID: <87r20h1s91.fsf@mid.deneb.enyo.de> * Philipp Kunz: > Hi, > > The Jar File Specification [1] states that, > >> Note: To prevent mangling of files sent via straight e-mail, >> no header will start with the four letters "From". > > But I can't see that this is actually the case. I think the problem are the five bytes "From " at the start of a line, not just "From". From-Field or something like that should indeed be fine. From verghese at amazon.com Thu Jan 2 21:18:16 2020 From: verghese at amazon.com (Verghese, Clive) Date: Thu, 2 Jan 2020 21:18:16 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> <6d674d42-32e5-2abc-ef2f-d3dd1fe0c3d8@oracle.com> <563a785e-e121-86ae-6f72-2e30f3a4a65f@oracle.com> Message-ID: <7904CC12-D4D3-423B-A344-F97B1DAFFA66@amazon.com> Hi Alan, Thanks for the feedback, I have removed the @Author tag and updated the tests as per your recommendation. Updated Webrev http://cr.openjdk.java.net/~phh/8235699/webrev.04/ Regards, Clive Verghsese Regards, Clive Verghese ?On 1/2/20, 11:19 AM, "Volker Simonis" wrote: On 02.01.20 18:39, Alan Bateman wrote: > On 02/01/2020 13:26, Volker Simonis wrote: >> : >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8235699.02/ >> >> Ready to push? >> > You shouldn't need to use core reflection here. Instead you can create > the test so that it is compiled and runs as if part of the java.text > package, e.g. > > @build java.base/java.text.CalendarBuilderToStringTest > @main Driver > Thanks for the hint. I wasn't aware of this possibility. I think Clive will rewrite the test. > Do you really want the @author tag? We try to avoid them if possible > because they are so hard to remove, even when code/tests are changed > significantly. No not really. It was just a part of the template I used :) @Clive: please feel free to remove the author tag. > -Alan From joe.darcy at oracle.com Thu Jan 2 21:26:36 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 2 Jan 2020 13:26:36 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> Message-ID: <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> The removal of the existing TEST.properties files look fine. Please also solicit feedback from the security libs team as their area is affected. Roger, FYI the serial filter tests are updated as part of this changeset. Cheers, -Joe On 12/23/2019 8:13 PM, Igor Ignatyev wrote: > Thanks David. > > core-libs folks, could you please review jdk part of this patch? > > Thanks, > -- Igor > >> On Dec 23, 2019, at 1:33 PM, David Holmes wrote: >> >> Hi Igor, >> >> Hotspot changes seem fine. Can't comment on jdk tests. >> >> Thanks, >> David >> >> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>> ping? >>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>> Hi all, >>>> >>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>>> >>>> from JBS: >>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>>> >>>> testing: tier1-5 >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>> >>>> Thanks, >>>> -- Igor From huizhe.wang at oracle.com Thu Jan 2 22:19:53 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 2 Jan 2020 14:19:53 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> References: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> Message-ID: <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com> Happy New Year, Naoto! Thanks for the explanation and changes. The changeset looks good to me. -Joe On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Happy new year and thanks for your comments. Please see my replies below: > > On 12/23/19 5:20 PM, Joe Wang wrote: >> Hi Naoto, >> >> Is there a need for an APINote to note the relationship between the >> new get/setMonetaryGroupingSeparator and get/setGroupingSeparator >> methods. The new method did state it "May be different from {@code >> grouping separator} in some locales", but that may be insufficient. >> For example, does setting one method affects the other (seems it >> should since the monetaryGroupingSeparator may be initialized by the >> groupingSeparator as the impl shows)? If yes, how it's affected? > > Setting the custom monetary grouping separator will not affect the > existing normal grouping separator. I added the explanation in the > method description. > >> >> If no, is there a compatibility concern? In the current impl, the new >> get method is used when "isCurrencyFormat" is true while the new set >> method doesn't affect the existing 'groupingSeparator'. For existing >> applications that have a custom grouping separator set through >> setGroupingSeparator, it seems to me the custom separator won't be >> used moving onto the new JDK impl. > > Good point. Modified the compatibility risk from minimum to low with > the explanation. > >> >> >> A minor comment about the definition statement in the following: >> >> ???? Add the following new serializable field >> in|java.text.DecimalFormatSymbols|class: >> >> |/** * The grouping separator used when formatting currency values. * >> * @serial * @since 15 */ private char monetaryGroupingSeparator;| >> >> >> and that for the new get method: >> ???????? Gets the character used for thousands separator for currencies. >> >> >> While the meanings are clear, they were not as consistent as that >> between the existing groupingSeparator and its get method, that is: >> ???????? Character used for thousands separator. >> >> ??? and then the get method states: >> >> ???????? Gets the character used for thousands separator. >> >> >> But this is minor, your call whether to change it or not. > > Consistency is important. I replaced all occurrences of "thousands > separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping > separator(s)." > > Here are the modified changeset: > > http://cr.openjdk.java.net/~naoto/8227313/webrev.01/ > > as well as the modified CSR at the same URL. > > Naoto > >> >> Best,? and have a great Christmas! :-) >> Joe >> >> On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227313 >>> >>> The proposed CSR and changeset are located at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8235942 >>> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ >>> >>> The change introduces the new monetary grouping separator in >>> DecimalFormatSymbols, and it is used if a DecimalFormat instance >>> designates currency formatting where its pattern includes the >>> currency symbol (U+00A5). The change makes use of the CLDR data >>> which provides two distinct grouping separators (one for generic, >>> the other for currency) in some locales. It also addresses the >>> similar cases for the decimal separator. >>> >>> Naoto >> From naoto.sato at oracle.com Fri Jan 3 17:23:55 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 3 Jan 2020 09:23:55 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com> References: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com> Message-ID: <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com> Hi Joe, I revised the changeset, as the cached hash code in DecimalFormatSymbols needs to be recalculated when any of the relevant fields is mutated. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8227313/webrev.02/ Naoto On 1/2/20 2:19 PM, Joe Wang wrote: > Happy New Year, Naoto! > > Thanks for the explanation and changes. The changeset looks good to me. > > -Joe > > On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Happy new year and thanks for your comments. Please see my replies below: >> >> On 12/23/19 5:20 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> Is there a need for an APINote to note the relationship between the >>> new get/setMonetaryGroupingSeparator and get/setGroupingSeparator >>> methods. The new method did state it "May be different from {@code >>> grouping separator} in some locales", but that may be insufficient. >>> For example, does setting one method affects the other (seems it >>> should since the monetaryGroupingSeparator may be initialized by the >>> groupingSeparator as the impl shows)? If yes, how it's affected? >> >> Setting the custom monetary grouping separator will not affect the >> existing normal grouping separator. I added the explanation in the >> method description. >> >>> >>> If no, is there a compatibility concern? In the current impl, the new >>> get method is used when "isCurrencyFormat" is true while the new set >>> method doesn't affect the existing 'groupingSeparator'. For existing >>> applications that have a custom grouping separator set through >>> setGroupingSeparator, it seems to me the custom separator won't be >>> used moving onto the new JDK impl. >> >> Good point. Modified the compatibility risk from minimum to low with >> the explanation. >> >>> >>> >>> A minor comment about the definition statement in the following: >>> >>> ???? Add the following new serializable field >>> in|java.text.DecimalFormatSymbols|class: >>> >>> |/** * The grouping separator used when formatting currency values. * >>> * @serial * @since 15 */ private char monetaryGroupingSeparator;| >>> >>> >>> and that for the new get method: >>> ???????? Gets the character used for thousands separator for currencies. >>> >>> >>> While the meanings are clear, they were not as consistent as that >>> between the existing groupingSeparator and its get method, that is: >>> ???????? Character used for thousands separator. >>> >>> ??? and then the get method states: >>> >>> ???????? Gets the character used for thousands separator. >>> >>> >>> But this is minor, your call whether to change it or not. >> >> Consistency is important. I replaced all occurrences of "thousands >> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping >> separator(s)." >> >> Here are the modified changeset: >> >> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/ >> >> as well as the modified CSR at the same URL. >> >> Naoto >> >>> >>> Best,? and have a great Christmas! :-) >>> Joe >>> >>> On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the fix for the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8227313 >>>> >>>> The proposed CSR and changeset are located at: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8235942 >>>> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ >>>> >>>> The change introduces the new monetary grouping separator in >>>> DecimalFormatSymbols, and it is used if a DecimalFormat instance >>>> designates currency formatting where its pattern includes the >>>> currency symbol (U+00A5). The change makes use of the CLDR data >>>> which provides two distinct grouping separators (one for generic, >>>> the other for currency) in some locales. It also addresses the >>>> similar cases for the decimal separator. >>>> >>>> Naoto >>> > From huizhe.wang at oracle.com Fri Jan 3 19:40:59 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 3 Jan 2020 11:40:59 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com> References: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com> <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com> Message-ID: <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com> Hi Naoto, The change looks fine to me as only monetaryGroupingSeparator was added to equals. I can't help to note though that, all fields participated in the equals calculation except exponential. Some of the other fields are in similar situations (one is public and the other not), e.g. percent and percentText, perMill and perMillText, minusSign and minusSignText, and also the currency related fields, but they all are included. It looks like exponential was never publicly accessible, but the (1.6) added exponentialSeparator became public. It's probably not necessary to include all of them in the first place as they are in sync. that is, changing one would change the other -- and in this regard, exponential is an exception: setExponentialSymbol won't change exponential. I understand this is all historical and it doesn't affect your changeset. If the reason is known, it won't hurt to add some notes as the other setXxxText clearly stated the relationship with their non-Text representation. If not, it's fine to me to not have to spend the extra time. Best, Joe On 1/3/20 9:23 AM, naoto.sato at oracle.com wrote: > Hi Joe, > > I revised the changeset, as the cached hash code in > DecimalFormatSymbols needs to be recalculated when any of the relevant > fields is mutated. Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8227313/webrev.02/ > > Naoto > > On 1/2/20 2:19 PM, Joe Wang wrote: >> Happy New Year, Naoto! >> >> Thanks for the explanation and changes. The changeset looks good to me. >> >> -Joe >> >> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> Happy new year and thanks for your comments. Please see my replies >>> below: >>> >>> On 12/23/19 5:20 PM, Joe Wang wrote: >>>> Hi Naoto, >>>> >>>> Is there a need for an APINote to note the relationship between the >>>> new get/setMonetaryGroupingSeparator and get/setGroupingSeparator >>>> methods. The new method did state it "May be different from {@code >>>> grouping separator} in some locales", but that may be insufficient. >>>> For example, does setting one method affects the other (seems it >>>> should since the monetaryGroupingSeparator may be initialized by >>>> the groupingSeparator as the impl shows)? If yes, how it's affected? >>> >>> Setting the custom monetary grouping separator will not affect the >>> existing normal grouping separator. I added the explanation in the >>> method description. >>> >>>> >>>> If no, is there a compatibility concern? In the current impl, the >>>> new get method is used when "isCurrencyFormat" is true while the >>>> new set method doesn't affect the existing 'groupingSeparator'. For >>>> existing applications that have a custom grouping separator set >>>> through setGroupingSeparator, it seems to me the custom separator >>>> won't be used moving onto the new JDK impl. >>> >>> Good point. Modified the compatibility risk from minimum to low with >>> the explanation. >>> >>>> >>>> >>>> A minor comment about the definition statement in the following: >>>> >>>> ???? Add the following new serializable field >>>> in|java.text.DecimalFormatSymbols|class: >>>> >>>> |/** * The grouping separator used when formatting currency values. >>>> * * @serial * @since 15 */ private char monetaryGroupingSeparator;| >>>> >>>> >>>> and that for the new get method: >>>> ???????? Gets the character used for thousands separator for >>>> currencies. >>>> >>>> >>>> While the meanings are clear, they were not as consistent as that >>>> between the existing groupingSeparator and its get method, that is: >>>> ???????? Character used for thousands separator. >>>> >>>> ??? and then the get method states: >>>> >>>> ???????? Gets the character used for thousands separator. >>>> >>>> >>>> But this is minor, your call whether to change it or not. >>> >>> Consistency is important. I replaced all occurrences of "thousands >>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping >>> separator(s)." >>> >>> Here are the modified changeset: >>> >>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/ >>> >>> as well as the modified CSR at the same URL. >>> >>> Naoto >>> >>>> >>>> Best,? and have a great Christmas! :-) >>>> Joe >>>> >>>> On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8227313 >>>>> >>>>> The proposed CSR and changeset are located at: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8235942 >>>>> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ >>>>> >>>>> The change introduces the new monetary grouping separator in >>>>> DecimalFormatSymbols, and it is used if a DecimalFormat instance >>>>> designates currency formatting where its pattern includes the >>>>> currency symbol (U+00A5). The change makes use of the CLDR data >>>>> which provides two distinct grouping separators (one for generic, >>>>> the other for currency) in some locales. It also addresses the >>>>> similar cases for the decimal separator. >>>>> >>>>> Naoto >>>> >> From bob.vandette at oracle.com Fri Jan 3 20:37:00 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 3 Jan 2020 15:37:00 -0500 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> Message-ID: <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> Here are a few comments from scanning the webrev. It looks like you can remove line 151 http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java.sdiff.html 151 int[] ints = new int[0]; ????? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/share/classes/jdk/internal/platform/Metrics.java.sdiff.html There are several comments stating that -2 == unlimited. This is not the case. @return count of elapsed periods or -2 if the quota is unlimited. ????? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java.sdiff.html Shouldn?t you just check for cgroupv2 before trying to run the testKernelMemoryLimit and testOomKillFlag tests? ????? There are a few places where getPerCpuUsage is returning ?new long[0]? but you changed the interface to expect null for not supported. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java.html You probably need to check all users of the APIs which used to return array[0] which now return null to make sure you don?t get null pointer exceptions. One example is testCpuConsumption. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java.html Also, http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java.html:167 You?ll also have to update copyrights to 2020. Bob. > On Dec 20, 2019, at 9:50 AM, Severin Gehwolf wrote: > > Hi Bob, > > Sorry for the delay to get this updated. > > Changes done in this latest webrev: > > 1. Rebased on top of 8226575: OperatingSystemMXBean should be made > container aware. File read ops now use privileged code. > 2. Warning for mixed cgroup controllers and returning null for metrics. > 3. Added implementations for getBlkIOServiceCount() and > getBlkIOServiced() using sum of rios/wios and rbytes/wbytes across > devices. Added impl for getTcpMemoryUsage() > 4. Returning -2 for not supported (if the metric would return long). > boolean metrics now return Boolean and null if not supported. Same > for array return types. null if not supported for symmetry. > 5. -XshowSettings:system output has been updated to return "N/A" for > when a metric is not available. E.g. "Kernel OOM killer enabled" > Boolean. > 6. Tests have been updated to reflect this. > > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/ > incremental webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/ > > Testing: Docker tests and podman testing on cgroupsv2. I'll run it > through jdk/submit as well. > > Hopefully this can get pushed with 8230305 early on in the jdk 15 cycle > :) > > A couple of more inline comments below. > > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: >> Sorry for the delay in responding. See comments below: >> >>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: >>> >>> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could I please get reviews of these core-libs, Linux-only, changes to >>>> the Metrics subsystem? This patch implements cgroupv2 support for >>>> Metrics which are currently cgroupv1-only. Fedora 31 switched to >>>> cgroupv2 by default so it's time to get OpenJDK recognize it. >>>> >>>> Note that a couple of metrics are no longer supported with cgroupv2. >>>> Most notably (not an exhaustive list, though): >>>> >>>> Metrics.getKernel*() family of methods. >>>> Metrics.getTcp*() family of methods. >>>> Metrics.getBlkIO*() family of methods. >>>> Metrics.isMemoryOOMKillEnabled() >>>> >>>> A couple of open questions with regards to that: >>>> >>>> 1) >>>> Most API docs of Metrics make no distiction between "unlimited" and >>>> "not supported", both returning -1 for longs, for example. This is a >>>> problem, because output of "java -XshowSettings:system -version" will >>>> not distinguish between unlimited and not supported metrics. Would it >>>> be acceptable to change the API to distinguish those cases so that >>>> LauncherHelper could display them appropriately? >>>> >>>> 2) >>>> How should we deal with "not supported" for booleans/arrays, etc.? >>>> Would it make sense to return record objects from the Metrics API so >>>> that this could be dealt with? E.g. >>>> >>>> Metrics m = ... >>>> MetricResult result = m.getCpuSetCpus(); >>>> switch(result.getType()) { >>>> case NOT_SUPPORTED: /* do something */; break; >>>> case SUPPORTED: int[] val = result.get(); break; >>>> ... >>>> } >>>> >>>> I'm bringing this up, because the proposed patch doesn't deal with the >>>> above open questions as of yet. With that being said, it's mostly >>>> identical to the proposed hotspot changes in [1]. >> >> For issue 1 and 2 ? >> >> I wonder if we should change the API to throw UnsupportedOperationException for those methods >> that are not available. This exception is used quite a lot in the java/nio and java/net packages >> for dealing with functionality not available on a host platform. >> >> As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot >> implementation. We could use this for non boolean values in the Metrics API. For boolean >> values, we could change the API to return ?Boolean?. A null return would signify not >> implemented. > > This alternative has been implemented in the latest webrev. > LauncherHelper has been updated to print "N/A" if some property being > printed is not supported. Example output for cgroupsv2: > > $ ./bin/java -XshowSettings:system -version > Operating System Metrics: > Provider: cgroupv2 > Effective CPU Count: 4 > CPU Period: 100000us > CPU Quota: -1 > CPU Shares: -1 > List of Processors: N/A > List of Effective Processors: N/A > List of Memory Nodes: N/A > List of Available Memory Nodes: N/A > CPUSet Memory Pressure Enabled: N/A > Memory Limit: Unlimited > Memory Soft Limit: Unlimited > Memory & Swap Limit: Unlimited > Kernel Memory Limit: N/A > TCP Memory Limit: N/A > Out Of Memory Killer Enabled: N/A > > openjdk version "15-internal" 2020-09-15 > OpenJDK Runtime Environment (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2) > OpenJDK 64-Bit Server VM (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing) > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ >>>> >> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html >> >> Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since >> you are not supporting mixing. > > Done. null is returned for metrics and a warning printed to stderr. > >> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html >> >> It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. >> >> BlkIOServicedCount (io.stat) >> KernelMemory (memory.stat) >> TcpMemory (memory.stat) > > The latest webrev has getBlkIOService* and getTcpMemoryUsage impls. > I've left out kernel memory metrics as it wasn't clear what this would > be. We can add that in a later patch. The size of this patch is already > rather big. > >> You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. > > We've decided to not do this. getMemoryAndSwapMaxUsage and > getMemoryMaxUsage is being returned as not supported in cgroups v2. > > Thanks, > Severin > >> for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. >> >> https://www.kernel.org/doc/Documentation/cgroup-v2.txt >> >>>> Testing: jdk/submit and platform docker tests on Linux x86_64 (with >>>> hybrid hierarchy, docker/podman) and on Linux x86_64 with unified >>>> hierarchy (podman only). >>>> >>>> Thoughts? Suggestions? >> >> Do you think we should check the docker version being used for the tests to make sure it >> supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. >> >> Bob. >> >> >> >>> Ping? >>> >>>> Thanks, >>>> Severin >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html > From naoto.sato at oracle.com Fri Jan 3 21:24:35 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 3 Jan 2020 13:24:35 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com> References: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com> <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com> <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com> Message-ID: Hi Joe, Thanks again for the review. The reason the way it is is all historical. percent/perMill/minusSign all had public APIs for the 'char' version since inception, and text version APIs were added later (JDK13). Thus they had to be in sync (both fields are accessible through API). On the other hand, exponential was private till JDK6, and at that time I guess the engineer decided only to expose public access to its text version, i.e., effectively deprecate 'char' version interface and field. I guess that's why he/she did not bother make them in sync, IMO. So there seems to be no explicit reason (to be noted in the source code) for not syncing. My $.02 Naoto On 1/3/20 11:40 AM, Joe Wang wrote: > Hi Naoto, > > The change looks fine to me as only monetaryGroupingSeparator was added > to equals. > > I can't help to note though that, all fields participated in the equals > calculation except exponential. Some of the other fields are in similar > situations (one is public and the other not), e.g. percent and > percentText, perMill and perMillText, minusSign and minusSignText, and > also the currency related fields, but they all are included. It looks > like exponential was never publicly accessible, but the (1.6) added > exponentialSeparator became public. It's probably not necessary to > include all of them in the first place as they are in sync. that is, > changing one would change the other -- and in this regard, exponential > is an exception: setExponentialSymbol won't change exponential. > > I understand this is all historical and it doesn't affect your > changeset. If the reason is known, it won't hurt to add some notes as > the other setXxxText clearly stated the relationship with their non-Text > representation. If not, it's fine to me to not have to spend the extra > time. > > Best, > Joe > > On 1/3/20 9:23 AM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> I revised the changeset, as the cached hash code in >> DecimalFormatSymbols needs to be recalculated when any of the relevant >> fields is mutated. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8227313/webrev.02/ >> >> Naoto >> >> On 1/2/20 2:19 PM, Joe Wang wrote: >>> Happy New Year, Naoto! >>> >>> Thanks for the explanation and changes. The changeset looks good to me. >>> >>> -Joe >>> >>> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote: >>>> Hi Joe, >>>> >>>> Happy new year and thanks for your comments. Please see my replies >>>> below: >>>> >>>> On 12/23/19 5:20 PM, Joe Wang wrote: >>>>> Hi Naoto, >>>>> >>>>> Is there a need for an APINote to note the relationship between the >>>>> new get/setMonetaryGroupingSeparator and get/setGroupingSeparator >>>>> methods. The new method did state it "May be different from {@code >>>>> grouping separator} in some locales", but that may be insufficient. >>>>> For example, does setting one method affects the other (seems it >>>>> should since the monetaryGroupingSeparator may be initialized by >>>>> the groupingSeparator as the impl shows)? If yes, how it's affected? >>>> >>>> Setting the custom monetary grouping separator will not affect the >>>> existing normal grouping separator. I added the explanation in the >>>> method description. >>>> >>>>> >>>>> If no, is there a compatibility concern? In the current impl, the >>>>> new get method is used when "isCurrencyFormat" is true while the >>>>> new set method doesn't affect the existing 'groupingSeparator'. For >>>>> existing applications that have a custom grouping separator set >>>>> through setGroupingSeparator, it seems to me the custom separator >>>>> won't be used moving onto the new JDK impl. >>>> >>>> Good point. Modified the compatibility risk from minimum to low with >>>> the explanation. >>>> >>>>> >>>>> >>>>> A minor comment about the definition statement in the following: >>>>> >>>>> ???? Add the following new serializable field >>>>> in|java.text.DecimalFormatSymbols|class: >>>>> >>>>> |/** * The grouping separator used when formatting currency values. >>>>> * * @serial * @since 15 */ private char monetaryGroupingSeparator;| >>>>> >>>>> >>>>> and that for the new get method: >>>>> ???????? Gets the character used for thousands separator for >>>>> currencies. >>>>> >>>>> >>>>> While the meanings are clear, they were not as consistent as that >>>>> between the existing groupingSeparator and its get method, that is: >>>>> ???????? Character used for thousands separator. >>>>> >>>>> ??? and then the get method states: >>>>> >>>>> ???????? Gets the character used for thousands separator. >>>>> >>>>> >>>>> But this is minor, your call whether to change it or not. >>>> >>>> Consistency is important. I replaced all occurrences of "thousands >>>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping >>>> separator(s)." >>>> >>>> Here are the modified changeset: >>>> >>>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/ >>>> >>>> as well as the modified CSR at the same URL. >>>> >>>> Naoto >>>> >>>>> >>>>> Best,? and have a great Christmas! :-) >>>>> Joe >>>>> >>>>> On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix for the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8227313 >>>>>> >>>>>> The proposed CSR and changeset are located at: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8235942 >>>>>> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ >>>>>> >>>>>> The change introduces the new monetary grouping separator in >>>>>> DecimalFormatSymbols, and it is used if a DecimalFormat instance >>>>>> designates currency formatting where its pattern includes the >>>>>> currency symbol (U+00A5). The change makes use of the CLDR data >>>>>> which provides two distinct grouping separators (one for generic, >>>>>> the other for currency) in some locales. It also addresses the >>>>>> similar cases for the decimal separator. >>>>>> >>>>>> Naoto >>>>> >>> > From huizhe.wang at oracle.com Fri Jan 3 22:28:06 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 3 Jan 2020 14:28:06 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: References: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com> <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com> <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com> <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com> Message-ID: Hi Naoto, Historical indeed, and true, it was not exposed prior to JDK6. Just need to make sure other classes within the package won't accidentally use its set method or mark it if it's 'deprecated'. But it's a minor issue. I'm fine with your changeset as is. Best, Joe On 1/3/20 1:24 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thanks again for the review. The reason the way it is is all > historical. percent/perMill/minusSign all had public APIs for the > 'char' version since inception, and text version APIs were added later > (JDK13). Thus they had to be in sync (both fields are accessible > through API). On the other hand, exponential was private till JDK6, > and at that time I guess the engineer decided only to expose public > access to its text version, i.e., effectively deprecate 'char' version > interface and field. I guess that's why he/she did not bother make > them in sync, IMO. So there seems to be no explicit reason (to be > noted in the source code) for not syncing. > > My $.02 > > Naoto > > On 1/3/20 11:40 AM, Joe Wang wrote: >> Hi Naoto, >> >> The change looks fine to me as only monetaryGroupingSeparator was >> added to equals. >> >> I can't help to note though that, all fields participated in the >> equals calculation except exponential. Some of the other fields are >> in similar situations (one is public and the other not), e.g. percent >> and percentText, perMill and perMillText, minusSign and >> minusSignText, and also the currency related fields, but they all are >> included. It looks like exponential was never publicly accessible, >> but the (1.6) added exponentialSeparator became public. It's probably >> not necessary to include all of them in the first place as they are >> in sync. that is, changing one would change the other -- and in this >> regard, exponential is an exception: setExponentialSymbol won't >> change exponential. >> >> I understand this is all historical and it doesn't affect your >> changeset. If the reason is known, it won't hurt to add some notes as >> the other setXxxText clearly stated the relationship with their >> non-Text representation. If not, it's fine to me to not have to spend >> the extra time. >> >> Best, >> Joe >> >> On 1/3/20 9:23 AM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> I revised the changeset, as the cached hash code in >>> DecimalFormatSymbols needs to be recalculated when any of the >>> relevant fields is mutated. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8227313/webrev.02/ >>> >>> Naoto >>> >>> On 1/2/20 2:19 PM, Joe Wang wrote: >>>> Happy New Year, Naoto! >>>> >>>> Thanks for the explanation and changes. The changeset looks good to >>>> me. >>>> >>>> -Joe >>>> >>>> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote: >>>>> Hi Joe, >>>>> >>>>> Happy new year and thanks for your comments. Please see my replies >>>>> below: >>>>> >>>>> On 12/23/19 5:20 PM, Joe Wang wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> Is there a need for an APINote to note the relationship between >>>>>> the new get/setMonetaryGroupingSeparator and >>>>>> get/setGroupingSeparator methods. The new method did state it >>>>>> "May be different from {@code grouping separator} in some >>>>>> locales", but that may be insufficient. For example, does setting >>>>>> one method affects the other (seems it should since the >>>>>> monetaryGroupingSeparator may be initialized by the >>>>>> groupingSeparator as the impl shows)? If yes, how it's affected? >>>>> >>>>> Setting the custom monetary grouping separator will not affect the >>>>> existing normal grouping separator. I added the explanation in the >>>>> method description. >>>>> >>>>>> >>>>>> If no, is there a compatibility concern? In the current impl, the >>>>>> new get method is used when "isCurrencyFormat" is true while the >>>>>> new set method doesn't affect the existing 'groupingSeparator'. >>>>>> For existing applications that have a custom grouping separator >>>>>> set through setGroupingSeparator, it seems to me the custom >>>>>> separator won't be used moving onto the new JDK impl. >>>>> >>>>> Good point. Modified the compatibility risk from minimum to low >>>>> with the explanation. >>>>> >>>>>> >>>>>> >>>>>> A minor comment about the definition statement in the following: >>>>>> >>>>>> ???? Add the following new serializable field >>>>>> in|java.text.DecimalFormatSymbols|class: >>>>>> >>>>>> |/** * The grouping separator used when formatting currency >>>>>> values. * * @serial * @since 15 */ private char >>>>>> monetaryGroupingSeparator;| >>>>>> >>>>>> >>>>>> and that for the new get method: >>>>>> ???????? Gets the character used for thousands separator for >>>>>> currencies. >>>>>> >>>>>> >>>>>> While the meanings are clear, they were not as consistent as that >>>>>> between the existing groupingSeparator and its get method, that is: >>>>>> ???????? Character used for thousands separator. >>>>>> >>>>>> ??? and then the get method states: >>>>>> >>>>>> ???????? Gets the character used for thousands separator. >>>>>> >>>>>> >>>>>> But this is minor, your call whether to change it or not. >>>>> >>>>> Consistency is important. I replaced all occurrences of "thousands >>>>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping >>>>> separator(s)." >>>>> >>>>> Here are the modified changeset: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/ >>>>> >>>>> as well as the modified CSR at the same URL. >>>>> >>>>> Naoto >>>>> >>>>>> >>>>>> Best,? and have a great Christmas! :-) >>>>>> Joe >>>>>> >>>>>> On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix for the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8227313 >>>>>>> >>>>>>> The proposed CSR and changeset are located at: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235942 >>>>>>> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ >>>>>>> >>>>>>> The change introduces the new monetary grouping separator in >>>>>>> DecimalFormatSymbols, and it is used if a DecimalFormat instance >>>>>>> designates currency formatting where its pattern includes the >>>>>>> currency symbol (U+00A5). The change makes use of the CLDR data >>>>>>> which provides two distinct grouping separators (one for >>>>>>> generic, the other for currency) in some locales. It also >>>>>>> addresses the similar cases for the decimal separator. >>>>>>> >>>>>>> Naoto >>>>>> >>>> >> From james at deepsymmetry.org Sat Jan 4 06:50:00 2020 From: james at deepsymmetry.org (James Elliott) Date: Sat, 4 Jan 2020 00:50:00 -0600 Subject: jpackage and macOS Catalina notarization Message-ID: <59AB5E37-0D67-4C09-B4CA-0F83C0A4432D@deepsymmetry.org> Hello, everyone, I finally found this list, as well as a way to search it, and so hope this question is relevant and appropriate and not already answered. For some time I have been using an old javapackager along with a newer release of jlink to create native macOS installers for a free, open-source Swing application, and am very excited to see that JEP-343 is finally on the horizon so I soon can stop relying on the ancient javapackager. Still, its ability to code sign my installer DMG has been very beneficial to my less-Java-savvy users (generally musicians and light/laser/video technicians running stage shows). Apple?s current operating system, Catalina, adds still more hoops for developers to jump through in order to enable their software to be run without complaint and complexity: It needs to be notarized (uploaded to Apple and scanned for malicious code and other unsafe properties). I am not asking if jpackage might assist with the notarization step any time soon; that is something that can be accomplished separately after the code-signed package or disk image has been produced. The issue, however, is that for notarization to succeed, the code signing must be performed in a manner that causes the application to use the hardened runtime, and therefore a set of entitlements must be added in order for Java code to run successfully. (These requirements have been temporarily relaxed because so few developers were ready for them, but they will be returning soon.) I could not see any evidence in the jpackage documentation or help text that it could support these code signing options, specifically ?timestamp, ?options runtime, and ?entitlements entitlements.plist (for full details on getting this process to work, I found the following two articles incredibly helpful: http://www.zarkonnen.com/signing_notarizing_catalina and http://kothar.net/macos_catalina_java_11 ). Is this something that is on the radar for a future jpackage release? Failing that, is there a way to perform the code signing separately and still use jpackage to produce the disk image? Thanks for any thoughts or insight you might be able to share, -James From philipp.kunz at paratix.ch Sat Jan 4 10:00:48 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 04 Jan 2020 11:00:48 +0100 Subject: Test Unicode support for "SplashScreen-Image" manifest attribute and potential clean up of some c code Message-ID: <866cb01ce33c1468f78b43ac51cbeb7b28d38125.camel@paratix.ch> Hi, When I tried to improve Unicode support in JAR manifests in [1], independent of what will happen with that, I found that there are not only Manifest and Attributes classes parsing manifests but also some c code which parses "SplashScreen-Image" attribute and also used to parse some other attributes such as "Main-Class" and others. There already are tests for splash screen images but those existing ones work with the "-splash" command line option and not with the "SplashScreen-Image" manifest attribute. I found "SplashScreen-Image" manifest attribute not yet covered with a test and extended the existing UnicodeTest accordingly, see attached patch which confirmed that the "SplashScreen-Image" manifest attribute already fully supports Unicode. Support for "JRE-Version" manifest attribute and "-jre-restrict-search" and "-jre-no-restrict-search" command line attributes has already been removed earlier already and the relevant lines of code determining the main class from the manifest when launching have already been moved to or near LauncherHelper::getMainClassFromJar in earlier versions, apparently leaving them with no use any longer in java.c, java.h, manifest_info.h, and parse_manifest.c, I figure. Hence, I propose to remove those parts as in the attached patch. This leaves manifest_info.h and parse_manifest.c with "SplashScreen- Image" as the only attribute parsed there. Certainly it would be a different change but anyway it might be worth a consideration to move the code opening the splash screen image to LauncherHelper or a similar appropriate place in Java which would allow to remove quite a number of some lines of c code, provided it could be acceptable to show the splash screen image slightly later. There is no existing related bug and I didn't find a new one. It would be nice to have "SplashScreen-Image" manifest attribute covered with a test and there is some potential for cleaning up unused code which certainly is not urgent at all and I would not know how desirable this really is. Also I'm not sure whether it's better or not to add SPLASHSCREEN_IMAGE to Attributes.Name.KNOWN_NAMES. Any opinion about to how to proceed with this, if at all or would someone sponsor this patch? Regards, Philipp [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/064149.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 20200104-splashscreenimageunicodetest.patch Type: text/x-patch Size: 25218 bytes Desc: not available URL: From akashche at redhat.com Mon Jan 6 09:57:02 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 6 Jan 2020 09:57:02 +0000 Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h In-Reply-To: References: <5E016C66.4040502@oracle.com> Message-ID: <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com> On 12/24/2019 11:54 AM, Alex Kashchenko wrote: > On 12/24/2019 01:39 AM, Philip Race wrote: >> Have you verified this with VS 2017 ? >> Not that I can see a problem but I doubt we want to trade breaking >> 2017 to fix 2013 ... > > Yes, VS 2017 compiles fine with this fix. > > >> [...] >> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 >> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/ >> [...] Gentle reminder, it would be great to have this included before jdk14 enters rampdown 2. -- -Alex From shade at redhat.com Mon Jan 6 10:54:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Jan 2020 11:54:03 +0100 Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h In-Reply-To: <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com> References: <5E016C66.4040502@oracle.com> <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com> Message-ID: <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com> On 1/6/20 10:57 AM, Alex Kashchenko wrote: > On 12/24/2019 11:54 AM, Alex Kashchenko wrote: >> On 12/24/2019 01:39 AM, Philip Race wrote: >>> Have you verified this with VS 2017 ? >>> Not that I can see a problem but I doubt we want to trade breaking >>> 2017 to fix 2013 ... >> >> Yes, VS 2017 compiles fine with this fix. >> >> >>> [...] >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 >>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/ >>> [...] > > Gentle reminder, it would be great to have this included before jdk14 > enters rampdown 2. The patch looks good to me. (I did the same in the original bug report). -- Thanks, -Aleksey From akashche at redhat.com Mon Jan 6 12:48:37 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 6 Jan 2020 12:48:37 +0000 Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h In-Reply-To: <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com> References: <5E016C66.4040502@oracle.com> <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com> <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com> Message-ID: On 01/06/2020 10:54 AM, Aleksey Shipilev wrote: > On 1/6/20 10:57 AM, Alex Kashchenko wrote: >> On 12/24/2019 11:54 AM, Alex Kashchenko wrote: >>> On 12/24/2019 01:39 AM, Philip Race wrote: >>>> Have you verified this with VS 2017 ? >>>> Not that I can see a problem but I doubt we want to trade breaking >>>> 2017 to fix 2013 ... >>> >>> Yes, VS 2017 compiles fine with this fix. >>> >>> >>>> [...] >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 >>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/ >>>> [...] >> >> Gentle reminder, it would be great to have this included before jdk14 >> enters rampdown 2. > > The patch looks good to me. (I did the same in the original bug report). Thanks for the review! Sponsor is required for this patch to be pushed (I am not an author in "jdk" and cannot export committed changeset). -- -Alex From naoto.sato at oracle.com Mon Jan 6 17:05:20 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 6 Jan 2020 09:05:20 -0800 Subject: [14] RFR: 8236495,open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale. Message-ID: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8236495 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8236495/webrev.00/ The test case for the fix to 8232860 was only intended for the US locale. Simply adding the default locale check will fix the test case. Naoto From lance.andersen at oracle.com Mon Jan 6 17:14:25 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Jan 2020 12:14:25 -0500 Subject: [14] RFR: 8236495,open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale. In-Reply-To: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> Message-ID: <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com> Hi Naoto, The change looks OK. One thought was whether any thought was given to use SkippedException in the else block starting at line 370 within LocaleProviders. Best Lance > On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com wrote: > > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8236495 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8236495/webrev.00/ > > The test case for the fix to 8232860 was only intended for the US locale. Simply adding the default locale check will fix the test case. > > 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 christoph.dreis at freenet.de Mon Jan 6 17:33:09 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Mon, 06 Jan 2020 18:33:09 +0100 Subject: Use single character replace variant in Resources.toPackageName(String) Message-ID: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de> Hi and a happy new year, I recently noticed that jdk.internal.module.Resources.toPackageName(String) makes use of String.replace(CharSequence, CharSequence) while it could use the single char variant in my opinion: diff --git a/src/java.base/share/classes/jdk/internal/module/Resources.java b/src/java.base/share/classes/jdk/internal/module/Resources.java --- a/src/java.base/share/classes/jdk/internal/module/Resources.java +++ b/src/java.base/share/classes/jdk/internal/module/Resources.java @@ -64,7 +64,7 @@ if (index == -1 || index == name.length()-1) { return ""; } else { - return name.substring(0, index).replace("/", "."); + return name.substring(0, index).replace('/', '.'); } } I ran an isolated benchmark with some test data on it, which shows the following results Benchmark (param) Mode Cnt Score Error Units MyBenchmark.testNew java/lang avgt 10 14,905 ? 0,130 ns/op MyBenchmark.testNew:?gc.alloc.rate.norm java/lang avgt 10 48,000 ? 0,001 B/op MyBenchmark.testNew a/b/c/d/e avgt 10 23,122 ? 0,389 ns/op MyBenchmark.testNew:?gc.alloc.rate.norm a/b/c/d/e avgt 10 96,000 ? 0,001 B/op MyBenchmark.testOld java/lang avgt 10 16,614 ? 0,420 ns/op MyBenchmark.testOld:?gc.alloc.rate.norm java/lang avgt 10 48,000 ? 0,001 B/op MyBenchmark.testOld a/b/c/d/e avgt 10 84,745 ? 1,329 ns/op MyBenchmark.testOld:?gc.alloc.rate.norm a/b/c/d/e avgt 10 120,000 ? 0,001 B/op As you can see the more replacing needs to be done the better the newer version seems to be perform. In case this is considered worthwhile I would need someone to sponsor the patch. If not, I'm sorry for the noise. Cheers, Christoph Dreis From philip.race at oracle.com Mon Jan 6 17:41:18 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 06 Jan 2020 09:41:18 -0800 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS In-Reply-To: <4ea1a4a8-9d7a-4b4b-804c-b22c4bc0cbe7@oracle.com> References: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> <57e519a8-a4a1-02f4-d06e-674a10fe9cdd@oracle.com> <4ea1a4a8-9d7a-4b4b-804c-b22c4bc0cbe7@oracle.com> Message-ID: <5E13713E.1020607@oracle.com> That didn't answer all my questions, at least not in a way that I can understand. How is this useful given that we disable jtreg failure handlers for the headful tests ? -phil. On 12/30/19, 11:33 AM, Sergey Bylokhov wrote: > On 12/23/19 9:15 pm, Phil Race wrote: >> I am not sure what the right mailing list(s) are for this change. >> It definitely isn't a core-libs change. I think build-dev may be better. > > Previous changes to these configs were discussed here, so I have send > it here as well. > >> >> I am also unclear when this failure handler is invoked and how all >> this machinery works. >> >> It is only useful for headful tests and so I'd only want it enabled >> in such a case. >> And we disable the failure handlers in the headful test jobs anyway >> because they seem >> focused on taking pointless core dumps ...> So we need something that >> can be used with headful tests only and doesn't involve >> re-enabling the other handlers. > It could be useful for other tests as well and may be able to identify > problems such as: > - Suggestions "to open under debugger" from the native asserts > - Various error dialogs from the OS > And it does not spend much resources compared to current handlers. > >> >> Also why exclude Windows ? No easy way to get the screenshot ? > > There is no command-line program that can take a screenshot on windows > by default > >> >> -phil. >> >> On 12/11/19 1:00 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for JDK 14. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 >>> Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 >>> >>> This change adds the "screen capture on the test failure" feature on >>> macOS and Linux. >>> - On Linux, it is implemented by the "gnome-screenshot" command(in >>> case of >>> multiscreen+xinerama the whole big screen will be saved to the >>> "screen.png" file). >>> - On macOS it is implemented by the "screencapture" command, note >>> that I have >>> used 1 file per screen, if the number of screens less than 5, >>> other files will be ignored. >>> >> > > From naoto.sato at oracle.com Mon Jan 6 17:55:02 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 6 Jan 2020 09:55:02 -0800 Subject: [14] RFR: 8236495,open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale. In-Reply-To: <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com> References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com> Message-ID: <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com> Hi Lance, Thank you for the prompt review. On 1/6/20 9:14 AM, Lance Andersen wrote: > Hi Naoto, > > The change looks OK. ?One thought was whether any thought was given to > use?SkippedException in the else block starting at line 370 within > LocaleProviders. I am not familiar with that exception. Is it jtreg.SkippedException? I searched for the exception, and one example is: jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java where it requires the platform is linux with the directive "@requires os.family == "linux"", so throwing the exception does work as an assertion. However in this LocaleProviders.java, it will need to simply ignore the case and should succeed. So I am not sure SkippedException can be applied here. Naoto > > Best > Lance > >> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com >> wrote: >> >> Hi, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8236495 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/ >> >> The test case for the fix to 8232860 was only intended for the US >> locale. Simply adding the default locale check will fix the test case. >> >> 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 lance.andersen at oracle.com Mon Jan 6 18:06:39 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Jan 2020 13:06:39 -0500 Subject: [14] RFR: 8236495,open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale. In-Reply-To: <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com> References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com> <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com> Message-ID: Hi Naoto > On Jan 6, 2020, at 12:55 PM, naoto.sato at oracle.com wrote: > > Hi Lance, > > Thank you for the prompt review. > > On 1/6/20 9:14 AM, Lance Andersen wrote: >> Hi Naoto, >> The change looks OK. One thought was whether any thought was given to use SkippedException in the else block starting at line 370 within LocaleProviders. > > I am not familiar with that exception. Is it jtreg.SkippedException? Yes I am, sorry for not being clearer. You can throw that in the else block where you print the message about skipping the test and it will be tracked as a skip vs a pass. Not a big deal either way but gives you extra granularity as to why the test was not run and easier to see vs just a print statement? I just wanted to point this out as something to consider going forward. Have a good rest of your day! > I searched for the exception, and one example is: > > jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java > > where it requires the platform is linux with the directive "@requires os.family == "linux"", so throwing the exception does work as an assertion. However in this LocaleProviders.java, it will need to simply ignore the case and should succeed. So I am not sure SkippedException can be applied here. > > Naoto > >> Best >> Lance >>> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com wrote: >>> >>> Hi, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8236495 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/ >>> >>> The test case for the fix to 8232860 was only intended for the US locale. Simply adding the default locale check will fix the test case. >>> >>> 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 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 Mon Jan 6 18:28:15 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 6 Jan 2020 10:28:15 -0800 Subject: [14] RFR: 8236495,open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale. In-Reply-To: References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com> <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com> Message-ID: <9e66d926-9cfb-f57e-8799-b5b26e05b441@oracle.com> Thanks, Lance, for the explanation. I explored your suggestion. Unfortunately, the test invokes a Java process where each test is performed (LocaleProvidersRun.testRun() method), and it only checks the exit code of the Java process. So throwing SkippedException in each test will not be handled in the expected manner (skip vs pass). Of course this could be improved, but I would rather not do it for this simple test case change :-) Naoto On 1/6/20 10:06 AM, Lance Andersen wrote: > Hi Naoto > >> On Jan 6, 2020, at 12:55 PM, naoto.sato at oracle.com >> wrote: >> >> Hi Lance, >> >> Thank you for the prompt review. >> >> On 1/6/20 9:14 AM, Lance Andersen wrote: >>> Hi Naoto, >>> The change looks OK. ?One thought was whether any thought was given >>> to use?SkippedException in the else block starting at line 370 within >>> LocaleProviders. >> >> I am not familiar with that exception. Is it jtreg.SkippedException? > > Yes I am, sorry for not being clearer. > > You can throw that in the else block where you print the message about > skipping the test and it will be tracked as a skip vs a pass. > > Not a big deal either way but gives you extra granularity as to why the > test was not run and easier to see vs just a print statement? ?I just > wanted to point this out as something to consider going forward. > > Have a good rest of your day! > >> I searched for the exception, and one example is: >> >> jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java >> >> where it requires the platform is linux with the directive "@requires >> os.family == "linux"", so throwing the exception does work as an >> assertion. However in this LocaleProviders.java, it will need to >> simply ignore the case and should succeed. So I am not sure >> SkippedException can be applied here. >> >> Naoto >> >>> Best >>> Lance >>>> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8236495 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/ >>>> >>>> The test case for the fix to 8232860 was only intended for the US >>>> locale. Simply adding the default locale check will fix the test case. >>>> >>>> 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 >>> > > > > 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 james.laskey at oracle.com Mon Jan 6 18:29:17 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 6 Jan 2020 14:29:17 -0400 Subject: RFR: JDK-8236683 StringBuilder / StringBuffer capacity() doc is misleading (CSR) Message-ID: <0A5D7986-836B-4DFE-9303-6D0EE0BED47A@oracle.com> Please review the following CSR intended to clarify the true meaning of StringBuilder::capacity and StringBuffer::capacity. csr: https://bugs.openjdk.java.net/browse/JDK-8236683 diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java @@ -181,9 +181,9 @@ } /** - * Returns the current capacity. The capacity is the amount of storage - * available for newly inserted characters, beyond which an allocation - * will occur. + * Returns the current capacity. The capacity is the number of characters + * that can be stored (including already written characters), beyond which + * an allocation will occur. * * @return the current capacity */ From Sergey.Bylokhov at oracle.com Mon Jan 6 20:34:30 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 6 Jan 2020 23:34:30 +0300 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS In-Reply-To: <5E13713E.1020607@oracle.com> References: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> <57e519a8-a4a1-02f4-d06e-674a10fe9cdd@oracle.com> <4ea1a4a8-9d7a-4b4b-804c-b22c4bc0cbe7@oracle.com> <5E13713E.1020607@oracle.com> Message-ID: <9ed4eec6-b1ca-8c62-9b50-5c94db384795@oracle.com> On 1/6/20 8:41 pm, Philip Race wrote: > How is this useful given that we disable jtreg failure handlers for the headful tests ? It is disabled only in mach5 for headful nightly and CI builds, but it is enabled for other builds, also it is enabled if the headful tests are executed standalone via "make test", and it could easily be enabled in mach5 for personal jobs(I do this time to time) > > -phil. > > On 12/30/19, 11:33 AM, Sergey Bylokhov wrote: >> On 12/23/19 9:15 pm, Phil Race wrote: >>> I am not sure what the right mailing list(s) are for this change. >>> It definitely isn't a core-libs change. I think build-dev may be better. >> >> Previous changes to these configs were discussed here, so I have send it here as well. >> >>> >>> I am also unclear when this failure handler is invoked and how all this machinery works. >>> >>> It is only useful for headful tests and so I'd only want it enabled in such a case. >>> And we disable the failure handlers in the headful test jobs anyway because they seem >>> focused on taking pointless core dumps ...> So we need something that can be used with headful tests only and doesn't involve >>> re-enabling the other handlers. >> It could be useful for other tests as well and may be able to identify problems such as: >> ?- Suggestions "to open under debugger" from the native asserts >> ?- Various error dialogs from the OS >> And it does not spend much resources compared to current handlers. >> >>> >>> Also why exclude Windows ? No easy way to get the screenshot ? >> >> There is no command-line program that can take a screenshot on windows by default >> >>> >>> -phil. >>> >>> On 12/11/19 1:00 AM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for JDK 14. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 >>>> Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 >>>> >>>> This change adds the "screen capture on the test failure" feature on macOS and Linux. >>>> ?- On Linux, it is implemented by the "gnome-screenshot" command(in case of >>>> ?? multiscreen+xinerama??? the whole big screen will be saved to the "screen.png" file). >>>> ?- On macOS it is implemented by the "screencapture" command, note that I have >>>> ?? used 1 file per screen, if the number of screens less than 5, other files will be ignored. >>>> >>> >> >> -- Best regards, Sergey. From joe.darcy at oracle.com Mon Jan 6 21:08:01 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 6 Jan 2020 13:08:01 -0800 Subject: JDK 14 RFR of JDK-8234783: Improve wording of spec of Record.equals Message-ID: <1ac6c441-a5ce-0e43-9264-0f4259c19e3d@oracle.com> Hello, Please review a clarification to the specification of Record.equals: ??? JDK-8234783: Improve wording of spec of Record.equals ??? http://cr.openjdk.java.net/~darcy/8234783.0/ Patch below. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 13:00:52.179585999 -0800 +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 13:00:51.987681999 -0800 @@ -105,9 +105,21 @@ ????? * The implicitly provided implementation returns {@code true} if and ????? * only if the argument is an instance of the same record type as this object, ????? * and each component of this record is equal to the corresponding component -???? * of the argument, according to {@link java.util.Objects#equals(Object,Object)} -???? * for components whose types are reference types, and according to the semantics -???? * of the {@code equals} method on the corresponding primitive wrapper type. +???? * of the argument. Equality of the components is determined as follows: +???? *
    +???? * +???? *
  • If the component is of a reference type, the component {@code +???? * cr} is considered equal if and only if {@link +???? * java.util.Objects#equals(Object,Object) +???? * Objects.equals(this.cr(), r.cr()} would return true . +???? * +???? *
  • If the component is of a primitive type, using the +???? * corresponding primitive wrapper class {@code P} the component +???? * {@code cp} is considered equal if and only if {@code +???? * P.valueOf(this.cp()).equals(P.valueOf(r.cp()))} would return +???? * true. +???? * +???? *
????? * ????? * @see java.util.Objects#equals(Object,Object) ????? * From jonathan.gibbons at oracle.com Mon Jan 6 21:22:23 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 6 Jan 2020 13:22:23 -0800 Subject: JDK 14 RFR of JDK-8234783: Improve wording of spec of Record.equals In-Reply-To: <1ac6c441-a5ce-0e43-9264-0f4259c19e3d@oracle.com> References: <1ac6c441-a5ce-0e43-9264-0f4259c19e3d@oracle.com> Message-ID: I like what you're trying to do, but the wording used to introduce the names `cr` and `cp` feels a bit contorted.? How about using a single name, c, introduced up front in this line: +???? * of the argument. Equality of a component {@code c} is determined as follows: with the rest of the text updated accordingly. Note the use of the indefinite article `a component` when the name is introduced, and the definite article `the component` in subsequent references. -- Jon On 1/6/20 1:08 PM, Joe Darcy wrote: > Hello, > > Please review a clarification to the specification of Record.equals: > > ??? JDK-8234783: Improve wording of spec of Record.equals > ??? http://cr.openjdk.java.net/~darcy/8234783.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 > 13:00:52.179585999 -0800 > +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 > 13:00:51.987681999 -0800 > @@ -105,9 +105,21 @@ > ????? * The implicitly provided implementation returns {@code true} if > and > ????? * only if the argument is an instance of the same record type as > this object, > ????? * and each component of this record is equal to the > corresponding component > -???? * of the argument, according to {@link > java.util.Objects#equals(Object,Object)} > -???? * for components whose types are reference types, and according > to the semantics > -???? * of the {@code equals} method on the corresponding primitive > wrapper type. > +???? * of the argument. Equality of the components is determined as > follows: > +???? *
    > +???? * > +???? *
  • If the component is of a reference type, the component > {@code > +???? * cr} is considered equal if and only if {@link > +???? * java.util.Objects#equals(Object,Object) > +???? * Objects.equals(this.cr(), r.cr()} would return true . > +???? * > +???? *
  • If the component is of a primitive type, using the > +???? * corresponding primitive wrapper class {@code P} the component > +???? * {@code cp} is considered equal if and only if {@code > +???? * P.valueOf(this.cp()).equals(P.valueOf(r.cp()))} would return > +???? * true. > +???? * > +???? *
> ????? * > ????? * @see java.util.Objects#equals(Object,Object) > ????? * > From brent.christian at oracle.com Mon Jan 6 21:42:58 2020 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 6 Jan 2020 13:42:58 -0800 Subject: RFR: JDK-8236683 StringBuilder / StringBuffer capacity() doc is misleading (CSR) In-Reply-To: <0A5D7986-836B-4DFE-9303-6D0EE0BED47A@oracle.com> References: <0A5D7986-836B-4DFE-9303-6D0EE0BED47A@oracle.com> Message-ID: <6901c11a-cfa9-936d-86f5-2ee5b138e9be@oracle.com> Looks reasonable to me - reviewed. -Brent On 1/6/20 10:29 AM, Jim Laskey wrote: > Please review the following CSR intended to clarify the true meaning of StringBuilder::capacity and StringBuffer::capacity. > > csr: https://bugs.openjdk.java.net/browse/JDK-8236683 > > > diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java > @@ -181,9 +181,9 @@ > } > > /** > - * Returns the current capacity. The capacity is the amount of storage > - * available for newly inserted characters, beyond which an allocation > - * will occur. > + * Returns the current capacity. The capacity is the number of characters > + * that can be stored (including already written characters), beyond which > + * an allocation will occur. > * > * @return the current capacity > */ > > > From christoph.langer at sap.com Mon Jan 6 22:25:24 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Jan 2020 22:25:24 +0000 Subject: [14] RFR: 8236495, open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale. In-Reply-To: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com> Message-ID: Hi Naoto, The change looks good. Thanks for fixing this. We're seeing it regularly in our test infrastructure where we're running Mac systems with German locale. Best regards Christoph > -----Original Message----- > From: i18n-dev On Behalf Of > naoto.sato at oracle.com > Sent: Montag, 6. Januar 2020 18:05 > To: i18n-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net> > Subject: [14] RFR: 8236495, > open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 > with de_DE locale. > > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8236495 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8236495/webrev.00/ > > The test case for the fix to 8232860 was only intended for the US > locale. Simply adding the default locale check will fix the test case. > > Naoto From joe.darcy at oracle.com Mon Jan 6 23:22:42 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 6 Jan 2020 15:22:42 -0800 Subject: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared with an explicit constructor Message-ID: <90c9a2ce-32c0-eaca-6a90-6f9998a96b7c@oracle.com> Hello, The initial implementation of java.lang.Record uses a default constructor; an explicit constructor should be added instead. Please review the code change and CSR for this: ??? JDK-8236695: java.lang.Record should be declared with an explicit constructor ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8236699 ??? http://cr.openjdk.java.net/~darcy/8236695.0/ Patch below. It is sufficient for the constructor to be declared as protected rather than public; the serialization tests and other records test pass with this change. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 13:47:31.740871560 -0800 +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 13:47:31.552777567 -0800 @@ -91,6 +91,11 @@ ????????????????????????????? essentialAPI=true) ?public abstract class Record { ???? /** +???? * Constructor for record classes to call. +???? */ +??? protected Record() {} + +??? /** ????? * Indicates whether some other object is "equal to" this one.? In addition ????? * to the general contract of {@link Object#equals(Object)}, ????? * record classes must further participate in the invariant that when From mandy.chung at oracle.com Mon Jan 6 23:36:14 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 6 Jan 2020 15:36:14 -0800 Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes In-Reply-To: References: <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com> <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com> <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com> Message-ID: <13ce2eb6-40d9-d7e3-e084-44a413aa1f5b@oracle.com> Hi Adam, Thanks for the examples. I was hoping for some customer issues and how they identified the root causes to understand if there is any specific problem to be considered than improving the overall class loading diagnosability. The solution you propose is to add debug/trace statements in the class loading implementation to improve diagnosability.?? I concern the volume of trace output could make it hard to troubleshoot. There are existing class loading traces with unified VM logging, JFR events and also jcmd that also output class loading information. Adding a new class loading tracing mechanism isn't a good option. Alan mentioned that discussion at OpenJDK worshop [1] about improving the serviceability and diagnosibility in the java.base module.? I think that'd better guide you if that makes further discussion. Mandy [1] https://mail.openjdk.java.net/pipermail/workshop-discuss/2019-August/000078.html On 11/8/19 5:49 AM, Adam Farley8 wrote: > Hi Mandy, > > Sorry for the delay in responding. > > Mandy Chung wrote on 29/10/2019 19:30:55: > > > From: Mandy Chung > > To: Adam Farley8 > > Cc: core-libs-dev > > Date: 29/10/2019 19:31 > > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > > for Specific Classes > > > > Hi Adam, > > > > It'd be useful to provide a few typical scenarios that customers run > into. > > > > That would give better understanding on the problem "hard to diagnose > > why a given class was not loaded" and help the consideration on > > alternatives. > > I'm happy to provide some hypothetical example scenarios, which I've > included below. We should note that this is not limited to customers, and > that this sort of diagnostic output is also extremely useful for people > helping customers to resolve issues. > When a class cannot be found, it's a configuration issue and Class-Path hell > I've also included the way the webrev's debug output aids people trying > to reproduce this problem. > > Scenario 1: A user gets a ClassNotFoundException because the location > of the class is not on the classpath used by the ClassLoader/s that > attempted to load it, despite the fact that one ClassLoader definitely > has the location of the class on its classpath. > > Aid: This webrev's debug output tells the user, or the tech support > aiding the user: > - If the ClassLoader with the classpath location for that class is > ever tasked with trying to load that class. > - If the ClassLoader with the classpath location for that class > actually tries to load that class from the classpath (vs a module). > - If the ClassLoader with the classpath location actually checks that > location at all. > - What other ClassLoaders are used to attempt to load that class, > allowing the user/support agent to adjust the classpath for another > ClassLoader if needed. > > Scenario 2: A program uses the wrong version of a class. > > Aid: This webrev's debug output tells the user, or the tech support > aiding the user: > - Which classpath was used by the ClassLoader that loaded the class > at the time that the class was loaded. > - Which locations were checked by that ClassLoader before finding the > wrong version of the class. This, among other things, helps identify > access issues for the location of the correct class. > - Which ClassLoaders attempted to load the class, and in which order, > (increasingly useful in the current "nested" ClassLoading model). > > Scenario 3: A program is unable to find a class because none of the > ClassLoaders could find it, and you lack both familiarity with the > ClassLoader code, and the time to figure out how all of the different > ones work. > > Aid: This webrev's debug output tells the user, or the tech support > aiding the user: > - Which ClassLoaders were involved in each attempt to load the class. > - What the logic path was for each ClassLoader asked to load the > class. > - Which module/s, if any, were identified by the ClassLoader as the > potential owner/s of the class, and how that worked out in each > case. > > > The debug output could produce lots of trace output but > > the output does not clearly indicate the initiating class is. > > Correct. The scope of my debug output was limited to the actions > of the ClassLoader/s attempting to load a class that matches a > specific regex. > > > I wonder > > if the problem you are looking at is related to JDK-6747450 [1] or > > really tracing the class loader delegation and search path. > > The latter. If I implied that I was interested in the initiating class, > then I was wrong. Also, though I am not fundamentally opposed to > expanding the scope to incorporate JDK-6747450, the fact that it's been > drifting for nine years tells me I'd just be adding complexity without > adding anything that would support the inclusion of the change. > > Short version: I think this issue's scope should not include details > of the initiating class. > > > Or maybe > > Java Flight Recorder is a better candidate? > > I don't know much about Java Flight Recorder, as it currently only > supports one of the VMs I work with. > > >? Without knowing specific > > of the problems customers have, perhaps VM logging can be enhanced to > > trace the initiating class and class loader? > > > > Mandy > > It's possible. I wouldn't know where to start with that. The simplest, > and most straight-forward approach (in my mind) is to add the debug > code directly to the code we're debugging. > > Plus, using a Class Library -based approach ensures that the debug > output is available regardless of the VM being used, or the user's > familiarity with Flight Recorder. > > Though this might just be a "me" problem. ;) > > What do you think? > > Best Regards > > Adam Farley From paul.sandoz at oracle.com Mon Jan 6 23:46:03 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 6 Jan 2020 15:46:03 -0800 Subject: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared with an explicit constructor In-Reply-To: <90c9a2ce-32c0-eaca-6a90-6f9998a96b7c@oracle.com> References: <90c9a2ce-32c0-eaca-6a90-6f9998a96b7c@oracle.com> Message-ID: <2ADEF3D8-9F9A-458D-992B-75DDDF4E14FF@oracle.com> +1 Paul. > On Jan 6, 2020, at 3:22 PM, Joe Darcy wrote: > > Hello, > > The initial implementation of java.lang.Record uses a default constructor; an explicit constructor should be added instead. Please review the code change and CSR for this: > > JDK-8236695: java.lang.Record should be declared with an explicit constructor > CSR: https://bugs.openjdk.java.net/browse/JDK-8236699 > http://cr.openjdk.java.net/~darcy/8236695.0/ > > Patch below. It is sufficient for the constructor to be declared as protected rather than public; the serialization tests and other records test pass with this change. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 13:47:31.740871560 -0800 > +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 13:47:31.552777567 -0800 > @@ -91,6 +91,11 @@ > essentialAPI=true) > public abstract class Record { > /** > + * Constructor for record classes to call. > + */ > + protected Record() {} > + > + /** > * Indicates whether some other object is "equal to" this one. In addition > * to the general contract of {@link Object#equals(Object)}, > * record classes must further participate in the invariant that when > From joe.darcy at oracle.com Tue Jan 7 00:23:02 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 6 Jan 2020 16:23:02 -0800 Subject: JDK 14 RFR of JDK-8234783: Improve wording of spec of Record.equals In-Reply-To: References: <1ac6c441-a5ce-0e43-9264-0f4259c19e3d@oracle.com> Message-ID: Hi Jon, Thanks for the comments; second take on the re-wording up at ??? http://cr.openjdk.java.net/~darcy/8234783.1/ and copied below for convenience. Cheers, -Joe --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 16:18:43.505405539 -0800 +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 16:18:43.317311546 -0800 @@ -92,8 +92,8 @@ ?public abstract class Record { ???? /** ????? * Indicates whether some other object is "equal to" this one.? In addition -???? * to the general contract of {@link Object#equals(Object)}, -???? * record classes must further participate in the invariant that when +???? * to the general contract of {@link Object#equals(Object) Object.equals}, +???? * record classes must further obey the invariant that when ????? * a record instance is "copied" by passing the result of the record component ????? * accessor methods to the canonical constructor, as follows: ????? * 
@@ -102,17 +102,37 @@
 ????? * then it must be the case that {@code r.equals(copy)}.
 ????? *
 ????? * @implSpec
-???? * The implicitly provided implementation returns {@code true} if and
-???? * only if the argument is an instance of the same record type as 
this object,
-???? * and each component of this record is equal to the corresponding 
component
-???? * of the argument, according to {@link 
java.util.Objects#equals(Object,Object)}
-???? * for components whose types are reference types, and according to 
the semantics
-???? * of the {@code equals} method on the corresponding primitive 
wrapper type.
+???? * The implicitly provided implementation returns {@code true} if
+???? * and only if the argument is an instance of the same record type
+???? * as this object, and each component of this record is equal to
+???? * the corresponding component of the argument; otherwise, {@code
+???? * false} is returned. Equality of a component {@code c} is
+???? * determined as follows:
+???? * 
    
+???? *
+???? * 
  •  If the component is of a reference type, the component is
+???? * considered equal if and only if {@link
+???? * java.util.Objects#equals(Object,Object)
+???? * Objects.equals(this.c(), r.c()} would return {@code true}.
+???? *
+???? * 
  •  If the component is of a primitive type, using the
+???? * corresponding primitive wrapper class {@code PW} (the wrapper
+???? * class {@code java.lang.Integer} for {@code int}, and so on) the
+???? * component is considered equal if and only if {@code
+???? * PW.valueOf(this.c()).equals(PW.valueOf(r.c()))} would return
+???? * {@code true}.
+???? *
+???? * 

+???? *
+???? * The implicitly provided implementation conforms to the
+???? * semantics described above; the implementation may or may not
+???? * accomplish this by using calls to the particular methods
+???? * listed.
 ????? *
 ????? * @see java.util.Objects#equals(Object,Object)
 ????? *
 ????? * @param?? obj?? the reference object with which to compare.
-???? * @return? {@code true} if this object is the same as the obj
+???? * @return? {@code true} if this object is equal to the
 ????? *????????? argument; {@code false} otherwise.
 ????? */
 ???? @Override

On 1/6/2020 1:22 PM, Jonathan Gibbons wrote:
> I like what you're trying to do, but the wording used to introduce the 
> names `cr` and `cp` feels a bit contorted.? How about using a single 
> name, c, introduced up front in this line:
>
>
> +???? * of the argument. Equality of a component {@code c} is 
> determined as follows:
>
> with the rest of the text updated accordingly. Note the use of the 
> indefinite article `a component` when the name is introduced, and the 
> definite article `the component` in subsequent references.
>
> -- Jon
>
>
> On 1/6/20 1:08 PM, Joe Darcy wrote:
>> Hello,
>>
>> Please review a clarification to the specification of Record.equals:
>>
>> ??? JDK-8234783: Improve wording of spec of Record.equals
>> ??? http://cr.openjdk.java.net/~darcy/8234783.0/
>>
>> Patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 
>> 13:00:52.179585999 -0800
>> +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 
>> 13:00:51.987681999 -0800
>> @@ -105,9 +105,21 @@
>> ????? * The implicitly provided implementation returns {@code true} 
>> if and
>> ????? * only if the argument is an instance of the same record type 
>> as this object,
>> ????? * and each component of this record is equal to the 
>> corresponding component
>> -???? * of the argument, according to {@link 
>> java.util.Objects#equals(Object,Object)}
>> -???? * for components whose types are reference types, and according 
>> to the semantics
>> -???? * of the {@code equals} method on the corresponding primitive 
>> wrapper type.
>> +???? * of the argument. Equality of the components is determined as 
>> follows:
>> +???? * 
    
>> +???? *
>> +???? * 
  •  If the component is of a reference type, the component 
>> {@code
>> +???? * cr} is considered equal if and only if {@link
>> +???? * java.util.Objects#equals(Object,Object)
>> +???? * Objects.equals(this.cr(), r.cr()} would return true .
>> +???? *
>> +???? * 
  •  If the component is of a primitive type, using the
>> +???? * corresponding primitive wrapper class {@code P} the component
>> +???? * {@code cp} is considered equal if and only if {@code
>> +???? * P.valueOf(this.cp()).equals(P.valueOf(r.cp()))} would return
>> +???? * true.
>> +???? *
>> +???? * 

>> ????? *
>> ????? * @see java.util.Objects#equals(Object,Object)
>> ????? *
>>

From alexander.matveev at oracle.com  Tue Jan  7 00:36:44 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 6 Jan 2020 16:36:44 -0800
Subject: RFR: JDK-8236132: Add missing properties to msi installers
In-Reply-To: 
References: 
 
Message-ID: <581fcb80-58a3-332c-5b28-7c95422caef0@oracle.com>

Hi Alexey,

Can you add description for JpIcon to overrides.wxi, otherwise looks fine.

Thanks,
Alexander

On 12/20/2019 12:16 PM, Alexey Semenyuk wrote:
> Please review fix [2] for jpackage bug [1].
>
> Add properties to msi installers to properly display installation 
> location and icon of the application in the list of installed 
> applications.
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8236132
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8236132/webrev.00


From jonathan.gibbons at oracle.com  Tue Jan  7 01:46:16 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 Jan 2020 17:46:16 -0800
Subject: JDK 14 RFR of JDK-8234783: Improve wording of spec of
 Record.equals
In-Reply-To: 
References: <1ac6c441-a5ce-0e43-9264-0f4259c19e3d@oracle.com>
 
 
Message-ID: 

Looks good to me.

-- Jon


On 01/06/2020 04:23 PM, Joe Darcy wrote:
> Hi Jon,
>
> Thanks for the comments; second take on the re-wording up at
>
> ??? http://cr.openjdk.java.net/~darcy/8234783.1/
>
> and copied below for convenience.
>
> Cheers,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 
> 16:18:43.505405539 -0800
> +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 
> 16:18:43.317311546 -0800
> @@ -92,8 +92,8 @@
> ?public abstract class Record {
> ???? /**
> ????? * Indicates whether some other object is "equal to" this one.? 
> In addition
> -???? * to the general contract of {@link Object#equals(Object)},
> -???? * record classes must further participate in the invariant that 
> when
> +???? * to the general contract of {@link Object#equals(Object) 
> Object.equals},
> +???? * record classes must further obey the invariant that when
> ????? * a record instance is "copied" by passing the result of the 
> record component
> ????? * accessor methods to the canonical constructor, as follows:
> ????? * 
> @@ -102,17 +102,37 @@
> ????? * then it must be the case that {@code r.equals(copy)}.
> ????? *
> ????? * @implSpec
> -???? * The implicitly provided implementation returns {@code true} if 
> and
> -???? * only if the argument is an instance of the same record type as 
> this object,
> -???? * and each component of this record is equal to the 
> corresponding component
> -???? * of the argument, according to {@link 
> java.util.Objects#equals(Object,Object)}
> -???? * for components whose types are reference types, and according 
> to the semantics
> -???? * of the {@code equals} method on the corresponding primitive 
> wrapper type.
> +???? * The implicitly provided implementation returns {@code true} if
> +???? * and only if the argument is an instance of the same record type
> +???? * as this object, and each component of this record is equal to
> +???? * the corresponding component of the argument; otherwise, {@code
> +???? * false} is returned. Equality of a component {@code c} is
> +???? * determined as follows:
> +???? * 
    
> +???? *
> +???? * 
  •  If the component is of a reference type, the component is
> +???? * considered equal if and only if {@link
> +???? * java.util.Objects#equals(Object,Object)
> +???? * Objects.equals(this.c(), r.c()} would return {@code true}.
> +???? *
> +???? * 
  •  If the component is of a primitive type, using the
> +???? * corresponding primitive wrapper class {@code PW} (the wrapper
> +???? * class {@code java.lang.Integer} for {@code int}, and so on) the
> +???? * component is considered equal if and only if {@code
> +???? * PW.valueOf(this.c()).equals(PW.valueOf(r.c()))} would return
> +???? * {@code true}.
> +???? *
> +???? * 

> +???? *
> +???? * The implicitly provided implementation conforms to the
> +???? * semantics described above; the implementation may or may not
> +???? * accomplish this by using calls to the particular methods
> +???? * listed.
> ????? *
> ????? * @see java.util.Objects#equals(Object,Object)
> ????? *
> ????? * @param?? obj?? the reference object with which to compare.
> -???? * @return? {@code true} if this object is the same as the obj
> +???? * @return? {@code true} if this object is equal to the
> ????? *????????? argument; {@code false} otherwise.
> ????? */
> ???? @Override
>
> On 1/6/2020 1:22 PM, Jonathan Gibbons wrote:
>> I like what you're trying to do, but the wording used to introduce 
>> the names `cr` and `cp` feels a bit contorted.? How about using a 
>> single name, c, introduced up front in this line:
>>
>>
>> +???? * of the argument. Equality of a component {@code c} is 
>> determined as follows:
>>
>> with the rest of the text updated accordingly. Note the use of the 
>> indefinite article `a component` when the name is introduced, and the 
>> definite article `the component` in subsequent references.
>>
>> -- Jon
>>
>>
>> On 1/6/20 1:08 PM, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please review a clarification to the specification of Record.equals:
>>>
>>> ??? JDK-8234783: Improve wording of spec of Record.equals
>>> ??? http://cr.openjdk.java.net/~darcy/8234783.0/
>>>
>>> Patch below.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> --- old/src/java.base/share/classes/java/lang/Record.java 2020-01-06 
>>> 13:00:52.179585999 -0800
>>> +++ new/src/java.base/share/classes/java/lang/Record.java 2020-01-06 
>>> 13:00:51.987681999 -0800
>>> @@ -105,9 +105,21 @@
>>> ????? * The implicitly provided implementation returns {@code true} 
>>> if and
>>> ????? * only if the argument is an instance of the same record type 
>>> as this object,
>>> ????? * and each component of this record is equal to the 
>>> corresponding component
>>> -???? * of the argument, according to {@link 
>>> java.util.Objects#equals(Object,Object)}
>>> -???? * for components whose types are reference types, and 
>>> according to the semantics
>>> -???? * of the {@code equals} method on the corresponding primitive 
>>> wrapper type.
>>> +???? * of the argument. Equality of the components is determined as 
>>> follows:
>>> +???? * 
    
>>> +???? *
>>> +???? * 
  •  If the component is of a reference type, the component 
>>> {@code
>>> +???? * cr} is considered equal if and only if {@link
>>> +???? * java.util.Objects#equals(Object,Object)
>>> +???? * Objects.equals(this.cr(), r.cr()} would return true .
>>> +???? *
>>> +???? * 
  •  If the component is of a primitive type, using the
>>> +???? * corresponding primitive wrapper class {@code P} the component
>>> +???? * {@code cp} is considered equal if and only if {@code
>>> +???? * P.valueOf(this.cp()).equals(P.valueOf(r.cp()))} would return
>>> +???? * true.
>>> +???? *
>>> +???? * 

>>> ????? *
>>> ????? * @see java.util.Objects#equals(Object,Object)
>>> ????? *
>>>


From ivan.gerasimov at oracle.com  Tue Jan  7 06:41:17 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 6 Jan 2020 22:41:17 -0800
Subject: Use single character replace variant in
 Resources.toPackageName(String)
In-Reply-To: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de>
References: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de>
Message-ID: 

Hi Christoph!

First, the same optimization can be done in 
src/java.base/share/classes/jdk/internal/module/ModulePath.java:
 ??????????????? mainClass = mainClass.replace("/", ".");

Second, I wonder what was the JDK version you ran your benchmark on?

After the fix for JDK-8222955 the method replace(CharSequence, 
CharSequence) now detects one-char arguments as a special case.

Thus, I think, more work should actually reduce the difference in 
performance between two versions of replace.

Still, I think this optimization is worthwhile.? I can sponsor it for you.

With kind regards,

Ivan


On 1/6/20 9:33 AM, Christoph Dreis wrote:
> Hi and a happy new year,
>
> I recently noticed that jdk.internal.module.Resources.toPackageName(String) makes use of String.replace(CharSequence, CharSequence) while it could use the single char variant in my opinion:
>
> diff --git a/src/java.base/share/classes/jdk/internal/module/Resources.java b/src/java.base/share/classes/jdk/internal/module/Resources.java
> --- a/src/java.base/share/classes/jdk/internal/module/Resources.java
> +++ b/src/java.base/share/classes/jdk/internal/module/Resources.java
> @@ -64,7 +64,7 @@
>           if (index == -1 || index == name.length()-1) {
>               return "";
>           } else {
> -            return name.substring(0, index).replace("/", ".");
> +            return name.substring(0, index).replace('/', '.');
>           }
>       }
>
> I ran an isolated benchmark with some test data on it, which shows the following results
>
> Benchmark                                                            (param)     Mode  Cnt     Score     Error   Units
> MyBenchmark.testNew                                       java/lang  avgt      10    14,905 ?   0,130   ns/op
> MyBenchmark.testNew:?gc.alloc.rate.norm    java/lang  avgt      10    48,000 ?   0,001    B/op
> MyBenchmark.testNew                                      a/b/c/d/e  avgt      10    23,122 ?   0,389   ns/op
> MyBenchmark.testNew:?gc.alloc.rate.norm   a/b/c/d/e  avgt      10    96,000 ?   0,001    B/op
> MyBenchmark.testOld                                        java/lang  avgt       10    16,614 ?   0,420   ns/op
> MyBenchmark.testOld:?gc.alloc.rate.norm     java/lang  avgt       10    48,000 ?   0,001    B/op
> MyBenchmark.testOld                                       a/b/c/d/e  avgt       10    84,745 ?   1,329   ns/op
> MyBenchmark.testOld:?gc.alloc.rate.norm    a/b/c/d/e  avgt       10   120,000 ?   0,001    B/op
>
> As you can see the more replacing needs to be done the better the newer version seems to be perform.
>
> In case this is considered worthwhile I would need someone to sponsor the patch. If not, I'm sorry for the noise.
>
> Cheers,
> Christoph Dreis
>
>
>
-- 
With kind regards,
Ivan Gerasimov


From shade at redhat.com  Tue Jan  7 06:50:23 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 7 Jan 2020 07:50:23 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: 
References: 
 <5E016C66.4040502@oracle.com>
 
 <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com>
 <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com>
 
Message-ID: <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>

On 1/6/20 1:48 PM, Alex Kashchenko wrote:
> On 01/06/2020 10:54 AM, Aleksey Shipilev wrote:
>> On 1/6/20 10:57 AM, Alex Kashchenko wrote:
>>> On 12/24/2019 11:54 AM, Alex Kashchenko wrote:
>>>> On 12/24/2019 01:39 AM, Philip Race wrote:
>>>>> Have you verified this with VS 2017 ?
>>>>> Not that I can see a problem but I doubt we want to trade breaking
>>>>> 2017 to fix 2013 ...
>>>>
>>>> Yes, VS 2017 compiles fine with this fix.
>>>>
>>>>
>>>>> [...]
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>>>>> [...]
>>>
>>> Gentle reminder, it would be great to have this included before jdk14
>>> enters rampdown 2.
>>
>> The patch looks good to me. (I did the same in the original bug report).
> 
> Thanks for the review! Sponsor is required for this patch to be pushed 
> (I am not an author in "jdk" and cannot export committed changeset).

I can sponsor jdk/jdk14 push. But I need someone else to acknowledge (I don't feel fancy acking
basically my own patch :]). Phil, maybe?

-- 
Thanks,
-Aleksey


From ivan.gerasimov at oracle.com  Tue Jan  7 07:09:37 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 6 Jan 2020 23:09:37 -0800
Subject: Use single character replace variant in
 Resources.toPackageName(String)
In-Reply-To: 
References: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de>
 
Message-ID: <8bb7168b-91b9-90ee-eae7-59d0f4ef82ee@oracle.com>

So, I filed a Jira bug:

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236705
WEBREV: http://cr.openjdk.java.net/~igerasim/8236705/00/webrev/

If we agree on the content of the fix, I can push it after a sanity build.

With kind regards,

Ivan


On 1/6/20 10:41 PM, Ivan Gerasimov wrote:
> Hi Christoph!
>
> First, the same optimization can be done in 
> src/java.base/share/classes/jdk/internal/module/ModulePath.java:
> ??????????????? mainClass = mainClass.replace("/", ".");
>
> Second, I wonder what was the JDK version you ran your benchmark on?
>
> After the fix for JDK-8222955 the method replace(CharSequence, 
> CharSequence) now detects one-char arguments as a special case.
>
> Thus, I think, more work should actually reduce the difference in 
> performance between two versions of replace.
>
> Still, I think this optimization is worthwhile.? I can sponsor it for 
> you.
>
> With kind regards,
>
> Ivan
>
>
> On 1/6/20 9:33 AM, Christoph Dreis wrote:
>> Hi and a happy new year,
>>
>> I recently noticed that 
>> jdk.internal.module.Resources.toPackageName(String) makes use of 
>> String.replace(CharSequence, CharSequence) while it could use the 
>> single char variant in my opinion:
>>
>> diff --git 
>> a/src/java.base/share/classes/jdk/internal/module/Resources.java 
>> b/src/java.base/share/classes/jdk/internal/module/Resources.java
>> --- a/src/java.base/share/classes/jdk/internal/module/Resources.java
>> +++ b/src/java.base/share/classes/jdk/internal/module/Resources.java
>> @@ -64,7 +64,7 @@
>> ????????? if (index == -1 || index == name.length()-1) {
>> ????????????? return "";
>> ????????? } else {
>> -??????????? return name.substring(0, index).replace("/", ".");
>> +??????????? return name.substring(0, index).replace('/', '.');
>> ????????? }
>> ????? }
>>
>> I ran an isolated benchmark with some test data on it, which shows 
>> the following results
>>
>> Benchmark (param)???? Mode? Cnt???? Score???? Error?? Units
>> MyBenchmark.testNew java/lang? avgt????? 10??? 14,905 ??? 0,130?? ns/op
>> MyBenchmark.testNew:?gc.alloc.rate.norm??? java/lang? avgt 10??? 
>> 48,000 ??? 0,001??? B/op
>> MyBenchmark.testNew a/b/c/d/e? avgt????? 10??? 23,122 ??? 0,389?? ns/op
>> MyBenchmark.testNew:?gc.alloc.rate.norm?? a/b/c/d/e? avgt 10??? 
>> 96,000 ??? 0,001??? B/op
>> MyBenchmark.testOld java/lang? avgt?????? 10??? 16,614 ??? 0,420?? ns/op
>> MyBenchmark.testOld:?gc.alloc.rate.norm???? java/lang avgt?????? 
>> 10??? 48,000 ??? 0,001??? B/op
>> MyBenchmark.testOld a/b/c/d/e? avgt?????? 10??? 84,745 ??? 1,329?? ns/op
>> MyBenchmark.testOld:?gc.alloc.rate.norm??? a/b/c/d/e? avgt 10?? 
>> 120,000 ??? 0,001??? B/op
>>
>> As you can see the more replacing needs to be done the better the 
>> newer version seems to be perform.
>>
>> In case this is considered worthwhile I would need someone to sponsor 
>> the patch. If not, I'm sorry for the noise.
>>
>> Cheers,
>> Christoph Dreis
>>
>>
>>
-- 
With kind regards,
Ivan Gerasimov


From christoph.dreis at freenet.de  Tue Jan  7 07:46:18 2020
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 07 Jan 2020 08:46:18 +0100
Subject: Use single character replace variant in
 Resources.toPackageName(String)
In-Reply-To: <8bb7168b-91b9-90ee-eae7-59d0f4ef82ee@oracle.com>
References: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de>
 
 <8bb7168b-91b9-90ee-eae7-59d0f4ef82ee@oracle.com>
Message-ID: <529D5870-DDBC-48E7-9718-A18D591332DA@freenet.de>

Hi Ivan,

I was indeed running with JDK 11 instead of JDK 13 (sorry), but like you I still think it's worthwhile.

>    BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236705
>    WEBREV: http://cr.openjdk.java.net/~igerasim/8236705/00/webrev/
>   If we agree on the content of the fix, I can push it after a sanity build.
    
Looks good to me. Thanks.

I wonder if the copyright should change to 2020, but I don't how this is handled in the JDK.

Cheers,
Christoph
    
    On 1/6/20 10:41 PM, Ivan Gerasimov wrote:
    > Hi Christoph!
    >
    > First, the same optimization can be done in 
    > src/java.base/share/classes/jdk/internal/module/ModulePath.java:
    >                 mainClass = mainClass.replace("/", ".");
    >
    > Second, I wonder what was the JDK version you ran your benchmark on?
    >
    > After the fix for JDK-8222955 the method replace(CharSequence, 
    > CharSequence) now detects one-char arguments as a special case.
    >
    > Thus, I think, more work should actually reduce the difference in 
    > performance between two versions of replace.
    >
    > Still, I think this optimization is worthwhile.  I can sponsor it for 
    > you.
    >
    > With kind regards,
    >
    > Ivan
    >
    >
    > On 1/6/20 9:33 AM, Christoph Dreis wrote:
    >> Hi and a happy new year,
    >>
    >> I recently noticed that 
    >> jdk.internal.module.Resources.toPackageName(String) makes use of 
    >> String.replace(CharSequence, CharSequence) while it could use the 
    >> single char variant in my opinion:
    >>
    >> diff --git 
    >> a/src/java.base/share/classes/jdk/internal/module/Resources.java 
    >> b/src/java.base/share/classes/jdk/internal/module/Resources.java
    >> --- a/src/java.base/share/classes/jdk/internal/module/Resources.java
    >> +++ b/src/java.base/share/classes/jdk/internal/module/Resources.java
    >> @@ -64,7 +64,7 @@
    >>           if (index == -1 || index == name.length()-1) {
    >>               return "";
    >>           } else {
    >> -            return name.substring(0, index).replace("/", ".");
    >> +            return name.substring(0, index).replace('/', '.');
    >>           }
    >>       }
    >>
    >> I ran an isolated benchmark with some test data on it, which shows 
    >> the following results
    >>
    >> Benchmark (param)     Mode  Cnt     Score     Error   Units
    >> MyBenchmark.testNew java/lang  avgt      10    14,905 ?   0,130   ns/op
    >> MyBenchmark.testNew:?gc.alloc.rate.norm    java/lang  avgt 10    
    >> 48,000 ?   0,001    B/op
    >> MyBenchmark.testNew a/b/c/d/e  avgt      10    23,122 ?   0,389   ns/op
    >> MyBenchmark.testNew:?gc.alloc.rate.norm   a/b/c/d/e  avgt 10    
    >> 96,000 ?   0,001    B/op
    >> MyBenchmark.testOld java/lang  avgt       10    16,614 ?   0,420   ns/op
    >> MyBenchmark.testOld:?gc.alloc.rate.norm     java/lang avgt       
    >> 10    48,000 ?   0,001    B/op
    >> MyBenchmark.testOld a/b/c/d/e  avgt       10    84,745 ?   1,329   ns/op
    >> MyBenchmark.testOld:?gc.alloc.rate.norm    a/b/c/d/e  avgt 10   
    >> 120,000 ?   0,001    B/op
    >>
    >> As you can see the more replacing needs to be done the better the 
    >> newer version seems to be perform.
    >>
    >> In case this is considered worthwhile I would need someone to sponsor 
    >> the patch. If not, I'm sorry for the noise.
    >>
    >> Cheers,
    >> Christoph Dreis
    >>
    >>
    >>
    -- 
    With kind regards,
    Ivan Gerasimov
    
    



From Alan.Bateman at oracle.com  Tue Jan  7 07:49:02 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Jan 2020 07:49:02 +0000
Subject: Use single character replace variant in
 Resources.toPackageName(String)
In-Reply-To: <8bb7168b-91b9-90ee-eae7-59d0f4ef82ee@oracle.com>
References: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de>
 
 <8bb7168b-91b9-90ee-eae7-59d0f4ef82ee@oracle.com>
Message-ID: <308972ac-5028-8c47-ce2a-5de1d469ced9@oracle.com>

On 07/01/2020 07:09, Ivan Gerasimov wrote:
> So, I filed a Jira bug:
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236705
> WEBREV: http://cr.openjdk.java.net/~igerasim/8236705/00/webrev/
>
I added these source files in JDK 9, it was just an oversight that I 
didn't use the single char replace. My guess is that the change 
ModulePath deriveModuleDescriptor won't be noticeable in any real 
benchmark. This method is deriving a module descriptor for a legacy JAR 
file on the module path so it's scanning the contents of the JAR file 
and all attributes in its main manifest. The Resources toPackageName 
method is used more widely so it may help in a few cases. Anyway, this 
change looks fine except the copyright year (you've changed it to 2019 
rather than 2020).

-Alan

From nick.gasson at arm.com  Tue Jan  7 08:21:53 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Tue, 7 Jan 2020 16:21:53 +0800
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
Message-ID: 

Hi,

Please review this set of fixes for the new memory access API on 32-bit 
Arm/x86.

Bug: https://bugs.openjdk.java.net/browse/JDK-8236634
Webrev: http://cr.openjdk.java.net/~ngasson/8236634/webrev.0/

libNativeAccess.c fails to build with warnings enabled due to casting
pointers to integers of different widths. Added an intermediate cast to
uintptr_t to silence this.

TestArrays::testTooBigForArray calls MemorySegment.allocateNative with
size Integer.MAX_VALUE * 2 (0xFFFF_FFFE). This gets passed to
Unsafe_AllocateMemory0 which aligns the size up to HeapWordSize. But
on a 32-bit system this overflows the value of size_t, resulting in a
call to os::malloc(0). Added an overflow check after the call to
align_up().

MemorySegment::makeNativeSegment assumes that the result of
Unsafe::allocateMemory will always be at least 16 byte aligned. But on a
32-bit system the result can be 8 byte aligned. Made the MAX_ALIGN
constant conditional on the address size.

Several of the tests in TestByteBuffer.java allocate a byte[] array on
the heap and then read or write Java long/double from the array base
address. On a 32-bit system the array data is located immediately after
12 bytes of header so these eight byte accesses are misaligned. I made a
minimal fix here to just skip the long/double cases on 32-bit systems.

Tested jdk_foreign on x86_32, arm32, x86_64, and aarch64.


Thanks,
Nick

From maurizio.cimadamore at oracle.com  Tue Jan  7 11:06:14 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 7 Jan 2020 11:06:14 +0000
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: 
References: 
Message-ID: 

Hi Nick,
thanks for the fixes - this generally looks good - the only bit I'm less 
sure of is the Unsafe::allocateMemory change. It looks good per se, but 
I guess a more targeted fix is also possible (e.g. by checking for size 
 > Integer.MAX_VALUE in case address size is 4 when we allocate the 
native segment).

I will leave the decision on what to do on this specific issue to others 
more versed than me in that part of the code.

As for integrating this - what are your plans? JDK 14 or panama repo? I 
see you have targeted 14 in the issue, which is fine, but the priority 
is P4. Needs to be at least a P3 to be pushed in the RDP1 period (and I 
think a case can be made for it being a P3 - since it's desirable for 
tests to pass on all platforms). Note that while we have no priority 
requirements on test/doc bugs (all can be fixed under RDP1/2), there 
requirement kicks in here because of your change to Unsafe (or the 
equivalent change to the memory access API implementation).

An alternative would be to fix all the tests and keeping existing 
priority (and maybe fix the testTooBigForArrays so that it does nothing 
on 32-bits) - and then deciding what to do with Unsafe::allocateMemory 
in a separate followup issue.

Maurizio

On 07/01/2020 08:21, Nick Gasson wrote:
> Hi,
>
> Please review this set of fixes for the new memory access API on 
> 32-bit Arm/x86.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236634
> Webrev: http://cr.openjdk.java.net/~ngasson/8236634/webrev.0/
>
> libNativeAccess.c fails to build with warnings enabled due to casting
> pointers to integers of different widths. Added an intermediate cast to
> uintptr_t to silence this.
>
> TestArrays::testTooBigForArray calls MemorySegment.allocateNative with
> size Integer.MAX_VALUE * 2 (0xFFFF_FFFE). This gets passed to
> Unsafe_AllocateMemory0 which aligns the size up to HeapWordSize. But
> on a 32-bit system this overflows the value of size_t, resulting in a
> call to os::malloc(0). Added an overflow check after the call to
> align_up().
>
> MemorySegment::makeNativeSegment assumes that the result of
> Unsafe::allocateMemory will always be at least 16 byte aligned. But on a
> 32-bit system the result can be 8 byte aligned. Made the MAX_ALIGN
> constant conditional on the address size.
>
> Several of the tests in TestByteBuffer.java allocate a byte[] array on
> the heap and then read or write Java long/double from the array base
> address. On a 32-bit system the array data is located immediately after
> 12 bytes of header so these eight byte accesses are misaligned. I made a
> minimal fix here to just skip the long/double cases on 32-bit systems.
>
> Tested jdk_foreign on x86_32, arm32, x86_64, and aarch64.
>
>
> Thanks,
> Nick

From chris.hegarty at oracle.com  Tue Jan  7 12:26:25 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 Jan 2020 12:26:25 +0000
Subject: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared
 with an explicit constructor
In-Reply-To: <90c9a2ce-32c0-eaca-6a90-6f9998a96b7c@oracle.com>
References: <90c9a2ce-32c0-eaca-6a90-6f9998a96b7c@oracle.com>
Message-ID: <6352373D-D819-4E9B-B2A8-BF85A52A4232@oracle.com>



> On 6 Jan 2020, at 23:22, Joe Darcy  wrote:
> 
> Hello,
> 
> The initial implementation of java.lang.Record uses a default constructor; an explicit constructor should be added instead. Please review the code change and CSR for this:
> 
>     JDK-8236695: java.lang.Record should be declared with an explicit constructor
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8236699
>     http://cr.openjdk.java.net/~darcy/8236695.0/

LGTM.

Some wording could be added about the restriction on the use of
this constructor, and its intended audience ( the compiler ), similar
to that of Enum(String,int), but equally that could be done separately.

-Chris.

From james.laskey at oracle.com  Tue Jan  7 12:32:53 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 7 Jan 2020 08:32:53 -0400
Subject: RFR: JDK-8236683 StringBuilder / StringBuffer capacity() doc is
 misleading (CSR)
In-Reply-To: <6901c11a-cfa9-936d-86f5-2ee5b138e9be@oracle.com>
References: <0A5D7986-836B-4DFE-9303-6D0EE0BED47A@oracle.com>
 <6901c11a-cfa9-936d-86f5-2ee5b138e9be@oracle.com>
Message-ID: <686B55AA-EAE6-45F9-B175-E4523054C48E@oracle.com>

Thank you Brent.

> On Jan 6, 2020, at 5:42 PM, Brent Christian  wrote:
> 
> Looks reasonable to me - reviewed.
> -Brent
> 
> On 1/6/20 10:29 AM, Jim Laskey wrote:
>> Please review the following CSR intended to clarify the true meaning of StringBuilder::capacity and StringBuffer::capacity.
>> csr: https://bugs.openjdk.java.net/browse/JDK-8236683
>> diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
>> --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
>> +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
>> @@ -181,9 +181,9 @@
>>      }
>>      /**
>> -     * Returns the current capacity. The capacity is the amount of storage
>> -     * available for newly inserted characters, beyond which an allocation
>> -     * will occur.
>> +     * Returns the current capacity. The capacity is the number of characters
>> +     * that can be stored (including already written characters), beyond which
>> +     * an allocation will occur.
>>       *
>>       * @return  the current capacity
>>       */


From fweimer at redhat.com  Tue Jan  7 12:37:48 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 07 Jan 2020 13:37:48 +0100
Subject: RFR 8234362: k_standard.c is not needed and should be removed
In-Reply-To: <3375b63c-e8aa-ea5d-c139-408b562c86bb@redhat.com> (Andrew Haley's
 message of "Mon, 23 Dec 2019 10:39:44 +0100")
References: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com>
 <871ru429ll.fsf@oldenburg2.str.redhat.com>
 <3375b63c-e8aa-ea5d-c139-408b562c86bb@redhat.com>
Message-ID: <87o8vftpb7.fsf@oldenburg2.str.redhat.com>

* Andrew Haley:

> On 11/18/19 9:49 PM, Florian Weimer wrote:
>> I think the file should just be removed.
>> 
>> Bug: 
>> Webrev: 
>> 
>> As usual, I'll need a sponsor for this.
>
> This is OK.

Great.  Would you be able to sponsor it?

> How many patches have you done now? maybe it's time to give you commit
> access.

I count 14 commits and two Co-authored-by: lines.  However, I consider
all but two or three of them trivial, so I'm not sure if they qualify.

Thanks,
Florian


From james.laskey at oracle.com  Tue Jan  7 12:43:08 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 7 Jan 2020 08:43:08 -0400
Subject: RFR JDK-8236688 Clarify String::indent javadoc (CSR)
Message-ID: <814CBF20-1BF9-4DE3-8189-ECADB6026B6B@oracle.com>

Please review this CSR to clarify the javadoc details of String::indent (proposed by Andrew Leonard).

webrev: http://cr.openjdk.java.net/~jlaskey/8230800/webrev.00/index.html 
csr: https://bugs.openjdk.java.net/browse/JDK-8236688
jbs: https://bugs.openjdk.java.net/browse/JDK-8230800

From Alan.Bateman at oracle.com  Tue Jan  7 13:04:57 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Jan 2020 13:04:57 +0000
Subject: RFR 8234362: k_standard.c is not needed and should be removed
In-Reply-To: <87o8vftpb7.fsf@oldenburg2.str.redhat.com>
References: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com>
 <871ru429ll.fsf@oldenburg2.str.redhat.com>
 <3375b63c-e8aa-ea5d-c139-408b562c86bb@redhat.com>
 <87o8vftpb7.fsf@oldenburg2.str.redhat.com>
Message-ID: 

Joe - is it still on your radar to port the remaining usages of fdlibm 
to Java?

-Alan


On 07/01/2020 12:37, Florian Weimer wrote:
> * Andrew Haley:
>
>> On 11/18/19 9:49 PM, Florian Weimer wrote:
>>> I think the file should just be removed.
>>>
>>> Bug: 
>>> Webrev: 
>>>
>>> As usual, I'll need a sponsor for this.
>> This is OK.
> Great.  Would you be able to sponsor it?
>
>> How many patches have you done now? maybe it's time to give you commit
>> access.
> I count 14 commits and two Co-authored-by: lines.  However, I consider
> all but two or three of them trivial, so I'm not sure if they qualify.
>
> Thanks,
> Florian
>


From Roger.Riggs at oracle.com  Tue Jan  7 15:02:55 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 7 Jan 2020 10:02:55 -0500
Subject: RFR JDK-8236688 Clarify String::indent javadoc (CSR)
In-Reply-To: <814CBF20-1BF9-4DE3-8189-ECADB6026B6B@oracle.com>
References: <814CBF20-1BF9-4DE3-8189-ECADB6026B6B@oracle.com>
Message-ID: <3b138c3a-af16-0c65-aa29-181d3d127b31@oracle.com>

Hi Jim,

The nature of the problem should be apparent from the summary and 
problem descriptions.

The CSR/diff does not identify the methods modified.

The new 3rd bullet seems more like a consequence of the first 2 actions, 
not an independent step.
The word 'implies' seems out of place in a specification of behavior.
I think you can drop 'this/thus implies' without loss of clarity or intent.

Is it significant that the first change spells out \n and \r and the second
refers to 'line terminator'?

Roger


On 1/7/20 7:43 AM, Jim Laskey wrote:
> Please review this CSR to clarify the javadoc details of String::indent (proposed by Andrew Leonard).
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8230800/webrev.00/index.html 
> csr: https://bugs.openjdk.java.net/browse/JDK-8236688
> jbs: https://bugs.openjdk.java.net/browse/JDK-8230800


From james.laskey at oracle.com  Tue Jan  7 15:36:19 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 7 Jan 2020 11:36:19 -0400
Subject: RFR JDK-8236688 Clarify String::indent javadoc (CSR)
In-Reply-To: <3b138c3a-af16-0c65-aa29-181d3d127b31@oracle.com>
References: <814CBF20-1BF9-4DE3-8189-ECADB6026B6B@oracle.com>
 <3b138c3a-af16-0c65-aa29-181d3d127b31@oracle.com>
Message-ID: 

Thanks Roger. Will apply your suggestions.

> On Jan 7, 2020, at 11:02 AM, Roger Riggs  wrote:
> 
> Hi Jim,
> 
> The nature of the problem should be apparent from the summary and problem descriptions.
> 
> The CSR/diff does not identify the methods modified.
> 
> The new 3rd bullet seems more like a consequence of the first 2 actions, not an independent step.
> The word 'implies' seems out of place in a specification of behavior.
> I think you can drop 'this/thus implies' without loss of clarity or intent.
> 
> Is it significant that the first change spells out \n and \r and the second
> refers to 'line terminator'?
> 
> Roger
> 
> 
> On 1/7/20 7:43 AM, Jim Laskey wrote:
>> Please review this CSR to clarify the javadoc details of String::indent (proposed by Andrew Leonard).
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8230800/webrev.00/index.html 
>> csr: https://bugs.openjdk.java.net/browse/JDK-8236688
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8230800
> 


From james.laskey at oracle.com  Tue Jan  7 16:05:42 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 7 Jan 2020 12:05:42 -0400
Subject: RFR JDK-8236688 Clarify String::indent javadoc (CSR)
In-Reply-To: <3b138c3a-af16-0c65-aa29-181d3d127b31@oracle.com>
References: <814CBF20-1BF9-4DE3-8189-ECADB6026B6B@oracle.com>
 <3b138c3a-af16-0c65-aa29-181d3d127b31@oracle.com>
Message-ID: 

I'm going to withdraw this change. It's been very painful to describe how String::indent this works in simple terms. The fact that it took 8 precise steps to describe in the JEP is an indication that simplification needs more thought.  The submitter was trying to clarify what happens when the last line was empty, but maybe his approach is not the way to go. Deferring for more thought.

-- Jim


> On Jan 7, 2020, at 11:02 AM, Roger Riggs  wrote:
> 
> Hi Jim,
> 
> The nature of the problem should be apparent from the summary and problem descriptions.
> 
> The CSR/diff does not identify the methods modified.
> 
> The new 3rd bullet seems more like a consequence of the first 2 actions, not an independent step.
> The word 'implies' seems out of place in a specification of behavior.
> I think you can drop 'this/thus implies' without loss of clarity or intent.
> 
> Is it significant that the first change spells out \n and \r and the second
> refers to 'line terminator'?
> 
> Roger
> 
> 
> On 1/7/20 7:43 AM, Jim Laskey wrote:
>> Please review this CSR to clarify the javadoc details of String::indent (proposed by Andrew Leonard).
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8230800/webrev.00/index.html 
>> csr: https://bugs.openjdk.java.net/browse/JDK-8236688
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8230800
> 


From joe.darcy at oracle.com  Tue Jan  7 17:04:42 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 7 Jan 2020 09:04:42 -0800
Subject: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared
 with an explicit constructor
In-Reply-To: <6352373D-D819-4E9B-B2A8-BF85A52A4232@oracle.com>
References: <90c9a2ce-32c0-eaca-6a90-6f9998a96b7c@oracle.com>
 <6352373D-D819-4E9B-B2A8-BF85A52A4232@oracle.com>
Message-ID: <30f90ea7-8a47-ce6f-32fb-482d9e41da12@oracle.com>

On 1/7/2020 4:26 AM, Chris Hegarty wrote:
>
>> On 6 Jan 2020, at 23:22, Joe Darcy  wrote:
>>
>> Hello,
>>
>> The initial implementation of java.lang.Record uses a default constructor; an explicit constructor should be added instead. Please review the code change and CSR for this:
>>
>>      JDK-8236695: java.lang.Record should be declared with an explicit constructor
>>      CSR: https://bugs.openjdk.java.net/browse/JDK-8236699
>>      http://cr.openjdk.java.net/~darcy/8236695.0/
> LGTM.
>
> Some wording could be added about the restriction on the use of
> this constructor, and its intended audience ( the compiler ), similar
> to that of Enum(String,int), but equally that could be done separately.

I'll push the current change as-is and leave the spec refinement for 
future work.

Thanks for the reviews.

-Joe


From christoph.dreis at freenet.de  Tue Jan  7 17:32:38 2020
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 07 Jan 2020 18:32:38 +0100
Subject: [NEW BUG] Fix duplicated word in Lookup#in documentation
Message-ID: <4A43C18F-BF66-414F-BCC0-189CD9277B4D@freenet.de>

Hi,

I just noticed that a duplicated "the" slipped into the docs of Lookup.in().

The change seems to have been introduced in https://bugs.openjdk.java.net/browse/JDK-8226916.

In case this is considered worthwhile I would need someone to sponsor the trivial change below:

diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -1451,7 +1451,7 @@
          * 
  • If the new lookup class is in the same module as the old lookup class,
          * the new previous lookup class is the old previous lookup class.
          * 
  • If the new lookup class is in a different module from the old lookup class,
-         * the new previous lookup class is the the old lookup class.
+         * the new previous lookup class is the old lookup class.
          *
          * 
    
          * The resulting lookup's capabilities for loading classes

Cheers,
Christoph



From mandy.chung at oracle.com  Tue Jan  7 17:49:28 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 7 Jan 2020 09:49:28 -0800
Subject: [NEW BUG] Fix duplicated word in Lookup#in documentation
In-Reply-To: <4A43C18F-BF66-414F-BCC0-189CD9277B4D@freenet.de>
References: <4A43C18F-BF66-414F-BCC0-189CD9277B4D@freenet.de>
Message-ID: 

Hi Christoph,

I'll sponsor this typo fix.

Mandy

On 1/7/20 9:32 AM, Christoph Dreis wrote:
> Hi,
>
> I just noticed that a duplicated "the" slipped into the docs of Lookup.in().
>
> The change seems to have been introduced in https://bugs.openjdk.java.net/browse/JDK-8226916.
>
> In case this is considered worthwhile I would need someone to sponsor the trivial change below:
>
> diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> @@ -1451,7 +1451,7 @@
>            * 
  • If the new lookup class is in the same module as the old lookup class,
>            * the new previous lookup class is the old previous lookup class.
>            * 
  • If the new lookup class is in a different module from the old lookup class,
> -         * the new previous lookup class is the the old lookup class.
> +         * the new previous lookup class is the old lookup class.
>            *
>            * 
    
>            * The resulting lookup's capabilities for loading classes
>
> Cheers,
> Christoph
>
>


From joe.darcy at oracle.com  Wed Jan  8 00:17:14 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 7 Jan 2020 16:17:14 -0800
Subject: RFR 8234362: k_standard.c is not needed and should be removed
In-Reply-To: 
References: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com>
 <871ru429ll.fsf@oldenburg2.str.redhat.com>
 <3375b63c-e8aa-ea5d-c139-408b562c86bb@redhat.com>
 <87o8vftpb7.fsf@oldenburg2.str.redhat.com>
 
Message-ID: <1e500e06-5ebf-fb14-48c4-51963d71c3eb@oracle.com>

Hello,

On 1/7/2020 5:04 AM, Alan Bateman wrote:
> Joe - is it still on your radar to port the remaining usages of fdlibm 
> to Java?

Yes; addressing JDK-8171407 "Port fdlibm to Java, part 2" remains on my 
to-do list. That bug is currently targeted to JDK 15, but it has been 
re-targeted before.

Cheers,

-Joe


>
> -Alan
>
>
> On 07/01/2020 12:37, Florian Weimer wrote:
>> * Andrew Haley:
>>
>>> On 11/18/19 9:49 PM, Florian Weimer wrote:
>>>> I think the file should just be removed.
>>>>
>>>> Bug: 
>>>> Webrev: 
>>>>
>>>> As usual, I'll need a sponsor for this.
>>> This is OK.
>> Great.? Would you be able to sponsor it?
>>
>>> How many patches have you done now? maybe it's time to give you commit
>>> access.
>> I count 14 commits and two Co-authored-by: lines.? However, I consider
>> all but two or three of them trivial, so I'm not sure if they qualify.
>>
>> Thanks,
>> Florian
>>
>

From nick.gasson at arm.com  Wed Jan  8 07:21:42 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 8 Jan 2020 15:21:42 +0800
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: 
References: 
 
Message-ID: <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>

Hi Maurizio,

On 07/01/2020 19:06, Maurizio Cimadamore wrote:
> 
> As for integrating this - what are your plans? JDK 14 or panama repo? I
> see you have targeted 14 in the issue, which is fine, but the priority
> is P4. Needs to be at least a P3 to be pushed in the RDP1 period (and I
> think a case can be made for it being a P3 - since it's desirable for
> tests to pass on all platforms). Note that while we have no priority
> requirements on test/doc bugs (all can be fixed under RDP1/2), there
> requirement kicks in here because of your change to Unsafe (or the
> equivalent change to the memory access API implementation).
> 
> An alternative would be to fix all the tests and keeping existing
> priority (and maybe fix the testTooBigForArrays so that it does nothing
> on 32-bits) - and then deciding what to do with Unsafe::allocateMemory
> in a separate followup issue.
> 

I'm happy to split it into two patches. One with the build/test fixes 
for jdk/jdk14 and another with the Unsafe and 
internal/foreign/Utils.java change for jdk/jdk (or panama/dev?). I think 
the most important change for jdk14 is the build fix for 
libNativeAccess.c as that causes "make test" to fail with the default 
warnings-as-errors.

Thanks,
Nick

From shade at redhat.com  Wed Jan  8 08:45:41 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 8 Jan 2020 09:45:41 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>
References: 
 <5E016C66.4040502@oracle.com>
 
 <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com>
 <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com>
 
 <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>
Message-ID: 

On 1/7/20 7:50 AM, Aleksey Shipilev wrote:
> On 1/6/20 1:48 PM, Alex Kashchenko wrote:
>>>>>> [...]
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>>>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>>>>>> [...]
>>>>
>>>> Gentle reminder, it would be great to have this included before jdk14
>>>> enters rampdown 2.
>>>
>>> The patch looks good to me. (I did the same in the original bug report).
>>
>> Thanks for the review! Sponsor is required for this patch to be pushed 
>> (I am not an author in "jdk" and cannot export committed changeset).
> 
> I can sponsor jdk/jdk14 push. But I need someone else to acknowledge (I don't feel fancy acking
> basically my own patch :]). Phil, maybe?

Actually, since jdk14 is in RDP1, we need a special approval to push, as per JEP 3
(https://openjdk.java.net/jeps/3). Please seek one in the JIRA comments, and that should be enough.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jan  8 09:12:21 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 8 Jan 2020 10:12:21 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: 
References: 
 <5E016C66.4040502@oracle.com>
 
 <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com>
 <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com>
 
 <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>
 
Message-ID: <7285ec8b-573c-52f8-5a0d-dd37598dfc7b@redhat.com>

On 1/8/20 9:45 AM, Aleksey Shipilev wrote:
> On 1/7/20 7:50 AM, Aleksey Shipilev wrote:
>> On 1/6/20 1:48 PM, Alex Kashchenko wrote:
>>>>>>> [...]
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>>>>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
> 
> Actually, since jdk14 is in RDP1, we need a special approval to push, as per JEP 3
> (https://openjdk.java.net/jeps/3). Please seek one in the JIRA comments, and that should be enough.

Disregard that, I misread the rules. We can push it to jdk14 without approval, until we hit RDP2.

So, somebody needs to ack this patch, and then I can push.

-- 
Thanks,
-Aleksey


From maurizio.cimadamore at oracle.com  Wed Jan  8 10:23:43 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 10:23:43 +0000
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>
References: 
 
 <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>
Message-ID: 


On 08/01/2020 07:21, Nick Gasson wrote:
> Hi Maurizio,
>
> On 07/01/2020 19:06, Maurizio Cimadamore wrote:
>>
>> As for integrating this - what are your plans? JDK 14 or panama repo? I
>> see you have targeted 14 in the issue, which is fine, but the priority
>> is P4. Needs to be at least a P3 to be pushed in the RDP1 period (and I
>> think a case can be made for it being a P3 - since it's desirable for
>> tests to pass on all platforms). Note that while we have no priority
>> requirements on test/doc bugs (all can be fixed under RDP1/2), there
>> requirement kicks in here because of your change to Unsafe (or the
>> equivalent change to the memory access API implementation).
>>
>> An alternative would be to fix all the tests and keeping existing
>> priority (and maybe fix the testTooBigForArrays so that it does nothing
>> on 32-bits) - and then deciding what to do with Unsafe::allocateMemory
>> in a separate followup issue.
>>
>
> I'm happy to split it into two patches. One with the build/test fixes 
> for jdk/jdk14 and another with the Unsafe and 
> internal/foreign/Utils.java change for jdk/jdk (or panama/dev?). I 
> think the most important change for jdk14 is the build fix for 
> libNativeAccess.c as that causes "make test" to fail with the default 
> warnings-as-errors.

That seems like a good idea. Also feel free to disable the 'bad' 
testTooBigForArrays on 32-bit platforms, so that you can get a clean 
test run.

Maurizio

>
> Thanks,
> Nick

From maurizio.cimadamore at oracle.com  Wed Jan  8 12:18:20 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 12:18:20 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
Message-ID: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>

Hi,
this is a small patch which addresses the javadoc issues in the memory 
access API, which were pointed out in the CSR review [1].

Additionally, this patch also adds a test (contributed by Paul Sandoz, 
thanks!), which makes sure that passing values of the wrong type to 
memory access var handle result in an CCE at runtime.

Since this is a doc & test fix, I've marked the issue as noreg-doc, and 
I think this should be ok for 14.

Cheers
Maurizio

[1] - https://bugs.openjdk.java.net/browse/JDK-8234050


From maurizio.cimadamore at oracle.com  Wed Jan  8 12:36:05 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 12:36:05 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
Message-ID: 

A link to the webrev might be useful I guess :-)

http://cr.openjdk.java.net/~mcimadamore/8236769/

Maurizio

On 08/01/2020 12:18, Maurizio Cimadamore wrote:
> Hi,
> this is a small patch which addresses the javadoc issues in the memory 
> access API, which were pointed out in the CSR review [1].
>
> Additionally, this patch also adds a test (contributed by Paul Sandoz, 
> thanks!), which makes sure that passing values of the wrong type to 
> memory access var handle result in an CCE at runtime.
>
> Since this is a doc & test fix, I've marked the issue as noreg-doc, 
> and I think this should be ok for 14.
>
> Cheers
> Maurizio
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8234050
>

From chris.hegarty at oracle.com  Wed Jan  8 15:07:26 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Jan 2020 15:07:26 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: 
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
Message-ID: <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>

Maurizio,

> On 8 Jan 2020, at 12:36, Maurizio Cimadamore  wrote:
> 
> A link to the webrev might be useful I guess :-)
> 
> http://cr.openjdk.java.net/~mcimadamore/8236769/

Mostly looks good.

Trivially, regarding the use of implSpec in MemoryLayout; I think that the tag is just not needed, right? The statement is normative.  Though I have to admit to being confused on occasion as to the difference between some of these tags, see draft JEP [1] ). I think that implSpec could be argued for byteAlighment, since that method provides a default implementation, then again maybe the new no-explicit natural-ordering wording is still spec, and an implSpec could be added to cover the actual default implementation?

-Chris.

[1] https://openjdk.java.net/jeps/8068562

From chris.hegarty at oracle.com  Wed Jan  8 15:16:21 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Jan 2020 15:16:21 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
 <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>
Message-ID: <417F53F7-15E8-469F-87D3-33F16B8D52D7@oracle.com>



> On 8 Jan 2020, at 15:07, Chris Hegarty  wrote:
> 
> Maurizio,
> 
>> On 8 Jan 2020, at 12:36, Maurizio Cimadamore  wrote:
>> 
>> A link to the webrev might be useful I guess :-)
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8236769/

Forgot to add... MemoryAddress equality has no temporal awareness. Is this worth calling out in the new apiNote ?

-Chris.


From maurizio.cimadamore at oracle.com  Wed Jan  8 15:22:25 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 15:22:25 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <417F53F7-15E8-469F-87D3-33F16B8D52D7@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
 <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>
 <417F53F7-15E8-469F-87D3-33F16B8D52D7@oracle.com>
Message-ID: <677f10f2-cfcd-cf66-cca7-626d7806827d@oracle.com>

Good ideas.

On the implSpec issue I think I got confused by the CSR comment, which was:

> MemoryLayout.byteAlignment() should have an @implSpec tag describing 
> its default implementation.
>
I think now that Joe wanted a tag to describe the default method 
implementation.

I agree that the new text I've added should be added as normative text.

How strongly do we feel about adding an @implSpec note for the default 
method - given that this method is not supposed to be overridden? (this 
is captured in the toplevel javadoc, where we say that users are not 
expected to implement the memory layout interface).

Maurizio

On 08/01/2020 15:16, Chris Hegarty wrote:
>
>> On 8 Jan 2020, at 15:07, Chris Hegarty  wrote:
>>
>> Maurizio,
>>
>>> On 8 Jan 2020, at 12:36, Maurizio Cimadamore  wrote:
>>>
>>> A link to the webrev might be useful I guess :-)
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8236769/
> Forgot to add... MemoryAddress equality has no temporal awareness. Is this worth calling out in the new apiNote ?
>
> -Chris.
>

From maurizio.cimadamore at oracle.com  Wed Jan  8 15:33:04 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 15:33:04 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <677f10f2-cfcd-cf66-cca7-626d7806827d@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
 <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>
 <417F53F7-15E8-469F-87D3-33F16B8D52D7@oracle.com>
 <677f10f2-cfcd-cf66-cca7-626d7806827d@oracle.com>
Message-ID: <180a48fe-12d4-7393-addd-4d9a4c8e6505@oracle.com>

I've looked at the java.lang.constant.ClassDesc interface which is 
similar in spirit to what MemoryLayout does: an interface that is not 
meant to be implemented by the user. There are many default methods 
there, and no implSpec, except for displayName() (to describe what the 
implementation does).

I'm really on the fence for byteAlignment() as the method javadoc is 
already clear enough about what the method does?

Maurizio

On 08/01/2020 15:22, Maurizio Cimadamore wrote:
> How strongly do we feel about adding an @implSpec note for the default 
> method - given that this method is not supposed to be overridden? 
> (this is captured in the toplevel javadoc, where we say that users are 
> not expected to implement the memory layout interface). 

From chris.hegarty at oracle.com  Wed Jan  8 15:34:57 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Jan 2020 15:34:57 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <180a48fe-12d4-7393-addd-4d9a4c8e6505@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
 <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>
 <417F53F7-15E8-469F-87D3-33F16B8D52D7@oracle.com>
 <677f10f2-cfcd-cf66-cca7-626d7806827d@oracle.com>
 <180a48fe-12d4-7393-addd-4d9a4c8e6505@oracle.com>
Message-ID: <66DAC02B-18C1-4CBD-8E3D-E4A6098D4563@oracle.com>



> On 8 Jan 2020, at 15:33, Maurizio Cimadamore  wrote:
> 
> I've looked at the java.lang.constant.ClassDesc interface which is similar in spirit to what MemoryLayout does: an interface that is not meant to be implemented by the user. There are many default methods there, and no implSpec, except for displayName() (to describe what the implementation does).
> 
> I'm really on the fence for byteAlignment() as the method javadoc is already clear enough about what the method does?

I would be fine with dropping the implSpec - just adding the new clarifying wording as ?regular? normative spec.

-Chris.


From maurizio.cimadamore at oracle.com  Wed Jan  8 15:52:14 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 15:52:14 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
Message-ID: 

New revision:

http://cr.openjdk.java.net/~mcimadamore/8236769_v2

delta from previous:

http://cr.openjdk.java.net/~mcimadamore/8236769_v2_delta/

Thanks for the comments so far

Maurizio

On 08/01/2020 12:18, Maurizio Cimadamore wrote:
> Hi,
> this is a small patch which addresses the javadoc issues in the memory 
> access API, which were pointed out in the CSR review [1].
>
> Additionally, this patch also adds a test (contributed by Paul Sandoz, 
> thanks!), which makes sure that passing values of the wrong type to 
> memory access var handle result in an CCE at runtime.
>
> Since this is a doc & test fix, I've marked the issue as noreg-doc, 
> and I think this should be ok for 14.
>
> Cheers
> Maurizio
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8234050
>

From maurizio.cimadamore at oracle.com  Wed Jan  8 16:06:51 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 16:06:51 +0000
Subject: RFR (14) 8236779: static field in implementation class erroneously
 leaking in memory access javadoc
Message-ID: <747e82a0-40f1-302d-c39d-1c780b026c20@oracle.com>

Please review this one liner, which is to fix a static implementation 
field leaking through the memory access API javadoc:

cr.openjdk.java.net/~mcimadamore/8236779

And corresponding CSR here:

https://bugs.openjdk.java.net/browse/JDK-8236780

Cheers
Maurizio


From chris.hegarty at oracle.com  Wed Jan  8 16:15:02 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Jan 2020 16:15:02 +0000
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: 
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
Message-ID: 


> On 8 Jan 2020, at 15:52, Maurizio Cimadamore  wrote:
> 
> New revision:
> 
> http://cr.openjdk.java.net/~mcimadamore/8236769_v2
> 
> delta from previous:
> 
> http://cr.openjdk.java.net/~mcimadamore/8236769_v2_delta/

LGTM.

-Chris.

From chris.hegarty at oracle.com  Wed Jan  8 16:20:06 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Jan 2020 16:20:06 +0000
Subject: RFR (14) 8236779: static field in implementation class
 erroneously leaking in memory access javadoc
In-Reply-To: <747e82a0-40f1-302d-c39d-1c780b026c20@oracle.com>
References: <747e82a0-40f1-302d-c39d-1c780b026c20@oracle.com>
Message-ID: <685B99CE-DD03-4CEF-BDD5-FE2C4306D43A@oracle.com>

Maurizio,

> On 8 Jan 2020, at 16:06, Maurizio Cimadamore  wrote:
> 
> Please review this one liner, which is to fix a static implementation field leaking through the memory access API javadoc:
> 
> cr.openjdk.java.net/~mcimadamore/8236779

Looks good.

> And corresponding CSR here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8236780

I added myself as reviewer.

-Chris.

From maurizio.cimadamore at oracle.com  Wed Jan  8 16:21:29 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Jan 2020 16:21:29 +0000
Subject: RFR (14) 8236779: static field in implementation class
 erroneously leaking in memory access javadoc
In-Reply-To: <685B99CE-DD03-4CEF-BDD5-FE2C4306D43A@oracle.com>
References: <747e82a0-40f1-302d-c39d-1c780b026c20@oracle.com>
 <685B99CE-DD03-4CEF-BDD5-FE2C4306D43A@oracle.com>
Message-ID: 

Thanks! CSR finalized.

Maurizio

On 08/01/2020 16:20, Chris Hegarty wrote:
> Maurizio,
>
>> On 8 Jan 2020, at 16:06, Maurizio Cimadamore  wrote:
>>
>> Please review this one liner, which is to fix a static implementation field leaking through the memory access API javadoc:
>>
>> cr.openjdk.java.net/~mcimadamore/8236779
> Looks good.
>
>> And corresponding CSR here:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8236780
> I added myself as reviewer.
>
> -Chris.

From joe.darcy at oracle.com  Thu Jan  9 00:33:00 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 8 Jan 2020 16:33:00 -0800
Subject: JDK 14 RFR of JDK-8233452: java.math.BigDecimal.sqrt() with
 RoundingMode.FLOOR results in incorrect result
In-Reply-To: 
References: <402ee79d-4c8c-7af1-10fc-f8a8bf0864de@oracle.com>
 
Message-ID: <3af1b7f1-3cd8-7686-f57c-54ca9e80730a@oracle.com>

Hello,

Some further refinements to the implementation and tests ready for 
re-review:

 ??? http://cr.openjdk.java.net/~darcy/8233452.4/

The fix-up code for directed roundings (up, down, etc.) was corrected to 
properly handle rounding down when the interim result is a power of 10, 
in this case 1.0. The adjustment down in that case needs to be reduced 
in size since the size of an ulp changes at exponent boundaries. The 
regression tests cover this situation.

The assertion checks on the numerical properties of the result were 
restructured to be more informative. One assert was overly strict and 
made weaker to accommodate the sort of situation discussed in the comments.

The comments make reference to the "2p + 2" property. This concerns 
floating-point rounding and when a double-rounding problem can be 
avoided. In brief, if you first round to (p + k) digits than then round 
that result to p digits, a difference result can be computed than if a 
single rounding to p digits occurred. For example, both the roundings to 
(p + k) and p digits could round up when a single rounding up would not 
round up. However, if the first rounding is to at least (2p + 2) digits, 
a second rounding to p digits will *not* have the double rounding hazard 
for +, -, *, / and square root.

The main Newton loop in the square root implementation has been modified 
to compute at least (2p + 2) digits so the rounding to p digits will be 
correct without a fix-up. With sufficient analysis, computing to about p 
digitis instead and doing a fix-up should be possible, but I'll leave 
that as a refinement for another day.

Thanks,

-Joe

On 11/7/2019 1:52 PM, Brian Burkhalter wrote:
>
> Hi Joe,
>
>> On Nov 5, 2019, at 6:04 PM, Joe Darcy > > wrote:
>>
>> Please review the changes to fix
>>
>> ??? JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR 
>> results in incorrect result
>> http://cr.openjdk.java.net/~darcy/8233452.0/
>>
>> Some background on the problem and fix.
>>
>> The core of the BigDecimal.sqrt method is a Newton-Raphson loop.
>> [?]
>> The Newton iteration reduces the error at each step and, as currently 
>> written, it can settle on a value like 2, which is closer to the 
>> actual answer, but *incorrect* according to the requested rounding mode.
>>
>> There are a few ways to fix this one. One is to run the Newton loop 
>> to a higher-precision where these finer distinctions can be teased 
>> out. [?]
>>
>> Another approach is to detect when the result is too large/too small 
>> and then subtract/add an ulp as a fix-up. This is the approach taken 
>> for BigDecimal.sqrt. [?]
>
> This implementation change looks reasonable to me.
>
>> An approach not explored for this fix would be to arrange for the 
>> iteration to start from the "right" side of the number line depending 
>> on the rounding mode and then monotonically increase/decrease to 
>> approach the square root. [?] I believe this is technically possible, 
>> but would require some additional analysis to setup.
>
> This approach seems more appealing and could perhaps be investigated 
> at a later date.
>
> In the test I think you want to replace ?down? with ?up" at line 238.
>
> Brian

From smita.kamath at intel.com  Thu Jan  9 01:22:14 2020
From: smita.kamath at intel.com (Kamath, Smita)
Date: Thu, 9 Jan 2020 01:22:14 +0000
Subject: RFR(M):8167065: Add intrinsic support for double precision
 shifting on x86_64
In-Reply-To: 
References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com>
 <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com>
 
 <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com>
 
 <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com>
 
Message-ID: 

Hi Alan,

Thanks for the comment. I added these checks for caution but on further analysis it appears that these checks are not needed.

1)  For PrimitiveRightShift, we have the input array and its length passed as arguments. Since the input array, result[], is copied using arraycopy, we know that IOOBE will be thrown.  Therefore, it is safe to remove the checkIndex condition. 
         int result[] = new int[nInts+len+1]; 
         System.arraycopy(a, 0, result, 0, len);
         primitiveRightShift(result, result.length, 32 - nBits);

2) In case of PrimitiveLeftShift, I checked the call stack and verified that the length passed to the method is same as the length of the array. Therefore, the check is not necessary in this scenario.

3) In case of shiftLeft and shiftRight,  the number of iterations (numIter) is computed from the mag.length. The newMag array length is also computed and adjusted based on mag.length. 

If these changes look fine, I can send an updated webrev removing these checks. Please let me know.  

Thanks and Regards,
Smita Kamath

-----Original Message-----
From: Alan Bateman  
Sent: Saturday, December 28, 2019 12:22 AM
To: Vladimir Kozlov ; Kamath, Smita 
Cc: core-libs-dev at openjdk.java.net; 'hotspot compiler' 
Subject: Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64

On 20/12/2019 22:19, Vladimir Kozlov wrote:
> We should have added core-libs to review since you modified 
> BigInteger.java.
>
This adds Objects.checkFromToIndex checks in the middle of several supporting methods. Is IOOBE really possible in these cases or are these stand in for always-on asserts to ensure the instrinic is never used when the preconditions aren't satisfied?

-Alan

From joe.darcy at oracle.com  Thu Jan  9 02:03:00 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 8 Jan 2020 18:03:00 -0800
Subject: RFR (14) 8236769: Clarify javadoc of memory access API
In-Reply-To: <677f10f2-cfcd-cf66-cca7-626d7806827d@oracle.com>
References: <6d9098b1-beee-3464-2521-8da16353b06f@oracle.com>
 
 <7EC29510-BBF0-4911-AE7A-9DD54C540DB9@oracle.com>
 <417F53F7-15E8-469F-87D3-33F16B8D52D7@oracle.com>
 <677f10f2-cfcd-cf66-cca7-626d7806827d@oracle.com>
Message-ID: <2c38f5ef-b483-aefe-c4fa-fde139f611dc@oracle.com>

Hello,

On 1/8/2020 7:22 AM, Maurizio Cimadamore wrote:
> Good ideas.
>
> On the implSpec issue I think I got confused by the CSR comment, which 
> was:
>
>> MemoryLayout.byteAlignment() should have an @implSpec tag describing 
>> its default implementation.
>>
> I think now that Joe wanted a tag to describe the default method 
> implementation.

A good rule of thumb is that (by default) a default method should have 
an @implSpec tag describing the operational semantics of the 
implementation. This is especially true when the method is intended to 
be overridden, such as when the default method does something like throw 
UnsupportedOperationException.

HTH,

-Joe


From nick.gasson at arm.com  Thu Jan  9 08:10:54 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Thu, 9 Jan 2020 16:10:54 +0800
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: 
References: 
 
 <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>
 
Message-ID: <943b0890-ad12-59d0-d18e-974c1dc797bd@arm.com>

Hi Maurizio,

On 08/01/2020 18:23, Maurizio Cimadamore wrote:
>>
>> I'm happy to split it into two patches. One with the build/test fixes
>> for jdk/jdk14 and another with the Unsafe and
>> internal/foreign/Utils.java change for jdk/jdk (or panama/dev?). I
>> think the most important change for jdk14 is the build fix for
>> libNativeAccess.c as that causes "make test" to fail with the default
>> warnings-as-errors.
> 
> That seems like a good idea. Also feel free to disable the 'bad'
> testTooBigForArrays on 32-bit platforms, so that you can get a clean
> test run.

I've done this here, the new webrev only touches files under test/* and 
builds/runs jdk_foreign jtreg cleanly on x86_32 and arm32:

http://cr.openjdk.java.net/~ngasson/8236634/webrev.1/index.html

TestMemoryAlignment.java is skipped completely on 32-bit platforms for 
now, as it needs the change to MAX_ALIGN in Utils.java.

Thanks,
Nick

From patrick at reini.net  Thu Jan  9 09:35:05 2020
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 09 Jan 2020 10:35:05 +0100
Subject: Specification of Properties.load() does not define behaviour in case
 of duplicate keys
Message-ID: 

He everyone,


When loading a properties file using java.util.Properties.load() the 
behaviour for duplicate key values is not yet specified.

The actual implementation overwrites existing key/value defined within 
the current file by the further down without any warning or exception. 
This has lead to various hard to detect errors as in big property files, 
where multiple existences of the same property key.

I would like to extend the existing specification in that regard that 
only the first key/value pair will be taken into account and be added to 
the properties.

Alternatively new methods using this behaviour could also introduced...


-Patrick

From Alan.Bateman at oracle.com  Thu Jan  9 09:52:05 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 Jan 2020 09:52:05 +0000
Subject: Specification of Properties.load() does not define behaviour in
 case of duplicate keys
In-Reply-To: 
References: 
Message-ID: 

On 09/01/2020 09:35, Patrick Reinhart wrote:
> He everyone,
>
>
> When loading a properties file using java.util.Properties.load() the 
> behaviour for duplicate key values is not yet specified.
>
> The actual implementation overwrites existing key/value defined within 
> the current file by the further down without any warning or exception. 
> This has lead to various hard to detect errors as in big property 
> files, where multiple existences of the same property key.
>
> I would like to extend the existing specification in that regard that 
> only the first key/value pair will be taken into account and be added 
> to the properties.
>
> Alternatively new methods using this behaviour could also introduced...
Changing long standing behavior when properties files have duplicate 
keys could be problematic, esp. if there are properties files are 
bundled with a library that is deployed with different JDK releases. 
There was another discussion here recently about storing properties in 
canonical form, JDK-8231640 [1] was created to look into that. I only 
mention because there is other "projects" in this area if you want to 
look into that too.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8231640

From maurizio.cimadamore at oracle.com  Thu Jan  9 12:01:26 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 9 Jan 2020 12:01:26 +0000
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: <943b0890-ad12-59d0-d18e-974c1dc797bd@arm.com>
References: 
 
 <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>
 
 <943b0890-ad12-59d0-d18e-974c1dc797bd@arm.com>
Message-ID: <9fa031ce-3a98-36e6-10b4-599104d7d74a@oracle.com>

Looks good - thanks!

Maurizio

On 09/01/2020 08:10, Nick Gasson wrote:
> Hi Maurizio,
>
> On 08/01/2020 18:23, Maurizio Cimadamore wrote:
>>>
>>> I'm happy to split it into two patches. One with the build/test fixes
>>> for jdk/jdk14 and another with the Unsafe and
>>> internal/foreign/Utils.java change for jdk/jdk (or panama/dev?). I
>>> think the most important change for jdk14 is the build fix for
>>> libNativeAccess.c as that causes "make test" to fail with the default
>>> warnings-as-errors.
>>
>> That seems like a good idea. Also feel free to disable the 'bad'
>> testTooBigForArrays on 32-bit platforms, so that you can get a clean
>> test run.
>
> I've done this here, the new webrev only touches files under test/* 
> and builds/runs jdk_foreign jtreg cleanly on x86_32 and arm32:
>
> http://cr.openjdk.java.net/~ngasson/8236634/webrev.1/index.html
>
> TestMemoryAlignment.java is skipped completely on 32-bit platforms for 
> now, as it needs the change to MAX_ALIGN in Utils.java.
>
> Thanks,
> Nick

From julia.boes at oracle.com  Thu Jan  9 13:46:55 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 9 Jan 2020 13:46:55 +0000
Subject: RFR 8231710: Add timeout asserting method to test library
Message-ID: 

Hi,

This test-only RFR proposes a tool for timeout testing for the JDK test 
library. It runs a task in a separate thread and cancels the task if it 
doesn't complete within a given timeout. Any exception thrown by the 
task is propagated transparently.

TestNG doesn't currently provide this functionality but it seems like a 
handy little tool to have. The webrev includes several sample use cases.

Bug: https://bugs.openjdk.java.net/browse/JDK-8231710
Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231710/webrev.01/

Any feedback appreciated.

Regards,
Julia



From patrick at reini.net  Thu Jan  9 14:09:16 2020
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 09 Jan 2020 15:09:16 +0100
Subject: Specification of Properties.load() does not define behaviour in
 case of duplicate keys
In-Reply-To: 
References: 
 
Message-ID: <42e1f82bf666cfdcf5ef74a6a5168a14@reini.net>


I see the the problematic there. At least we should clarify the actual
behavior within the load() method specification stating the current 
state.

Having done this the question would be what could be an appropriate 
method
name/signature for the new behavior?

loadUnique()
loadDistinct()

or something like:

@FunctionalInterface
interface EntryRemappingFunction {
   Object merge(Object key, String oldValue, String newValue);
}

load(Reader reader, EntryRemappingFunction remappingFunction)

load(InputStream inStream, EntryRemappingFunction remappingFunction)


where the remappingFunction is used to handle existing values. So the 
existing methods could
be rewired internally to those methods.

Note that the functional interface is just for demonstrating the idea...


-Patrick


> Changing long standing behavior when properties files have duplicate
> keys could be problematic, esp. if there are properties files are
> bundled with a library that is deployed with different JDK releases.
> There was another discussion here recently about storing properties in
> canonical form, JDK-8231640 [1] was created to look into that. I only
> mention because there is other "projects" in this area if you want to
> look into that too.
> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8231640

From maurizio.cimadamore at oracle.com  Thu Jan  9 14:36:33 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 9 Jan 2020 14:36:33 +0000
Subject: RFR (14) 8235837: Memory access API refinements
Message-ID: 

Hi,
following the JEP 370 code review and CSR, certain comments that have 
not been addressed have been added to the tracker issue:

https://bugs.openjdk.java.net/browse/JDK-8235837

For further evaluation. After some discussion in the Panama channel (see 
[1] and [2]), the Panama team has come to the following conclusions:

* the MemoryAddress::offset(long) method should be renamed to 
MemoryAddress::addOffset(long)
* the MemorySegment::isAccessible() predicate should be dropped and 
replaced with the MemorySegment::ownerThread() accessor
* a new predicate should be added to MemoryLayout, namely 
MemoryLayout::hasSize() to allow clients to establish as to whether a 
layout contains some unsized parts
* a new method should be added to SequenceLayout, namely 
SequenceLayout::withElementCount, to create a new sequence layout with 
new element count
* 2 new helper methods should be added to MemoryLayout, namely:
 ?? - MemoryLayout::map - to allow transformation of a layout into a new 
layout (by replacing the sub-layout at given path with a new layout)
 ?? - MemoryLayout::select - to allow selection of a sub-layout given a 
layout path

Overall, we think this set of change strikes a good compromise between 
usability, readability and minimality.

The javadoc for the layout path-accepting methods (both old and new 
ones) has been significantly refactored and improved - and the toplevel 
javadoc section on layout paths has been enhanced to cover all the 
concepts. The implementation for these methods has also been 
consolidated greatly, which revealed subtle bugs in the old 
implementation which have now been rectified (new tests have been added).

Webrev is available here:

http://cr.openjdk.java.net/~mcimadamore/8235837/

Specdiff for changes here:

http://cr.openjdk.java.net/~mcimadamore/8235837_specdiff/overview-summary.html

A draft CSR for this issue is available here (I will finalize once the 
review converges on the API changes):

https://bugs.openjdk.java.net/browse/JDK-8236853

I plan to push this to JDK 14 under the late enhancement process [3].

Cheers
Maurizio

[1] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006873.html
[2] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006885.html
[3] - https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process






From aph at redhat.com  Thu Jan  9 15:36:21 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 9 Jan 2020 15:36:21 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
Message-ID: <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>

On 1/9/20 2:36 PM, Maurizio Cimadamore wrote:
> following the JEP 370 code review and CSR, certain comments that have 
> not been addressed have been added to the tracker issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8235837

Where is the spec? I can't find it linked from anywhere

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From martinrb at google.com  Thu Jan  9 16:18:16 2020
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Jan 2020 08:18:16 -0800
Subject: RFR 8231710: Add timeout asserting method to test library
In-Reply-To: 
References: 
Message-ID: 

There's a lot of prior art in JSR166TestCase.java.
In general, junit/testng don't have support for test methods that need to
run code in more than one thread, and jsr166 tck tests do that a lot.

Often you want a higher-level blocking API like:

    public void await(CountDownLatch latch, long timeoutMillis) {
        boolean timedOut = false;
        try {
            timedOut = !latch.await(timeoutMillis, MILLISECONDS);
        } catch (Throwable fail) {
            threadUnexpectedException(fail);
        }
        if (timedOut)
            fail("timed out waiting for CountDownLatch for "
                 + (timeoutMillis/1000) + " sec");
    }

    public void await(CountDownLatch latch) {
        await(latch, LONG_DELAY_MS);
    }

On Thu, Jan 9, 2020 at 5:47 AM Julia Boes  wrote:

> Hi,
>
> This test-only RFR proposes a tool for timeout testing for the JDK test
> library. It runs a task in a separate thread and cancels the task if it
> doesn't complete within a given timeout. Any exception thrown by the
> task is propagated transparently.
>
> TestNG doesn't currently provide this functionality but it seems like a
> handy little tool to have. The webrev includes several sample use cases.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231710
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231710/webrev.01/
>
> Any feedback appreciated.
>
> Regards,
> Julia
>
>
>

From maurizio.cimadamore at oracle.com  Thu Jan  9 16:37:01 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 9 Jan 2020 16:37:01 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
Message-ID: <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>

There you go

cr.openjdk.java.net/~mcimadamore/8235837_javadoc

Cheers
Maurizio

On 09/01/2020 15:36, Andrew Haley wrote:
> On 1/9/20 2:36 PM, Maurizio Cimadamore wrote:
>> following the JEP 370 code review and CSR, certain comments that have
>> not been addressed have been added to the tracker issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8235837
> Where is the spec? I can't find it linked from anywhere
>

From chris.hegarty at oracle.com  Thu Jan  9 17:48:18 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 Jan 2020 17:48:18 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
Message-ID: <177B2147-D1F8-48A7-8730-9360C51C74DA@oracle.com>

Maurizio,

> On 9 Jan 2020, at 14:36, Maurizio Cimadamore  wrote:
> 
> Hi,
> following the JEP 370 code review and CSR, certain comments that have not been addressed have been added to the tracker issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8235837
> 
> For further evaluation. After some discussion in the Panama channel (see [1] and [2]), the Panama team has come to the following conclusions:
> 
> * the MemoryAddress::offset(long) method should be renamed to MemoryAddress::addOffset(long)
> * the MemorySegment::isAccessible() predicate should be dropped and replaced with the MemorySegment::ownerThread() accessor
> * a new predicate should be added to MemoryLayout, namely MemoryLayout::hasSize() to allow clients to establish as to whether a layout contains some unsized parts
> * a new method should be added to SequenceLayout, namely SequenceLayout::withElementCount, to create a new sequence layout with new element count
> * 2 new helper methods should be added to MemoryLayout, namely:
>    - MemoryLayout::map - to allow transformation of a layout into a new layout (by replacing the sub-layout at given path with a new layout)
>    - MemoryLayout::select - to allow selection of a sub-layout given a layout path
> 
> Overall, we think this set of change strikes a good compromise between usability, readability and minimality.
> 
> The javadoc for the layout path-accepting methods (both old and new ones) has been significantly refactored and improved - and the toplevel javadoc section on layout paths has been enhanced to cover all the concepts. The implementation for these methods has also been consolidated greatly, which revealed subtle bugs in the old implementation which have now been rectified (new tests have been added).
> 
> Webrev is available here:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837/
> 
> Specdiff for changes here:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_specdiff/overview-summary.html

This mostly looks good. Some comments on the specification:

Is the example in Layout paths right?
   long valueOffset = seq.offset(PathElement.sequenceElement(), PathElement.groupElement("value"));

  Doesn?t the sequence element need to have a specified position ( rather than an unspecified element )?

MemoryLayout::offset  - I find the throws clause hard to parse, maybe:
    UnsupportedOperationException - if a layout with an unknown size is encountered during traversal

MemoryAddress::addOffset ( I like the name ) allows a negative value. I get the use case, so you can do:
    ms.baseAddress().offset(10).offset(-5)  is equivalent to ms.baseAddress().offset(5)

   , but what if one does ms.baseAddress().offset(-11)  ? 
Does addOffset need to throw an IAE? If so, then maybe it should be specified, otherwise what is the purpose of allowing the offset to go negative ( or even beyond the segments size? ) [ maybe we don?t care, since the bounds are checked during access operations ]

SequenceLayout::withElementCount should probably specify IAE if given a negative elementCount, right?

hasSize()  - Suggest: "TELLS whether or not this layout has a KNOWN size".??  The reason I suggest ?known? is that the class-level docs says that ?all layouts have a size?, just that the size is not known for an unbound sequence layout. I would suggest a method name of ?knownSize? or "sizeKnown", but that maybe a little too far?

-Chris.

From maurizio.cimadamore at oracle.com  Thu Jan  9 17:54:33 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 9 Jan 2020 17:54:33 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <177B2147-D1F8-48A7-8730-9360C51C74DA@oracle.com>
References: 
 <177B2147-D1F8-48A7-8730-9360C51C74DA@oracle.com>
Message-ID: 


On 09/01/2020 17:48, Chris Hegarty wrote:
> Maurizio,
>
>> On 9 Jan 2020, at 14:36, Maurizio Cimadamore  wrote:
>>
>> Hi,
>> following the JEP 370 code review and CSR, certain comments that have not been addressed have been added to the tracker issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8235837
>>
>> For further evaluation. After some discussion in the Panama channel (see [1] and [2]), the Panama team has come to the following conclusions:
>>
>> * the MemoryAddress::offset(long) method should be renamed to MemoryAddress::addOffset(long)
>> * the MemorySegment::isAccessible() predicate should be dropped and replaced with the MemorySegment::ownerThread() accessor
>> * a new predicate should be added to MemoryLayout, namely MemoryLayout::hasSize() to allow clients to establish as to whether a layout contains some unsized parts
>> * a new method should be added to SequenceLayout, namely SequenceLayout::withElementCount, to create a new sequence layout with new element count
>> * 2 new helper methods should be added to MemoryLayout, namely:
>>     - MemoryLayout::map - to allow transformation of a layout into a new layout (by replacing the sub-layout at given path with a new layout)
>>     - MemoryLayout::select - to allow selection of a sub-layout given a layout path
>>
>> Overall, we think this set of change strikes a good compromise between usability, readability and minimality.
>>
>> The javadoc for the layout path-accepting methods (both old and new ones) has been significantly refactored and improved - and the toplevel javadoc section on layout paths has been enhanced to cover all the concepts. The implementation for these methods has also been consolidated greatly, which revealed subtle bugs in the old implementation which have now been rectified (new tests have been added).
>>
>> Webrev is available here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8235837/
>>
>> Specdiff for changes here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8235837_specdiff/overview-summary.html
> This mostly looks good. Some comments on the specification:
>
> Is the example in Layout paths right?
>     long valueOffset = seq.offset(PathElement.sequenceElement(), PathElement.groupElement("value"));
>
>    Doesn?t the sequence element need to have a specified position ( rather than an unspecified element )?
Yes, this looks like a mistake
>
> MemoryLayout::offset  - I find the throws clause hard to parse, maybe:
>      UnsupportedOperationException - if a layout with an unknown size is encountered during traversal
I'll see what I can do here
>
> MemoryAddress::addOffset ( I like the name ) allows a negative value. I get the use case, so you can do:
>      ms.baseAddress().offset(10).offset(-5)  is equivalent to ms.baseAddress().offset(5)
>
>     , but what if one does ms.baseAddress().offset(-11)  ?
> Does addOffset need to throw an IAE? If so, then maybe it should be specified, otherwise what is the purpose of allowing the offset to go negative ( or even beyond the segments size? ) [ maybe we don?t care, since the bounds are checked during access operations ]
No, an out of bound address is allowed (and in fact sometimes is useful, 
e.g. when an address is used as? a 'limit' in a loop). So we don't ban 
those on construction. Of course you dereference you get an exception.
>
> SequenceLayout::withElementCount should probably specify IAE if given a negative elementCount, right?
Whoops, yes
>
> hasSize()  - Suggest: "TELLS whether or not this layout has a KNOWN size".??  The reason I suggest ?known? is that the class-level docs says that ?all layouts have a size?, just that the size is not known for an unbound sequence layout. I would suggest a method name of ?knownSize? or "sizeKnown", but that maybe a little too far?

Uhm - I would argue that the problem here lies in the class-level doc. 
If a layout embeds a sequence w/o a size, then the layout does not have 
a size (it might have a 'minimum size'). I'm more for fixing the 
class-level assertion which seems too far reaching.

Maurizio

>
> -Chris.

From maurizio.cimadamore at oracle.com  Thu Jan  9 18:36:56 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 9 Jan 2020 18:36:56 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
Message-ID: 

New revision:

http://cr.openjdk.java.net/~mcimadamore/8235837_v2

delta from previous iteration:

http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta

javadoc

http://cr.openjdk.java.net/~mcimadamore/8235837_v2_javadoc

specdiff

http://cr.openjdk.java.net/~mcimadamore/8235837_v2_specdiff/overview-summary.html

Cheers
Maurizio

On 09/01/2020 14:36, Maurizio Cimadamore wrote:
> Hi,
> following the JEP 370 code review and CSR, certain comments that have 
> not been addressed have been added to the tracker issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8235837
>
> For further evaluation. After some discussion in the Panama channel 
> (see [1] and [2]), the Panama team has come to the following conclusions:
>
> * the MemoryAddress::offset(long) method should be renamed to 
> MemoryAddress::addOffset(long)
> * the MemorySegment::isAccessible() predicate should be dropped and 
> replaced with the MemorySegment::ownerThread() accessor
> * a new predicate should be added to MemoryLayout, namely 
> MemoryLayout::hasSize() to allow clients to establish as to whether a 
> layout contains some unsized parts
> * a new method should be added to SequenceLayout, namely 
> SequenceLayout::withElementCount, to create a new sequence layout with 
> new element count
> * 2 new helper methods should be added to MemoryLayout, namely:
> ?? - MemoryLayout::map - to allow transformation of a layout into a 
> new layout (by replacing the sub-layout at given path with a new layout)
> ?? - MemoryLayout::select - to allow selection of a sub-layout given a 
> layout path
>
> Overall, we think this set of change strikes a good compromise between 
> usability, readability and minimality.
>
> The javadoc for the layout path-accepting methods (both old and new 
> ones) has been significantly refactored and improved - and the 
> toplevel javadoc section on layout paths has been enhanced to cover 
> all the concepts. The implementation for these methods has also been 
> consolidated greatly, which revealed subtle bugs in the old 
> implementation which have now been rectified (new tests have been added).
>
> Webrev is available here:
>
> http://cr.openjdk.java.net/~mcimadamore/8235837/
>
> Specdiff for changes here:
>
> http://cr.openjdk.java.net/~mcimadamore/8235837_specdiff/overview-summary.html 
>
>
> A draft CSR for this issue is available here (I will finalize once the 
> review converges on the API changes):
>
> https://bugs.openjdk.java.net/browse/JDK-8236853
>
> I plan to push this to JDK 14 under the late enhancement process [3].
>
> Cheers
> Maurizio
>
> [1] - 
> https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006873.html
> [2] - 
> https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006885.html
> [3] - https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
>
>
>
>
>

From Roger.Riggs at oracle.com  Thu Jan  9 18:36:54 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 9 Jan 2020 13:36:54 -0500
Subject: RFR 8234423 : Modifying ArrayList.subList().subList() resets
 modCount of subList
In-Reply-To: 
References: 
 
Message-ID: <167a1462-6012-2f64-03a6-c4498c032907@oracle.com>

Hi Ivan,

Happy New Year!

This change looks fine.

Roger


On 11/23/19 2:30 AM, Ivan Gerasimov wrote:
> Re-sending the request with the correct Subject line - the bug is not 
> (only) about the iterator.
>
>
> On 11/20/19 10:11 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> When a sublist of a sublist of an ArrayList is created, its modCount 
>> is initialized from the ArrayList root, and not from its immediate 
>> parent.
>>
>> This means that modifying that 2nd level sublist will reset modCounts 
>> of the entire chain up to the root, and consequently the 1st level 
>> sublist won't detect concurrent modification done to the ArrayList root.
>>
>> Along with the fix, handling of modCount is slightly improved in a 
>> few other places.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234423
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8234423/00/webrev/
>>


From joe.darcy at oracle.com  Thu Jan  9 19:22:13 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 9 Jan 2020 11:22:13 -0800
Subject: JDK 14 RFR of JDK-8236877: Add "record" to descriptions in
 java.lang.{annotation, reflect}
Message-ID: 

Hello,

As noted by Werner [1], one of the discussions of the kinds of types in 
java.lang.annotation was not updated for records. I checked 
java.lang.annotation, java.lang.reflect, and java.lang.Class and found 
another location to update:

 ??? JDK-8236877: Add "record" to descriptions in java.lang.{annotation, 
reflect}
 ??? http://cr.openjdk.java.net/~darcy/8236877.0/

I kept long-lines for the review to make review the change easier; I'll 
re-flow the text before pushing.

Patch below; thanks,

-Joe

[1] 
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014150.html


--- old/src/java.base/share/classes/java/lang/Class.java 2020-01-09 
10:58:53.311010487 -0800
+++ new/src/java.base/share/classes/java/lang/Class.java 2020-01-09 
10:58:53.122916487 -0800
@@ -90,7 +90,7 @@

 ?/**
 ? * Instances of the class {@code Class} represent classes and interfaces
- * in a running Java application. An enum type is a kind of class and an
+ * in a running Java application. An enum type and a record type are 
kinds of class; an
 ? * annotation type is a kind of interface. Every array also
 ? * belongs to a class that is reflected as a {@code Class} object
 ? * that is shared by all arrays with the same element type and number
--- 
old/src/java.base/share/classes/java/lang/annotation/ElementType.java 
2020-01-09 10:58:53.719214486 -0800
+++ 
new/src/java.base/share/classes/java/lang/annotation/ElementType.java 
2020-01-09 10:58:53.543126487 -0800
@@ -71,7 +71,7 @@
 ? * @jls 4.1 The Kinds of Types and Values
 ? */
 ?public enum ElementType {
-??? /** Class, interface (including annotation type), or enum 
declaration */
+??? /** Class, interface (including annotation type), enum, or record 
declaration */
 ???? TYPE,

 ???? /** Field declaration (includes enum constants) */


From mandy.chung at oracle.com  Thu Jan  9 19:25:48 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 9 Jan 2020 11:25:48 -0800
Subject: JDK 14 RFR of JDK-8236877: Add "record" to descriptions in
 java.lang.{annotation, reflect}
In-Reply-To: 
References: 
Message-ID: 

+1

Mandy

On 1/9/20 11:22 AM, Joe Darcy wrote:
> Hello,
>
> As noted by Werner [1], one of the discussions of the kinds of types 
> in java.lang.annotation was not updated for records. I checked 
> java.lang.annotation, java.lang.reflect, and java.lang.Class and found 
> another location to update:
>
> ??? JDK-8236877: Add "record" to descriptions in 
> java.lang.{annotation, reflect}
> ??? http://cr.openjdk.java.net/~darcy/8236877.0/
>
> I kept long-lines for the review to make review the change easier; 
> I'll re-flow the text before pushing.
>
> Patch below; thanks,
>
> -Joe
>
> [1] 
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014150.html
>
>
> --- old/src/java.base/share/classes/java/lang/Class.java 2020-01-09 
> 10:58:53.311010487 -0800
> +++ new/src/java.base/share/classes/java/lang/Class.java 2020-01-09 
> 10:58:53.122916487 -0800
> @@ -90,7 +90,7 @@
>
> ?/**
> ? * Instances of the class {@code Class} represent classes and interfaces
> - * in a running Java application. An enum type is a kind of class and an
> + * in a running Java application. An enum type and a record type are 
> kinds of class; an
> ? * annotation type is a kind of interface. Every array also
> ? * belongs to a class that is reflected as a {@code Class} object
> ? * that is shared by all arrays with the same element type and number
> --- 
> old/src/java.base/share/classes/java/lang/annotation/ElementType.java 
> 2020-01-09 10:58:53.719214486 -0800
> +++ 
> new/src/java.base/share/classes/java/lang/annotation/ElementType.java 
> 2020-01-09 10:58:53.543126487 -0800
> @@ -71,7 +71,7 @@
> ? * @jls 4.1 The Kinds of Types and Values
> ? */
> ?public enum ElementType {
> -??? /** Class, interface (including annotation type), or enum 
> declaration */
> +??? /** Class, interface (including annotation type), enum, or record 
> declaration */
> ???? TYPE,
>
> ???? /** Field declaration (includes enum constants) */
>


From sgehwolf at redhat.com  Thu Jan  9 19:51:58 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 09 Jan 2020 20:51:58 +0100
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
Message-ID: <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>

Hi,

On Fri, 2020-01-03 at 15:37 -0500, Bob Vandette wrote:
> Here are a few comments from scanning the webrev.
> 
> 
> It looks like you can remove line 151
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java.sdiff.html
> 
> 151         int[] ints = new int[0];
> 
> ?????
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/share/classes/jdk/internal/platform/Metrics.java.sdiff.html
> 
> There are several comments stating that -2 == unlimited.  This is not
> the case.
> 
> @return count of elapsed periods or -2 if the quota is unlimited.
> 
> ?????
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java.sdiff.html
> 
> Shouldn?t you just check for cgroupv2 before trying to run the
> testKernelMemoryLimit and testOomKillFlag tests?
> 
> ?????
> 
> There are a few places where getPerCpuUsage is returning ?new
> long[0]? but you changed the interface to expect null
> for not supported.
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java.html
> 
> You probably need to check all users of the APIs which used to return
> array[0] which now return null to make sure you
> don?t get null pointer exceptions.
> 
> One example is testCpuConsumption.
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java.html
> 
> Also, 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java.html:167
> 
> 
> You?ll also have to update copyrights to 2020.

Thanks for the review! Should all be fixed now. Updated webrev:

incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/

Note: I'll go through touched files and update copyright dates to 2020.
Not all have been updated in the full webrev. It'll be done though.

Thanks,
Severin

> Bob.
> 
> 
> > On Dec 20, 2019, at 9:50 AM, Severin Gehwolf 
> > wrote:
> > 
> > Hi Bob,
> > 
> > Sorry for the delay to get this updated.
> > 
> > Changes done in this latest webrev:
> > 
> >   1. Rebased on top of 8226575: OperatingSystemMXBean should be
> > made
> >      container aware. File read ops now use privileged code.
> >   2. Warning for mixed cgroup controllers and returning null for
> > metrics.
> >   3. Added implementations for getBlkIOServiceCount() and
> >      getBlkIOServiced() using sum of rios/wios and rbytes/wbytes
> > across
> >      devices. Added impl for getTcpMemoryUsage()
> >   4. Returning -2 for not supported (if the metric would return
> > long).
> >      boolean metrics now return Boolean and null if not supported.
> > Same
> >      for array return types. null if not supported for symmetry.
> >   5. -XshowSettings:system output has been updated to return "N/A"
> > for
> >      when a metric is not available. E.g. "Kernel OOM killer
> > enabled"
> >      Boolean.
> >   6. Tests have been updated to reflect this.
> > 
> > webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/
> > incremental webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/
> > 
> > Testing: Docker tests and podman testing on cgroupsv2. I'll run it
> > through jdk/submit as well.
> > 
> > Hopefully this can get pushed with 8230305 early on in the jdk 15
> > cycle
> > :)
> > 
> > A couple of more inline comments below.
> > 
> > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote:
> > > Sorry for the delay in responding.  See comments below:
> > > 
> > > > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf <
> > > > sgehwolf at redhat.com> wrote:
> > > > 
> > > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote:
> > > > > Hi,
> > > > > 
> > > > > Could I please get reviews of these core-libs, Linux-only,
> > > > > changes to
> > > > > the Metrics subsystem? This patch implements cgroupv2 support
> > > > > for
> > > > > Metrics which are currently cgroupv1-only. Fedora 31 switched
> > > > > to
> > > > > cgroupv2 by default so it's time to get OpenJDK recognize it.
> > > > > 
> > > > > Note that a couple of metrics are no longer supported with
> > > > > cgroupv2.
> > > > > Most notably (not an exhaustive list, though):
> > > > > 
> > > > > Metrics.getKernel*() family of methods.
> > > > > Metrics.getTcp*() family of methods.
> > > > > Metrics.getBlkIO*() family of methods.
> > > > > Metrics.isMemoryOOMKillEnabled()
> > > > > 
> > > > > A couple of open questions with regards to that:
> > > > > 
> > > > > 1)
> > > > > Most API docs of Metrics make no distiction between
> > > > > "unlimited" and
> > > > > "not supported", both returning -1 for longs, for example.
> > > > > This is a
> > > > > problem, because output of "java -XshowSettings:system
> > > > > -version" will
> > > > > not distinguish between unlimited and not supported metrics.
> > > > > Would it
> > > > > be acceptable to change the API to distinguish those cases so
> > > > > that
> > > > > LauncherHelper could display them appropriately?
> > > > > 
> > > > > 2)
> > > > > How should we deal with "not supported" for booleans/arrays,
> > > > > etc.?
> > > > > Would it make sense to return record objects from the Metrics
> > > > > API so
> > > > > that this could be dealt with? E.g.
> > > > > 
> > > > > Metrics m = ...
> > > > > MetricResult result = m.getCpuSetCpus();
> > > > > switch(result.getType()) {
> > > > >  case NOT_SUPPORTED: /* do something */; break;
> > > > >  case SUPPORTED: int[] val = result.get(); break;
> > > > >  ...         
> > > > > }
> > > > > 
> > > > > I'm bringing this up, because the proposed patch doesn't deal
> > > > > with the
> > > > > above open questions as of yet. With that being said, it's
> > > > > mostly
> > > > > identical to the proposed hotspot changes in [1].
> > > 
> > > For issue 1 and 2 ?
> > > 
> > > I wonder if we should change the API to throw
> > > UnsupportedOperationException for those methods 
> > > that are not available.  This exception is used quite a lot in
> > > the java/nio and java/net packages
> > > for dealing with functionality not available on a host platform.
> > > 
> > > As an alternate suggestion, we already return -2 for "not
> > > supported" for most APIs in the hotspot
> > > implementation.  We could use this for non boolean values in the
> > > Metrics API.  For boolean
> > > values, we could change the API to return ?Boolean?.  A null
> > > return would signify not
> > > implemented.
> > 
> > This alternative has been implemented in the latest webrev.
> > LauncherHelper has been updated to print "N/A" if some property
> > being
> > printed is not supported. Example output for cgroupsv2:
> > 
> > $ ./bin/java -XshowSettings:system -version
> > Operating System Metrics:
> >    Provider: cgroupv2
> >    Effective CPU Count: 4
> >    CPU Period: 100000us
> >    CPU Quota: -1
> >    CPU Shares: -1
> >    List of Processors: N/A
> >    List of Effective Processors: N/A
> >    List of Memory Nodes: N/A
> >    List of Available Memory Nodes: N/A
> >    CPUSet Memory Pressure Enabled: N/A
> >    Memory Limit: Unlimited
> >    Memory Soft Limit: Unlimited
> >    Memory & Swap Limit: Unlimited
> >    Kernel Memory Limit: N/A
> >    TCP Memory Limit: N/A
> >    Out Of Memory Killer Enabled: N/A
> > 
> > openjdk version "15-internal" 2020-09-15
> > OpenJDK Runtime Environment (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2)
> > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> > 
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231111
> > > > > webrev: 
> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/
> > > > > 
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html
> > > 
> > > Should we check to make sure that there are no mixed cgroupv1 and
> > > cgroupv2 mounted subsystems since
> > > you are not supporting mixing.
> > 
> > Done. null is returned for metrics and a warning printed to stderr.
> > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
> > > 
> > > It looks looks like there may be alternate ways of reporting some
> > > of the metrics that you have classified as RETVAL_NOT_SUPPORTED.
> > > 
> > > BlkIOServicedCount (io.stat)
> > > KernelMemory (memory.stat)
> > > TcpMemory (memory.stat)
> > 
> > The latest webrev has getBlkIOService* and getTcpMemoryUsage impls.
> > I've left out kernel memory metrics as it wasn't clear what this
> > would
> > be. We can add that in a later patch. The size of this patch is
> > already
> > rather big.
> > 
> > > You could try the same trick for getMemoryAndSwapMaxUsage which
> > > keeps track of the highest returned value.
> > 
> > We've decided to not do this. getMemoryAndSwapMaxUsage and
> > getMemoryMaxUsage is being returned as not supported in cgroups v2.
> > 
> > Thanks,
> > Severin
> > 
> > > for the benefit of other reviewers, you should provide links to
> > > the cgroupv1 and v2 docs.
> > > 
> > > https://www.kernel.org/doc/Documentation/cgroup-v2.txt
> > > 
> > > > > Testing: jdk/submit and platform docker tests on Linux x86_64
> > > > > (with
> > > > > hybrid hierarchy, docker/podman) and on Linux x86_64 with
> > > > > unified
> > > > > hierarchy (podman only).
> > > > > 
> > > > > Thoughts? Suggestions?
> > > 
> > > Do you think we should check the docker version being used for
> > > the tests to make sure it
> > > supports cgroupv2?  I assume a fairly recent version is required
> > > to work with cgroupv2.
> > > 
> > > Bob.
> > > 
> > > 
> > > 
> > > > Ping?
> > > > 
> > > > > Thanks,
> > > > > Severin
> > > > > 
> > > > > [1] 
> > > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html


From lance.andersen at oracle.com  Thu Jan  9 20:11:33 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 9 Jan 2020 15:11:33 -0500
Subject: JDK 14 RFR of JDK-8236877: Add "record" to descriptions in
 java.lang.{annotation, reflect}
In-Reply-To: 
References: 
Message-ID: <6C241118-0A7B-496C-BE16-110B4CB53CD3@oracle.com>

+1

> On Jan 9, 2020, at 2:22 PM, Joe Darcy  wrote:
> 
> Hello,
> 
> As noted by Werner [1], one of the discussions of the kinds of types in java.lang.annotation was not updated for records. I checked java.lang.annotation, java.lang.reflect, and java.lang.Class and found another location to update:
> 
>     JDK-8236877: Add "record" to descriptions in java.lang.{annotation, reflect}
>     http://cr.openjdk.java.net/~darcy/8236877.0/
> 
> I kept long-lines for the review to make review the change easier; I'll re-flow the text before pushing.
> 
> Patch below; thanks,
> 
> -Joe
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014150.html
> 
> 
> --- old/src/java.base/share/classes/java/lang/Class.java 2020-01-09 10:58:53.311010487 -0800
> +++ new/src/java.base/share/classes/java/lang/Class.java 2020-01-09 10:58:53.122916487 -0800
> @@ -90,7 +90,7 @@
> 
>  /**
>   * Instances of the class {@code Class} represent classes and interfaces
> - * in a running Java application. An enum type is a kind of class and an
> + * in a running Java application. An enum type and a record type are kinds of class; an
>   * annotation type is a kind of interface. Every array also
>   * belongs to a class that is reflected as a {@code Class} object
>   * that is shared by all arrays with the same element type and number
> --- old/src/java.base/share/classes/java/lang/annotation/ElementType.java 2020-01-09 10:58:53.719214486 -0800
> +++ new/src/java.base/share/classes/java/lang/annotation/ElementType.java 2020-01-09 10:58:53.543126487 -0800
> @@ -71,7 +71,7 @@
>   * @jls 4.1 The Kinds of Types and Values
>   */
>  public enum ElementType {
> -    /** Class, interface (including annotation type), or enum declaration */
> +    /** Class, interface (including annotation type), enum, or record declaration */
>      TYPE,
> 
>      /** Field declaration (includes enum constants) */
> 

 
  
 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  Fri Jan 10 00:19:06 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 9 Jan 2020 16:19:06 -0800
Subject: Use single character replace variant in
 Resources.toPackageName(String)
In-Reply-To: <308972ac-5028-8c47-ce2a-5de1d469ced9@oracle.com>
References: <5E68F7A2-BAAA-488F-B3D2-7B815E1B09D8@freenet.de>
 
 <8bb7168b-91b9-90ee-eae7-59d0f4ef82ee@oracle.com>
 <308972ac-5028-8c47-ce2a-5de1d469ced9@oracle.com>
Message-ID: 

FYI.? I changed the year to 2020 and pushed the fix.

Thank you Christoph and Alan!

On 1/6/20 11:49 PM, Alan Bateman wrote:
> On 07/01/2020 07:09, Ivan Gerasimov wrote:
>> So, I filed a Jira bug:
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236705
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8236705/00/webrev/
>>
> I added these source files in JDK 9, it was just an oversight that I 
> didn't use the single char replace. My guess is that the change 
> ModulePath deriveModuleDescriptor won't be noticeable in any real 
> benchmark. This method is deriving a module descriptor for a legacy 
> JAR file on the module path so it's scanning the contents of the JAR 
> file and all attributes in its main manifest. The Resources 
> toPackageName method is used more widely so it may help in a few 
> cases. Anyway, this change looks fine except the copyright year 
> (you've changed it to 2019 rather than 2020).
>
> -Alan

-- 
With kind regards,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Fri Jan 10 00:20:17 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 9 Jan 2020 16:20:17 -0800
Subject: RFR 8234423 : Modifying ArrayList.subList().subList() resets
 modCount of subList
In-Reply-To: <167a1462-6012-2f64-03a6-c4498c032907@oracle.com>
References: 
 
 <167a1462-6012-2f64-03a6-c4498c032907@oracle.com>
Message-ID: 

Thank you Roger for your review!

Happy New Year to you too! :)

With kind regards,

Ivan

On 1/9/20 10:36 AM, Roger Riggs wrote:
> Hi Ivan,
>
> Happy New Year!
>
> This change looks fine.
>
> Roger
>
>
> On 11/23/19 2:30 AM, Ivan Gerasimov wrote:
>> Re-sending the request with the correct Subject line - the bug is not 
>> (only) about the iterator.
>>
>>
>> On 11/20/19 10:11 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> When a sublist of a sublist of an ArrayList is created, its modCount 
>>> is initialized from the ArrayList root, and not from its immediate 
>>> parent.
>>>
>>> This means that modifying that 2nd level sublist will reset 
>>> modCounts of the entire chain up to the root, and consequently the 
>>> 1st level sublist won't detect concurrent modification done to the 
>>> ArrayList root.
>>>
>>> Along with the fix, handling of modCount is slightly improved in a 
>>> few other places.
>>>
>>> Would you please help review the fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234423
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8234423/00/webrev/
>>>
>
-- 
With kind regards,
Ivan Gerasimov


From shade at redhat.com  Fri Jan 10 09:11:28 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 10 Jan 2020 10:11:28 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <7285ec8b-573c-52f8-5a0d-dd37598dfc7b@redhat.com>
References: 
 <5E016C66.4040502@oracle.com>
 
 <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com>
 <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com>
 
 <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>
 
 <7285ec8b-573c-52f8-5a0d-dd37598dfc7b@redhat.com>
Message-ID: <76141aa4-5b8f-08b6-0343-63f68f63a074@redhat.com>

On 1/8/20 10:12 AM, Aleksey Shipilev wrote:
> On 1/8/20 9:45 AM, Aleksey Shipilev wrote:
>> On 1/7/20 7:50 AM, Aleksey Shipilev wrote:
>>> On 1/6/20 1:48 PM, Alex Kashchenko wrote:
>>>> [...]
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>
> So, somebody needs to ack this patch, and then I can push.

No other takers? I would then push this trivial patch for Alex under my single review.

-- 
Thanks,
-Aleksey


From Alan.Bateman at oracle.com  Fri Jan 10 09:24:52 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 10 Jan 2020 09:24:52 +0000
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <76141aa4-5b8f-08b6-0343-63f68f63a074@redhat.com>
References: 
 <5E016C66.4040502@oracle.com>
 
 <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com>
 <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com>
 
 <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>
 
 <7285ec8b-573c-52f8-5a0d-dd37598dfc7b@redhat.com>
 <76141aa4-5b8f-08b6-0343-63f68f63a074@redhat.com>
Message-ID: <93f0dfb4-0ba2-de79-ae33-60b306b64e8d@oracle.com>

On 10/01/2020 09:11, Aleksey Shipilev wrote:
> :
> No other takers? I would then push this trivial patch for Alex under my single review.
>
I think it's okay but would be nice if one of the jpackager maintainers 
jumped in.

I also think it would be useful to get an inventory of the Visual Studio 
versions that are in use. It's a bit annoying to have to keep the JDK 
still building on VS2013. Ditto for VS2015. Oracle engineers moved to 
VS2017 some time ago (discussed on build-dev). I don't know if anyone is 
building with VS2019 at this time. It may actually be more important to 
establish a base SDK release as it really annoying to have to 
dynamically look up symbols that aren't declared in the older header files.

-Alan

From chris.hegarty at oracle.com  Fri Jan 10 10:05:06 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 10 Jan 2020 10:05:06 +0000
Subject: JDK 14 RFR of JDK-8236877: Add "record" to descriptions in
 java.lang.{annotation, reflect}
In-Reply-To: 
References: 
Message-ID: <2cdd7254-cad9-f7c1-922a-bd2042f3a71e@oracle.com>


On 09/01/2020 19:22, Joe Darcy wrote:
> Hello,
> 
> As noted by Werner [1], one of the discussions of the kinds of types in 
> java.lang.annotation was not updated for records. I checked 
> java.lang.annotation, java.lang.reflect, and java.lang.Class and found 
> another location to update:
> 
>  ??? JDK-8236877: Add "record" to descriptions in java.lang.{annotation, 
> reflect}
>  ??? http://cr.openjdk.java.net/~darcy/8236877.0/

LGTM.

-Chris.

From sundararajan.athijegannathan at oracle.com  Fri Jan 10 13:07:13 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 10 Jan 2020 18:37:13 +0530
Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java
 time out
In-Reply-To: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
Message-ID: <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com>

Adding core-libs-dev.

-Sundar

On 10/01/20 11:33 am, sundararajan.athijegannathan at oracle.com wrote:
> Please review.
>
> Not really a fix - but increasing the default timeout for the test.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222098
>
> Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/
>
> Thanks,
>
> -Sundar
>

From takiguc at linux.vnet.ibm.com  Fri Jan 10 13:13:37 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 10 Jan 2020 22:13:37 +0900
Subject: RFR: CSR JDK-8233385 Align some one-way conversion in MS950 charset
 with Windows
Message-ID: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>

Hello.

Could you review CSR JDK-8233385 [1] ?

[1] https://bugs.openjdk.java.net/browse/JDK-8233385

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From james.laskey at oracle.com  Fri Jan 10 13:32:45 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 10 Jan 2020 09:32:45 -0400
Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java
 time out
In-Reply-To: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
Message-ID: <0044B474-C75D-4D4F-937E-42EDBF213FC6@oracle.com>

+1

> On Jan 10, 2020, at 2:03 AM, sundararajan.athijegannathan at oracle.com wrote:
> 
> Please review.
> 
> Not really a fix - but increasing the default timeout for the test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222098
> 
> Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/
> 
> Thanks,
> 
> -Sundar
> 


From naoto.sato at oracle.com  Fri Jan 10 13:50:16 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 05:50:16 -0800
Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java
 time out
In-Reply-To: <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com>
References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
 <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com>
Message-ID: 

Hi Sundar,

You might want to add the bug id in the regression test, and change the 
copyright year to 2020.

Otherwise, looks good.

Naoto

On 1/10/20 5:07 AM, sundararajan.athijegannathan at oracle.com wrote:
> Adding core-libs-dev.
> 
> -Sundar
> 
> On 10/01/20 11:33 am, sundararajan.athijegannathan at oracle.com wrote:
>> Please review.
>>
>> Not really a fix - but increasing the default timeout for the test.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222098
>>
>> Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/
>>
>> Thanks,
>>
>> -Sundar
>>

From bob.vandette at oracle.com  Fri Jan 10 16:50:25 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 10 Jan 2020 11:50:25 -0500
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
Message-ID: 

Severin,

The changes look ok to me.  I assume you?ve run the container tests on a cgroupv2 and cgroupv1 enabled system, right?

You?re going to have to find a ?R? reviewer.

What?s the status of the hotspot cgroupv2 changes.  Have these been reviewed?

Bob.


> On Jan 9, 2020, at 2:51 PM, Severin Gehwolf  wrote:
> 
> Hi,
> 
> On Fri, 2020-01-03 at 15:37 -0500, Bob Vandette wrote:
>> Here are a few comments from scanning the webrev.
>> 
>> 
>> It looks like you can remove line 151
>> 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java.sdiff.html
>> 
>> 151         int[] ints = new int[0];
>> 
>> ?????
>> 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/share/classes/jdk/internal/platform/Metrics.java.sdiff.html
>> 
>> There are several comments stating that -2 == unlimited.  This is not
>> the case.
>> 
>> @return count of elapsed periods or -2 if the quota is unlimited.
>> 
>> ?????
>> 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java.sdiff.html
>> 
>> Shouldn?t you just check for cgroupv2 before trying to run the
>> testKernelMemoryLimit and testOomKillFlag tests?
>> 
>> ?????
>> 
>> There are a few places where getPerCpuUsage is returning ?new
>> long[0]? but you changed the interface to expect null
>> for not supported.
>> 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
>> 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java.html
>> 
>> You probably need to check all users of the APIs which used to return
>> array[0] which now return null to make sure you
>> don?t get null pointer exceptions.
>> 
>> One example is testCpuConsumption.
>> 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java.html
>> 
>> Also, 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java.html:167
>> 
>> 
>> You?ll also have to update copyrights to 2020.
> 
> Thanks for the review! Should all be fixed now. Updated webrev:
> 
> incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
> full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/
> 
> Note: I'll go through touched files and update copyright dates to 2020.
> Not all have been updated in the full webrev. It'll be done though.
> 
> Thanks,
> Severin
> 
>> Bob.
>> 
>> 
>>> On Dec 20, 2019, at 9:50 AM, Severin Gehwolf 
>>> wrote:
>>> 
>>> Hi Bob,
>>> 
>>> Sorry for the delay to get this updated.
>>> 
>>> Changes done in this latest webrev:
>>> 
>>>  1. Rebased on top of 8226575: OperatingSystemMXBean should be
>>> made
>>>     container aware. File read ops now use privileged code.
>>>  2. Warning for mixed cgroup controllers and returning null for
>>> metrics.
>>>  3. Added implementations for getBlkIOServiceCount() and
>>>     getBlkIOServiced() using sum of rios/wios and rbytes/wbytes
>>> across
>>>     devices. Added impl for getTcpMemoryUsage()
>>>  4. Returning -2 for not supported (if the metric would return
>>> long).
>>>     boolean metrics now return Boolean and null if not supported.
>>> Same
>>>     for array return types. null if not supported for symmetry.
>>>  5. -XshowSettings:system output has been updated to return "N/A"
>>> for
>>>     when a metric is not available. E.g. "Kernel OOM killer
>>> enabled"
>>>     Boolean.
>>>  6. Tests have been updated to reflect this.
>>> 
>>> webrev:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/
>>> incremental webrev:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/
>>> 
>>> Testing: Docker tests and podman testing on cgroupsv2. I'll run it
>>> through jdk/submit as well.
>>> 
>>> Hopefully this can get pushed with 8230305 early on in the jdk 15
>>> cycle
>>> :)
>>> 
>>> A couple of more inline comments below.
>>> 
>>> On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote:
>>>> Sorry for the delay in responding.  See comments below:
>>>> 
>>>>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf <
>>>>> sgehwolf at redhat.com> wrote:
>>>>> 
>>>>> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Could I please get reviews of these core-libs, Linux-only,
>>>>>> changes to
>>>>>> the Metrics subsystem? This patch implements cgroupv2 support
>>>>>> for
>>>>>> Metrics which are currently cgroupv1-only. Fedora 31 switched
>>>>>> to
>>>>>> cgroupv2 by default so it's time to get OpenJDK recognize it.
>>>>>> 
>>>>>> Note that a couple of metrics are no longer supported with
>>>>>> cgroupv2.
>>>>>> Most notably (not an exhaustive list, though):
>>>>>> 
>>>>>> Metrics.getKernel*() family of methods.
>>>>>> Metrics.getTcp*() family of methods.
>>>>>> Metrics.getBlkIO*() family of methods.
>>>>>> Metrics.isMemoryOOMKillEnabled()
>>>>>> 
>>>>>> A couple of open questions with regards to that:
>>>>>> 
>>>>>> 1)
>>>>>> Most API docs of Metrics make no distiction between
>>>>>> "unlimited" and
>>>>>> "not supported", both returning -1 for longs, for example.
>>>>>> This is a
>>>>>> problem, because output of "java -XshowSettings:system
>>>>>> -version" will
>>>>>> not distinguish between unlimited and not supported metrics.
>>>>>> Would it
>>>>>> be acceptable to change the API to distinguish those cases so
>>>>>> that
>>>>>> LauncherHelper could display them appropriately?
>>>>>> 
>>>>>> 2)
>>>>>> How should we deal with "not supported" for booleans/arrays,
>>>>>> etc.?
>>>>>> Would it make sense to return record objects from the Metrics
>>>>>> API so
>>>>>> that this could be dealt with? E.g.
>>>>>> 
>>>>>> Metrics m = ...
>>>>>> MetricResult result = m.getCpuSetCpus();
>>>>>> switch(result.getType()) {
>>>>>> case NOT_SUPPORTED: /* do something */; break;
>>>>>> case SUPPORTED: int[] val = result.get(); break;
>>>>>> ...         
>>>>>> }
>>>>>> 
>>>>>> I'm bringing this up, because the proposed patch doesn't deal
>>>>>> with the
>>>>>> above open questions as of yet. With that being said, it's
>>>>>> mostly
>>>>>> identical to the proposed hotspot changes in [1].
>>>> 
>>>> For issue 1 and 2 ?
>>>> 
>>>> I wonder if we should change the API to throw
>>>> UnsupportedOperationException for those methods 
>>>> that are not available.  This exception is used quite a lot in
>>>> the java/nio and java/net packages
>>>> for dealing with functionality not available on a host platform.
>>>> 
>>>> As an alternate suggestion, we already return -2 for "not
>>>> supported" for most APIs in the hotspot
>>>> implementation.  We could use this for non boolean values in the
>>>> Metrics API.  For boolean
>>>> values, we could change the API to return ?Boolean?.  A null
>>>> return would signify not
>>>> implemented.
>>> 
>>> This alternative has been implemented in the latest webrev.
>>> LauncherHelper has been updated to print "N/A" if some property
>>> being
>>> printed is not supported. Example output for cgroupsv2:
>>> 
>>> $ ./bin/java -XshowSettings:system -version
>>> Operating System Metrics:
>>>   Provider: cgroupv2
>>>   Effective CPU Count: 4
>>>   CPU Period: 100000us
>>>   CPU Quota: -1
>>>   CPU Shares: -1
>>>   List of Processors: N/A
>>>   List of Effective Processors: N/A
>>>   List of Memory Nodes: N/A
>>>   List of Available Memory Nodes: N/A
>>>   CPUSet Memory Pressure Enabled: N/A
>>>   Memory Limit: Unlimited
>>>   Memory Soft Limit: Unlimited
>>>   Memory & Swap Limit: Unlimited
>>>   Kernel Memory Limit: N/A
>>>   TCP Memory Limit: N/A
>>>   Out Of Memory Killer Enabled: N/A
>>> 
>>> openjdk version "15-internal" 2020-09-15
>>> OpenJDK Runtime Environment (build 15-internal+0-
>>> adhoc.sgehwolf.openjdk-head-2)
>>> OpenJDK 64-Bit Server VM (build 15-internal+0-
>>> adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111
>>>>>> webrev: 
>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/
>>>>>> 
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html
>>>> 
>>>> Should we check to make sure that there are no mixed cgroupv1 and
>>>> cgroupv2 mounted subsystems since
>>>> you are not supporting mixing.
>>> 
>>> Done. null is returned for metrics and a warning printed to stderr.
>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
>>>> 
>>>> It looks looks like there may be alternate ways of reporting some
>>>> of the metrics that you have classified as RETVAL_NOT_SUPPORTED.
>>>> 
>>>> BlkIOServicedCount (io.stat)
>>>> KernelMemory (memory.stat)
>>>> TcpMemory (memory.stat)
>>> 
>>> The latest webrev has getBlkIOService* and getTcpMemoryUsage impls.
>>> I've left out kernel memory metrics as it wasn't clear what this
>>> would
>>> be. We can add that in a later patch. The size of this patch is
>>> already
>>> rather big.
>>> 
>>>> You could try the same trick for getMemoryAndSwapMaxUsage which
>>>> keeps track of the highest returned value.
>>> 
>>> We've decided to not do this. getMemoryAndSwapMaxUsage and
>>> getMemoryMaxUsage is being returned as not supported in cgroups v2.
>>> 
>>> Thanks,
>>> Severin
>>> 
>>>> for the benefit of other reviewers, you should provide links to
>>>> the cgroupv1 and v2 docs.
>>>> 
>>>> https://www.kernel.org/doc/Documentation/cgroup-v2.txt
>>>> 
>>>>>> Testing: jdk/submit and platform docker tests on Linux x86_64
>>>>>> (with
>>>>>> hybrid hierarchy, docker/podman) and on Linux x86_64 with
>>>>>> unified
>>>>>> hierarchy (podman only).
>>>>>> 
>>>>>> Thoughts? Suggestions?
>>>> 
>>>> Do you think we should check the docker version being used for
>>>> the tests to make sure it
>>>> supports cgroupv2?  I assume a fairly recent version is required
>>>> to work with cgroupv2.
>>>> 
>>>> Bob.
>>>> 
>>>> 
>>>> 
>>>>> Ping?
>>>>> 
>>>>>> Thanks,
>>>>>> Severin
>>>>>> 
>>>>>> [1] 
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html
> 


From claes.redestad at oracle.com  Fri Jan 10 17:01:40 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 10 Jan 2020 18:01:40 +0100
Subject: RFR: 8236850: Operations on constant List/Set.of(element) instances
 does not consistently constant fold
Message-ID: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>

Hi,

this patch ensures operations on constant (static final) single-element
lists and sets created via List.of(foo) and Set.of(bar) to constant fold
properly.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8236850
Webrev: http://cr.openjdk.java.net/~redestad/8236850/open.00

On micros that are set up to test constant folding, e.g.
sumSizesFinalList, we see improvements around 10-15%.

I also cleaned up and consolidated the heap archiving interaction a
notch. It was needed in an earlier prototype version of the patch, but
no longer.. since it's a cleanup I kept the changes.

Testing: tier1-3

Thanks!

/Claes

From leonid.mesnik at oracle.com  Fri Jan 10 18:06:34 2020
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Fri, 10 Jan 2020 10:06:34 -0800
Subject: RFR: 8236939: [TESTBUG] Incorrect initialization in
 java/foreign/TestArrays.java
Message-ID: 

Hi

Could you please review following trivial fix which corrects type of 
used SequenceLayout in the java/foreign/TestArrays.java test. Really 
both long and double layouts are actually "MemoryLayout.ofValueBits(64L, 
ByteOrder.nativeOrder());" so this issue didn't cause test failure.

I am going to push it in jdk/jdk only and not in jdk14.

bug: https://bugs.openjdk.java.net/browse/JDK-8236939

fix:


--- a/test/jdk/java/foreign/TestArrays.java     Wed Jan 01 03:08:45 2020 +0100
+++ b/test/jdk/java/foreign/TestArrays.java     Fri Jan 10 09:51:51 2020 -0800
@@ -76,8 +76,8 @@
      static VarHandle shortHandle = shorts.varHandle(short.class, PathElement.sequenceElement());
      static VarHandle intHandle = ints.varHandle(int.class, PathElement.sequenceElement());
      static VarHandle floatHandle = floats.varHandle(float.class, PathElement.sequenceElement());
-    static VarHandle longHandle = doubles.varHandle(long.class, PathElement.sequenceElement());
-    static VarHandle doubleHandle = longs.varHandle(double.class, PathElement.sequenceElement());
+    static VarHandle longHandle = longs.varHandle(long.class, PathElement.sequenceElement());
+    static VarHandle doubleHandle = doubles.varHandle(double.class, PathElement.sequenceElement());
  
      static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {
          for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {


Leonid

From shade at redhat.com  Fri Jan 10 18:16:34 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 10 Jan 2020 19:16:34 +0100
Subject: RFR: 8236939: [TESTBUG] Incorrect initialization in
 java/foreign/TestArrays.java
In-Reply-To: 
References: 
Message-ID: <757de32f-c115-6bef-643d-b98a0d7b2701@redhat.com>

On 1/10/20 7:06 PM, Leonid Mesnik wrote:
> I am going to push it in jdk/jdk only and not in jdk14.

I suspect there would be some work around x86_32 before RDP2 hits, so maybe this can go into
jdk/jdk14 as well? This would minimize the jdk/jdk14 -> jdk/jdk merge chore next week.

> --- a/test/jdk/java/foreign/TestArrays.java     Wed Jan 01 03:08:45 2020 +0100
> +++ b/test/jdk/java/foreign/TestArrays.java     Fri Jan 10 09:51:51 2020 -0800
> @@ -76,8 +76,8 @@
>       static VarHandle shortHandle = shorts.varHandle(short.class, PathElement.sequenceElement());
>       static VarHandle intHandle = ints.varHandle(int.class, PathElement.sequenceElement());
>       static VarHandle floatHandle = floats.varHandle(float.class, PathElement.sequenceElement());
> -    static VarHandle longHandle = doubles.varHandle(long.class, PathElement.sequenceElement());
> -    static VarHandle doubleHandle = longs.varHandle(double.class, PathElement.sequenceElement());
> +    static VarHandle longHandle = longs.varHandle(long.class, PathElement.sequenceElement());
> +    static VarHandle doubleHandle = doubles.varHandle(double.class, PathElement.sequenceElement());
>   
>       static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {
>           for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {

This looks good to me. It does look trivial.

-- 
Thanks,
-Aleksey


From leonid.mesnik at oracle.com  Fri Jan 10 18:28:42 2020
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Fri, 10 Jan 2020 10:28:42 -0800
Subject: RFR: 8236939: [TESTBUG] Incorrect initialization in
 java/foreign/TestArrays.java
In-Reply-To: <757de32f-c115-6bef-643d-b98a0d7b2701@redhat.com>
References: 
 <757de32f-c115-6bef-643d-b98a0d7b2701@redhat.com>
Message-ID: 


On 1/10/20 10:16 AM, Aleksey Shipilev wrote:
> On 1/10/20 7:06 PM, Leonid Mesnik wrote:
>> I am going to push it in jdk/jdk only and not in jdk14.
> I suspect there would be some work around x86_32 before RDP2 hits, so maybe this can go into
> jdk/jdk14 as well? This would minimize the jdk/jdk14 -> jdk/jdk merge chore next week.

Sure. The test bugs could be fixed during RDP2. So if you feel it is 
useful I will push it in jdk14.

Leonid

>
>> --- a/test/jdk/java/foreign/TestArrays.java     Wed Jan 01 03:08:45 2020 +0100
>> +++ b/test/jdk/java/foreign/TestArrays.java     Fri Jan 10 09:51:51 2020 -0800
>> @@ -76,8 +76,8 @@
>>        static VarHandle shortHandle = shorts.varHandle(short.class, PathElement.sequenceElement());
>>        static VarHandle intHandle = ints.varHandle(int.class, PathElement.sequenceElement());
>>        static VarHandle floatHandle = floats.varHandle(float.class, PathElement.sequenceElement());
>> -    static VarHandle longHandle = doubles.varHandle(long.class, PathElement.sequenceElement());
>> -    static VarHandle doubleHandle = longs.varHandle(double.class, PathElement.sequenceElement());
>> +    static VarHandle longHandle = longs.varHandle(long.class, PathElement.sequenceElement());
>> +    static VarHandle doubleHandle = doubles.varHandle(double.class, PathElement.sequenceElement());
>>    
>>        static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {
>>            for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {
> This looks good to me. It does look trivial.
>

From Roger.Riggs at oracle.com  Fri Jan 10 18:41:59 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 10 Jan 2020 13:41:59 -0500
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
Message-ID: 

Hi Claes,

Looks fine.

ImmutableCollections.java: 418? looks like an extra blank line

Thanks, Roger


On 1/10/20 12:01 PM, Claes Redestad wrote:
> Hi,
>
> this patch ensures operations on constant (static final) single-element
> lists and sets created via List.of(foo) and Set.of(bar) to constant fold
> properly.
>
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236850
> Webrev: http://cr.openjdk.java.net/~redestad/8236850/open.00
>
> On micros that are set up to test constant folding, e.g.
> sumSizesFinalList, we see improvements around 10-15%.
>
> I also cleaned up and consolidated the heap archiving interaction a
> notch. It was needed in an earlier prototype version of the patch, but
> no longer.. since it's a cleanup I kept the changes.
>
> Testing: tier1-3
>
> Thanks!
>
> /Claes


From forax at univ-mlv.fr  Fri Jan 10 18:47:52 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 10 Jan 2020 19:47:52 +0100 (CET)
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
Message-ID: <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>

Seem to be a JIT bug to me,
the fields of Set12 are declared final not @Stable (even if the field storing the instanceof of Set&2 itself is marked @Stable) so there is no reason not not let the constant folding happen.

R?mi 

----- Mail original -----
> De: "Claes Redestad" 
> ?: "core-libs-dev" 
> Envoy?: Vendredi 10 Janvier 2020 18:01:40
> Objet: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

> Hi,
> 
> this patch ensures operations on constant (static final) single-element
> lists and sets created via List.of(foo) and Set.of(bar) to constant fold
> properly.
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8236850
> Webrev: http://cr.openjdk.java.net/~redestad/8236850/open.00
> 
> On micros that are set up to test constant folding, e.g.
> sumSizesFinalList, we see improvements around 10-15%.
> 
> I also cleaned up and consolidated the heap archiving interaction a
> notch. It was needed in an earlier prototype version of the patch, but
> no longer.. since it's a cleanup I kept the changes.
> 
> Testing: tier1-3
> 
> Thanks!
> 
> /Claes

From mandy.chung at oracle.com  Fri Jan 10 20:02:31 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Jan 2020 12:02:31 -0800
Subject: [NEW BUG] Fix duplicated word in Lookup#in documentation
In-Reply-To: <4A43C18F-BF66-414F-BCC0-189CD9277B4D@freenet.de>
References: <4A43C18F-BF66-414F-BCC0-189CD9277B4D@freenet.de>
Message-ID: 

Pushed.

See https://bugs.openjdk.java.net/browse/JDK-8236945

Mandy

On 1/7/20 9:32 AM, Christoph Dreis wrote:
> Hi,
>
> I just noticed that a duplicated "the" slipped into the docs of Lookup.in().
>
> The change seems to have been introduced in https://bugs.openjdk.java.net/browse/JDK-8226916.
>
> In case this is considered worthwhile I would need someone to sponsor the trivial change below:
>
> diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> @@ -1451,7 +1451,7 @@
>            * 
  • If the new lookup class is in the same module as the old lookup class,
>            * the new previous lookup class is the old previous lookup class.
>            * 
  • If the new lookup class is in a different module from the old lookup class,
> -         * the new previous lookup class is the the old lookup class.
> +         * the new previous lookup class is the old lookup class.
>            *
>            * 
    
>            * The resulting lookup's capabilities for loading classes
>
> Cheers,
> Christoph
>
>


From naoto.sato at oracle.com  Fri Jan 10 22:02:20 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 14:02:20 -0800
Subject: [15] RFR: 8174270: Consolidate ICU sources in one location
Message-ID: 

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8174270

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8174270/webrev.00/

Although the number of modified files are huge, the change is simply 
moving the scattered ICU sources in various locations under 
jdk.internal.icu package, keeping the original ICU's source tree structure.

Naoto

From srl at icu-project.org  Fri Jan 10 22:26:25 2020
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 10 Jan 2020 14:26:25 -0800
Subject:  [15] RFR: 8174270: Consolidate ICU sources in one
 location
In-Reply-To: 
References: 
Message-ID: <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>

in Norm2AllModes.java and UBiDiProps.java  and UCharacterProperty.java the stub name (icudt64b) should be calculated from the version number.  At least put ?icudt64b? in one place and refer to it.

OR keep the data file names unversioned, such as src/java.base/share/classes/jdk/internal/icu/impl/data/nfc.nrm

otherwise looks good

--
Steven R. Loomis | @srl295 | git.io/srl295



> El ene. 10, 2020, a las 2:02 p. m., naoto.sato at oracle.com escribi?:
> 
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8174270
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
> 
> Although the number of modified files are huge, the change is simply moving the scattered ICU sources in various locations under jdk.internal.icu package, keeping the original ICU's source tree structure.
> 
> Naoto


From huizhe.wang at oracle.com  Fri Jan 10 22:57:48 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 10 Jan 2020 14:57:48 -0800
Subject: [15] RFR: 8174270: Consolidate ICU sources in one location
In-Reply-To: 
References: 
Message-ID: <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>

Is there a reason why uidna.spp was left out of the move?

-Joe

On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8174270
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>
> Although the number of modified files are huge, the change is simply 
> moving the scattered ICU sources in various locations under 
> jdk.internal.icu package, keeping the original ICU's source tree 
> structure.
>
> Naoto


From naoto.sato at oracle.com  Sat Jan 11 00:02:57 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 16:02:57 -0800
Subject:  [15] RFR: 8174270: Consolidate ICU sources in one
 location
In-Reply-To: <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>
References: 
 <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>
Message-ID: <835cc98d-fa1c-9e7d-c1b9-0a5e075dd683@oracle.com>

Hi Steven,

On 1/10/20 2:26 PM, Steven R. Loomis wrote:
> in?Norm2AllModes.java and?UBiDiProps.java ?and?UCharacterProperty.java 
> the stub name (icudt64b) should be calculated from the version number. 
>  ?At least put ?icudt64b? in one place and refer to it.

Good point. Modified as suggested:

https://cr.openjdk.java.net/~naoto/8174270/webrev.01/

Naoto

> 
> OR keep the data file names unversioned, such 
> as?src/java.base/share/classes/jdk/internal/icu/impl/data/nfc.nrm
> 
> otherwise looks good
> 
> --
> Steven R. Loomis | @srl295 | git.io/srl295 
> 
> 
> 
>> El ene. 10, 2020, a las 2:02 p. m., naoto.sato at oracle.com 
>>  escribi?:
>>
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>
>> Although the number of modified files are huge, the change is simply 
>> moving the scattered ICU sources in various locations under 
>> jdk.internal.icu package, keeping the original ICU's source tree 
>> structure.
>>
>> Naoto
> 

From naoto.sato at oracle.com  Sat Jan 11 00:04:22 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 16:04:22 -0800
Subject: [15] RFR: 8174270: Consolidate ICU sources in one location
In-Reply-To: <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
References: 
 <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
Message-ID: 

Hi Joe,

That data file seems no longer included in the ICU4J package (as of 
64.2), thus I left it as it is.

Naoto

On 1/10/20 2:57 PM, Joe Wang wrote:
> Is there a reason why uidna.spp was left out of the move?
> 
> -Joe
> 
> On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>
>> Although the number of modified files are huge, the change is simply 
>> moving the scattered ICU sources in various locations under 
>> jdk.internal.icu package, keeping the original ICU's source tree 
>> structure.
>>
>> Naoto
> 

From john.r.rose at oracle.com  Sat Jan 11 01:23:50 2020
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 10 Jan 2020 17:23:50 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
Message-ID: 

On Jan 10, 2020, at 10:47 AM, Remi Forax  wrote:

> Seem to be a JIT bug to me,
> the fields of Set12 are declared final not @Stable (even if the field storing the instanceof of Set&2 itself is marked @Stable) so there is no reason not not let the constant folding happen.

It?s part of the contract of @Stable that default values (null) are not
inlined.  The reason for this is that some @Stable variables are lazy,
and the JIT needs to avoid assuming that default values stay that
way forever.

So, Claes is right that the empty slots need filling with a non-default
(non-null) value.

I think I?d prefer to see the following filler value rather `this`:

private static final EMPTY = new Object();

It might make escape analysis more robust if we don?t have objects
randomly storing pointer to themselves.

That value `SALT >= 0` inverts regularly every four seconds,
doesn?t it?  Not very salty, that.  I suggest adding a multiply to
make that sign bit more spicy:

         long nt = System.nanoTime();
         nt *=  0x243F_6A88_85A3_08D3L;  // a slice of pi
         SALT = (int)((nt >>> 32) ^ nt);
        REVERSE = SALT >= 0;

The hex number is the fractional part of pi (in hex).
Any arbitrary odd number with a balance of 1?s and 0?s will mix
things up well enough to produce an irregularly varying sign bit.
Using a well-known number makes it obvious there?s nothing
up our sleeve.

? John

P.S.  Not for this change set, but such salty values should be
derived from an optionally specified seed value, so JVM executions
can be made reproducible.  Could be a diagnostic flag:

    java -XX:+UnlockDiagnosticVMOptions -XX:VMSaltSeed=42

The salt seed would be initialized from the nanotime or some such.


From claes.redestad at oracle.com  Sat Jan 11 02:48:35 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 11 Jan 2020 03:48:35 +0100
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: 
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>

Hi,

On 2020-01-11 02:23, John Rose wrote:
> On Jan 10, 2020, at 10:47 AM, Remi Forax  > wrote:
> 
>> Seem to be a JIT bug to me,
>> the fields of Set12 are declared final not @Stable (even if the field 
>> storing the instanceof of Set&2 itself is marked @Stable) so there is 
>> no reason not not let the constant folding happen.
> 
> It?s part of the contract of @Stable that default values (null) are not
> inlined. ?The reason for this is that some @Stable variables are lazy,
> and the JIT needs to avoid assuming that default values stay that
> way forever.
> 
> So, Claes is right that the empty slots need filling with a non-default
> (non-null) value.
> 
> I think I?d prefer to see the following filler value rather `this`:
> 
> private static final EMPTY = new Object(); >
> It might make escape analysis more robust if we don?t have objects
> randomly storing pointer to themselves.

this was actually what I did in my first stab at this. :-) Also why I
needed to fiddle with the archiving state: the EMPTY marker needs to be
archived to retain identity (this is why we need to archive the
EMPTY_MAP/SET/.., too).

Stuart suggested the 'this' approach, which seemed to perform just as
well in microbenchmarks. You're probably right in your suspicion that it
might interact subtly with EA in more complex scenarios, so going back
to an EMPTY marker object might be the safer route here.

> 
> That value `SALT >= 0` inverts regularly every four seconds,
> doesn?t it? ?Not very salty, that. ?I suggest adding a multiply to
> make that sign bit more spicy:
> 
>  ? ? ? ? ?long nt = System.nanoTime();
>  ? ? ? ? ?nt *= ?0x243F_6A88_85A3_08D3L; ?// a slice of pi
>  ? ? ? ? ?SALT = (int)((nt >>> 32) ^ nt);
>  ? ? ? ? REVERSE = SALT >= 0;
> 
> The hex number is the fractional part of pi (in hex).
> Any arbitrary odd number with a balance of 1?s and 0?s will mix
> things up well enough to produce an irregularly varying sign bit.
> Using a well-known number makes it obvious there?s nothing
> up our sleeve.

Yes. The XOR seems pointless with this approach, but some shifting
might be good.

> 
> ? John
> 
> P.S. ?Not for this change set, but such salty values should be
> derived from an optionally specified seed value, so JVM executions
> can be made reproducible. ?Could be a diagnostic flag:
> 
>  ? ? java -XX:+UnlockDiagnosticVMOptions -XX:VMSaltSeed=42
> 
> The salt seed would be initialized from the nanotime or some such.

This'd be useful in some cases.

/Claes

From john.r.rose at oracle.com  Sat Jan 11 03:19:04 2020
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 10 Jan 2020 19:19:04 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
Message-ID: <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>

On Jan 10, 2020, at 6:48 PM, Claes Redestad  wrote:
> 
> Yes. The XOR seems pointless with this approach, but some shifting
> might be good.

A single multiply mixes the bits of its inputs.  If one input is
?random? or ?white? (50% 1?s irregularly spaced) then the output
will probably look similar.  The output bits are not equally mixed,
though:  The LSB depends only on two bits of the input, and the
MSB (barring rare carry-outs) depends mostly on two other bits
of the input.  But the middle bits depend on most of the input bits.

So, given the goal of making a very simple, good-enough mixing
expression to get a 32-bit salt, this one is relatively good:

   long COLOR = 0x243F_6A88_85A3_08D3L;  // pi slice
   long SEED = System.nanoTime();  // or command line value
   int SALT = (int)( (COLOR * SEED) >> 16 );  // avoid LSB and MSB

In the longer term, I think the JVM should provide salt values
both for itself and (a few) core libs., and should allow those values
to be (partially) configured from the command line.  (Crash dumps
should report the SEED values used for reproducing the error.)
Given such a facility, it would be reasonable to upgrade it to use
better quality entropy sources and hashing (maybe optionally
crypto-quality, though I have reservations about that).  That
would make the variable behaviors unpredictable in practice.
Except when they are intentionally configured to be predictable.
An algorithm like xxHash would be a good starting point; it?s
cheap and salty.

? John

From huizhe.wang at oracle.com  Sat Jan 11 04:21:49 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 10 Jan 2020 20:21:49 -0800
Subject: [15] RFR: 8174270: Consolidate ICU sources in one location
In-Reply-To: 
References: 
 <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
 
Message-ID: <39bfd4c6-fe4f-3967-9fb8-5ba9bcd7e804@oracle.com>

I see. It's all good to me then.

Best,
Joe

On 1/10/20 4:04 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> That data file seems no longer included in the ICU4J package (as of 
> 64.2), thus I left it as it is.
>
> Naoto
>
> On 1/10/20 2:57 PM, Joe Wang wrote:
>> Is there a reason why uidna.spp was left out of the move?
>>
>> -Joe
>>
>> On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>>
>>> Although the number of modified files are huge, the change is simply 
>>> moving the scattered ICU sources in various locations under 
>>> jdk.internal.icu package, keeping the original ICU's source tree 
>>> structure.
>>>
>>> Naoto
>>


From jai.forums2013 at gmail.com  Sat Jan 11 09:51:25 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 11 Jan 2020 15:21:25 +0530
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
Message-ID: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>

Can I please get a review and a sponsor for a patch which fixes
JDK-7143743[1]? The patch is hosted as a webrev at [2].

As noted in the JBS issue, the ZipFileSystem, even after being closed
can end up holding on to large amounts of memory. The root of the issue
is the "inodes" map which is maintained by the
jdk.nio.zipfs.ZipFileSystem class. This map holds on to "IndexNode"(s).
IndexNode(s) are added/updated/removed to/from this map as and when the
filesystem is used to add/update/remove files. One such IndexNode type
is the jdk.nio.zipfs.ZipFileSystem$Entry type and an instance of this
type will actually hold on to the underlying data of the file as a
byte[] (the member is called "bytes").

Once the instance of the ZipFileSystem is closed, this "inodes" map
isn't cleared and as a result, potentially, large amounts of data can
end up staying in the jdk.nio.zipfs.ZipFileSystem$Entry.bytes member(s).

The commit here fixes that issue by simply clearing the "inodes" map in
the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
of the "inodes" map and from what I see, it's usage in various places is
guarded by "ensureOpen" checks, which means that once the ZipFileSystem
instance is closed, the contents of these "inodes" map is no longer
relevant and hence clearing it shouldn't cause any issues.

Given the nature of this issue, I haven't included a jtreg test for this
change. However, I have run the existing ZipFSTester.java testcase to
make sure no obvious regressions are introduced. That test passed
successfully with this change.

A program (a slightly modified version of the one available in the JBS
issue) is made available at the end of this mail to reproduce this issue
(and verify the fix). To run this program, pass it a path to a directory
(as first argument) which contains files with large sizes and a path to
a (non-existent) zip file that needs to be created (as second argument).

In my manual testing, I used a directory with 3 files of a total size of
around 831MB:

$ pwd

/home/me/testdir

$ ls -lh

total 1702360
-rw-r--r--@ 1 jaikiran? 184M Oct 29 09:52 a
-rw-r--r--@ 1 jaikiran? 258M Oct? 9 19:52 b
-rw-r--r--@ 1 jaikiran? 368M Dec 26 08:30 c

$ du -sh

831M .

Running the program resulted in:

$ java ZipFSLeak.java /home/me/testdir/ before-fix.zip

Zipping /home/me/testdir/ to before-fix.zip
Copied a total of 849617826 bytes from /home/me/testdir/
Running some GC ...
Memory in use (after GC): 853071256

(notice that the memory in use at the end of the program, after the
ZipFileSystem has been closed a while back, stays extremely high and
almost equal to the total bytes of the files that were added to the
ZipFileSystem).

Now after the fix, running the same program against the same directory
results in:

$ java ZipFSLeak.java /home/me/testdir/ after-fix.zip

Zipping /home/me/testdir/ to after-fix.zip
Copied a total of 849617826 bytes from /home/me/testdir/
Running some GC ...
Memory in use (after GC): 4769904

(notice the drastic improvement in the memory usage)

Following is the program used to reproduce the issue:


import java.io.IOException;
import java.net.URI;
import java.nio.file.DirectoryStream;
import java.nio.file.FileSystem;
import java.nio.file.FileSystems;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.HashMap;
import java.util.Map;


public class ZipFSLeak {

??? public static void main(String[] args) throws IOException {
??? ??? // first arg is dir contatining (preferably) files of large sizes
??? ??? final Path srcDir = FileSystems.getDefault().getPath(args[0]);
??? ??? // second arg is path to the target zip which will be created by
this program
??? ??? final Path targetZip = FileSystems.getDefault().getPath(args[1]);
??? ??? System.out.println("Zipping " + srcDir + " to " + targetZip);

??? ??? final FileSystem zip = createZipFileSystem(targetZip, true);
??? ??? long totalCopiedSize = 0;
??? ??? try (final DirectoryStream dirStream =
Files.newDirectoryStream(srcDir);
??? ??? ??? ??? var zipFS = zip) {

??? ??? ??? final Path zipRoot = zipFS.getPath("/");
??? ??? ??? for (Path path : dirStream) {
??? ??? ??? ??? Files.copy(path,
zipRoot.resolve(path.getFileName().toString()));
??? ??? ??? ??? totalCopiedSize += path.toFile().length();
??? ??? ??? }
??? ??? }

??? ??? System.out.println("Copied a total of " + totalCopiedSize + "
bytes from " + srcDir);
??? ??? System.out.println("Running some GC ...");
??? ??? // run some GC
??? ??? for (int i = 0; i < 10; i++) {
??? ??? ??? Runtime.getRuntime().gc();
??? ??? }
??? ??? System.out.println("Memory in use (after GC): " +
(Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()));
??? }

??? private static FileSystem createZipFileSystem(Path path, boolean
create) throws IOException {
??? ??? final URI uri = URI.create("jar:file:" + path.toUri().getPath());

??? ??? final Map env = new HashMap<>();
??? ??? if (create) {
??? ??? ??? env.put("create", "true");
??? ??? }
??? ??? return FileSystems.newFileSystem(uri, env);

??? }
}


[1] https://bugs.openjdk.java.net/browse/JDK-7143743

[2] https://cr.openjdk.java.net/~jpai/webrev/7143743/1/webrev/

P.S: This affects all prominent Java versions since Java 8 (that's the
least one I tested) and not just the latest upstream.

-Jaikiran



From Alan.Bateman at oracle.com  Sat Jan 11 10:07:28 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 11 Jan 2020 10:07:28 +0000
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
Message-ID: 

On 11/01/2020 09:51, Jaikiran Pai wrote:
> :
>
> The commit here fixes that issue by simply clearing the "inodes" map in
> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
> of the "inodes" map and from what I see, it's usage in various places is
> guarded by "ensureOpen" checks, which means that once the ZipFileSystem
> instance is closed, the contents of these "inodes" map is no longer
> relevant and hence clearing it shouldn't cause any issues.
>
Clearing the inodes map should be okay for cases where something is 
holding a reference to a closed zip file system. However, you should 
look at beginWrite/endWrite so that all access to the map is 
consistently synchronized.

-Alan.

From jai.forums2013 at gmail.com  Sat Jan 11 10:24:16 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 11 Jan 2020 15:54:16 +0530
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
Message-ID: 

Hello Alan,

On 11/01/20 3:37 pm, Alan Bateman wrote:
> On 11/01/2020 09:51, Jaikiran Pai wrote:
>> :
>>
>> The commit here fixes that issue by simply clearing the "inodes" map in
>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
>> of the "inodes" map and from what I see, it's usage in various places is
>> guarded by "ensureOpen" checks, which means that once the ZipFileSystem
>> instance is closed, the contents of these "inodes" map is no longer
>> relevant and hence clearing it shouldn't cause any issues.
>>
> Clearing the inodes map should be okay for cases where something is
> holding a reference to a closed zip file system. However, you should
> look at beginWrite/endWrite so that all access to the map is
> consistently synchronized.
>
Thank you very much for that input - I hadn't considered the concurrency
aspect of it. Based on your input and after looking at the usage of the
"inodes", I have now updated the patch to use proper locks during the
clearing of the inodes. The updated webrev is available at
https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/

-Jaikiran


From forax at univ-mlv.fr  Sat Jan 11 11:59:12 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 11 Jan 2020 12:59:12 +0100 (CET)
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: 
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <1802618548.1104761.1578743952268.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" 
> ?: "Remi Forax" 
> Cc: "Claes Redestad" , "core-libs-dev"
> 
> Envoy?: Samedi 11 Janvier 2020 02:23:50
> Objet: Re: RFR: 8236850: Operations on constant List/Set.of(element) instances
> does not consistently constant fold

> On Jan 10, 2020, at 10:47 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Seem to be a JIT bug to me,
>> the fields of Set12 are declared final not @Stable (even if the field storing
>> the instanceof of Set&2 itself is marked @Stable) so there is no reason not not
>> let the constant folding happen.

> It?s part of the contract of @Stable that default values (null) are not
> inlined. The reason for this is that some @Stable variables are lazy,
> and the JIT needs to avoid assuming that default values stay that
> way forever.

My bad, reading the patch i've not seen that the fields were both annotated with final *and* @Shared. 

So it's another occurrence of final not meaning true final but instead of having an annotation @TrueScottmanFinal, 
this patch try to use @Stable but it doesn't work if the field is null, so the code is twisted to consider 'this' as a marker for null. 

In my opinion, it's better to introduce an annotation @TrueScottmanFinal instead of using @Stable in a way it was not designed to be used. 

cheers, 
R?mi 

From claes.redestad at oracle.com  Sat Jan 11 15:11:20 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 11 Jan 2020 16:11:20 +0100
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <1802618548.1104761.1578743952268.JavaMail.zimbra@u-pem.fr>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <1802618548.1104761.1578743952268.JavaMail.zimbra@u-pem.fr>
Message-ID: 



On 2020-01-11 12:59, forax at univ-mlv.fr wrote:
> 
> 
> ------------------------------------------------------------------------
> 
>     *De: *"John Rose" 
>     *?: *"Remi Forax" 
>     *Cc: *"Claes Redestad" , "core-libs-dev"
>     
>     *Envoy?: *Samedi 11 Janvier 2020 02:23:50
>     *Objet: *Re: RFR: 8236850: Operations on constant
>     List/Set.of(element) instances does not consistently constant fold
> 
>     On Jan 10, 2020, at 10:47 AM, Remi Forax      > wrote:
> 
>         Seem to be a JIT bug to me,
>         the fields of Set12 are declared final not @Stable (even if the
>         field storing the instanceof of Set&2 itself is marked @Stable)
>         so there is no reason not not let the constant folding happen.
> 
> 
>     It?s part of the contract of @Stable that default values (null) are not
>     inlined. ?The reason for this is that some @Stable variables are lazy,
>     and the JIT needs to avoid assuming that default values stay that
>     way forever.
> 
> 
> My bad, reading the patch i've not seen that the fields were both 
> annotated with final *and* @Shared.
> 
> So it's another occurrence of final not meaning true final but instead 
> of having an annotation @TrueScottmanFinal,
> this patch try to use @Stable but it doesn't work if the field is null, 
> so the code is twisted to consider 'this' as a marker for null.

Interestingly, -XX:+UnlockExperimentalVMOptions
-XX:+TrustFinalNonStaticFields does not help here: It seems null
"constants" are treated specially even in this case.

> 
> In my opinion, it's better to introduce an annotation @TrueScottmanFinal 
> instead of using @Stable in a way it was not designed to be used.

While something explicit like this is probably better, I don't think we
should hold back improvements in the short term, even hacky ones like
this. Especially when backing out the hack would be trivial once a
better way of doing things is invented (and the cost of forgetting about
it is low or non-existent).

/Claes

From lance.andersen at oracle.com  Sat Jan 11 20:56:22 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 11 Jan 2020 15:56:22 -0500
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
Message-ID: <5278C64C-9BF1-4616-BA7E-67771FD3AB3D@oracle.com>

I am happy to sponsor this next week after providing time for additional review feedback and also sanity check it via Mach5

Best
Lance

> On Jan 11, 2020, at 5:24 AM, Jaikiran Pai  wrote:
> 
> Hello Alan,
> 
> On 11/01/20 3:37 pm, Alan Bateman wrote:
>> On 11/01/2020 09:51, Jaikiran Pai wrote:
>>> :
>>> 
>>> The commit here fixes that issue by simply clearing the "inodes" map in
>>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
>>> of the "inodes" map and from what I see, it's usage in various places is
>>> guarded by "ensureOpen" checks, which means that once the ZipFileSystem
>>> instance is closed, the contents of these "inodes" map is no longer
>>> relevant and hence clearing it shouldn't cause any issues.
>>> 
>> Clearing the inodes map should be okay for cases where something is
>> holding a reference to a closed zip file system. However, you should
>> look at beginWrite/endWrite so that all access to the map is
>> consistently synchronized.
>> 
> Thank you very much for that input - I hadn't considered the concurrency
> aspect of it. Based on your input and after looking at the usage of the
> "inodes", I have now updated the patch to use proper locks during the
> clearing of the inodes. The updated webrev is available at
> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ 
> 
> -Jaikiran

 
  
 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 jai.forums2013 at gmail.com  Sun Jan 12 03:27:31 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 12 Jan 2020 08:57:31 +0530
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: <5278C64C-9BF1-4616-BA7E-67771FD3AB3D@oracle.com>
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
 <5278C64C-9BF1-4616-BA7E-67771FD3AB3D@oracle.com>
Message-ID: <326a43ed-9c67-89ff-b46e-b66e4985d8ea@gmail.com>

Thank you Lance.

-Jaikiran

On 12/01/20 2:26 am, Lance Andersen wrote:
> I am happy to sponsor this next week after providing time for
> additional review feedback and also sanity check it via Mach5
>
> Best
> Lance
>
>> On Jan 11, 2020, at 5:24 AM, Jaikiran Pai > > wrote:
>>
>> Hello Alan,
>>
>> On 11/01/20 3:37 pm, Alan Bateman wrote:
>>> On 11/01/2020 09:51, Jaikiran Pai wrote:
>>>> :
>>>>
>>>> The commit here fixes that issue by simply clearing the "inodes" map in
>>>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the
>>>> usage
>>>> of the "inodes" map and from what I see, it's usage in various
>>>> places is
>>>> guarded by "ensureOpen" checks, which means that once the ZipFileSystem
>>>> instance is closed, the contents of these "inodes" map is no longer
>>>> relevant and hence clearing it shouldn't cause any issues.
>>>>
>>> Clearing the inodes map should be okay for cases where something is
>>> holding a reference to a closed zip file system. However, you should
>>> look at beginWrite/endWrite so that all access to the map is
>>> consistently synchronized.
>>>
>> Thank you very much for that input - I hadn't considered the concurrency
>> aspect of it. Based on your input and after looking at the usage of the
>> "inodes", I have now updated the patch to use proper locks during the
>> clearing of the inodes. The updated webrev is available at
>> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/
>>
>> -Jaikiran
>
> 
> 
> 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 tech.meshter at gmail.com  Sun Jan 12 04:26:26 2020
From: tech.meshter at gmail.com (Chris T)
Date: Sat, 11 Jan 2020 23:26:26 -0500
Subject: question about String.stripIndent method
Message-ID: 

Hi,

I am working on an educational material about OpenJDK 14. Downloaded the
code, compiled it and while "playing" with the new features I found
something that seems to be inconsistent (maybe a bug?). So here we go:

I defined this method:
  public void questionToOpenJDKPossibleBugOnStripIdent() {

    String endsWithNewLine = """
        \s\s\s\s\s<- this line starts with 5 blank spaces.
        \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
                """;
    System.out.println("The string ending with new lines looks like this:");
    System.out.println(endsWithNewLine);

    System.out.println();
    System.out.println("If we call stripIndent, the white spaces are not
eliminated (maybe I misunderstand the concept of incidental white space):");
    System.out.println(endsWithNewLine.stripIndent());

    String endsWithAsterisk = """
        \s\s\s\s\s<- this line starts with 5 blank spaces.
        \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
                *""";
    System.out.println("The string ending with asterisk looks like this:");
    System.out.println(endsWithAsterisk);

    System.out.println();
    System.out.println("If we call stripIndent, the white spaces ARE
eliminated (this seems to be inconsistent with the previous behaviour):");
    System.out.println(endsWithAsterisk.stripIndent());
  }

If I run the code above, I get this output:
The string ending with new lines looks like this:
     <- this line starts with 5 blank spaces.
     <- count again: 1, 2, 3, 4, 5


If we call stripIndent, the white spaces are not eliminated (maybe I
misunderstand the concept of incidental white space):
     <- this line starts with 5 blank spaces.
     <- count again: 1, 2, 3, 4, 5

The string ending with asterisk looks like this:
     <- this line starts with 5 blank spaces.
     <- count again: 1, 2, 3, 4, 5
        *

If we call stripIndent, the white spaces ARE eliminated (this seems to be
inconsistent with the previous behaviour):
<- this line starts with 5 blank spaces.
<- count again: 1, 2, 3, 4, 5
   *

I looked over the stripIdent code and found this line (which, after
debugging, turns out that "blocks" the entire indentation process):
boolean optOut = lastChar == '\n' || lastChar == '\r';

Can somebody explain me what am I missing? Maybe there is an area din the
JEP documentation that clarifies this and I didn't see nor actively paid
attention to?

Thanks!
  Chris T

From shade at redhat.com  Sun Jan 12 11:08:48 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Sun, 12 Jan 2020 12:08:48 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <93f0dfb4-0ba2-de79-ae33-60b306b64e8d@oracle.com>
References: 
 <5E016C66.4040502@oracle.com>
 
 <81420fea-1966-0953-2c34-8d531ca217e2@redhat.com>
 <50fe369d-7e84-d71b-84c6-3db5684fa1c5@redhat.com>
 
 <97c4da2d-a664-67fa-20ba-949cd196b241@redhat.com>
 
 <7285ec8b-573c-52f8-5a0d-dd37598dfc7b@redhat.com>
 <76141aa4-5b8f-08b6-0343-63f68f63a074@redhat.com>
 <93f0dfb4-0ba2-de79-ae33-60b306b64e8d@oracle.com>
Message-ID: <0877aa47-31ac-1218-7a86-e9c5d83d6c6c@redhat.com>

On 1/10/20 10:24 AM, Alan Bateman wrote:
> On 10/01/2020 09:11, Aleksey Shipilev wrote:
>> :
>> No other takers? I would then push this trivial patch for Alex under my single review.
>>
> I think it's okay but would be nice if one of the jpackager maintainers 
> jumped in.

Thanks!

It had been weeks (granted, over the EOY holidays) without clear acks from jpackager maintainers.
With jdk14 RDP2 looming over us, I don't think we can wait any longer. I would appreciate if you can
nudge some people internally to make this happen.

-- 
-Aleksey


From shade at redhat.com  Sun Jan 12 11:15:52 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Sun, 12 Jan 2020 12:15:52 +0100
Subject: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c
Message-ID: <28e68b3a-1d3f-7268-1860-1d0381292293@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8236920

Fix:
  https://cr.openjdk.java.net/~shade/8236920/webrev.01/

This breaks x86_32 test builds. I would like to have this fix in 14.

Testing: Linux {x86_64, x86_32} builds; java/foreign (still passes on x86_64; still fails on x86_32,
seems unrelated to this build breakage); jdk14-submit (still stuck somewhere!)

-- 
Thanks,
-Aleksey


From shade at redhat.com  Sun Jan 12 19:33:46 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Sun, 12 Jan 2020 20:33:46 +0100
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: <9fa031ce-3a98-36e6-10b4-599104d7d74a@oracle.com>
References: 
 
 <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>
 
 <943b0890-ad12-59d0-d18e-974c1dc797bd@arm.com>
 <9fa031ce-3a98-36e6-10b4-599104d7d74a@oracle.com>
Message-ID: <80f0d55c-e598-1aad-b743-87f1e64c72b7@redhat.com>

On 1/9/20 1:01 PM, Maurizio Cimadamore wrote:
> On 09/01/2020 08:10, Nick Gasson wrote:
>> http://cr.openjdk.java.net/~ngasson/8236634/webrev.1/index.html

Looks fine.

The long/doubleHandle changes probably clash with JDK-8236939.
The test changes probably benefit from cleaner accessors like in JDK-8236920.

But whatever, having any fix in jdk14 that unbreaks 32-bit platforms before RDP2 hits is good, so I
don't mind the patch going in in this form.

-- 
Thanks,
-Aleksey


From john.r.rose at oracle.com  Sun Jan 12 20:56:01 2020
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 12 Jan 2020 12:56:01 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <1802618548.1104761.1578743952268.JavaMail.zimbra@u-pem.fr>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <1802618548.1104761.1578743952268.JavaMail.zimbra@u-pem.fr>
Message-ID: <3137BFAB-E943-4E6F-8E1F-6B157DA991AD@oracle.com>

On Jan 11, 2020, at 3:59 AM, forax at univ-mlv.fr wrote:
> In my opinion, it's better to introduce an annotation @TrueScottmanFinal instead of using @Stable in a way it was not designed to be used.

And even better than that is fixing ?final? so it?s really final.

But @TrueScottmanFinal is surprisingly harder than @Stable.
The problem is that the JIT needs to distinguish two states
that look very similar:  1. The final variable is freshly created
and hasn?t been initialized yet, and 2. The final variable has
been initialized (redundantly) to its default value.

The design of @Stable neatly steps around this problem by
defining the contract to be the same in both cases.  A real
fix to ?final?, or an intermediate @TrueScottmanFinal, seems
to require new mechanisms in the JVM for tracking initialization
(at least, initialization to default).  Either that or else we need
to convince ourselves that it?s OK for the JIT to capture the
default value from an uninitialized final and hold onto it
forever, which I don?t think works.  Or a hybrid scheme
where the JIT captures a default and polls for updates,
somehow, at some rate.  The problem with these latter
solutions is that (a) they probably will cause bugs, and (b)
they are probably (but not certainly) illegal in the JMM,
since the JMM does not clearly model the effects of threads
re-using JIT-ted code.

So, coming up from that deep dive, the result is that we
are stuck with @Stable for the present, not because it is
the perfect design for the job, but it is the best we can do
without adding complicated tracking to JIT constants.
It?s served us well, and will continue to do so until we do
that extra work.

? John

From james.laskey at oracle.com  Mon Jan 13 01:30:13 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Sun, 12 Jan 2020 21:30:13 -0400
Subject: question about String.stripIndent method
In-Reply-To: 
References: 
Message-ID: <86DAD1B1-FA48-45A1-AF21-CC9A967B91C8@oracle.com>

Chris,

String::stripIndent might not be the routine you are looking for. It is provided to duplicate the actions performed by the compiler when processing a Text Block. To use String::stripIndent as a method to strip indentation in the way you might expect you might have to massage the input string.

Note: using ????? to represent leading spaces 

To understand what is going on, reverse the process and image what the string looked like as a Text Block.

The first case goes like this.

String endsWithNewLine = """
\s\s\s\s\s<- this line starts with 5 blank spaces.
\s\s\s\s\s<- count again: 1, 2, 3, 4, 5
????????""";

String endsWithNewLineAfterStripIndent = """
?????<- this line starts with 5 blank spaces.
?????<- count again: 1, 2, 3, 4, 5
""";

In this case the first two lines start with 5 spaces and the last line has zero spaces because we stripped trailing spaces.

So applying the rules, the last line dominates and the indentation doesn't change.

?????<- this line starts with 5 blank spaces.
?????<- count again: 1, 2, 3, 4, 5


The last line still has zero spaces.

The second case goes like this.

String endsWithAsterisk = """
?????\s\s\s\s\s<- this line starts with 5 blank spaces.
?????\s\s\s\s\s<- count again: 1, 2, 3, 4, 5
????????*""";

String endsWithAsteriskAfterStripIndent = """
<- this line starts with 5 blank spaces.
<- count again: 1, 2, 3, 4, 5
???*""";

Since there was no stripping of all characters on the last line, first two lines dominate and we get

<- this line starts with 5 blank spaces.
<- count again: 1, 2, 3, 4, 5
???*

So it all comes down to the last line being blank or not blank. A blank line becomes an empty line due to stripping of trailing blanks.

Cheers,

-- Jim



> On Jan 12, 2020, at 12:26 AM, Chris T  wrote:
> 
> Hi,
> 
> I am working on an educational material about OpenJDK 14. Downloaded the
> code, compiled it and while "playing" with the new features I found
> something that seems to be inconsistent (maybe a bug?). So here we go:
> 
> I defined this method:
>  public void questionToOpenJDKPossibleBugOnStripIdent() {
> 
>    String endsWithNewLine = """
>        \s\s\s\s\s<- this line starts with 5 blank spaces.
>        \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
>                """;
>    System.out.println("The string ending with new lines looks like this:");
>    System.out.println(endsWithNewLine);
> 
>    System.out.println();
>    System.out.println("If we call stripIndent, the white spaces are not
> eliminated (maybe I misunderstand the concept of incidental white space):");
>    System.out.println(endsWithNewLine.stripIndent());
> 
>    String endsWithAsterisk = """
>        \s\s\s\s\s<- this line starts with 5 blank spaces.
>        \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
>                *""";
>    System.out.println("The string ending with asterisk looks like this:");
>    System.out.println(endsWithAsterisk);
> 
>    System.out.println();
>    System.out.println("If we call stripIndent, the white spaces ARE
> eliminated (this seems to be inconsistent with the previous behaviour):");
>    System.out.println(endsWithAsterisk.stripIndent());
>  }
> 
> If I run the code above, I get this output:
> The string ending with new lines looks like this:
>     <- this line starts with 5 blank spaces.
>     <- count again: 1, 2, 3, 4, 5
> 
> 
> If we call stripIndent, the white spaces are not eliminated (maybe I
> misunderstand the concept of incidental white space):
>     <- this line starts with 5 blank spaces.
>     <- count again: 1, 2, 3, 4, 5
> 
> The string ending with asterisk looks like this:
>     <- this line starts with 5 blank spaces.
>     <- count again: 1, 2, 3, 4, 5
>        *
> 
> If we call stripIndent, the white spaces ARE eliminated (this seems to be
> inconsistent with the previous behaviour):
> <- this line starts with 5 blank spaces.
> <- count again: 1, 2, 3, 4, 5
>   *
> 
> I looked over the stripIdent code and found this line (which, after
> debugging, turns out that "blocks" the entire indentation process):
> boolean optOut = lastChar == '\n' || lastChar == '\r';
> 
> Can somebody explain me what am I missing? Maybe there is an area din the
> JEP documentation that clarifies this and I didn't see nor actively paid
> attention to?
> 
> Thanks!
>  Chris T


From sundararajan.athijegannathan at oracle.com  Mon Jan 13 02:50:56 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 13 Jan 2020 08:20:56 +0530
Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java
 time out
In-Reply-To: 
References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
 <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com>
 
Message-ID: 

Hi Naoto,

Thanks. I'll make those changes and push.

-Sundar

On 10/01/20 7:20 pm, naoto.sato at oracle.com wrote:
> Hi Sundar,
>
> You might want to add the bug id in the regression test, and change 
> the copyright year to 2020.
>
> Otherwise, looks good.
>
> Naoto
>
> On 1/10/20 5:07 AM, sundararajan.athijegannathan at oracle.com wrote:
>> Adding core-libs-dev.
>>
>> -Sundar
>>
>> On 10/01/20 11:33 am, sundararajan.athijegannathan at oracle.com wrote:
>>> Please review.
>>>
>>> Not really a fix - but increasing the default timeout for the test.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222098
>>>
>>> Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/
>>>
>>> Thanks,
>>>
>>> -Sundar
>>>

From tech.meshter at gmail.com  Mon Jan 13 04:48:58 2020
From: tech.meshter at gmail.com (Chris T)
Date: Sun, 12 Jan 2020 23:48:58 -0500
Subject: question about String.stripIndent method
In-Reply-To: <86DAD1B1-FA48-45A1-AF21-CC9A967B91C8@oracle.com>
References: 
 <86DAD1B1-FA48-45A1-AF21-CC9A967B91C8@oracle.com>
Message-ID: 

Jim, this was the information that somehow I was not able to wrap my mind
around:

"So it all comes down to the last line being blank or not blank. A blank
line becomes an empty line due to stripping of trailing blanks."

Any character inserted on the last line (ending with """) will actually
automatically make the whole string fill up with space till that character.
Thank you so much for the clarification!

All the best!
  Chris

On Sun, Jan 12, 2020 at 8:30 PM Jim Laskey  wrote:

> Chris,
>
> String::stripIndent might not be the routine you are looking for. It is
> provided to duplicate the actions performed by the compiler when processing
> a Text Block. To use String::stripIndent as a method to strip indentation
> in the way you might expect you might have to massage the input string.
>
> Note: using ????? to represent leading spaces
>
> To understand what is going on, reverse the process and image what the
> string looked like as a Text Block.
>
> The first case goes like this.
>
> String endsWithNewLine = """
> \s\s\s\s\s<- this line starts with 5 blank spaces.
> \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
> ????????""";
>
> String endsWithNewLineAfterStripIndent = """
> ?????<- this line starts with 5 blank spaces.
> ?????<- count again: 1, 2, 3, 4, 5
> """;
>
> In this case the first two lines start with 5 spaces and the last line has
> zero spaces because we stripped trailing spaces.
>
> So applying the rules, the last line dominates and the indentation doesn't
> change.
>
> ?????<- this line starts with 5 blank spaces.
> ?????<- count again: 1, 2, 3, 4, 5
>
>
> The last line still has zero spaces.
>
> The second case goes like this.
>
> String endsWithAsterisk = """
> ?????\s\s\s\s\s<- this line starts with 5 blank spaces.
> ?????\s\s\s\s\s<- count again: 1, 2, 3, 4, 5
> ????????*""";
>
> String endsWithAsteriskAfterStripIndent = """
> <- this line starts with 5 blank spaces.
> <- count again: 1, 2, 3, 4, 5
> ???*""";
>
> Since there was no stripping of all characters on the last line, first two
> lines dominate and we get
>
> <- this line starts with 5 blank spaces.
> <- count again: 1, 2, 3, 4, 5
> ???*
>
> So it all comes down to the last line being blank or not blank. A blank
> line becomes an empty line due to stripping of trailing blanks.
>
> Cheers,
>
> -- Jim
>
>
>
> > On Jan 12, 2020, at 12:26 AM, Chris T  wrote:
> >
> > Hi,
> >
> > I am working on an educational material about OpenJDK 14. Downloaded the
> > code, compiled it and while "playing" with the new features I found
> > something that seems to be inconsistent (maybe a bug?). So here we go:
> >
> > I defined this method:
> >  public void questionToOpenJDKPossibleBugOnStripIdent() {
> >
> >    String endsWithNewLine = """
> >        \s\s\s\s\s<- this line starts with 5 blank spaces.
> >        \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
> >                """;
> >    System.out.println("The string ending with new lines looks like
> this:");
> >    System.out.println(endsWithNewLine);
> >
> >    System.out.println();
> >    System.out.println("If we call stripIndent, the white spaces are not
> > eliminated (maybe I misunderstand the concept of incidental white
> space):");
> >    System.out.println(endsWithNewLine.stripIndent());
> >
> >    String endsWithAsterisk = """
> >        \s\s\s\s\s<- this line starts with 5 blank spaces.
> >        \s\s\s\s\s<- count again: 1, 2, 3, 4, 5
> >                *""";
> >    System.out.println("The string ending with asterisk looks like
> this:");
> >    System.out.println(endsWithAsterisk);
> >
> >    System.out.println();
> >    System.out.println("If we call stripIndent, the white spaces ARE
> > eliminated (this seems to be inconsistent with the previous
> behaviour):");
> >    System.out.println(endsWithAsterisk.stripIndent());
> >  }
> >
> > If I run the code above, I get this output:
> > The string ending with new lines looks like this:
> >     <- this line starts with 5 blank spaces.
> >     <- count again: 1, 2, 3, 4, 5
> >
> >
> > If we call stripIndent, the white spaces are not eliminated (maybe I
> > misunderstand the concept of incidental white space):
> >     <- this line starts with 5 blank spaces.
> >     <- count again: 1, 2, 3, 4, 5
> >
> > The string ending with asterisk looks like this:
> >     <- this line starts with 5 blank spaces.
> >     <- count again: 1, 2, 3, 4, 5
> >        *
> >
> > If we call stripIndent, the white spaces ARE eliminated (this seems to be
> > inconsistent with the previous behaviour):
> > <- this line starts with 5 blank spaces.
> > <- count again: 1, 2, 3, 4, 5
> >   *
> >
> > I looked over the stripIdent code and found this line (which, after
> > debugging, turns out that "blocks" the entire indentation process):
> > boolean optOut = lastChar == '\n' || lastChar == '\r';
> >
> > Can somebody explain me what am I missing? Maybe there is an area din the
> > JEP documentation that clarifies this and I didn't see nor actively paid
> > attention to?
> >
> > Thanks!
> >  Chris T
>
>

From christoph.langer at sap.com  Mon Jan 13 06:56:47 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 Jan 2020 06:56:47 +0000
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
Message-ID: 

Hi,

I'm wondering whether we shouldn't just do "inodes = null;"? I guess this is cheaper and accesses to the inodes map on a closed filesystem object should not happen anyway (e.g. all is guarded by ensureOpen()). Other than that, the change looks fine.

Cheers
Christoph

> -----Original Message-----
> From: nio-dev  On Behalf Of Jaikiran
> Pai
> Sent: Samstag, 11. Januar 2020 11:24
> To: Alan Bateman ; nio-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider
> 
> Hello Alan,
> 
> On 11/01/20 3:37 pm, Alan Bateman wrote:
> > On 11/01/2020 09:51, Jaikiran Pai wrote:
> >> :
> >>
> >> The commit here fixes that issue by simply clearing the "inodes" map in
> >> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
> >> of the "inodes" map and from what I see, it's usage in various places is
> >> guarded by "ensureOpen" checks, which means that once the
> ZipFileSystem
> >> instance is closed, the contents of these "inodes" map is no longer
> >> relevant and hence clearing it shouldn't cause any issues.
> >>
> > Clearing the inodes map should be okay for cases where something is
> > holding a reference to a closed zip file system. However, you should
> > look at beginWrite/endWrite so that all access to the map is
> > consistently synchronized.
> >
> Thank you very much for that input - I hadn't considered the concurrency
> aspect of it. Based on your input and after looking at the usage of the
> "inodes", I have now updated the patch to use proper locks during the
> clearing of the inodes. The updated webrev is available at
> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/
> 
> -Jaikiran


From nick.gasson at arm.com  Mon Jan 13 07:35:46 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 13 Jan 2020 15:35:46 +0800
Subject: RFR: 8236634: Memory Access API tests fail on 32-bit
In-Reply-To: <80f0d55c-e598-1aad-b743-87f1e64c72b7@redhat.com>
References: 
 
 <94a4d437-99d4-6c40-7fca-8d0a1ff9e69e@arm.com>
 
 <943b0890-ad12-59d0-d18e-974c1dc797bd@arm.com>
 <9fa031ce-3a98-36e6-10b4-599104d7d74a@oracle.com>
 <80f0d55c-e598-1aad-b743-87f1e64c72b7@redhat.com>
Message-ID: <1ca09672-1fc7-ba43-728d-f3eb957a402f@arm.com>

Hi Aleksey,

On 13/01/2020 03:33, Aleksey Shipilev wrote:
> 
> Looks fine.
> 
> The long/doubleHandle changes probably clash with JDK-8236939.
> The test changes probably benefit from cleaner accessors like in JDK-8236920.
> 
> But whatever, having any fix in jdk14 that unbreaks 32-bit platforms before RDP2 hits is good, so I
> don't mind the patch going in in this form.
> 

Thanks. It's here:

http://hg.openjdk.java.net/jdk/jdk14/rev/e70d8459c2ba


Nick

From nick.gasson at arm.com  Mon Jan 13 07:39:55 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 13 Jan 2020 15:39:55 +0800
Subject: RFR: 8236939: [TESTBUG] Incorrect initialization in
 java/foreign/TestArrays.java
In-Reply-To: 
References: 
Message-ID: <3b4193a0-d321-9e36-51d4-0b63f148f4bb@arm.com>

Hi Leonid,

On 11/01/2020 02:06, Leonid Mesnik wrote:
> --- a/test/jdk/java/foreign/TestArrays.java     Wed Jan 01 03:08:45 2020 +0100
> +++ b/test/jdk/java/foreign/TestArrays.java     Fri Jan 10 09:51:51 2020 -0800
> @@ -76,8 +76,8 @@
>        static VarHandle shortHandle = shorts.varHandle(short.class, PathElement.sequenceElement());
>        static VarHandle intHandle = ints.varHandle(int.class, PathElement.sequenceElement());
>        static VarHandle floatHandle = floats.varHandle(float.class, PathElement.sequenceElement());
> -    static VarHandle longHandle = doubles.varHandle(long.class, PathElement.sequenceElement());
> -    static VarHandle doubleHandle = longs.varHandle(double.class, PathElement.sequenceElement());
> +    static VarHandle longHandle = longs.varHandle(long.class, PathElement.sequenceElement());
> +    static VarHandle doubleHandle = doubles.varHandle(double.class, PathElement.sequenceElement());
>    
>        static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {
>            for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {
> 

There's also an identical mix-up in TestByteBuffer.java. The patch for 
8236634 fixes this too along with some other things:

http://hg.openjdk.java.net/jdk/jdk14/rev/e70d8459c2ba


Thanks,
Nick

From leonid.mesnik at oracle.com  Mon Jan 13 07:45:56 2020
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Sun, 12 Jan 2020 23:45:56 -0800
Subject: RFR: 8236939: [TESTBUG] Incorrect initialization in
 java/foreign/TestArrays.java
In-Reply-To: <3b4193a0-d321-9e36-51d4-0b63f148f4bb@arm.com>
References: 
 <3b4193a0-d321-9e36-51d4-0b63f148f4bb@arm.com>
Message-ID: 

Thanks for letting me know. I'll just close bug.

Leonid

> On Jan 12, 2020, at 11:39 PM, Nick Gasson  wrote:
> 
> Hi Leonid,
> 
> On 11/01/2020 02:06, Leonid Mesnik wrote:
>> --- a/test/jdk/java/foreign/TestArrays.java     Wed Jan 01 03:08:45 2020 +0100
>> +++ b/test/jdk/java/foreign/TestArrays.java     Fri Jan 10 09:51:51 2020 -0800
>> @@ -76,8 +76,8 @@
>>       static VarHandle shortHandle = shorts.varHandle(short.class, PathElement.sequenceElement());
>>       static VarHandle intHandle = ints.varHandle(int.class, PathElement.sequenceElement());
>>       static VarHandle floatHandle = floats.varHandle(float.class, PathElement.sequenceElement());
>> -    static VarHandle longHandle = doubles.varHandle(long.class, PathElement.sequenceElement());
>> -    static VarHandle doubleHandle = longs.varHandle(double.class, PathElement.sequenceElement());
>> +    static VarHandle longHandle = longs.varHandle(long.class, PathElement.sequenceElement());
>> +    static VarHandle doubleHandle = doubles.varHandle(double.class, PathElement.sequenceElement());
>>          static void initBytes(MemoryAddress base, SequenceLayout seq, BiConsumer handleSetter) {
>>           for (long i = 0; i < seq.elementCount().getAsLong() ; i++) {
> 
> There's also an identical mix-up in TestByteBuffer.java. The patch for 8236634 fixes this too along with some other things:
> 
> http://hg.openjdk.java.net/jdk/jdk14/rev/e70d8459c2ba
> 
> 
> Thanks,
> Nick


From sgehwolf at redhat.com  Mon Jan 13 09:04:59 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 13 Jan 2020 10:04:59 +0100
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: 
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
Message-ID: <4cbdcf7ab8b2cd99cb66590b7ad408364b7a497b.camel@redhat.com>

Hi Bob,

On Fri, 2020-01-10 at 11:50 -0500, Bob Vandette wrote:
> Severin,
> 
> The changes look ok to me.  I assume you?ve run the container tests
> on a cgroupv2 and cgroupv1 enabled system, right?

Yes, I have.

> You?re going to have to find a ?R? reviewer.

Indeed.

> What?s the status of the hotspot cgroupv2 changes.  Have these been
> reviewed?

Latest webvrev was v5 here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/040120.html

It included the memory_max_usage_in_bytes synthesized hack for cgroups
v2, though. Should I remove it there as well? I'd be in favor of that.
Otherwise nothing new. It's ready from my perspective other than
finding another Reviewer for it.

Thanks,
Severin

> Bob.
> 
> 
> > On Jan 9, 2020, at 2:51 PM, Severin Gehwolf 
> > wrote:
> > 
> > Hi,
> > 
> > On Fri, 2020-01-03 at 15:37 -0500, Bob Vandette wrote:
> > > Here are a few comments from scanning the webrev.
> > > 
> > > 
> > > It looks like you can remove line 151
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java.sdiff.html
> > > 
> > > 151         int[] ints = new int[0];
> > > 
> > > ?????
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/share/classes/jdk/internal/platform/Metrics.java.sdiff.html
> > > 
> > > There are several comments stating that -2 == unlimited.  This is
> > > not
> > > the case.
> > > 
> > > @return count of elapsed periods or -2 if the quota is unlimited.
> > > 
> > > ?????
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java.sdiff.html
> > > 
> > > Shouldn?t you just check for cgroupv2 before trying to run the
> > > testKernelMemoryLimit and testOomKillFlag tests?
> > > 
> > > ?????
> > > 
> > > There are a few places where getPerCpuUsage is returning ?new
> > > long[0]? but you changed the interface to expect null
> > > for not supported.
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java.html
> > > 
> > > You probably need to check all users of the APIs which used to
> > > return
> > > array[0] which now return null to make sure you
> > > don?t get null pointer exceptions.
> > > 
> > > One example is testCpuConsumption.
> > > 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java.html
> > > 
> > > Also, 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java.html:167
> > > 
> > > 
> > > You?ll also have to update copyrights to 2020.
> > 
> > Thanks for the review! Should all be fixed now. Updated webrev:
> > 
> > incremental: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
> > full: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/
> > 
> > Note: I'll go through touched files and update copyright dates to
> > 2020.
> > Not all have been updated in the full webrev. It'll be done though.
> > 
> > Thanks,
> > Severin
> > 
> > > Bob.
> > > 
> > > 
> > > > On Dec 20, 2019, at 9:50 AM, Severin Gehwolf <
> > > > sgehwolf at redhat.com>
> > > > wrote:
> > > > 
> > > > Hi Bob,
> > > > 
> > > > Sorry for the delay to get this updated.
> > > > 
> > > > Changes done in this latest webrev:
> > > > 
> > > >  1. Rebased on top of 8226575: OperatingSystemMXBean should be
> > > > made
> > > >     container aware. File read ops now use privileged code.
> > > >  2. Warning for mixed cgroup controllers and returning null for
> > > > metrics.
> > > >  3. Added implementations for getBlkIOServiceCount() and
> > > >     getBlkIOServiced() using sum of rios/wios and rbytes/wbytes
> > > > across
> > > >     devices. Added impl for getTcpMemoryUsage()
> > > >  4. Returning -2 for not supported (if the metric would return
> > > > long).
> > > >     boolean metrics now return Boolean and null if not
> > > > supported.
> > > > Same
> > > >     for array return types. null if not supported for symmetry.
> > > >  5. -XshowSettings:system output has been updated to return
> > > > "N/A"
> > > > for
> > > >     when a metric is not available. E.g. "Kernel OOM killer
> > > > enabled"
> > > >     Boolean.
> > > >  6. Tests have been updated to reflect this.
> > > > 
> > > > webrev:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/
> > > > incremental webrev:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/
> > > > 
> > > > Testing: Docker tests and podman testing on cgroupsv2. I'll run
> > > > it
> > > > through jdk/submit as well.
> > > > 
> > > > Hopefully this can get pushed with 8230305 early on in the jdk
> > > > 15
> > > > cycle
> > > > :)
> > > > 
> > > > A couple of more inline comments below.
> > > > 
> > > > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote:
> > > > > Sorry for the delay in responding.  See comments below:
> > > > > 
> > > > > > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf <
> > > > > > sgehwolf at redhat.com> wrote:
> > > > > > 
> > > > > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Could I please get reviews of these core-libs, Linux-
> > > > > > > only,
> > > > > > > changes to
> > > > > > > the Metrics subsystem? This patch implements cgroupv2
> > > > > > > support
> > > > > > > for
> > > > > > > Metrics which are currently cgroupv1-only. Fedora 31
> > > > > > > switched
> > > > > > > to
> > > > > > > cgroupv2 by default so it's time to get OpenJDK recognize
> > > > > > > it.
> > > > > > > 
> > > > > > > Note that a couple of metrics are no longer supported
> > > > > > > with
> > > > > > > cgroupv2.
> > > > > > > Most notably (not an exhaustive list, though):
> > > > > > > 
> > > > > > > Metrics.getKernel*() family of methods.
> > > > > > > Metrics.getTcp*() family of methods.
> > > > > > > Metrics.getBlkIO*() family of methods.
> > > > > > > Metrics.isMemoryOOMKillEnabled()
> > > > > > > 
> > > > > > > A couple of open questions with regards to that:
> > > > > > > 
> > > > > > > 1)
> > > > > > > Most API docs of Metrics make no distiction between
> > > > > > > "unlimited" and
> > > > > > > "not supported", both returning -1 for longs, for
> > > > > > > example.
> > > > > > > This is a
> > > > > > > problem, because output of "java -XshowSettings:system
> > > > > > > -version" will
> > > > > > > not distinguish between unlimited and not supported
> > > > > > > metrics.
> > > > > > > Would it
> > > > > > > be acceptable to change the API to distinguish those
> > > > > > > cases so
> > > > > > > that
> > > > > > > LauncherHelper could display them appropriately?
> > > > > > > 
> > > > > > > 2)
> > > > > > > How should we deal with "not supported" for
> > > > > > > booleans/arrays,
> > > > > > > etc.?
> > > > > > > Would it make sense to return record objects from the
> > > > > > > Metrics
> > > > > > > API so
> > > > > > > that this could be dealt with? E.g.
> > > > > > > 
> > > > > > > Metrics m = ...
> > > > > > > MetricResult result = m.getCpuSetCpus();
> > > > > > > switch(result.getType()) {
> > > > > > > case NOT_SUPPORTED: /* do something */; break;
> > > > > > > case SUPPORTED: int[] val = result.get(); break;
> > > > > > > ...         
> > > > > > > }
> > > > > > > 
> > > > > > > I'm bringing this up, because the proposed patch doesn't
> > > > > > > deal
> > > > > > > with the
> > > > > > > above open questions as of yet. With that being said,
> > > > > > > it's
> > > > > > > mostly
> > > > > > > identical to the proposed hotspot changes in [1].
> > > > > 
> > > > > For issue 1 and 2 ?
> > > > > 
> > > > > I wonder if we should change the API to throw
> > > > > UnsupportedOperationException for those methods 
> > > > > that are not available.  This exception is used quite a lot
> > > > > in
> > > > > the java/nio and java/net packages
> > > > > for dealing with functionality not available on a host
> > > > > platform.
> > > > > 
> > > > > As an alternate suggestion, we already return -2 for "not
> > > > > supported" for most APIs in the hotspot
> > > > > implementation.  We could use this for non boolean values in
> > > > > the
> > > > > Metrics API.  For boolean
> > > > > values, we could change the API to return ?Boolean?.  A null
> > > > > return would signify not
> > > > > implemented.
> > > > 
> > > > This alternative has been implemented in the latest webrev.
> > > > LauncherHelper has been updated to print "N/A" if some property
> > > > being
> > > > printed is not supported. Example output for cgroupsv2:
> > > > 
> > > > $ ./bin/java -XshowSettings:system -version
> > > > Operating System Metrics:
> > > >   Provider: cgroupv2
> > > >   Effective CPU Count: 4
> > > >   CPU Period: 100000us
> > > >   CPU Quota: -1
> > > >   CPU Shares: -1
> > > >   List of Processors: N/A
> > > >   List of Effective Processors: N/A
> > > >   List of Memory Nodes: N/A
> > > >   List of Available Memory Nodes: N/A
> > > >   CPUSet Memory Pressure Enabled: N/A
> > > >   Memory Limit: Unlimited
> > > >   Memory Soft Limit: Unlimited
> > > >   Memory & Swap Limit: Unlimited
> > > >   Kernel Memory Limit: N/A
> > > >   TCP Memory Limit: N/A
> > > >   Out Of Memory Killer Enabled: N/A
> > > > 
> > > > openjdk version "15-internal" 2020-09-15
> > > > OpenJDK Runtime Environment (build 15-internal+0-
> > > > adhoc.sgehwolf.openjdk-head-2)
> > > > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > > > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> > > > 
> > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231111
> > > > > > > webrev: 
> > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/
> > > > > > > 
> > > > > 
> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html
> > > > > 
> > > > > Should we check to make sure that there are no mixed cgroupv1
> > > > > and
> > > > > cgroupv2 mounted subsystems since
> > > > > you are not supporting mixing.
> > > > 
> > > > Done. null is returned for metrics and a warning printed to
> > > > stderr.
> > > > 
> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
> > > > > 
> > > > > It looks looks like there may be alternate ways of reporting
> > > > > some
> > > > > of the metrics that you have classified as
> > > > > RETVAL_NOT_SUPPORTED.
> > > > > 
> > > > > BlkIOServicedCount (io.stat)
> > > > > KernelMemory (memory.stat)
> > > > > TcpMemory (memory.stat)
> > > > 
> > > > The latest webrev has getBlkIOService* and getTcpMemoryUsage
> > > > impls.
> > > > I've left out kernel memory metrics as it wasn't clear what
> > > > this
> > > > would
> > > > be. We can add that in a later patch. The size of this patch is
> > > > already
> > > > rather big.
> > > > 
> > > > > You could try the same trick for getMemoryAndSwapMaxUsage
> > > > > which
> > > > > keeps track of the highest returned value.
> > > > 
> > > > We've decided to not do this. getMemoryAndSwapMaxUsage and
> > > > getMemoryMaxUsage is being returned as not supported in cgroups
> > > > v2.
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > for the benefit of other reviewers, you should provide links
> > > > > to
> > > > > the cgroupv1 and v2 docs.
> > > > > 
> > > > > https://www.kernel.org/doc/Documentation/cgroup-v2.txt
> > > > > 
> > > > > > > Testing: jdk/submit and platform docker tests on Linux
> > > > > > > x86_64
> > > > > > > (with
> > > > > > > hybrid hierarchy, docker/podman) and on Linux x86_64 with
> > > > > > > unified
> > > > > > > hierarchy (podman only).
> > > > > > > 
> > > > > > > Thoughts? Suggestions?
> > > > > 
> > > > > Do you think we should check the docker version being used
> > > > > for
> > > > > the tests to make sure it
> > > > > supports cgroupv2?  I assume a fairly recent version is
> > > > > required
> > > > > to work with cgroupv2.
> > > > > 
> > > > > Bob.
> > > > > 
> > > > > 
> > > > > 
> > > > > > Ping?
> > > > > > 
> > > > > > > Thanks,
> > > > > > > Severin
> > > > > > > 
> > > > > > > [1] 
> > > > > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html


From sean.coffey at oracle.com  Mon Jan 13 10:28:18 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 13 Jan 2020 10:28:18 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: 
References: 
Message-ID: 

some off line comments suggested that I could move the jar 
initialization checks to the EventHelper class. With that in place, the 
EventHelper utility class should never initialize the logging framework 
early during jar initialization.

http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/

regards,
Sean.

On 16/12/2019 14:15, Se?n Coffey wrote:
> The recent crypto event logging mechanism (JDK-8148188) has introduced 
> a regression whereby the System Logger may be invoked too early in the 
> bootstrap phase. This causes issue when JarFile objects are locked by 
> JarFile verifier initialization code. The logging work records an X509 
> Certificate which is used during the jar file 
> verification/initialization phase and hence leads to an early 
> System.Logger call.
>
> One thread invokes the initialization of the Logger framework via 
> ServiceLoader and waits to lock a JarFile in use via another thread. 
> Unfortunately that other thread is also waiting for the System Logger 
> to initialize. For now, I think we can avoid the early Logger 
> initialization via use of a ThreadLocal. I've tried reproducing the 
> reported issue through manual and automated tests but to no avail. 
> I've added a new ServiceLoader test which has concurrent threads. One 
> is loading providers and another is initializing JarFile verifiers. 
> Hope it helps improve code coverage for the future.
>
> JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/
>

From jai.forums2013 at gmail.com  Mon Jan 13 10:31:38 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 13 Jan 2020 16:01:38 +0530
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
 
Message-ID: <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com>

Hello Christoph,

Setting inodes to null sounds fine to me and as you say since its usage
is already guarded by ensureOpen, IMO, it should be fine. I've now
updated the patch to set inodes to null in close() and the new updated
webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/

-Jaikiran

On 13/01/20 12:26 pm, Langer, Christoph wrote:
> Hi,
>
> I'm wondering whether we shouldn't just do "inodes = null;"? I guess this is cheaper and accesses to the inodes map on a closed filesystem object should not happen anyway (e.g. all is guarded by ensureOpen()). Other than that, the change looks fine.
>
> Cheers
> Christoph
>
>> -----Original Message-----
>> From: nio-dev  On Behalf Of Jaikiran
>> Pai
>> Sent: Samstag, 11. Januar 2020 11:24
>> To: Alan Bateman ; nio-dev at openjdk.java.net
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider
>>
>> Hello Alan,
>>
>> On 11/01/20 3:37 pm, Alan Bateman wrote:
>>> On 11/01/2020 09:51, Jaikiran Pai wrote:
>>>> :
>>>>
>>>> The commit here fixes that issue by simply clearing the "inodes" map in
>>>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
>>>> of the "inodes" map and from what I see, it's usage in various places is
>>>> guarded by "ensureOpen" checks, which means that once the
>> ZipFileSystem
>>>> instance is closed, the contents of these "inodes" map is no longer
>>>> relevant and hence clearing it shouldn't cause any issues.
>>>>
>>> Clearing the inodes map should be okay for cases where something is
>>> holding a reference to a closed zip file system. However, you should
>>> look at beginWrite/endWrite so that all access to the map is
>>> consistently synchronized.
>>>
>> Thank you very much for that input - I hadn't considered the concurrency
>> aspect of it. Based on your input and after looking at the usage of the
>> "inodes", I have now updated the patch to use proper locks during the
>> clearing of the inodes. The updated webrev is available at
>> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/
>>
>> -Jaikiran

From maurizio.cimadamore at oracle.com  Mon Jan 13 12:22:33 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 13 Jan 2020 12:22:33 +0000
Subject: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c
In-Reply-To: <28e68b3a-1d3f-7268-1860-1d0381292293@redhat.com>
References: <28e68b3a-1d3f-7268-1860-1d0381292293@redhat.com>
Message-ID: <3d6fa4fa-3205-22d6-875c-d25f17f3ebb9@oracle.com>

Hi Alex,
has this been addressed by Nick changes (JDK-8236634) ?

Thanks
Maurizio


On 12/01/2020 11:15, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8236920
>
> Fix:
>    https://cr.openjdk.java.net/~shade/8236920/webrev.01/
>
> This breaks x86_32 test builds. I would like to have this fix in 14.
>
> Testing: Linux {x86_64, x86_32} builds; java/foreign (still passes on x86_64; still fails on x86_32,
> seems unrelated to this build breakage); jdk14-submit (still stuck somewhere!)
>

From shade at redhat.com  Mon Jan 13 12:25:52 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 13 Jan 2020 13:25:52 +0100
Subject: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c
In-Reply-To: <3d6fa4fa-3205-22d6-875c-d25f17f3ebb9@oracle.com>
References: <28e68b3a-1d3f-7268-1860-1d0381292293@redhat.com>
 <3d6fa4fa-3205-22d6-875c-d25f17f3ebb9@oracle.com>
Message-ID: <3a33b288-a30c-4c57-62ab-be5642c22434@redhat.com>

On 1/13/20 1:22 PM, Maurizio Cimadamore wrote:
> Hi Alex,
> has this been addressed by Nick changes (JDK-8236634) ?

Seems to be, I already closed my issue as duplicate.

-- 
Thanks,
-Aleksey


From maurizio.cimadamore at oracle.com  Mon Jan 13 12:27:02 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 13 Jan 2020 12:27:02 +0000
Subject: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c
In-Reply-To: <3a33b288-a30c-4c57-62ab-be5642c22434@redhat.com>
References: <28e68b3a-1d3f-7268-1860-1d0381292293@redhat.com>
 <3d6fa4fa-3205-22d6-875c-d25f17f3ebb9@oracle.com>
 <3a33b288-a30c-4c57-62ab-be5642c22434@redhat.com>
Message-ID: 

Thanks

Maurizio

On 13/01/2020 12:25, Aleksey Shipilev wrote:
> On 1/13/20 1:22 PM, Maurizio Cimadamore wrote:
>> Hi Alex,
>> has this been addressed by Nick changes (JDK-8236634) ?
> Seems to be, I already closed my issue as duplicate.
>

From daniel.fuchs at oracle.com  Mon Jan 13 13:14:43 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 Jan 2020 13:14:43 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: 
References: 
 
Message-ID: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>

On 13/01/2020 10:28, Se?n Coffey wrote:
> some off line comments suggested that I could move the jar 
> initialization checks to the EventHelper class. With that in place, the 
> EventHelper utility class should never initialize the logging framework 
> early during jar initialization.
> 
> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/

Looks good to me Se?n. Probably safer than the other alternatives.
   46     private static boolean loggingSecurity;
that should be volatile too.


best regard,

-- daniel

> 
> regards,
> Sean.
> 
> On 16/12/2019 14:15, Se?n Coffey wrote:
>> The recent crypto event logging mechanism (JDK-8148188) has introduced 
>> a regression whereby the System Logger may be invoked too early in the 
>> bootstrap phase. This causes issue when JarFile objects are locked by 
>> JarFile verifier initialization code. The logging work records an X509 
>> Certificate which is used during the jar file 
>> verification/initialization phase and hence leads to an early 
>> System.Logger call.
>>
>> One thread invokes the initialization of the Logger framework via 
>> ServiceLoader and waits to lock a JarFile in use via another thread. 
>> Unfortunately that other thread is also waiting for the System Logger 
>> to initialize. For now, I think we can avoid the early Logger 
>> initialization via use of a ThreadLocal. I've tried reproducing the 
>> reported issue through manual and automated tests but to no avail. 
>> I've added a new ServiceLoader test which has concurrent threads. One 
>> is loading providers and another is initializing JarFile verifiers. 
>> Hope it helps improve code coverage for the future.
>>
>> JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/
>>


From chris.hegarty at oracle.com  Mon Jan 13 13:57:22 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 Jan 2020 13:57:22 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
 
Message-ID: <0DBEFF04-969E-47D3-9BEC-D3108A0DC5FE@oracle.com>



> On 9 Jan 2020, at 18:36, Maurizio Cimadamore  wrote:
> 
> New revision:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2
> 
> delta from previous iteration:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta
> 
> javadoc
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_javadoc
> 
> specdiff
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_specdiff/overview-summary.html

Thank you for the updates Maurizio. The changes look good to me. ( I?ve added myself as reviewer on the CSR )

-Chris.

From chris.hegarty at oracle.com  Mon Jan 13 14:06:22 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 Jan 2020 14:06:22 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>
References: 
 
 <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>
Message-ID: <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com>



> On 13 Jan 2020, at 13:14, Daniel Fuchs  wrote:
> 
> On 13/01/2020 10:28, Se?n Coffey wrote:
>> some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility class should never initialize the logging framework early during jar initialization.
>> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/
> 
> Looks good to me Se?n. Probably safer than the other alternatives.

+1

I?m going to ask, since I cannot find the answer myself. Why are some securityLogger::log invocations guarded with isLoggingSecurity, and others not? With this change shouldn?t all invocations be guarded, since it is isLoggingSecurity that assigns securityLogger a value?

-Chris

From sundararajan.athijegannathan at oracle.com  Mon Jan 13 14:25:04 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 13 Jan 2020 19:55:04 +0530
Subject: RFR 8222100: tools/jimage/JImageTest.java time out
Message-ID: 

Bumping the default timeout (other tests in the same dir have similar 
timeout settings).

Bug: https://bugs.openjdk.java.net/browse/JDK-8222100

Webrev: http://cr.openjdk.java.net/~sundar/8222100/webrev.00/

Thanks,

-Sundar


From james.laskey at oracle.com  Mon Jan 13 14:29:09 2020
From: james.laskey at oracle.com (James Laskey)
Date: Mon, 13 Jan 2020 10:29:09 -0400
Subject: RFR 8222100: tools/jimage/JImageTest.java time out
In-Reply-To: 
References: 
Message-ID: <2D287495-0C18-41A5-9823-366F17E32736@oracle.com>

+1

On the road.

> On Jan 13, 2020, at 10:25 AM, sundararajan.athijegannathan at oracle.com wrote:
> 
> ?Bumping the default timeout (other tests in the same dir have similar timeout settings).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222100
> 
> Webrev: http://cr.openjdk.java.net/~sundar/8222100/webrev.00/
> 
> Thanks,
> 
> -Sundar
> 


From daniel.fuchs at oracle.com  Mon Jan 13 14:38:43 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 Jan 2020 14:38:43 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com>
References: 
 
 <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>
 <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com>
Message-ID: <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com>

On 13/01/2020 14:06, Chris Hegarty wrote:
> I?m going to ask, since I cannot find the answer myself. Why are some securityLogger::log invocations guarded with isLoggingSecurity, and others not? With this change shouldn?t all invocations be guarded, since it is isLoggingSecurity that assigns securityLogger a value?

Argh! Well spotted chris!

-- daniel

From claes.redestad at oracle.com  Mon Jan 13 14:48:53 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Jan 2020 15:48:53 +0100
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
Message-ID: <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>

Hi,

I included John's suggested salt improvement, reverted to use an
EMPTY object marker rather than 'this', and removed the
extraneous blank line Roger pointed out:

http://cr.openjdk.java.net/~redestad/8236850/open.01/

/Claes

On 2020-01-11 04:19, John Rose wrote:
> On Jan 10, 2020, at 6:48 PM, Claes Redestad  > wrote:
>>
>> Yes. The XOR seems pointless with this approach, but some shifting
>> might be good.
> 
> A single multiply mixes the bits of its inputs. ?If one input is
> ?random? or ?white? (50% 1?s irregularly spaced) then the output
> will probably look similar. ?The output bits are not equally mixed,
> though: ?The LSB depends only on two bits of the input, and the
> MSB (barring rare carry-outs) depends mostly on two other bits
> of the input. ?But the middle bits depend on most of the input bits.
> 
> So, given the goal of making a very simple, good-enough mixing
> expression to get a 32-bit salt, this one is relatively good:
> 
>  ? ?long COLOR = 0x243F_6A88_85A3_08D3L; ?// pi slice
>  ? ?long SEED = System.nanoTime(); ?// or command line value
>  ? ?int SALT = (int)( (COLOR * SEED) >> 16 ); ?// avoid LSB and MSB
> 
> In the longer term, I think the JVM should provide salt values
> both for itself and (a few) core libs., and should allow those values
> to be (partially) configured from the command line. ?(Crash dumps
> should report the SEED values used for reproducing the error.)
> Given such a facility, it would be reasonable to upgrade it to use
> better quality entropy sources and hashing (maybe optionally
> crypto-quality, though I have reservations about that). ?That
> would make the variable behaviors unpredictable in practice.
> Except when they are intentionally configured to be predictable.
> An algorithm like xxHash would be a good starting point; it?s
> cheap and salty.
> 
> ? John

From andy.herrick at oracle.com  Mon Jan 13 15:15:29 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 13 Jan 2020 10:15:29 -0500
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: 
References: 
Message-ID: <41ef4341-2853-44a8-8c50-a61c3f1db755@oracle.com>

I'm fine with this change.

/Andy

On 12/23/2019 6:52 PM, Alex Kashchenko wrote:
> Hi,
>
> Please review this minor change to jpackage, that is required for 
> successful compilation with VS2013 toolchain:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>
> Some details on this problem: https://stackoverflow.com/a/24302290/314015
>

From claes.redestad at oracle.com  Mon Jan 13 16:03:10 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Jan 2020 17:03:10 +0100
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup characteristics
Message-ID: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>

Hi,

we're doing plenty of iterations over Set.of() instances during
bootstrap, which makes these operations show up prominently in
startup profiles. This patch refactors a few hot methods to get a
measureable startup improvement without regressing on targeted
microbenchmarks.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8236641
Webrev: http://cr.openjdk.java.net/~redestad/8236641/open.00/

(The patch is baselined against 8236850)

Thanks!

/Claes

From shade at redhat.com  Mon Jan 13 16:03:21 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 13 Jan 2020 17:03:21 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <41ef4341-2853-44a8-8c50-a61c3f1db755@oracle.com>
References: 
 <41ef4341-2853-44a8-8c50-a61c3f1db755@oracle.com>
Message-ID: <9d848b83-9fd4-bb4a-30e8-13ea08cd32bb@redhat.com>

You good for this to go to jdk14?

On 1/13/20 4:15 PM, Andy Herrick wrote:
> I'm fine with this change.
> 
> /Andy
> 
> On 12/23/2019 6:52 PM, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review this minor change to jpackage, that is required for 
>> successful compilation with VS2013 toolchain:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>>
>> Some details on this problem: https://stackoverflow.com/a/24302290/314015
>>
> 


-- 
Thanks,
-Aleksey


From Roger.Riggs at oracle.com  Mon Jan 13 16:07:25 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 13 Jan 2020 11:07:25 -0500
Subject: [15] RFR: 8174270: Consolidate ICU sources in one location
In-Reply-To: <39bfd4c6-fe4f-3967-9fb8-5ba9bcd7e804@oracle.com>
References: 
 <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
 
 <39bfd4c6-fe4f-3967-9fb8-5ba9bcd7e804@oracle.com>
Message-ID: 

Looks fine to me also.

Roger

On 1/10/20 11:21 PM, Joe Wang wrote:
> I see. It's all good to me then.
>
> Best,
> Joe
>
> On 1/10/20 4:04 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> That data file seems no longer included in the ICU4J package (as of 
>> 64.2), thus I left it as it is.
>>
>> Naoto
>>
>> On 1/10/20 2:57 PM, Joe Wang wrote:
>>> Is there a reason why uidna.spp was left out of the move?
>>>
>>> -Joe
>>>
>>> On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>>>
>>>> Although the number of modified files are huge, the change is 
>>>> simply moving the scattered ICU sources in various locations under 
>>>> jdk.internal.icu package, keeping the original ICU's source tree 
>>>> structure.
>>>>
>>>> Naoto
>>>
>


From andy.herrick at oracle.com  Mon Jan 13 16:41:23 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 13 Jan 2020 11:41:23 -0500
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <9d848b83-9fd4-bb4a-30e8-13ea08cd32bb@redhat.com>
References: 
 <41ef4341-2853-44a8-8c50-a61c3f1db755@oracle.com>
 <9d848b83-9fd4-bb4a-30e8-13ea08cd32bb@redhat.com>
Message-ID: <7d6c4b50-d5f5-d73f-624c-6dd9aa6d307e@oracle.com>

sure

/Andy

On 1/13/2020 11:03 AM, Aleksey Shipilev wrote:
> You good for this to go to jdk14?
>
> On 1/13/20 4:15 PM, Andy Herrick wrote:
>> I'm fine with this change.
>>
>> /Andy
>>
>> On 12/23/2019 6:52 PM, Alex Kashchenko wrote:
>>> Hi,
>>>
>>> Please review this minor change to jpackage, that is required for
>>> successful compilation with VS2013 toolchain:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>>>
>>> Some details on this problem: https://stackoverflow.com/a/24302290/314015
>>>
>

From sean.coffey at oracle.com  Mon Jan 13 17:19:48 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 13 Jan 2020 17:19:48 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com>
References: 
 
 <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>
 <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com>
 <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com>
Message-ID: 

Thanks for the reviews. All callers of EventHelper log methods are 
ensuring that isLoggingSecurity() is true before proceeding. I've added 
an assert null check in the 4 logger methods to ensure expectations are 
in place.

http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/

Hope this helps,
Sean.

On 13/01/2020 14:38, Daniel Fuchs wrote:
> On 13/01/2020 14:06, Chris Hegarty wrote:
>> I?m going to ask, since I cannot find the answer myself. Why are some 
>> securityLogger::log invocations guarded with isLoggingSecurity, and 
>> others not? With this change shouldn?t all invocations be guarded, 
>> since it is isLoggingSecurity that assigns securityLogger a value?
>
> Argh! Well spotted chris!
>
> -- daniel

From chris.hegarty at oracle.com  Mon Jan 13 17:21:03 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 Jan 2020 17:21:03 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: 
References: 
 
 <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>
 <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com>
 <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com>
 
Message-ID: <2D1BAE15-0A47-43D5-87C5-14C80A974B86@oracle.com>



> On 13 Jan 2020, at 17:19, Se?n Coffey  wrote:
> 
> Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place.
> 
> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/

Thanks. LGTM.

-Chris.

From shade at redhat.com  Mon Jan 13 17:40:41 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 13 Jan 2020 18:40:41 +0100
Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage:
 Need to include strsafe.h after tchar.h
In-Reply-To: <7d6c4b50-d5f5-d73f-624c-6dd9aa6d307e@oracle.com>
References: 
 <41ef4341-2853-44a8-8c50-a61c3f1db755@oracle.com>
 <9d848b83-9fd4-bb4a-30e8-13ea08cd32bb@redhat.com>
 <7d6c4b50-d5f5-d73f-624c-6dd9aa6d307e@oracle.com>
Message-ID: <0b7df216-49bc-5226-9734-f93b1eafcdfc@redhat.com>

Thank you, pushed.

-Aleksey

On 1/13/20 5:41 PM, Andy Herrick wrote:
> sure
> 
> /Andy
> 
> On 1/13/2020 11:03 AM, Aleksey Shipilev wrote:
>> You good for this to go to jdk14?
>>
>> On 1/13/20 4:15 PM, Andy Herrick wrote:
>>> I'm fine with this change.
>>>
>>> /Andy
>>>
>>> On 12/23/2019 6:52 PM, Alex Kashchenko wrote:
>>>> Hi,
>>>>
>>>> Please review this minor change to jpackage, that is required for
>>>> successful compilation with VS2013 toolchain:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
>>>>
>>>> Some details on this problem: https://stackoverflow.com/a/24302290/314015


From srl at icu-project.org  Sat Jan 11 00:23:20 2020
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 10 Jan 2020 16:23:20 -0800
Subject:  [15] RFR: 8174270: Consolidate ICU sources in one
 location
In-Reply-To: <835cc98d-fa1c-9e7d-c1b9-0a5e075dd683@oracle.com>
References: 
 <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>
 <835cc98d-fa1c-9e7d-c1b9-0a5e075dd683@oracle.com>
Message-ID: 

approve

--
Steven R. Loomis | @srl295 | git.io/srl295



> El ene. 10, 2020, a las 4:02 p. m., naoto.sato at oracle.com escribi?:
> 
> Hi Steven,
> 
> On 1/10/20 2:26 PM, Steven R. Loomis wrote:
>> in Norm2AllModes.java and UBiDiProps.java  and UCharacterProperty.java the stub name (icudt64b) should be calculated from the version number.   At least put ?icudt64b? in one place and refer to it.
> 
> Good point. Modified as suggested:
> 
> https://cr.openjdk.java.net/~naoto/8174270/webrev.01/
> 
> Naoto
> 
>> OR keep the data file names unversioned, such as src/java.base/share/classes/jdk/internal/icu/impl/data/nfc.nrm
>> otherwise looks good
>> --
>> Steven R. Loomis | @srl295 | git.io/srl295 
>>> El ene. 10, 2020, a las 2:02 p. m., naoto.sato at oracle.com  escribi?:
>>> 
>>> Hi,
>>> 
>>> Please review the fix to the following issue:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>> 
>>> The proposed changeset is located at:
>>> 
>>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>> 
>>> Although the number of modified files are huge, the change is simply moving the scattered ICU sources in various locations under jdk.internal.icu package, keeping the original ICU's source tree structure.
>>> 
>>> Naoto


From daniel.fuchs at oracle.com  Mon Jan 13 17:42:57 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 Jan 2020 17:42:57 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: <2D1BAE15-0A47-43D5-87C5-14C80A974B86@oracle.com>
References: 
 
 <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com>
 <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com>
 <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com>
 
 <2D1BAE15-0A47-43D5-87C5-14C80A974B86@oracle.com>
Message-ID: <78428501-7395-3a50-1d7a-6c1f84acc1c1@oracle.com>

On 13/01/2020 17:21, Chris Hegarty wrote:
>> On 13 Jan 2020, at 17:19, Se?n Coffey  wrote:
>>
>> Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place.
>>
>> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/
> Thanks. LGTM.
> 

Likewise.

Thanks Se?n!

best regards,

-- daniel

From Alan.Bateman at oracle.com  Mon Jan 13 18:50:28 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Jan 2020 18:50:28 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: 
References: 
 
Message-ID: <43190e76-8028-3419-b07c-58e8cd6aeb50@oracle.com>

On 13/01/2020 10:28, Se?n Coffey wrote:
> some off line comments suggested that I could move the jar 
> initialization checks to the EventHelper class. With that in place, 
> the EventHelper utility class should never initialize the logging 
> framework early during jar initialization.
>
> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/
Thanks for the update. JAR file verification is tricky and important not 
to attempt to run arbitrary code while doing that, esp. anything that 
might need to load a class or resource from the class path. So I think 
the approach (in v5) looks okay.? A minor nit in JarFile is that it 
should be "static final".? Also you might want to replace or change the 
@summary in both tests to make it clearer that the tests attempt to 
trigger class loading from the class loader during JAR file verification.

-Alan.

From Alan.Bateman at oracle.com  Mon Jan 13 18:53:39 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Jan 2020 18:53:39 +0000
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com>
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
 
 <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com>
Message-ID: 

On 13/01/2020 10:31, Jaikiran Pai wrote:
> Hello Christoph,
>
> Setting inodes to null sounds fine to me and as you say since its usage
> is already guarded by ensureOpen, IMO, it should be fine. I've now
> updated the patch to set inodes to null in close() and the new updated
> webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/
>
This version looks good except it might be better if the comment just 
says that it clears the inodes map to allow the keys/values be GC'ed.

-Alan

From paul.sandoz at oracle.com  Mon Jan 13 19:49:58 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Jan 2020 11:49:58 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
 <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
Message-ID: <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>

Looks good.

  78     private static final Object[] EMPTY;

Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ?

--

For information purposes: an alternative salt might be to use mix32 from Splittable random:

/**
 * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
 */
private static int mix32(long z) {
    z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
    return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
}

as in:

SALT = mix32(System.nanoTime());

Paul.

> On Jan 13, 2020, at 6:48 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> I included John's suggested salt improvement, reverted to use an
> EMPTY object marker rather than 'this', and removed the
> extraneous blank line Roger pointed out:
> 
> http://cr.openjdk.java.net/~redestad/8236850/open.01/
> 
> /Claes
> 
> On 2020-01-11 04:19, John Rose wrote:
>> On Jan 10, 2020, at 6:48 PM, Claes Redestad > wrote:
>>> 
>>> Yes. The XOR seems pointless with this approach, but some shifting
>>> might be good.
>> A single multiply mixes the bits of its inputs.  If one input is
>> ?random? or ?white? (50% 1?s irregularly spaced) then the output
>> will probably look similar.  The output bits are not equally mixed,
>> though:  The LSB depends only on two bits of the input, and the
>> MSB (barring rare carry-outs) depends mostly on two other bits
>> of the input.  But the middle bits depend on most of the input bits.
>> So, given the goal of making a very simple, good-enough mixing
>> expression to get a 32-bit salt, this one is relatively good:
>>    long COLOR = 0x243F_6A88_85A3_08D3L;  // pi slice
>>    long SEED = System.nanoTime();  // or command line value
>>    int SALT = (int)( (COLOR * SEED) >> 16 );  // avoid LSB and MSB
>> In the longer term, I think the JVM should provide salt values
>> both for itself and (a few) core libs., and should allow those values
>> to be (partially) configured from the command line.  (Crash dumps
>> should report the SEED values used for reproducing the error.)
>> Given such a facility, it would be reasonable to upgrade it to use
>> better quality entropy sources and hashing (maybe optionally
>> crypto-quality, though I have reservations about that).  That
>> would make the variable behaviors unpredictable in practice.
>> Except when they are intentionally configured to be predictable.
>> An algorithm like xxHash would be a good starting point; it?s
>> cheap and salty.
>> ? John


From john.r.rose at oracle.com  Mon Jan 13 20:09:39 2020
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 13 Jan 2020 12:09:39 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
 <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
 <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
Message-ID: <61502926-167B-4EB0-BE85-0ADAC6F7EE5A@oracle.com>

On Jan 13, 2020, at 11:49 AM, Paul Sandoz  wrote:
> 
> For information purposes: an alternative salt might be to use mix32 from Splittable random:
> 
> /**
> * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
> */
> private static int mix32(long z) {
>    z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
>    return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
> }
> 
> as in:
> 
> SALT = mix32(System.nanoTime());

Thank you for mentioning that!  I get this google hit on it:

https://blogs.oracle.com/dave/a-simple-prng-construction-idiom

There are also similar functions in xxHash.

https://github.com/easyaspi314/xxhash-clean/blob/master/xxhash64-ref.c#L104

Here?s a scary list:

https://en.wikipedia.org/wiki/List_of_hash_functions

I think ?doing it right? is overkill for this one place, but I hope we can put
something like that into the JVM or some other low-level place for use
whenever we need a cheap pseudo-random nonce of some sort.

Once there?s an API for it I think we will reach for it a little more often.
Having a common engine means we can afford to tune its predictability
qualities.  In both directions:  resistance to attack, and reproducibility
for debugging.  In the case of Set.of, the former concern doesn?t apply
much, but the latter might.

? John

From lance.andersen at oracle.com  Mon Jan 13 20:26:01 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 13 Jan 2020 15:26:01 -0500
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
 
 <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com>
 
Message-ID: 



> On Jan 13, 2020, at 1:53 PM, Alan Bateman  wrote:
> 
> On 13/01/2020 10:31, Jaikiran Pai wrote:
>> Hello Christoph,
>> 
>> Setting inodes to null sounds fine to me and as you say since its usage
>> is already guarded by ensureOpen, IMO, it should be fine. I've now
>> updated the patch to set inodes to null in close() and the new updated
>> webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/
>> 
> This version looks good except it might be better if the comment just says that it clears the inodes map to allow the keys/values be GC?ed.

I revised the comment to:

????????

$ hg diff
diff -r 9338d0f52b2e src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java      Mon Jan 13 11:51:45 2020 -0500
+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java      Mon Jan 13 15:24:37 2020 -0500
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2009, 2020, 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
@@ -490,6 +490,14 @@
                 def.end();
         }
 
+        beginWrite();                // lock and sync
+        try {
+            // Clear the map so that its keys & values can be garbage collected
+            inodes = null;
+        } finally {
+            endWrite();
+        }
+
         IOException ioe = null;
         synchronized (tmppaths) {
             for (Path p : tmppaths) {
$
???????????

I will push the change tomorrow barring any hiccups with Mach5 or additional comments?.

Best
lance
> 
> -Alan

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From claes.redestad at oracle.com  Mon Jan 13 21:12:25 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Jan 2020 22:12:25 +0100
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
 <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
 <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
Message-ID: 

On 2020-01-13 20:49, Paul Sandoz wrote:
> Looks good.

Thanks!

> 
>    78     private static final Object[] EMPTY;
> 
> Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ?

No, this was part of an experiment I did to have EMPTY_LIST etc use the
EMPTY backing array, but that didn't pan out to anything but more code.
I thought I backed out all changes, but must've slipped.

> 
> --
> 
> For information purposes: an alternative salt might be to use mix32 from Splittable random:
> 
> /**
>   * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
>   */
> private static int mix32(long z) {
>      z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
>      return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
> }
> 
> as in:
> 
> SALT = mix32(System.nanoTime());

Interesting - but as John points out we don't need a _really_ good salt
for this, and I don't want to pull in SplittableRandom since we'd
distort the bootstrap sequence if we did so here.

/Claes

From paul.sandoz at oracle.com  Mon Jan 13 21:18:06 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Jan 2020 13:18:06 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: 
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
 <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
 <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
 
Message-ID: <2326D899-6C1F-405C-A074-26E43068A1AE@oracle.com>



> On Jan 13, 2020, at 1:12 PM, Claes Redestad  wrote:
> 
> On 2020-01-13 20:49, Paul Sandoz wrote:
>> Looks good.
> 
> Thanks!
> 
>>   78     private static final Object[] EMPTY;
>> Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ?
> 
> No, this was part of an experiment I did to have EMPTY_LIST etc use the
> EMPTY backing array, but that didn't pan out to anything but more code.
> I thought I backed out all changes, but must've slipped.
> 

Ok.


>> --
>> For information purposes: an alternative salt might be to use mix32 from Splittable random:
>> /**
>>  * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
>>  */
>> private static int mix32(long z) {
>>     z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
>>     return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
>> }
>> as in:
>> SALT = mix32(System.nanoTime());
> 
> Interesting - but as John points out we don't need a _really_ good salt
> for this, and I don't want to pull in SplittableRandom since we'd
> distort the bootstrap sequence if we did so here.
> 

That?s fine, it was really for informational purposes in case it comes in handy later on.

Speculating: if we had such a public method (with minimal dependencies) I suspect we would reach for it in this case even if overkill.  It reduces the cognitive load, but as a downside it would not afford us the opportunity of a slice Pi :-)

Paul.

From sean.coffey at oracle.com  Mon Jan 13 21:18:19 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 13 Jan 2020 21:18:19 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
In-Reply-To: <43190e76-8028-3419-b07c-58e8cd6aeb50@oracle.com>
References: 
 
 <43190e76-8028-3419-b07c-58e8cd6aeb50@oracle.com>
Message-ID: 

Thanks Alan. Updates made and changes pushed.

regards,
Sean.

On 13/01/2020 18:50, Alan Bateman wrote:
> On 13/01/2020 10:28, Se?n Coffey wrote:
>> some off line comments suggested that I could move the jar 
>> initialization checks to the EventHelper class. With that in place, 
>> the EventHelper utility class should never initialize the logging 
>> framework early during jar initialization.
>>
>> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/
> Thanks for the update. JAR file verification is tricky and important 
> not to attempt to run arbitrary code while doing that, esp. anything 
> that might need to load a class or resource from the class path. So I 
> think the approach (in v5) looks okay.? A minor nit in JarFile is that 
> it should be "static final".? Also you might want to replace or change 
> the @summary in both tests to make it clearer that the tests attempt 
> to trigger class loading from the class loader during JAR file 
> verification.
>
> -Alan.

From claes.redestad at oracle.com  Mon Jan 13 21:23:45 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Jan 2020 22:23:45 +0100
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: <2326D899-6C1F-405C-A074-26E43068A1AE@oracle.com>
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
 <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
 <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
 
 <2326D899-6C1F-405C-A074-26E43068A1AE@oracle.com>
Message-ID: 

On 2020-01-13 22:18, Paul Sandoz wrote:
> That?s fine, it was really for informational purposes in case it comes in handy later on.

Got it.

> Speculating: if we had such a public method (with minimal dependencies) I suspect we would reach for it in this case even if overkill.  It reduces the cognitive load, but as a downside it would not afford us the opportunity of a slice Pi:-)

Not sure it'd pull its own weight as a public API, but refactoring to a
shared internal utility might be a good start?

/Claes

From john.r.rose at oracle.com  Mon Jan 13 21:33:00 2020
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 13 Jan 2020 13:33:00 -0800
Subject: RFR: 8236850: Operations on constant List/Set.of(element)
 instances does not consistently constant fold
In-Reply-To: 
References: <1ca416e1-4bc0-8303-b2a2-3143407d4e8d@oracle.com>
 <511023678.1033527.1578682072485.JavaMail.zimbra@u-pem.fr>
 
 <59f3162c-6db2-88af-9c3a-c7bdb0acfafa@oracle.com>
 <802435EA-8EDD-4762-AD6A-1E704AEB5B76@oracle.com>
 <20f8ddf2-cb33-0b0f-5460-def0b8554893@oracle.com>
 <7448FACF-65DB-4F45-8477-30CC3BBE5595@oracle.com>
 
 <2326D899-6C1F-405C-A074-26E43068A1AE@oracle.com>
 
Message-ID: 

On Jan 13, 2020, at 1:23 PM, Claes Redestad  wrote:
> 
> On 2020-01-13 22:18, Paul Sandoz wrote:
>> That?s fine, it was really for informational purposes in case it comes in handy later on.
> 
> Got it.
> 
>> Speculating: if we had such a public method (with minimal dependencies) I suspect we would reach for it in this case even if overkill.  It reduces the cognitive load, but as a downside it would not afford us the opportunity of a slice Pi:-)
> 
> Not sure it'd pull its own weight as a public API, but refactoring to a
> shared internal utility might be a good start?

Yes.  I want it in the JVM so I can use it there also, to fuzz things like
stack positions and TLB chunk sizes and monitor wait times and
central hash table placements.

As long as the core libs only need it for an occasional static constant,
the JNI call overhead will not be a problem.

? John

From alexander.matveev at oracle.com  Mon Jan 13 22:43:20 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 13 Jan 2020 14:43:20 -0800
Subject: RFR: JDK-8232077: Investigate if default behavior should allow
 downgrade scenario
In-Reply-To: 
References: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com>
 
 
Message-ID: <34c583b0-03aa-8eb6-7798-f99d2c0a0c2e@oracle.com>

Looks good.

Thanks,
Alexander

On 12/20/2019 8:53 AM, Andy Herrick wrote:
> fix looks fine.
>
> /Andy
>
> On 12/19/2019 8:02 PM, Alexey Semenyuk wrote:
>> Please review fix [2] for jpackage bug [1].
>>
>> The fix changes the default setting for Windows installers to allow 
>> downgrades.
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232077
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8232077/webrev.00


From alexander.matveev at oracle.com  Mon Jan 13 22:44:52 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 13 Jan 2020 14:44:52 -0800
Subject: RFR: JDK-8233578: Document configurable parameters of msi packages
In-Reply-To: <563ce369-c6ec-6846-075b-06eecf7633b1@oracle.com>
References: 
 <6a0e63fe-d1c7-28b9-64c2-598a306bb693@oracle.com>
 <563ce369-c6ec-6846-075b-06eecf7633b1@oracle.com>
Message-ID: <2ffc5ef4-b48f-1d90-eb95-2c5148c7e7ad@oracle.com>

Looks good.

Thanks,
Alexander

On 12/20/2019 8:56 AM, Andy Herrick wrote:
> looks good.
>
> /Andy
>
> On 12/19/2019 8:52 PM, Alexey Semenyuk wrote:
>> Please review fix [2] for jpackage bug [1].
>>
>> Comments added to the default WiX source file explaining how the 
>> default file is expected to be overridden.
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233578
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8233578/webrev.00


From jai.forums2013 at gmail.com  Tue Jan 14 03:11:49 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 14 Jan 2020 08:41:49 +0530
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
 
 <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com>
 
 
Message-ID: <7d48fd19-502d-39df-96b3-1397b3e42c36@gmail.com>

Looks fine Lance. I forgot about the copyright year, thank you for
taking care of that one too.

-Jaikiran

On 14/01/20 1:56 am, Lance Andersen wrote:
>
>
>> On Jan 13, 2020, at 1:53 PM, Alan Bateman > > wrote:
>>
>> On 13/01/2020 10:31, Jaikiran Pai wrote:
>>> Hello Christoph,
>>>
>>> Setting inodes to null sounds fine to me and as you say since its usage
>>> is already guarded by ensureOpen, IMO, it should be fine. I've now
>>> updated the patch to set inodes to null in close() and the new updated
>>> webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/
>>>
>> This version looks good except it might be better if the comment just
>> says that it clears the inodes map to allow the keys/values be GC?ed.
>
> I revised the comment to:
>
> ????????
>
> $ hg diff
> *diff -r 9338d0f52b2e
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java*
> *--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java? ?
> ? Mon Jan 13 11:51:45 2020 -0500*
> *+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java? ?
> ? Mon Jan 13 15:24:37 2020 -0500*
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2009, 2020, 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
> @@ -490,6 +490,14 @@
> ?? ? ? ? ? ? ? ? def.end();
> ?? ? ? ? }
>
> ?
>
> +? ? ? ? beginWrite();? ? ? ? ? ? ? ? // lock and sync
> +? ? ? ? try {
> +? ? ? ? ? ? // Clear the map so that its keys & values can be garbage
> collected
> +? ? ? ? ? ? inodes = null;
> +? ? ? ? } finally {
> +? ? ? ? ? ? endWrite();
> +? ? ? ? }
> +
> ?? ? ? ? IOException ioe = null;
> ?? ? ? ? synchronized (tmppaths) {
> ?? ? ? ? ? ? for (Path p : tmppaths) {
> $
> ???????????
>
> I will push the change tomorrow barring any hiccups with Mach5 or
> additional comments?.
>
> Best
> lance
>>
>> -Alan
>
> 
> 
> Lance
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering?
> 1 Network Drive?
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
>
>
>

From christoph.langer at sap.com  Tue Jan 14 10:16:52 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 Jan 2020 10:16:52 +0000
Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider
In-Reply-To: 
References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com>
 
 
 
 <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com>
 
 
Message-ID: 

Hi,

Looks good to me ??

Cheers
Christoph

From: Lance Andersen 
Sent: Montag, 13. Januar 2020 21:26
To: Alan Bateman 
Cc: Jaikiran Pai ; Langer, Christoph ; nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider




On Jan 13, 2020, at 1:53 PM, Alan Bateman > wrote:

On 13/01/2020 10:31, Jaikiran Pai wrote:

Hello Christoph,

Setting inodes to null sounds fine to me and as you say since its usage
is already guarded by ensureOpen, IMO, it should be fine. I've now
updated the patch to set inodes to null in close() and the new updated
webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/
This version looks good except it might be better if the comment just says that it clears the inodes map to allow the keys/values be GC?ed.

I revised the comment to:

????????

$ hg diff
diff -r 9338d0f52b2e src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java      Mon Jan 13 11:51:45 2020 -0500
+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java      Mon Jan 13 15:24:37 2020 -0500
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2009, 2020, 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
@@ -490,6 +490,14 @@
                 def.end();
         }

+        beginWrite();                // lock and sync
+        try {
+            // Clear the map so that its keys & values can be garbage collected
+            inodes = null;
+        } finally {
+            endWrite();
+        }
+
         IOException ioe = null;
         synchronized (tmppaths) {
             for (Path p : tmppaths) {
$
???????????

I will push the change tomorrow barring any hiccups with Mach5 or additional comments?.

Best
lance


-Alan

[cid:image001.gif at 01D5CACC.1E85C500]

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 erik.joelsson at oracle.com  Tue Jan 14 16:12:24 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 14 Jan 2020 08:12:24 -0800
Subject: RFR: 8236714: enable link-time section-gc for linux to remove
 unused code
In-Reply-To: 
References: 
Message-ID: 

(adding core-libs-dev)

Change looks good to me, but would like input from at least someone in 
core-libs.

/Erik

On 2020-01-14 06:07, Baesken, Matthias wrote:
> Hello,  the following change enables the  link-time section-gc for linux .
>
> gcc and ld support enabling "garbage collection" of unused input sections.
> This can be used to eliminate unused coding from native libraries (especially when already compiling the objects with compiler flags -ffunction-sections -fdata-sections .
> See for details the --gc-sections and --print-gc-sections parts of the ld documentation :
>
> https://linux.die.net/man/1/ld
>
>
> We had this enabled already  for  linux s390x ,  with https://bugs.openjdk.java.net/browse/JDK-8234525
> 8234525: enable link-time section-gc for linux s390x to remove unused code .
>
> This  time we enable it too for  the other linux platforms .
>
> For the other platforms I do not enable it for JVM, just for the JDK libs.  The reason is that the serviceability agent  (not supported on linux s390x )    is not  (yet) ready for the optimization .
> Below you see the results , for some libraries  a significant  size reduction can be achieved .
>
>
> Results from linux x86_64 product builds :
>
> without / with ltgc
>
> 320K / 300K    /images/jdk/lib/libsunec.so       <-------------------------
> 36K  / 36K     /images/jdk/lib/libdt_socket.so
> 280K / 276K   /images/jdk/lib/libjdwp.so
> 23M  / 23M    /images/jdk/lib/server/libjvm.so    <---- not set for libjvm.so for x86_64
> 16K  / 16K    /images/jdk/lib/server/libjsig.so
> 72K  / 72M    /images/jdk/lib/libverify.so
> 84K  / 84M   /images/jdk/lib/libjli.so
> 16K  / 16K    /images/jdk/lib/libjsig.so
> 196K / 196K   /images/jdk/lib/libjava.so
> 44K  / 44K    /images/jdk/lib/libzip.so
> 144K / 136K   /images/jdk/lib/libjimage.so
> 112K / 112K   /images/jdk/lib/libnet.so
> 100K / 100K   /images/jdk/lib/libnio.so
> 36K  / 36K    /images/jdk/lib/libsctp.so
> 576K / 556K   /images/jdk/lib/libmlib_image.so
> 752K / 752K   /images/jdk/lib/libawt.so
> 260K / 252K   /images/jdk/lib/libjavajpeg.so
> 784K / 784K   /images/jdk/lib/libfreetype.so
> 368K / 236K /images/jdk/lib/libsplashscreen.so   <-------------------------
> 88K / 88K    /images/jdk/lib/libjsound.so
> 472K / 468K    /images/jdk/lib/libawt_xawt.so
> 564K / 404K   /images/jdk/lib/liblcms.so         <--------------------------
> 48K / 48K    /images/jdk/lib/libawt_headless.so
> 12K / 12K    /images/jdk/lib/libjawt.so
> 1.5M / 900K   /images/jdk/lib/libfontmanager.so  <------------------------------
> 12K / 12K    /images/jdk/lib/libjaas.so
> 92K / 92K    /images/jdk/lib/libj2pkcs11.so
> 16K / 16K    /images/jdk/lib/libattach.so
> 8.0K / 8.0K   /images/jdk/lib/librmi.so
> 56K / 56K    /images/jdk/lib/libinstrument.so
> 16K / 16K    /images/jdk/lib/libprefs.so
> 52K / 52K    /images/jdk/lib/libj2gss.so
> 12K / 12K    /images/jdk/lib/libmanagement_agent.so
> 36K / 32K    /images/jdk/lib/libmanagement.so
> 16K / 16K    /images/jdk/lib/libextnet.so
> 20K / 20K    /images/jdk/lib/libj2pcsc.so
> 40K / 40K    /images/jdk/lib/libmanagement_ext.so
> 60K / 60K    /images/jdk/lib/libsaproc.so
>
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8236714
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/
>
>
> Thanks, Matthias

From naoto.sato at oracle.com  Tue Jan 14 16:35:47 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 14 Jan 2020 08:35:47 -0800
Subject: [15] RFR: 8187987: Add a mechanism to configure custom variants in
 HijrahChronology
Message-ID: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8187987

The proposed CSR and changeset are located at:

CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/

The spec of java.time.chrono.HijrahChronology suggests that it could 
load custom variants of Hijirah calendar type using properties files. 
However it does not work as designed. This change intends to make it work.

Naoto

From igor.ignatyev at oracle.com  Tue Jan 14 17:03:38 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 14 Jan 2020 09:03:38 -0800
Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling
In-Reply-To: <916e0375-abba-9945-b845-0fd4198513f0@oracle.com>
References: 
 
 <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com>
 <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com>
 <916e0375-abba-9945-b845-0fd4198513f0@oracle.com>
Message-ID: 

Joe and Roger, thank you for your reviews.

security-libs guys, could you please take a look?

Thanks,
-- Igor

> On Jan 2, 2020, at 12:58 PM, Roger Riggs  wrote:
> 
> The core lib changes look ok.
> 
> Roger

> On Jan 2, 2020, at 1:26 PM, Joe Darcy  wrote:
> 
> The removal of the existing TEST.properties files look fine.
> 
> Please also solicit feedback from the security libs team as their area is affected.
> 
> Roger, FYI the serial filter tests are updated as part of this changeset.
> 
> Cheers,
> 
> -Joe
> 
> On 12/23/2019 8:13 PM, Igor Ignatyev wrote:
>> Thanks David.
>> 
>> core-libs folks, could you please review jdk part of this patch?
>> 
>> Thanks,
>> -- Igor
>> 
>>> On Dec 23, 2019, at 1:33 PM, David Holmes  wrote:
>>> 
>>> Hi Igor,
>>> 
>>> Hotspot changes seem fine. Can't comment on jdk tests.
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 24/12/2019 6:42 am, Igor Ignatyev wrote:
>>>> ping?
>>>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev  wrote:
>>>>> 
>>>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/
>>>>>> 31 lines changed: 20 ins; 11 del; 0 mod;
>>>>> Hi all,
>>>>> 
>>>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore.
>>>>> 
>>>>> from JBS:
>>>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating.
>>>>> 
>>>>> testing: tier1-5
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/
>>>>> 
>>>>> Thanks,
>>>>> -- Igor


From maurizio.cimadamore at oracle.com  Tue Jan 14 18:30:17 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 14 Jan 2020 18:30:17 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
 
Message-ID: <3aa88ad8-c985-69e2-a00e-b18436effd3d@oracle.com>

Another revision which addresses some additional CSR feedback:

* SequenceLayout::withElementCount should throw if new element count < 0
* MemoryLayout::hasSize should clarify that certain layout (e.g. 
ValueLayout) always have a size

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8235837_v3

delta from previous iteration:

http://cr.openjdk.java.net/~mcimadamore/8235837_v3_delta

javadoc

http://cr.openjdk.java.net/~mcimadamore/8235837_v3_javadoc

specdiff

http://cr.openjdk.java.net/~mcimadamore/8235837_v3_specdiff/overview-summary.html 


Cheers
Maurizio

On 09/01/2020 18:36, Maurizio Cimadamore wrote:
> New revision:
>
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2
>
> delta from previous iteration:
>
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta
>
> javadoc
>
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_javadoc
>
> specdiff
>
> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_specdiff/overview-summary.html 
>
>
> Cheers
> Maurizio
>
> On 09/01/2020 14:36, Maurizio Cimadamore wrote:
>> Hi,
>> following the JEP 370 code review and CSR, certain comments that have 
>> not been addressed have been added to the tracker issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8235837
>>
>> For further evaluation. After some discussion in the Panama channel 
>> (see [1] and [2]), the Panama team has come to the following 
>> conclusions:
>>
>> * the MemoryAddress::offset(long) method should be renamed to 
>> MemoryAddress::addOffset(long)
>> * the MemorySegment::isAccessible() predicate should be dropped and 
>> replaced with the MemorySegment::ownerThread() accessor
>> * a new predicate should be added to MemoryLayout, namely 
>> MemoryLayout::hasSize() to allow clients to establish as to whether a 
>> layout contains some unsized parts
>> * a new method should be added to SequenceLayout, namely 
>> SequenceLayout::withElementCount, to create a new sequence layout 
>> with new element count
>> * 2 new helper methods should be added to MemoryLayout, namely:
>> ?? - MemoryLayout::map - to allow transformation of a layout into a 
>> new layout (by replacing the sub-layout at given path with a new layout)
>> ?? - MemoryLayout::select - to allow selection of a sub-layout given 
>> a layout path
>>
>> Overall, we think this set of change strikes a good compromise 
>> between usability, readability and minimality.
>>
>> The javadoc for the layout path-accepting methods (both old and new 
>> ones) has been significantly refactored and improved - and the 
>> toplevel javadoc section on layout paths has been enhanced to cover 
>> all the concepts. The implementation for these methods has also been 
>> consolidated greatly, which revealed subtle bugs in the old 
>> implementation which have now been rectified (new tests have been 
>> added).
>>
>> Webrev is available here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8235837/
>>
>> Specdiff for changes here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8235837_specdiff/overview-summary.html 
>>
>>
>> A draft CSR for this issue is available here (I will finalize once 
>> the review converges on the API changes):
>>
>> https://bugs.openjdk.java.net/browse/JDK-8236853
>>
>> I plan to push this to JDK 14 under the late enhancement process [3].
>>
>> Cheers
>> Maurizio
>>
>> [1] - 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006873.html
>> [2] - 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006885.html
>> [3] - https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
>>
>>
>>
>>
>>

From bob.vandette at oracle.com  Tue Jan 14 19:05:32 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 14 Jan 2020 14:05:32 -0500
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <4cbdcf7ab8b2cd99cb66590b7ad408364b7a497b.camel@redhat.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
 <4cbdcf7ab8b2cd99cb66590b7ad408364b7a497b.camel@redhat.com>
Message-ID: <45B04590-3C8C-4157-AE6E-EE67D74FA5B1@oracle.com>



> On Jan 13, 2020, at 4:04 AM, Severin Gehwolf  wrote:
> 
> Hi Bob,
> 
> On Fri, 2020-01-10 at 11:50 -0500, Bob Vandette wrote:
>> Severin,
>> 
>> The changes look ok to me.  I assume you?ve run the container tests
>> on a cgroupv2 and cgroupv1 enabled system, right?
> 
> Yes, I have.
> 
>> You?re going to have to find a ?R? reviewer.
> 
> Indeed.
> 
>> What?s the status of the hotspot cgroupv2 changes.  Have these been
>> reviewed?
> 
> Latest webvrev was v5 here:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/040120.html

It appears that cgroup v2 is getting supported in RHEL 8 and Oracle Linux 8 so I think we need to
make a strong case to get this work reviewed and integrated in JDK 15.

> 
> It included the memory_max_usage_in_bytes synthesized hack for cgroups
> v2, though. Should I remove it there as well? I'd be in favor of that.
> Otherwise nothing new. It's ready from my perspective other than
> finding another Reviewer for it.

Yes, I?d remove it.

Bob.

> 
> Thanks,
> Severin
> 
>> Bob.
>> 
>> 
>>> On Jan 9, 2020, at 2:51 PM, Severin Gehwolf 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> On Fri, 2020-01-03 at 15:37 -0500, Bob Vandette wrote:
>>>> Here are a few comments from scanning the webrev.
>>>> 
>>>> 
>>>> It looks like you can remove line 151
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java.sdiff.html
>>>> 
>>>> 151         int[] ints = new int[0];
>>>> 
>>>> ?????
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/share/classes/jdk/internal/platform/Metrics.java.sdiff.html
>>>> 
>>>> There are several comments stating that -2 == unlimited.  This is
>>>> not
>>>> the case.
>>>> 
>>>> @return count of elapsed periods or -2 if the quota is unlimited.
>>>> 
>>>> ?????
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java.sdiff.html
>>>> 
>>>> Shouldn?t you just check for cgroupv2 before trying to run the
>>>> testKernelMemoryLimit and testOomKillFlag tests?
>>>> 
>>>> ?????
>>>> 
>>>> There are a few places where getPerCpuUsage is returning ?new
>>>> long[0]? but you changed the interface to expect null
>>>> for not supported.
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java.html
>>>> 
>>>> You probably need to check all users of the APIs which used to
>>>> return
>>>> array[0] which now return null to make sure you
>>>> don?t get null pointer exceptions.
>>>> 
>>>> One example is testCpuConsumption.
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java.html
>>>> 
>>>> Also, 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java.html:167
>>>> 
>>>> 
>>>> You?ll also have to update copyrights to 2020.
>>> 
>>> Thanks for the review! Should all be fixed now. Updated webrev:
>>> 
>>> incremental: 
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
>>> full: 
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/
>>> 
>>> Note: I'll go through touched files and update copyright dates to
>>> 2020.
>>> Not all have been updated in the full webrev. It'll be done though.
>>> 
>>> Thanks,
>>> Severin
>>> 
>>>> Bob.
>>>> 
>>>> 
>>>>> On Dec 20, 2019, at 9:50 AM, Severin Gehwolf <
>>>>> sgehwolf at redhat.com>
>>>>> wrote:
>>>>> 
>>>>> Hi Bob,
>>>>> 
>>>>> Sorry for the delay to get this updated.
>>>>> 
>>>>> Changes done in this latest webrev:
>>>>> 
>>>>> 1. Rebased on top of 8226575: OperatingSystemMXBean should be
>>>>> made
>>>>>    container aware. File read ops now use privileged code.
>>>>> 2. Warning for mixed cgroup controllers and returning null for
>>>>> metrics.
>>>>> 3. Added implementations for getBlkIOServiceCount() and
>>>>>    getBlkIOServiced() using sum of rios/wios and rbytes/wbytes
>>>>> across
>>>>>    devices. Added impl for getTcpMemoryUsage()
>>>>> 4. Returning -2 for not supported (if the metric would return
>>>>> long).
>>>>>    boolean metrics now return Boolean and null if not
>>>>> supported.
>>>>> Same
>>>>>    for array return types. null if not supported for symmetry.
>>>>> 5. -XshowSettings:system output has been updated to return
>>>>> "N/A"
>>>>> for
>>>>>    when a metric is not available. E.g. "Kernel OOM killer
>>>>> enabled"
>>>>>    Boolean.
>>>>> 6. Tests have been updated to reflect this.
>>>>> 
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/
>>>>> incremental webrev:
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/
>>>>> 
>>>>> Testing: Docker tests and podman testing on cgroupsv2. I'll run
>>>>> it
>>>>> through jdk/submit as well.
>>>>> 
>>>>> Hopefully this can get pushed with 8230305 early on in the jdk
>>>>> 15
>>>>> cycle
>>>>> :)
>>>>> 
>>>>> A couple of more inline comments below.
>>>>> 
>>>>> On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote:
>>>>>> Sorry for the delay in responding.  See comments below:
>>>>>> 
>>>>>>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf <
>>>>>>> sgehwolf at redhat.com> wrote:
>>>>>>> 
>>>>>>> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Could I please get reviews of these core-libs, Linux-
>>>>>>>> only,
>>>>>>>> changes to
>>>>>>>> the Metrics subsystem? This patch implements cgroupv2
>>>>>>>> support
>>>>>>>> for
>>>>>>>> Metrics which are currently cgroupv1-only. Fedora 31
>>>>>>>> switched
>>>>>>>> to
>>>>>>>> cgroupv2 by default so it's time to get OpenJDK recognize
>>>>>>>> it.
>>>>>>>> 
>>>>>>>> Note that a couple of metrics are no longer supported
>>>>>>>> with
>>>>>>>> cgroupv2.
>>>>>>>> Most notably (not an exhaustive list, though):
>>>>>>>> 
>>>>>>>> Metrics.getKernel*() family of methods.
>>>>>>>> Metrics.getTcp*() family of methods.
>>>>>>>> Metrics.getBlkIO*() family of methods.
>>>>>>>> Metrics.isMemoryOOMKillEnabled()
>>>>>>>> 
>>>>>>>> A couple of open questions with regards to that:
>>>>>>>> 
>>>>>>>> 1)
>>>>>>>> Most API docs of Metrics make no distiction between
>>>>>>>> "unlimited" and
>>>>>>>> "not supported", both returning -1 for longs, for
>>>>>>>> example.
>>>>>>>> This is a
>>>>>>>> problem, because output of "java -XshowSettings:system
>>>>>>>> -version" will
>>>>>>>> not distinguish between unlimited and not supported
>>>>>>>> metrics.
>>>>>>>> Would it
>>>>>>>> be acceptable to change the API to distinguish those
>>>>>>>> cases so
>>>>>>>> that
>>>>>>>> LauncherHelper could display them appropriately?
>>>>>>>> 
>>>>>>>> 2)
>>>>>>>> How should we deal with "not supported" for
>>>>>>>> booleans/arrays,
>>>>>>>> etc.?
>>>>>>>> Would it make sense to return record objects from the
>>>>>>>> Metrics
>>>>>>>> API so
>>>>>>>> that this could be dealt with? E.g.
>>>>>>>> 
>>>>>>>> Metrics m = ...
>>>>>>>> MetricResult result = m.getCpuSetCpus();
>>>>>>>> switch(result.getType()) {
>>>>>>>> case NOT_SUPPORTED: /* do something */; break;
>>>>>>>> case SUPPORTED: int[] val = result.get(); break;
>>>>>>>> ...         
>>>>>>>> }
>>>>>>>> 
>>>>>>>> I'm bringing this up, because the proposed patch doesn't
>>>>>>>> deal
>>>>>>>> with the
>>>>>>>> above open questions as of yet. With that being said,
>>>>>>>> it's
>>>>>>>> mostly
>>>>>>>> identical to the proposed hotspot changes in [1].
>>>>>> 
>>>>>> For issue 1 and 2 ?
>>>>>> 
>>>>>> I wonder if we should change the API to throw
>>>>>> UnsupportedOperationException for those methods 
>>>>>> that are not available.  This exception is used quite a lot
>>>>>> in
>>>>>> the java/nio and java/net packages
>>>>>> for dealing with functionality not available on a host
>>>>>> platform.
>>>>>> 
>>>>>> As an alternate suggestion, we already return -2 for "not
>>>>>> supported" for most APIs in the hotspot
>>>>>> implementation.  We could use this for non boolean values in
>>>>>> the
>>>>>> Metrics API.  For boolean
>>>>>> values, we could change the API to return ?Boolean?.  A null
>>>>>> return would signify not
>>>>>> implemented.
>>>>> 
>>>>> This alternative has been implemented in the latest webrev.
>>>>> LauncherHelper has been updated to print "N/A" if some property
>>>>> being
>>>>> printed is not supported. Example output for cgroupsv2:
>>>>> 
>>>>> $ ./bin/java -XshowSettings:system -version
>>>>> Operating System Metrics:
>>>>>  Provider: cgroupv2
>>>>>  Effective CPU Count: 4
>>>>>  CPU Period: 100000us
>>>>>  CPU Quota: -1
>>>>>  CPU Shares: -1
>>>>>  List of Processors: N/A
>>>>>  List of Effective Processors: N/A
>>>>>  List of Memory Nodes: N/A
>>>>>  List of Available Memory Nodes: N/A
>>>>>  CPUSet Memory Pressure Enabled: N/A
>>>>>  Memory Limit: Unlimited
>>>>>  Memory Soft Limit: Unlimited
>>>>>  Memory & Swap Limit: Unlimited
>>>>>  Kernel Memory Limit: N/A
>>>>>  TCP Memory Limit: N/A
>>>>>  Out Of Memory Killer Enabled: N/A
>>>>> 
>>>>> openjdk version "15-internal" 2020-09-15
>>>>> OpenJDK Runtime Environment (build 15-internal+0-
>>>>> adhoc.sgehwolf.openjdk-head-2)
>>>>> OpenJDK 64-Bit Server VM (build 15-internal+0-
>>>>> adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111
>>>>>>>> webrev: 
>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/
>>>>>>>> 
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html
>>>>>> 
>>>>>> Should we check to make sure that there are no mixed cgroupv1
>>>>>> and
>>>>>> cgroupv2 mounted subsystems since
>>>>>> you are not supporting mixing.
>>>>> 
>>>>> Done. null is returned for metrics and a warning printed to
>>>>> stderr.
>>>>> 
>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
>>>>>> 
>>>>>> It looks looks like there may be alternate ways of reporting
>>>>>> some
>>>>>> of the metrics that you have classified as
>>>>>> RETVAL_NOT_SUPPORTED.
>>>>>> 
>>>>>> BlkIOServicedCount (io.stat)
>>>>>> KernelMemory (memory.stat)
>>>>>> TcpMemory (memory.stat)
>>>>> 
>>>>> The latest webrev has getBlkIOService* and getTcpMemoryUsage
>>>>> impls.
>>>>> I've left out kernel memory metrics as it wasn't clear what
>>>>> this
>>>>> would
>>>>> be. We can add that in a later patch. The size of this patch is
>>>>> already
>>>>> rather big.
>>>>> 
>>>>>> You could try the same trick for getMemoryAndSwapMaxUsage
>>>>>> which
>>>>>> keeps track of the highest returned value.
>>>>> 
>>>>> We've decided to not do this. getMemoryAndSwapMaxUsage and
>>>>> getMemoryMaxUsage is being returned as not supported in cgroups
>>>>> v2.
>>>>> 
>>>>> Thanks,
>>>>> Severin
>>>>> 
>>>>>> for the benefit of other reviewers, you should provide links
>>>>>> to
>>>>>> the cgroupv1 and v2 docs.
>>>>>> 
>>>>>> https://www.kernel.org/doc/Documentation/cgroup-v2.txt
>>>>>> 
>>>>>>>> Testing: jdk/submit and platform docker tests on Linux
>>>>>>>> x86_64
>>>>>>>> (with
>>>>>>>> hybrid hierarchy, docker/podman) and on Linux x86_64 with
>>>>>>>> unified
>>>>>>>> hierarchy (podman only).
>>>>>>>> 
>>>>>>>> Thoughts? Suggestions?
>>>>>> 
>>>>>> Do you think we should check the docker version being used
>>>>>> for
>>>>>> the tests to make sure it
>>>>>> supports cgroupv2?  I assume a fairly recent version is
>>>>>> required
>>>>>> to work with cgroupv2.
>>>>>> 
>>>>>> Bob.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Ping?
>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Severin
>>>>>>>> 
>>>>>>>> [1] 
>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html
> 


From bob.vandette at oracle.com  Tue Jan 14 20:05:50 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 14 Jan 2020 15:05:50 -0500
Subject: Fwd: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
References: <0ea132f764b6881d1c4b4cfa077c2ff45f9b6b16.camel@redhat.com>
Message-ID: 


Cgroup V2 is about to go mainstream this year for popular distros such as Oracle Linux 8, Redhat Linux 8 and Fedora
so this fix it?s important to get into JDK 15 so we can start shaking out this support.

Please take a look and helpsev get this change reviewed.

Thanks,
Bob Vandette


> Begin forwarded message:
> 
> From: Severin Gehwolf 
> Subject: Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy
> Date: January 13, 2020 at 4:21:18 AM EST
> To: Bob Vandette 
> 
> On Fri, 2020-01-10 at 13:16 -0500, Bob Vandette wrote:
>> Severin,
>> 
>> Where is the file CgroupUtil located?  When I looked through your webrev, I assumed that it
>> was already in JDK14 but I don?t see it.
> 
> Sorry about that. Forgot to run 'hg add' on it. This webrev has it:
> 
> full:        http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/08/webrev/
> incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/08/incremental/webrev/
> 
> Thanks,
> Severin
> 
>> Bob.
>> 
>>> On Jan 9, 2020, at 2:51 PM, Severin Gehwolf 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> On Fri, 2020-01-03 at 15:37 -0500, Bob Vandette wrote:
>>>> Here are a few comments from scanning the webrev.
>>>> 
>>>> 
>>>> It looks like you can remove line 151
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java.sdiff.html
>>>> 
>>>> 151         int[] ints = new int[0];
>>>> 
>>>> ?????
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/src/java.base/share/classes/jdk/internal/platform/Metrics.java.sdiff.html
>>>> 
>>>> There are several comments stating that -2 == unlimited.  This is
>>>> not
>>>> the case.
>>>> 
>>>> @return count of elapsed periods or -2 if the quota is unlimited.
>>>> 
>>>> ?????
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java.sdiff.html
>>>> 
>>>> Shouldn?t you just check for cgroupv2 before trying to run the
>>>> testKernelMemoryLimit and testOomKillFlag tests?
>>>> 
>>>> ?????
>>>> 
>>>> There are a few places where getPerCpuUsage is returning ?new
>>>> long[0]? but you changed the interface to expect null
>>>> for not supported.
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java.html
>>>> 
>>>> You probably need to check all users of the APIs which used to
>>>> return
>>>> array[0] which now return null to make sure you
>>>> don?t get null pointer exceptions.
>>>> 
>>>> One example is testCpuConsumption.
>>>> 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java.html
>>>> 
>>>> Also, 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java.html:167
>>>> 
>>>> 
>>>> You?ll also have to update copyrights to 2020.
>>> 
>>> Thanks for the review! Should all be fixed now. Updated webrev:
>>> 
>>> incremental: 
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
>>> full: 
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/
>>> 
>>> Note: I'll go through touched files and update copyright dates to
>>> 2020.
>>> Not all have been updated in the full webrev. It'll be done though.
>>> 
>>> Thanks,
>>> Severin
>>> 
>>>> Bob.
>>>> 
>>>> 
>>>>> On Dec 20, 2019, at 9:50 AM, Severin Gehwolf <
>>>>> sgehwolf at redhat.com>
>>>>> wrote:
>>>>> 
>>>>> Hi Bob,
>>>>> 
>>>>> Sorry for the delay to get this updated.
>>>>> 
>>>>> Changes done in this latest webrev:
>>>>> 
>>>>> 1. Rebased on top of 8226575: OperatingSystemMXBean should be
>>>>> made
>>>>>    container aware. File read ops now use privileged code.
>>>>> 2. Warning for mixed cgroup controllers and returning null for
>>>>> metrics.
>>>>> 3. Added implementations for getBlkIOServiceCount() and
>>>>>    getBlkIOServiced() using sum of rios/wios and rbytes/wbytes
>>>>> across
>>>>>    devices. Added impl for getTcpMemoryUsage()
>>>>> 4. Returning -2 for not supported (if the metric would return
>>>>> long).
>>>>>    boolean metrics now return Boolean and null if not
>>>>> supported.
>>>>> Same
>>>>>    for array return types. null if not supported for symmetry.
>>>>> 5. -XshowSettings:system output has been updated to return
>>>>> "N/A"
>>>>> for
>>>>>    when a metric is not available. E.g. "Kernel OOM killer
>>>>> enabled"
>>>>>    Boolean.
>>>>> 6. Tests have been updated to reflect this.
>>>>> 
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/
>>>>> incremental webrev:
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/
>>>>> 
>>>>> Testing: Docker tests and podman testing on cgroupsv2. I'll run
>>>>> it
>>>>> through jdk/submit as well.
>>>>> 
>>>>> Hopefully this can get pushed with 8230305 early on in the jdk
>>>>> 15
>>>>> cycle
>>>>> :)
>>>>> 
>>>>> A couple of more inline comments below.
>>>>> 
>>>>> On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote:
>>>>>> Sorry for the delay in responding.  See comments below:
>>>>>> 
>>>>>>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf <
>>>>>>> sgehwolf at redhat.com> wrote:
>>>>>>> 
>>>>>>> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Could I please get reviews of these core-libs, Linux-
>>>>>>>> only,
>>>>>>>> changes to
>>>>>>>> the Metrics subsystem? This patch implements cgroupv2
>>>>>>>> support
>>>>>>>> for
>>>>>>>> Metrics which are currently cgroupv1-only. Fedora 31
>>>>>>>> switched
>>>>>>>> to
>>>>>>>> cgroupv2 by default so it's time to get OpenJDK recognize
>>>>>>>> it.
>>>>>>>> 
>>>>>>>> Note that a couple of metrics are no longer supported
>>>>>>>> with
>>>>>>>> cgroupv2.
>>>>>>>> Most notably (not an exhaustive list, though):
>>>>>>>> 
>>>>>>>> Metrics.getKernel*() family of methods.
>>>>>>>> Metrics.getTcp*() family of methods.
>>>>>>>> Metrics.getBlkIO*() family of methods.
>>>>>>>> Metrics.isMemoryOOMKillEnabled()
>>>>>>>> 
>>>>>>>> A couple of open questions with regards to that:
>>>>>>>> 
>>>>>>>> 1)
>>>>>>>> Most API docs of Metrics make no distiction between
>>>>>>>> "unlimited" and
>>>>>>>> "not supported", both returning -1 for longs, for
>>>>>>>> example.
>>>>>>>> This is a
>>>>>>>> problem, because output of "java -XshowSettings:system
>>>>>>>> -version" will
>>>>>>>> not distinguish between unlimited and not supported
>>>>>>>> metrics.
>>>>>>>> Would it
>>>>>>>> be acceptable to change the API to distinguish those
>>>>>>>> cases so
>>>>>>>> that
>>>>>>>> LauncherHelper could display them appropriately?
>>>>>>>> 
>>>>>>>> 2)
>>>>>>>> How should we deal with "not supported" for
>>>>>>>> booleans/arrays,
>>>>>>>> etc.?
>>>>>>>> Would it make sense to return record objects from the
>>>>>>>> Metrics
>>>>>>>> API so
>>>>>>>> that this could be dealt with? E.g.
>>>>>>>> 
>>>>>>>> Metrics m = ...
>>>>>>>> MetricResult result = m.getCpuSetCpus();
>>>>>>>> switch(result.getType()) {
>>>>>>>> case NOT_SUPPORTED: /* do something */; break;
>>>>>>>> case SUPPORTED: int[] val = result.get(); break;
>>>>>>>> ...         
>>>>>>>> }
>>>>>>>> 
>>>>>>>> I'm bringing this up, because the proposed patch doesn't
>>>>>>>> deal
>>>>>>>> with the
>>>>>>>> above open questions as of yet. With that being said,
>>>>>>>> it's
>>>>>>>> mostly
>>>>>>>> identical to the proposed hotspot changes in [1].
>>>>>> 
>>>>>> For issue 1 and 2 ?
>>>>>> 
>>>>>> I wonder if we should change the API to throw
>>>>>> UnsupportedOperationException for those methods 
>>>>>> that are not available.  This exception is used quite a lot
>>>>>> in
>>>>>> the java/nio and java/net packages
>>>>>> for dealing with functionality not available on a host
>>>>>> platform.
>>>>>> 
>>>>>> As an alternate suggestion, we already return -2 for "not
>>>>>> supported" for most APIs in the hotspot
>>>>>> implementation.  We could use this for non boolean values in
>>>>>> the
>>>>>> Metrics API.  For boolean
>>>>>> values, we could change the API to return ?Boolean?.  A null
>>>>>> return would signify not
>>>>>> implemented.
>>>>> 
>>>>> This alternative has been implemented in the latest webrev.
>>>>> LauncherHelper has been updated to print "N/A" if some property
>>>>> being
>>>>> printed is not supported. Example output for cgroupsv2:
>>>>> 
>>>>> $ ./bin/java -XshowSettings:system -version
>>>>> Operating System Metrics:
>>>>>  Provider: cgroupv2
>>>>>  Effective CPU Count: 4
>>>>>  CPU Period: 100000us
>>>>>  CPU Quota: -1
>>>>>  CPU Shares: -1
>>>>>  List of Processors: N/A
>>>>>  List of Effective Processors: N/A
>>>>>  List of Memory Nodes: N/A
>>>>>  List of Available Memory Nodes: N/A
>>>>>  CPUSet Memory Pressure Enabled: N/A
>>>>>  Memory Limit: Unlimited
>>>>>  Memory Soft Limit: Unlimited
>>>>>  Memory & Swap Limit: Unlimited
>>>>>  Kernel Memory Limit: N/A
>>>>>  TCP Memory Limit: N/A
>>>>>  Out Of Memory Killer Enabled: N/A
>>>>> 
>>>>> openjdk version "15-internal" 2020-09-15
>>>>> OpenJDK Runtime Environment (build 15-internal+0-
>>>>> adhoc.sgehwolf.openjdk-head-2)
>>>>> OpenJDK 64-Bit Server VM (build 15-internal+0-
>>>>> adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111
>>>>>>>> webrev: 
>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/
>>>>>>>> 
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html
>>>>>> 
>>>>>> Should we check to make sure that there are no mixed cgroupv1
>>>>>> and
>>>>>> cgroupv2 mounted subsystems since
>>>>>> you are not supporting mixing.
>>>>> 
>>>>> Done. null is returned for metrics and a warning printed to
>>>>> stderr.
>>>>> 
>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html
>>>>>> 
>>>>>> It looks looks like there may be alternate ways of reporting
>>>>>> some
>>>>>> of the metrics that you have classified as
>>>>>> RETVAL_NOT_SUPPORTED.
>>>>>> 
>>>>>> BlkIOServicedCount (io.stat)
>>>>>> KernelMemory (memory.stat)
>>>>>> TcpMemory (memory.stat)
>>>>> 
>>>>> The latest webrev has getBlkIOService* and getTcpMemoryUsage
>>>>> impls.
>>>>> I've left out kernel memory metrics as it wasn't clear what
>>>>> this
>>>>> would
>>>>> be. We can add that in a later patch. The size of this patch is
>>>>> already
>>>>> rather big.
>>>>> 
>>>>>> You could try the same trick for getMemoryAndSwapMaxUsage
>>>>>> which
>>>>>> keeps track of the highest returned value.
>>>>> 
>>>>> We've decided to not do this. getMemoryAndSwapMaxUsage and
>>>>> getMemoryMaxUsage is being returned as not supported in cgroups
>>>>> v2.
>>>>> 
>>>>> Thanks,
>>>>> Severin
>>>>> 
>>>>>> for the benefit of other reviewers, you should provide links
>>>>>> to
>>>>>> the cgroupv1 and v2 docs.
>>>>>> 
>>>>>> https://www.kernel.org/doc/Documentation/cgroup-v2.txt
>>>>>> 
>>>>>>>> Testing: jdk/submit and platform docker tests on Linux
>>>>>>>> x86_64
>>>>>>>> (with
>>>>>>>> hybrid hierarchy, docker/podman) and on Linux x86_64 with
>>>>>>>> unified
>>>>>>>> hierarchy (podman only).
>>>>>>>> 
>>>>>>>> Thoughts? Suggestions?
>>>>>> 
>>>>>> Do you think we should check the docker version being used
>>>>>> for
>>>>>> the tests to make sure it
>>>>>> supports cgroupv2?  I assume a fairly recent version is
>>>>>> required
>>>>>> to work with cgroupv2.
>>>>>> 
>>>>>> Bob.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Ping?
>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Severin
>>>>>>>> 
>>>>>>>> [1] 
>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html
> 


From huizhe.wang at oracle.com  Tue Jan 14 20:08:30 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jan 2020 12:08:30 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
Message-ID: 

Hi,

Please review an update to BCEL 6.4.1.

JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
webrev: http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html

Similar approach as the last update:
1. Format
 ??? All format changes are kept as they are in the source in order to 
reduce the amount of changes in future updates, the exceptions are 
extreme long lines.

2. Exclusions
 ??? Contents that were not in the JDK or unnecessary for java.xml are 
excluded. This includes: the ability to load arbitrary classes and 
classes related to ClassLoader, ClassPath and JavaWrapper, and relevant 
methods and references in other classes; System Properties used to set 
cache sizes and track certain statistics (caches are set as in previous 
version); Deprecated classes and related contents.

3. Warnings
 ??? Warnings were the main reason for the changes made to the original 
source. It has been done in the previous update. They are re-applied for 
this update. The LastModified field indicates such changes to the 
original source.

4. Deprecated fields to private and references to deprecated methods
 ?? Deprecated fields in the original source were changed to private 
ones in previous update. References to deprecated methods were modified 
to use proper methods. These changes are inherited in this update.

5. Test
 ??? Since the update does not affect java.xml's usage of the BCEL 
component, it is essential to pass all of the existing tests. I've run 
the tests multiple times and noted that all of the XML functional and 
unit tests passed, so were JCK XML tests. A performance test is running.


Thanks,
Joe



From paul.sandoz at oracle.com  Tue Jan 14 21:40:06 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Jan 2020 13:40:06 -0800
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <3aa88ad8-c985-69e2-a00e-b18436effd3d@oracle.com>
References: 
 
 <3aa88ad8-c985-69e2-a00e-b18436effd3d@oracle.com>
Message-ID: <8943C91B-31E4-4504-9126-7872E2EE74CD@oracle.com>

+1
Paul.

> On Jan 14, 2020, at 10:30 AM, Maurizio Cimadamore  wrote:
> 
> Another revision which addresses some additional CSR feedback:
> 
> * SequenceLayout::withElementCount should throw if new element count < 0
> * MemoryLayout::hasSize should clarify that certain layout (e.g. ValueLayout) always have a size
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3
> 
> delta from previous iteration:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3_delta
> 
> javadoc
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3_javadoc
> 
> specdiff
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3_specdiff/overview-summary.html 
> 
> Cheers
> Maurizio
> 
> On 09/01/2020 18:36, Maurizio Cimadamore wrote:
>> New revision:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8235837_v2
>> 
>> delta from previous iteration:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta
>> 
>> javadoc
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_javadoc
>> 
>> specdiff
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8235837_v2_specdiff/overview-summary.html 
>> 
>> Cheers
>> Maurizio
>> 
>> On 09/01/2020 14:36, Maurizio Cimadamore wrote:
>>> Hi,
>>> following the JEP 370 code review and CSR, certain comments that have not been addressed have been added to the tracker issue:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8235837
>>> 
>>> For further evaluation. After some discussion in the Panama channel (see [1] and [2]), the Panama team has come to the following conclusions:
>>> 
>>> * the MemoryAddress::offset(long) method should be renamed to MemoryAddress::addOffset(long)
>>> * the MemorySegment::isAccessible() predicate should be dropped and replaced with the MemorySegment::ownerThread() accessor
>>> * a new predicate should be added to MemoryLayout, namely MemoryLayout::hasSize() to allow clients to establish as to whether a layout contains some unsized parts
>>> * a new method should be added to SequenceLayout, namely SequenceLayout::withElementCount, to create a new sequence layout with new element count
>>> * 2 new helper methods should be added to MemoryLayout, namely:
>>>    - MemoryLayout::map - to allow transformation of a layout into a new layout (by replacing the sub-layout at given path with a new layout)
>>>    - MemoryLayout::select - to allow selection of a sub-layout given a layout path
>>> 
>>> Overall, we think this set of change strikes a good compromise between usability, readability and minimality.
>>> 
>>> The javadoc for the layout path-accepting methods (both old and new ones) has been significantly refactored and improved - and the toplevel javadoc section on layout paths has been enhanced to cover all the concepts. The implementation for these methods has also been consolidated greatly, which revealed subtle bugs in the old implementation which have now been rectified (new tests have been added).
>>> 
>>> Webrev is available here:
>>> 
>>> http://cr.openjdk.java.net/~mcimadamore/8235837/
>>> 
>>> Specdiff for changes here:
>>> 
>>> http://cr.openjdk.java.net/~mcimadamore/8235837_specdiff/overview-summary.html 
>>> 
>>> A draft CSR for this issue is available here (I will finalize once the review converges on the API changes):
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8236853
>>> 
>>> I plan to push this to JDK 14 under the late enhancement process [3].
>>> 
>>> Cheers
>>> Maurizio
>>> 
>>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006873.html
>>> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2019-December/006885.html
>>> [3] - https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
>>> 
>>> 
>>> 
>>> 
>>> 


From brian.burkhalter at oracle.com  Tue Jan 14 21:59:29 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Jan 2020 13:59:29 -0800
Subject: JDK 14 RFR of JDK-8233452: java.math.BigDecimal.sqrt() with
 RoundingMode.FLOOR results in incorrect result
In-Reply-To: <3af1b7f1-3cd8-7686-f57c-54ca9e80730a@oracle.com>
References: <402ee79d-4c8c-7af1-10fc-f8a8bf0864de@oracle.com>
 
 <3af1b7f1-3cd8-7686-f57c-54ca9e80730a@oracle.com>
Message-ID: 

Hi Joe,

This looks good modulo a few picayune things I noticed in the implementation and test. Line numbers refer to the updated version of each file.

1. Implementation

2: Newer copyright year 2020, of course.
2150: s/much many/many/.
2185: I suppose that this is in case targetPrecision overflowed.
2231: Why ulp = ulp?
2376: s/larger than/larger/

2. Test

2: Newer copyright year 2020, of course.
39: Perhaps for symmetry with BigInteger (https://bugs.openjdk.java.net/browse/JDK-8152237) we should add BigDecimal.TWO at a later date.
112: s/valueOf(2)/TWO/
117: Alignment of RoundingMode.DOWN
137-138:

Probe inputs with two digits of precision, 10 ? 99 and those
values scaled by 10^-1, 1.0, ? 9.9, and by 10^-2, 0.1, ? 0.99.

167: Two spaces after return
282, 303: ?doesn?t not improperly? sounds awkward: should be ?does not improperly??
289, 310: ?Sqrt root? also sounds awkward
296, 317: Extra space before ?:?
316: s/down/up/ ?
337: s/rounding down/half even/ ?
362: s/near 1 half even/?near 1 ? + mc.toString()/ ?
397: delete commented out line?
520: s/+1)/+ 1)/
607: Introduce a square() method in BigSquareRoot also for parity with BigDecimal?

Brian

> On Jan 8, 2020, at 4:33 PM, Joe Darcy  wrote:
> 
> Some further refinements to the implementation and tests ready for re-review:
> 
>     http://cr.openjdk.java.net/~darcy/8233452.4/ 
> The fix-up code for directed roundings (up, down, etc.) was corrected to properly handle rounding down when the interim result is a power of 10, in this case 1.0. The adjustment down in that case needs to be reduced in size since the size of an ulp changes at exponent boundaries. The regression tests cover this situation.
> 
> The assertion checks on the numerical properties of the result were restructured to be more informative. One assert was overly strict and made weaker to accommodate the sort of situation discussed in the comments.
> 
> The comments make reference to the "2p + 2" property. This concerns floating-point rounding and when a double-rounding problem can be avoided. In brief, if you first round to (p + k) digits than then round that result to p digits, a difference result can be computed than if a single rounding to p digits occurred. For example, both the roundings to (p + k) and p digits could round up when a single rounding up would not round up. However, if the first rounding is to at least (2p + 2) digits, a second rounding to p digits will *not* have the double rounding hazard for +, -, *, / and square root.
> 
> The main Newton loop in the square root implementation has been modified to compute at least (2p + 2) digits so the rounding to p digits will be correct without a fix-up. With sufficient analysis, computing to about p digitis instead and doing a fix-up should be possible, but I'll leave that as a refinement for another day.
> 


From huizhe.wang at oracle.com  Tue Jan 14 22:42:38 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jan 2020 14:42:38 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: 
References: 
Message-ID: <632189f6-2593-3003-83fa-a0d26bd033df@oracle.com>

Performance test results show no regression over the current build (15-b5).

-Joe

On 1/14/20 12:08 PM, Joe Wang wrote:
> A performance test is running. 


From huizhe.wang at oracle.com  Tue Jan 14 23:35:56 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jan 2020 15:35:56 -0800
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
Message-ID: <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>

Hi Naoto,

Since it's dealing with non-standard properties files, is there a need 
to verify the files? The constructor (HijrahChronology) does check 
whether the id or type is empty. If there is no existing process to 
validate, it's probably not worth it to spend time as it's rare and it's 
config time.

The test summary states "Test image creation", it may be better to say 
sth. like verifies custom configuration?

Best,
Joe

On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8187987
>
> The proposed CSR and changeset are located at:
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>
> The spec of java.time.chrono.HijrahChronology suggests that it could 
> load custom variants of Hijirah calendar type using properties files. 
> However it does not work as designed. This change intends to make it 
> work.
>
> Naoto


From brian.burkhalter at oracle.com  Wed Jan 15 01:49:12 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Jan 2020 17:49:12 -0800
Subject: 8237186: Fix typo in copyright header of
 java/io/Reader/TransferTo.java 
Message-ID: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>

Please review this trivial fix

--- a/test/jdk/java/io/Reader/TransferTo.java
+++ b/test/jdk/java/io/Reader/TransferTo.java
@@ -14,7 +14,7 @@
  *
  * You should have received a copy of the GNU General Public License version
  * 2 along with this work; if not, write to the Free Software Foundation,
- * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  * or visit www.oracle.com if you need additional information or have any

for https://bugs.openjdk.java.net/browse/JDK-8237186.

Thanks,

Brian

From brian.burkhalter at oracle.com  Wed Jan 15 01:51:33 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Jan 2020 17:51:33 -0800
Subject: 8237186: Fix typo in copyright header of
 java/io/Reader/TransferTo.java
In-Reply-To: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>
References: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>
Message-ID: 

Oops: correction.

--- a/test/jdk/java/io/Reader/TransferTo.java
+++ b/test/jdk/java/io/Reader/TransferTo.java
@@ -6,15 +6,15 @@
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.
  *
- * This code is distributed source the hope that it will be useful, but WITHOUT
+ * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
- * version 2 for more details (a copy is included source the LICENSE file that
+ * version 2 for more details (a copy is included in the LICENSE file that
  * accompanied this code).
  *
  * You should have received a copy of the GNU General Public License version
  * 2 along with this work; if not, write to the Free Software Foundation,
- * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  * or visit www.oracle.com if you need additional information or have any

There were three of those culprits.

Thanks,

Brian

> On Jan 14, 2020, at 5:49 PM, Brian Burkhalter  wrote:
> 
> Please review this trivial fix
> 
> --- a/test/jdk/java/io/Reader/TransferTo.java
> +++ b/test/jdk/java/io/Reader/TransferTo.java
> @@ -14,7 +14,7 @@
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com  if you need additional information or have any
> 
> for https://bugs.openjdk.java.net/browse/JDK-8237186 .


From mandy.chung at oracle.com  Wed Jan 15 01:52:49 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Jan 2020 17:52:49 -0800
Subject: 8237186: Fix typo in copyright header of
 java/io/Reader/TransferTo.java
In-Reply-To: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>
References: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>
Message-ID: <77497c6e-0817-9ba7-9329-0bbe291359f0@oracle.com>

+1

Mandy

On 1/14/20 5:49 PM, Brian Burkhalter wrote:
> Please review this trivial fix
>
> --- a/test/jdk/java/io/Reader/TransferTo.java
> +++ b/test/jdk/java/io/Reader/TransferTo.java
> @@ -14,7 +14,7 @@
>    *
>    * You should have received a copy of the GNU General Public License version
>    * 2 along with this work; if not, write to the Free Software Foundation,
> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>    *
>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>    * or visit www.oracle.com if you need additional information or have any
>
> for https://bugs.openjdk.java.net/browse/JDK-8237186.
>
> Thanks,
>
> Brian


From lance.andersen at oracle.com  Wed Jan 15 01:57:45 2020
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Tue, 14 Jan 2020 20:57:45 -0500
Subject: 8237186: Fix typo in copyright header of
 java/io/Reader/TransferTo.java
In-Reply-To: 
References: 
Message-ID: <3EE0D606-A9C2-4EFE-B87F-F616466D468D@oracle.com>

Looks ok Brian 

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
Sent from my iPad

> On Jan 14, 2020, at 8:51 PM, Brian Burkhalter  wrote:
> 
> ?Oops: correction.
> 
> --- a/test/jdk/java/io/Reader/TransferTo.java
> +++ b/test/jdk/java/io/Reader/TransferTo.java
> @@ -6,15 +6,15 @@
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
> - * This code is distributed source the hope that it will be useful, but WITHOUT
> + * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> - * version 2 for more details (a copy is included source the LICENSE file that
> + * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
> 
> There were three of those culprits.
> 
> Thanks,
> 
> Brian
> 
>> On Jan 14, 2020, at 5:49 PM, Brian Burkhalter  wrote:
>> 
>> Please review this trivial fix
>> 
>> --- a/test/jdk/java/io/Reader/TransferTo.java
>> +++ b/test/jdk/java/io/Reader/TransferTo.java
>> @@ -14,7 +14,7 @@
>> *
>> * You should have received a copy of the GNU General Public License version
>> * 2 along with this work; if not, write to the Free Software Foundation,
>> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> *
>> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> * or visit www.oracle.com  if you need additional information or have any
>> 
>> for https://bugs.openjdk.java.net/browse/JDK-8237186 .
> 

From mandy.chung at oracle.com  Wed Jan 15 02:03:45 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Jan 2020 18:03:45 -0800
Subject: 8237186: Fix typo in copyright header of
 java/io/Reader/TransferTo.java
In-Reply-To: 
References: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>
 
Message-ID: 

Looks okay.? I wonder how the word "source" got creeped in :-)

Mandy

On 1/14/20 5:51 PM, Brian Burkhalter wrote:
> Oops: correction.
>
> --- a/test/jdk/java/io/Reader/TransferTo.java
> +++ b/test/jdk/java/io/Reader/TransferTo.java
> @@ -6,15 +6,15 @@
>    * under the terms of the GNU General Public License version 2 only, as
>    * published by the Free Software Foundation.
>    *
> - * This code is distributed source the hope that it will be useful, but WITHOUT
> + * This code is distributed in the hope that it will be useful, but WITHOUT
>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> - * version 2 for more details (a copy is included source the LICENSE file that
> + * version 2 for more details (a copy is included in the LICENSE file that
>    * accompanied this code).
>    *
>    * You should have received a copy of the GNU General Public License version
>    * 2 along with this work; if not, write to the Free Software Foundation,
> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>    *
>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>    * or visit www.oracle.com if you need additional information or have any
>
> There were three of those culprits.
>
> Thanks,
>
> Brian
>
>> On Jan 14, 2020, at 5:49 PM, Brian Burkhalter  wrote:
>>
>> Please review this trivial fix
>>
>> --- a/test/jdk/java/io/Reader/TransferTo.java
>> +++ b/test/jdk/java/io/Reader/TransferTo.java
>> @@ -14,7 +14,7 @@
>>   *
>>   * You should have received a copy of the GNU General Public License version
>>   * 2 along with this work; if not, write to the Free Software Foundation,
>> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>   *
>>   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>   * or visit www.oracle.com  if you need additional information or have any
>>
>> for https://bugs.openjdk.java.net/browse/JDK-8237186 .


From naoto.sato at oracle.com  Wed Jan 15 02:04:57 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 14 Jan 2020 18:04:57 -0800
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
Message-ID: <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>

Hi Joe,

Thank you for the review. Please find my comments below:

On 1/14/20 3:35 PM, Joe Wang wrote:
> Hi Naoto,
> 
> Since it's dealing with non-standard properties files, is there a need 
> to verify the files? The constructor (HijrahChronology) does check 
> whether the id or type is empty. If there is no existing process to 
> validate, it's probably not worth it to spend time as it's rare and it's 
> config time.

IIUC, the idea is to create the instance at class loading time (thus the 
faster the better) and cache it, then check the validity later at actual 
method invocation (cf. checkCalendarInit() method).

> 
> The test summary states "Test image creation", it may be better to say 
> sth. like verifies custom configuration?

Good catch! I was simply copying some portion from other test case. 
Corrected:

https://cr.openjdk.java.net/~naoto/8187987/webrev.01/

Naoto

> 
> Best,
> Joe
> 
> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>
>> The proposed CSR and changeset are located at:
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>
>> The spec of java.time.chrono.HijrahChronology suggests that it could 
>> load custom variants of Hijirah calendar type using properties files. 
>> However it does not work as designed. This change intends to make it 
>> work.
>>
>> Naoto
> 

From huizhe.wang at oracle.com  Wed Jan 15 02:37:21 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jan 2020 18:37:21 -0800
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
Message-ID: <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>



On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thank you for the review. Please find my comments below:
>
> On 1/14/20 3:35 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> Since it's dealing with non-standard properties files, is there a 
>> need to verify the files? The constructor (HijrahChronology) does 
>> check whether the id or type is empty. If there is no existing 
>> process to validate, it's probably not worth it to spend time as it's 
>> rare and it's config time.
>
> IIUC, the idea is to create the instance at class loading time (thus 
> the faster the better) and cache it, then check the validity later at 
> actual method invocation (cf. checkCalendarInit() method).

Make sense.
>
>>
>> The test summary states "Test image creation", it may be better to 
>> say sth. like verifies custom configuration?
>
> Good catch! I was simply copying some portion from other test case. 
> Corrected:
>
> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/

Looks good to me.

Best regards,
Joe

>
> Naoto
>
>>
>> Best,
>> Joe
>>
>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>
>>> The proposed CSR and changeset are located at:
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>
>>> The spec of java.time.chrono.HijrahChronology suggests that it could 
>>> load custom variants of Hijirah calendar type using properties 
>>> files. However it does not work as designed. This change intends to 
>>> make it work.
>>>
>>> Naoto
>>


From joe.darcy at oracle.com  Wed Jan 15 04:21:46 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 14 Jan 2020 20:21:46 -0800
Subject: JDK 14 RFR of JDK-8233452: java.math.BigDecimal.sqrt() with
 RoundingMode.FLOOR results in incorrect result
In-Reply-To: 
References: <402ee79d-4c8c-7af1-10fc-f8a8bf0864de@oracle.com>
 
 <3af1b7f1-3cd8-7686-f57c-54ca9e80730a@oracle.com>
 
Message-ID: <96934d5a-0cca-a6db-ac0c-6806f343a198@oracle.com>

Hi Brian,

Pushed with recommend changes; webrev of final version:

 ??? http://cr.openjdk.java.net/~darcy/8233452.5

Thanks,

-Joe

On 1/14/2020 1:59 PM, Brian Burkhalter wrote:
> Hi Joe,
>
> This looks good modulo a few picayune things I noticed in the 
> implementation and test. Line numbers refer to the updated version of 
> each file.
>
> 1. Implementation
>
> 2: Newer copyright year 2020, of course.

Will do.

> 2150: s/much many/many/.
> 2185: I suppose that this is in case targetPrecision overflowed.

Right; I'll add a comment to make that explicit.

The code as written is probably not fully overflow-hardened, but I at 
least wanted to avoid certain infinite loops from coming up.


> 2231: Why ulp = ulp?


Just a typo; will fix before pushing.

> 2376: s/larger than/larger/
>
> 2. Test
>
> 2: Newer copyright year 2020, of course.
> 39: Perhaps for symmetry with BigInteger 
> (https://bugs.openjdk.java.net/browse/JDK-8152237) we should add 
> BigDecimal.TWO at a later date.
> 112: s/valueOf(2)/TWO/
> 117: Alignment of RoundingMode.DOWN
> 137-138:
>
> Probe inputs with two digits of precision, 10 ? 99 and those
> values scaled by 10^-1, 1.0, ? 9.9, and by 10^-2, 0.1, ? 0.99.


Corrected.


>
> 167: Two spaces after return
> 282, 303: ?doesn?t not improperly? sounds awkward: should be ?does not 
> improperly??
> 289, 310: ?Sqrt root? also sounds awkward
> 296, 317: Extra space before ?:?
> 316: s/down/up/ ?

Yep; cut and paste issue.


> 337: s/rounding down/half even/ ?
> 362: s/near 1 half even/?near 1 ? + mc.toString()/ ?
> 397: delete commented out line?
> 520: s/+1)/+ 1)/
> 607: Introduce a square() method in BigSquareRoot also for parity with 
> BigDecimal?

Addressed.



From james at deepsymmetry.org  Wed Jan 15 05:57:55 2020
From: james at deepsymmetry.org (James Elliott)
Date: Tue, 14 Jan 2020 23:57:55 -0600
Subject: jpackage and macOS Catalina notarization
In-Reply-To: <59AB5E37-0D67-4C09-B4CA-0F83C0A4432D@deepsymmetry.org>
References: <59AB5E37-0D67-4C09-B4CA-0F83C0A4432D@deepsymmetry.org>
Message-ID: 

I can report that this question is no longer theoretical. As of this morning, Apple began rejecting notarization of my disk images that had been code-signed by jpackage for lacking secure timestamps and not using the hardened runtime. So jpackage-signed applications are no longer accepted by macOS Catalina.

Using the resources below, I found a way to forcibly re-sign all the executables in my disk image with timestamps and the hardened runtime, along with the entitlements required for the JVM to work. I hope that jpackage can be updated soon to do this on its own, because not all developers are going to be as doggedly persistent as I have in figuring out how to get Java applications packaged as working Mac applications. If anyone would like to see the exact script that is now working for me (I am using GitHub Actions to continuously deploy my releases so I can just point you at a file in the public repository), or ask any follow-up questions, I would be happy to help.

I also notice that the background image and Applications folder alias that are supposed to be in the disk image don?t seem to work in Catalina, so I may give up on having jpackage create my disk images as well, and do that using native tools, until that can be fixed. (I realize it is in early access still, and hope these issues are being worked on.)

A colleague who was creating my Windows builds reports that there are Wix settings missing in the jpackage Windows MSI installers that will prevent automatic upgrading/replacement. I am trying to encourage him to join this mailing list so he can share the details, but if anyone would like details before he does I can relay them.

Thanks,

	-James

> On Jan 4, 2020, at 00:50, James Elliott  wrote:
> 
> Hello, everyone, I finally found this list, as well as a way to search it, and so hope this question is relevant and appropriate and not already answered.
> 
> For some time I have been using an old javapackager along with a newer release of jlink to create native macOS installers for a free, open-source Swing application, and am very excited to see that JEP-343 is finally on the horizon so I soon can stop relying on the ancient javapackager. Still, its ability to code sign my installer DMG has been very beneficial to my less-Java-savvy users (generally musicians and light/laser/video technicians running stage shows).
> 
> Apple?s current operating system, Catalina, adds still more hoops for developers to jump through in order to enable their software to be run without complaint and complexity: It needs to be notarized (uploaded to Apple and scanned for malicious code and other unsafe properties). I am not asking if jpackage might assist with the notarization step any time soon; that is something that can be accomplished separately after the code-signed package or disk image has been produced.
> 
> The issue, however, is that for notarization to succeed, the code signing must be performed in a manner that causes the application to use the hardened runtime, and therefore a set of entitlements must be added in order for Java code to run successfully. (These requirements have been temporarily relaxed because so few developers were ready for them, but they will be returning soon.) I could not see any evidence in the jpackage documentation or help text that it could support these code signing options, specifically ?timestamp, ?options runtime, and ?entitlements entitlements.plist (for full details on getting this process to work, I found the following two articles incredibly helpful: http://www.zarkonnen.com/signing_notarizing_catalina  and http://kothar.net/macos_catalina_java_11  ).
> 
> Is this something that is on the radar for a future jpackage release? Failing that, is there a way to perform the code signing separately and still use jpackage to produce the disk image?
> 
> Thanks for any thoughts or insight you might be able to share,
> 
> 	-James


From alexey.semenyuk at oracle.com  Wed Jan 15 07:29:35 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 15 Jan 2020 02:29:35 -0500
Subject: RFR: JDK-8236132: Add missing properties to msi installers
In-Reply-To: <581fcb80-58a3-332c-5b28-7c95422caef0@oracle.com>
References: 
 
 <581fcb80-58a3-332c-5b28-7c95422caef0@oracle.com>
Message-ID: <5cfca416-d9d5-46cb-57d9-dc75b94201e1@oracle.com>

Alexander,

Icon can be configured on jpackage command line and should not be 
overridden in custom overrides.wxi file. This is the reason why I didn't 
put its description in the default overrides.wxi file.
JpIcon is just one of WiX variables to pass configuration data from 
jpackage Java into WiX toolset.

- Alexey

On 1/6/2020 7:36 PM, Alexander Matveev wrote:
> Hi Alexey,
>
> Can you add description for JpIcon to overrides.wxi, otherwise looks 
> fine.
>
> Thanks,
> Alexander
>
> On 12/20/2019 12:16 PM, Alexey Semenyuk wrote:
>> Please review fix [2] for jpackage bug [1].
>>
>> Add properties to msi installers to properly display installation 
>> location and icon of the application in the list of installed 
>> applications.
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8236132
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8236132/webrev.00
>


From matthias.baesken at sap.com  Wed Jan 15 08:27:09 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 15 Jan 2020 08:27:09 +0000
Subject: RFR: 8236714: enable link-time section-gc for linux to remove
 unused code
In-Reply-To: 
References: 
 
Message-ID: 

Hi Erik, thanks for the review and for forwarding ,  you are correct  corelibs-dev is probably  interested in this as well .

Best regards, Matthias


> (adding core-libs-dev)
> 
> Change looks good to me, but would like input from at least someone in
> core-libs.
> 
> /Erik
> 
> On 2020-01-14 06:07, Baesken, Matthias wrote:
> > Hello,  the following change enables the  link-time section-gc for linux .
> >
> > gcc and ld support enabling "garbage collection" of unused input sections.
> > This can be used to eliminate unused coding from native libraries
> (especially when already compiling the objects with compiler flags -ffunction-
> sections -fdata-sections .
> > See for details the --gc-sections and --print-gc-sections parts of the ld
> documentation :
> >
> > https://linux.die.net/man/1/ld
> >
> >
> > We had this enabled already  for  linux s390x ,  with
> https://bugs.openjdk.java.net/browse/JDK-8234525
> > 8234525: enable link-time section-gc for linux s390x to remove unused code
> .
> >
> > This  time we enable it too for  the other linux platforms .
> >
> > For the other platforms I do not enable it for JVM, just for the JDK libs.  The
> reason is that the serviceability agent  (not supported on linux s390x )    is not
> (yet) ready for the optimization .
> > Below you see the results , for some libraries  a significant  size reduction
> can be achieved .
> >
> >
> > Results from linux x86_64 product builds :
> >
> > without / with ltgc
> >
> > 320K / 300K    /images/jdk/lib/libsunec.so       <-------------------------
> > 36K  / 36K     /images/jdk/lib/libdt_socket.so
> > 280K / 276K   /images/jdk/lib/libjdwp.so
> > 23M  / 23M    /images/jdk/lib/server/libjvm.so    <---- not set for libjvm.so
> for x86_64
> > 16K  / 16K    /images/jdk/lib/server/libjsig.so
> > 72K  / 72M    /images/jdk/lib/libverify.so
> > 84K  / 84M   /images/jdk/lib/libjli.so
> > 16K  / 16K    /images/jdk/lib/libjsig.so
> > 196K / 196K   /images/jdk/lib/libjava.so
> > 44K  / 44K    /images/jdk/lib/libzip.so
> > 144K / 136K   /images/jdk/lib/libjimage.so
> > 112K / 112K   /images/jdk/lib/libnet.so
> > 100K / 100K   /images/jdk/lib/libnio.so
> > 36K  / 36K    /images/jdk/lib/libsctp.so
> > 576K / 556K   /images/jdk/lib/libmlib_image.so
> > 752K / 752K   /images/jdk/lib/libawt.so
> > 260K / 252K   /images/jdk/lib/libjavajpeg.so
> > 784K / 784K   /images/jdk/lib/libfreetype.so
> > 368K / 236K /images/jdk/lib/libsplashscreen.so   <-------------------------
> > 88K / 88K    /images/jdk/lib/libjsound.so
> > 472K / 468K    /images/jdk/lib/libawt_xawt.so
> > 564K / 404K   /images/jdk/lib/liblcms.so         <--------------------------
> > 48K / 48K    /images/jdk/lib/libawt_headless.so
> > 12K / 12K    /images/jdk/lib/libjawt.so
> > 1.5M / 900K   /images/jdk/lib/libfontmanager.so  <------------------------------
> > 12K / 12K    /images/jdk/lib/libjaas.so
> > 92K / 92K    /images/jdk/lib/libj2pkcs11.so
> > 16K / 16K    /images/jdk/lib/libattach.so
> > 8.0K / 8.0K   /images/jdk/lib/librmi.so
> > 56K / 56K    /images/jdk/lib/libinstrument.so
> > 16K / 16K    /images/jdk/lib/libprefs.so
> > 52K / 52K    /images/jdk/lib/libj2gss.so
> > 12K / 12K    /images/jdk/lib/libmanagement_agent.so
> > 36K / 32K    /images/jdk/lib/libmanagement.so
> > 16K / 16K    /images/jdk/lib/libextnet.so
> > 20K / 20K    /images/jdk/lib/libj2pcsc.so
> > 40K / 40K    /images/jdk/lib/libmanagement_ext.so
> > 60K / 60K    /images/jdk/lib/libsaproc.so
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8236714
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/
> >
> >
> > Thanks, Matthias

From chris.hegarty at oracle.com  Wed Jan 15 08:48:51 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Jan 2020 08:48:51 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <3aa88ad8-c985-69e2-a00e-b18436effd3d@oracle.com>
References: 
 
 <3aa88ad8-c985-69e2-a00e-b18436effd3d@oracle.com>
Message-ID: <35C2EA20-96F9-4159-8B40-C3346B8040BC@oracle.com>


> On 14 Jan 2020, at 18:30, Maurizio Cimadamore  wrote:
> 
> Another revision which addresses some additional CSR feedback:
> 
> * SequenceLayout::withElementCount should throw if new element count < 0
> * MemoryLayout::hasSize should clarify that certain layout (e.g. ValueLayout) always have a size
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3
> 
> delta from previous iteration:
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3_delta
> 
> javadoc
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3_javadoc
> 
> specdiff
> 
> http://cr.openjdk.java.net/~mcimadamore/8235837_v3_specdiff/overview-summary.html 

This latest revision looks good.

-Chris.

From pavel.rappo at oracle.com  Wed Jan 15 09:40:10 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Jan 2020 09:40:10 +0000
Subject: 8237186: Fix typo in copyright header of
 java/io/Reader/TransferTo.java
In-Reply-To: 
References: <11CD4342-A014-40BB-BEEE-F8D8D9A54367@oracle.com>
 
 
Message-ID: <740D2781-1805-44B4-B79E-2EAC1AEBD5C2@oracle.com>

:%s/in /source /g 

(or similar) I guess.

> On 15 Jan 2020, at 02:03, Mandy Chung  wrote:
> 
> Looks okay.  I wonder how the word "source" got creeped in :-)
> 
> Mandy
> 
> On 1/14/20 5:51 PM, Brian Burkhalter wrote:
>> Oops: correction.
>> 
>> --- a/test/jdk/java/io/Reader/TransferTo.java
>> +++ b/test/jdk/java/io/Reader/TransferTo.java
>> @@ -6,15 +6,15 @@
>>   * under the terms of the GNU General Public License version 2 only, as
>>   * published by the Free Software Foundation.
>>   *
>> - * This code is distributed source the hope that it will be useful, but WITHOUT
>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>>   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>   * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> - * version 2 for more details (a copy is included source the LICENSE file that
>> + * version 2 for more details (a copy is included in the LICENSE file that
>>   * accompanied this code).
>>   *
>>   * You should have received a copy of the GNU General Public License version
>>   * 2 along with this work; if not, write to the Free Software Foundation,
>> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>   *
>>   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>   * or visit www.oracle.com if you need additional information or have any
>> 
>> There were three of those culprits.
>> 
>> Thanks,
>> 
>> Brian
>> 
>>> On Jan 14, 2020, at 5:49 PM, Brian Burkhalter  wrote:
>>> 
>>> Please review this trivial fix
>>> 
>>> --- a/test/jdk/java/io/Reader/TransferTo.java
>>> +++ b/test/jdk/java/io/Reader/TransferTo.java
>>> @@ -14,7 +14,7 @@
>>>  *
>>>  * You should have received a copy of the GNU General Public License version
>>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>> - * Inc., 51 Franklsource St, Fifth Floor, Boston, MA 02110-1301 USA.
>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>  *
>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>>  * or visit www.oracle.com  if you need additional information or have any
>>> 
>>> for https://bugs.openjdk.java.net/browse/JDK-8237186 .
> 


From kiran.sidhartha.ravikumar at oracle.com  Wed Jan 15 12:07:10 2020
From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar)
Date: Wed, 15 Jan 2020 12:07:10 +0000
Subject: RFR [15] 8161558: ListIterator should not discard cause on exception
Message-ID: 

Hi Guys,


Could someone please review my fix to add missing standard constructor 
overloads to NoSuchElementException class and update the AbstractList 
class to use them.


A CSR was filed and approved. Along with the code change a new test is 
added to verify the behavior.


Please find the webrev at? -


http://cr.openjdk.java.net/~kravikumar/8161558/webrev.00/


JBS: https://bugs.openjdk.java.net/browse/JDK-8161558


Thanks,

Kiran


From martinrb at google.com  Wed Jan 15 12:46:02 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 15 Jan 2020 04:46:02 -0800
Subject: RFR [15] 8161558: ListIterator should not discard cause on
 exception
In-Reply-To: 
References: 
Message-ID: 

Hi Kiran,

Looks good to me, but I always nitpick ...

Stray semicolon?
       var iterator = list.listIterator(list.size());; // position at end

I would have documented whitebox test assumptions: that nCopies iterators
are implemented via AbstractList, and that AbstractList's list iterator
inherits behavior from iterator.

I probably would have added a plain iterator test, and might have
refactored the code that tests the exception.


On Wed, Jan 15, 2020 at 4:07 AM Kiran Ravikumar <
kiran.sidhartha.ravikumar at oracle.com> wrote:

> Hi Guys,
>
>
> Could someone please review my fix to add missing standard constructor
> overloads to NoSuchElementException class and update the AbstractList
> class to use them.
>
>
> A CSR was filed and approved. Along with the code change a new test is
> added to verify the behavior.
>
>
> Please find the webrev at  -
>
>
> http://cr.openjdk.java.net/~kravikumar/8161558/webrev.00/
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8161558
>
>
> Thanks,
>
> Kiran
>
>

From mp at jugs.org  Wed Jan 15 13:54:55 2020
From: mp at jugs.org (Michael Paus)
Date: Wed, 15 Jan 2020 14:54:55 +0100
Subject: jpackage and macOS Catalina notarization
In-Reply-To: 
References: 
Message-ID: <84d90e7b-fbc8-4be5-09a2-56457edf4e23@jugs.org>

> I also notice that the background image and Applications folder alias that are supposed to be in the disk image don?t seem to work in Catalina, so I may give up on having jpackage create my disk images as well, and do that using native tools, until that can be fixed. (I realize it is in early access still, and hope these issues are being worked on.)

What exactly is wrong with the background image? Were there any build 
errors reported during packaging?

The creation of the disk image is done via some script and you can tell 
jpackage via the
option --temp  to dump that into a temporary folder. You 
can modify it
and place it into another folder which you tell jpackage via 
--resource-dir 
Maybe you can fix your issue that way or at least you can find out what 
the problem is.

I am still on the previous version of macOS until all these Catalina 
issues are sorted out.
Java/JavaFX on Catalina is a mess right now.



From erik.joelsson at oracle.com  Wed Jan 15 14:06:59 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 15 Jan 2020 06:06:59 -0800
Subject: RFR: 8236714: enable link-time section-gc for linux to remove
 unused code
In-Reply-To: 
References: 
 
 
Message-ID: <998c4a08-5670-f51d-4625-9c7e984b4b5d@oracle.com>

Given the discussion regarding lto on hotspot and the extreme increased 
build time, have you noticed any difference in build times with this patch?

/Erik

On 2020-01-15 00:27, Baesken, Matthias wrote:
> Hi Erik, thanks for the review and for forwarding ,  you are correct  corelibs-dev is probably  interested in this as well .
>
> Best regards, Matthias
>
>
>> (adding core-libs-dev)
>>
>> Change looks good to me, but would like input from at least someone in
>> core-libs.
>>
>> /Erik
>>
>> On 2020-01-14 06:07, Baesken, Matthias wrote:
>>> Hello,  the following change enables the  link-time section-gc for linux .
>>>
>>> gcc and ld support enabling "garbage collection" of unused input sections.
>>> This can be used to eliminate unused coding from native libraries
>> (especially when already compiling the objects with compiler flags -ffunction-
>> sections -fdata-sections .
>>> See for details the --gc-sections and --print-gc-sections parts of the ld
>> documentation :
>>> https://linux.die.net/man/1/ld
>>>
>>>
>>> We had this enabled already  for  linux s390x ,  with
>> https://bugs.openjdk.java.net/browse/JDK-8234525
>>> 8234525: enable link-time section-gc for linux s390x to remove unused code
>> .
>>> This  time we enable it too for  the other linux platforms .
>>>
>>> For the other platforms I do not enable it for JVM, just for the JDK libs.  The
>> reason is that the serviceability agent  (not supported on linux s390x )    is not
>> (yet) ready for the optimization .
>>> Below you see the results , for some libraries  a significant  size reduction
>> can be achieved .
>>>
>>> Results from linux x86_64 product builds :
>>>
>>> without / with ltgc
>>>
>>> 320K / 300K    /images/jdk/lib/libsunec.so       <-------------------------
>>> 36K  / 36K     /images/jdk/lib/libdt_socket.so
>>> 280K / 276K   /images/jdk/lib/libjdwp.so
>>> 23M  / 23M    /images/jdk/lib/server/libjvm.so    <---- not set for libjvm.so
>> for x86_64
>>> 16K  / 16K    /images/jdk/lib/server/libjsig.so
>>> 72K  / 72M    /images/jdk/lib/libverify.so
>>> 84K  / 84M   /images/jdk/lib/libjli.so
>>> 16K  / 16K    /images/jdk/lib/libjsig.so
>>> 196K / 196K   /images/jdk/lib/libjava.so
>>> 44K  / 44K    /images/jdk/lib/libzip.so
>>> 144K / 136K   /images/jdk/lib/libjimage.so
>>> 112K / 112K   /images/jdk/lib/libnet.so
>>> 100K / 100K   /images/jdk/lib/libnio.so
>>> 36K  / 36K    /images/jdk/lib/libsctp.so
>>> 576K / 556K   /images/jdk/lib/libmlib_image.so
>>> 752K / 752K   /images/jdk/lib/libawt.so
>>> 260K / 252K   /images/jdk/lib/libjavajpeg.so
>>> 784K / 784K   /images/jdk/lib/libfreetype.so
>>> 368K / 236K /images/jdk/lib/libsplashscreen.so   <-------------------------
>>> 88K / 88K    /images/jdk/lib/libjsound.so
>>> 472K / 468K    /images/jdk/lib/libawt_xawt.so
>>> 564K / 404K   /images/jdk/lib/liblcms.so         <--------------------------
>>> 48K / 48K    /images/jdk/lib/libawt_headless.so
>>> 12K / 12K    /images/jdk/lib/libjawt.so
>>> 1.5M / 900K   /images/jdk/lib/libfontmanager.so  <------------------------------
>>> 12K / 12K    /images/jdk/lib/libjaas.so
>>> 92K / 92K    /images/jdk/lib/libj2pkcs11.so
>>> 16K / 16K    /images/jdk/lib/libattach.so
>>> 8.0K / 8.0K   /images/jdk/lib/librmi.so
>>> 56K / 56K    /images/jdk/lib/libinstrument.so
>>> 16K / 16K    /images/jdk/lib/libprefs.so
>>> 52K / 52K    /images/jdk/lib/libj2gss.so
>>> 12K / 12K    /images/jdk/lib/libmanagement_agent.so
>>> 36K / 32K    /images/jdk/lib/libmanagement.so
>>> 16K / 16K    /images/jdk/lib/libextnet.so
>>> 20K / 20K    /images/jdk/lib/libj2pcsc.so
>>> 40K / 40K    /images/jdk/lib/libmanagement_ext.so
>>> 60K / 60K    /images/jdk/lib/libsaproc.so
>>>
>>>
>>> Bug/webrev :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8236714
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/
>>>
>>>
>>> Thanks, Matthias

From chris.hegarty at oracle.com  Wed Jan 15 15:01:57 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Jan 2020 15:01:57 +0000
Subject: RFR [14] 8234782: Discuss evolution of records in serialization spec 
Message-ID: 

As raised in the CSR feedback for records [1], evolution of serializable
records should be discussed in the updates to the serialization spec.

The most significant aspects of serialization evolution concerning
records are 1) adding and removing record components, and 2) the
compatible scenarios where an ordinary class may be changed to a record
class. The following is a proposal to address both.

Spec changes:
  https://cr.openjdk.java.net/~chegar/records/spec/records-serialization-addendum.html

CSR:
  https://bugs.openjdk.java.net/browse/JDK-8237202
  
-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8233436

From matthias.baesken at sap.com  Wed Jan 15 16:14:54 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 15 Jan 2020 16:14:54 +0000
Subject: RFR: 8236714: enable link-time section-gc for linux to remove
 unused code
In-Reply-To: <998c4a08-5670-f51d-4625-9c7e984b4b5d@oracle.com>
References: 
 
 
 <998c4a08-5670-f51d-4625-9c7e984b4b5d@oracle.com>
Message-ID: 

Hi Erik, I did not notice  slowdowns in our night makes .

Looking at a specific  test machine  I use  (x86_64,  build JOBS hardwired  set  to 12 )   I  get around  6 minutes build time  with and without the feature .

( but you have to take into account  that  the  link-time section-gc   on  x86_64    in my patch is only enabled  for the smaller JDK libs and not libjvm.so  )  

Best regards, Matthias


> 
> Given the discussion regarding lto on hotspot and the extreme increased
> build time, have you noticed any difference in build times with this patch?
> 
> /Erik
> 


From james at deepsymmetry.org  Wed Jan 15 16:35:44 2020
From: james at deepsymmetry.org (James Elliott)
Date: Wed, 15 Jan 2020 10:35:44 -0600
Subject: jpackage and macOS Catalina notarization
In-Reply-To: 
References: 
Message-ID: 

Ok, thanks for clarifying that, I will drop my expectations for Catalina happiness for the moment, and perhaps can help make things work better when I have some time. Is there a pointer at how one gets vetted for submitting pull requests? Or I could just look at the source and post ideas here if that is better.

For now, here is what a jpackage-created disk image looks like when I open it in Catalina The command that generates this is:
https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_dmg.zsh#L37-L42 

There are no errors reported during the build


> Date: Wed, 15 Jan 2020 14:54:55 +0100
> From: Michael Paus 
> To: core-libs-dev at openjdk.java.net
> Subject: Re: jpackage and macOS Catalina notarization
> Message-ID: <84d90e7b-fbc8-4be5-09a2-56457edf4e23 at jugs.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
>> I also notice that the background image and Applications folder alias that are supposed to be in the disk image don?t seem to work in Catalina, so I may give up on having jpackage create my disk images as well, and do that using native tools, until that can be fixed. (I realize it is in early access still, and hope these issues are being worked on.)
> 
> What exactly is wrong with the background image? Were there any build
> errors reported during packaging?
> 
> The creation of the disk image is done via some script and you can tell
> jpackage via the
> option --temp  to dump that into a temporary folder. You
> can modify it
> and place it into another folder which you tell jpackage via
> --resource-dir 
> Maybe you can fix your issue that way or at least you can find out what
> the problem is.
> 
> I am still on the previous version of macOS until all these Catalina
> issues are sorted out.
> Java/JavaFX on Catalina is a mess right now.


From aph at redhat.com  Wed Jan 15 18:00:00 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Jan 2020 18:00:00 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
 <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
Message-ID: <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>

On 1/9/20 4:37 PM, Maurizio Cimadamore wrote:
> There you go
>
> cr.openjdk.java.net/~mcimadamore/8235837_javadoc

Thank you.

So I've been kicking the tyres, and I'm rather surprised at how poor
the performance seems to be. My simple test, like this:

    @Benchmark
    public void intHandleTest(BenchmarkState state) {
        try (var segment = BenchmarkState.segment.acquire()) {
            var base = segment.baseAddress();
            final var byteSize = ARRAY_SIZE * 4;
            for (int i = 0; i < byteSize; i += 4) {
                BenchmarkState.intHandle.set(base.offset(i), (int) 4);
            }
        }
    }

has a great deal of overhead. It was a bit of a struggle to get it to
unroll nicely, and the best I could get was

  6.90%  ?  0x00007faeeff7dec8:   mov    r9d,r11d
         ?  0x00007faeeff7decb:   add    r9d,0x4                      ;*iinc {reexecute=0 rethrow=0 return_oop=0}
         ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 45 (line 34)
         ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
         ?  0x00007faeeff7decf:   mov    rdx,rbx
         ?  0x00007faeeff7ded2:   add    rdx,0x10                     ;*i2l {reexecute=0 rethrow=0 return_oop=0}
         ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 35 (line 35)
         ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
  0.06%  ?  0x00007faeeff7ded6:   cmp    rdx,rdi
         ?  0x00007faeeff7ded9:   jg     0x00007faeeff7df94           ;*ifle {reexecute=0 rethrow=0 return_oop=0}
         ?                                                            ; - jdk.internal.foreign.MemorySegmentImpl::checkBounds at 20 (line 196)
         ?                                                            ; - jdk.internal.foreign.MemorySegmentImpl::checkRange at 29 (line 178)
         ?                                                            ; - jdk.internal.foreign.MemoryAddressImpl::checkAccess at 21 (line 84)
         ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts::checkAddress at 15 (line 50)
         ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts::set0 at 7 (line 85)
         ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts0/0x0000000800bc3840::set at 7
         ?                                                            ; - java.lang.invoke.VarHandleGuards::guard_LI_V at 33 (line 114)
         ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 42 (line 35)
         ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
         ?  0x00007faeeff7dedf:   mov    DWORD PTR [rsi+0x10],0x4     ;*invokevirtual putIntUnaligned {reexecute=0 rethrow=0 return_oop=0}
         ?                                                            ; - jdk.internal.misc.Unsafe::putIntUnaligned at 10 (line 3693)
         ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts::set0 at 38 (line 86)
         ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts0/0x0000000800bc3840::set at 7
         ?                                                            ; - java.lang.invoke.VarHandleGuards::guard_LI_V at 33 (line 114)
         ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 42 (line 35)
         ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)

for every store. In contrast, similar ByteBuffer code looks like:


  0.08%   ?  0x00007f3b5bf717c0:   movsxd r13,r8d
  0.16%   ?  0x00007f3b5bf717c3:   mov    r14,rdx
          ?  0x00007f3b5bf717c6:   add    r14,r13
  1.00%   ?  0x00007f3b5bf717c9:   movsxd r13,r8d
  0.04%   ?  0x00007f3b5bf717cc:   vmovdqu YMMWORD PTR [rdx+r13*1],ymm4
  6.87%   ?  0x00007f3b5bf717d2:   vmovdqu YMMWORD PTR [r14+0x20],ymm4
  5.77%   ?  0x00007f3b5bf717d8:   vmovdqu YMMWORD PTR [r14+0x40],ymm4
  3.99%   ?  0x00007f3b5bf717de:   vmovdqu YMMWORD PTR [r14+0x60],ymm4
  6.09%   ?  0x00007f3b5bf717e4:   vmovdqu YMMWORD PTR [r14+0x80],ymm4
  4.97%   ?  0x00007f3b5bf717ed:   vmovdqu YMMWORD PTR [r14+0xa0],ymm4
  4.93%   ?  0x00007f3b5bf717f6:   vmovdqu YMMWORD PTR [r14+0xc0],ymm4
  5.07%   ?  0x00007f3b5bf717ff:   vmovdqu YMMWORD PTR [r14+0xe0],ymm4
  4.87%   ?  0x00007f3b5bf71808:   vmovdqu YMMWORD PTR [r14+0x100],ymm4
  7.39%   ?  0x00007f3b5bf71811:   vmovdqu YMMWORD PTR [r14+0x120],ymm4
  5.19%   ?  0x00007f3b5bf7181a:   vmovdqu YMMWORD PTR [r14+0x140],ymm4
  6.21%   ?  0x00007f3b5bf71823:   vmovdqu YMMWORD PTR [r14+0x160],ymm4
  4.93%   ?  0x00007f3b5bf7182c:   vmovdqu YMMWORD PTR [r14+0x180],ymm4
  5.69%   ?  0x00007f3b5bf71835:   vmovdqu YMMWORD PTR [r14+0x1a0],ymm4
 11.28%   ?  0x00007f3b5bf7183e:   vmovdqu YMMWORD PTR [r14+0x1c0],ymm4
  4.83%   ?  0x00007f3b5bf71847:   vmovdqu YMMWORD PTR [r14+0x1e0],ymm4;*invokevirtual putIntUnaligned {reexecute=0 rethrow=0 return_oop=0}
          ?                                                            ; - jdk.internal.misc.Unsafe::putIntUnaligned at 10 (line 3693)
          ?                                                            ; - java.nio.DirectByteBuffer::putInt at 18 (line 860)
          ?                                                            ; - java.nio.DirectByteBuffer::putInt at 12 (line 881)
          ?                                                            ; - org.sample.ByteBufferTest::floss at 15 (line 34)
          ?                                                            ; - org.sample.ByteBufferTest::test at 14 (line 42)
          ?                                                            ; - org.sample.generated.ByteBufferTest_test_jmhTest::test_avgt_jmhStub at 17 (line 241)
  2.85%   ?  0x00007f3b5bf71850:   add    r8d,0x200                    ;*iinc {reexecute=0 rethrow=0 return_oop=0}
          ?                                                            ; - org.sample.ByteBufferTest::floss at 19 (line 33)
          ?                                                            ; - org.sample.ByteBufferTest::test at 14 (line 42)
          ?                                                            ; - org.sample.generated.ByteBufferTest_test_jmhTest::test_avgt_jmhStub at 17 (line 241)
          ?  0x00007f3b5bf71857:   cmp    r8d,ecx
          ?  0x00007f3b5bf7185a:   jl     0x00007f3b5bf717c0           ;*goto {reexecute=0 rethrow=0 return_oop=0}

nice, eh?

Benchmark                             Mode  Cnt     Score       Error  Units
ByteBufferTest.test                   avgt    5   620.628 ?     2.947  ns/op
MemoryHandlesTest.intHandleTest       avgt    5  2778.602 ? 10557.068  ns/op

Could it be that some C2 improvements or similar are proposed?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From Roger.Riggs at oracle.com  Wed Jan 15 18:30:25 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Jan 2020 13:30:25 -0500
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
Message-ID: 

Hi Naoto,

Is it correct to say that there is no impact on startup until there is 
an explicit reference to HijrahChronology?
It would seem that the registering HijrahChronology would trigger all 
the work and that happens when Chronology is initialized. (see below)

HijrahChronology.java:

291-295: Since registerCustomChrono is the only place where CONF_PATH is 
used,
 ?? do all the work, including the property lookup in that method.
836:? If other chronologies are built-in this code will need to be changed.
 ?? Can it do the getResourceAsStream first in all cases and fall back 
to /conf/chronology?

855: Since all the loading is triggered from a static initializer, is 
there really any point in throwing an exception.
 ? More useful would be a logging message (assuming logging is allowed 
early in startup when Chronology is initialized)

1054: readConfigProperties: The case for the other HijrahChronologies 
delays loading the data until it is needed.
This is doing the work to read the file and create the properties 
instance but then discards it to be read a second time later.

Perhaps we need to specify that the config file name includes both the 
id and type so it can be registered without reading the file.

Regards, Roger


On 1/14/20 9:37 PM, Joe Wang wrote:
>
>
> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Thank you for the review. Please find my comments below:
>>
>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>> Hi Naoto,
>>>
>>> Since it's dealing with non-standard properties files, is there a 
>>> need to verify the files? The constructor (HijrahChronology) does 
>>> check whether the id or type is empty. If there is no existing 
>>> process to validate, it's probably not worth it to spend time as 
>>> it's rare and it's config time.
>>
>> IIUC, the idea is to create the instance at class loading time (thus 
>> the faster the better) and cache it, then check the validity later at 
>> actual method invocation (cf. checkCalendarInit() method).
>
> Make sense.
>>
>>>
>>> The test summary states "Test image creation", it may be better to 
>>> say sth. like verifies custom configuration?
>>
>> Good catch! I was simply copying some portion from other test case. 
>> Corrected:
>>
>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>
> Looks good to me.
>
> Best regards,
> Joe
>
>>
>> Naoto
>>
>>>
>>> Best,
>>> Joe
>>>
>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>
>>>> The proposed CSR and changeset are located at:
>>>>
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>
>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>> could load custom variants of Hijirah calendar type using 
>>>> properties files. However it does not work as designed. This change 
>>>> intends to make it work.
>>>>
>>>> Naoto
>>>
>


From maurizio.cimadamore at oracle.com  Wed Jan 15 18:48:55 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 15 Jan 2020 18:48:55 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
 <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
 <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>
Message-ID: 

Maybe this would be best moved on panama-dev?

In any case, for obtaining best performances, it is best to use an 
indexed (or strided) var handle - your loop will create a new memory 
address on each new iteration, which will not be a problem once 
MemoryAddress will be an inline type, but in the meantime...

We have some benchmarks here:

http://hg.openjdk.java.net/panama/dev/file/5249395528dc/test/micro/org/openjdk/bench/jdk/incubator/foreign

Your test seems similar to this:

http://hg.openjdk.java.net/panama/dev/file/5249395528dc/test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNew.java

In the panama repo this benchmark obtains same numbers as bytebuffer, 
and same loop unrolling (but the panama repo has one performance 
optimization that JDK 14 doesn't yet have, to workaround the lack of 
optimization with longs used in loops). This has been rectified with an 
implementation change which allows us to use ints instead of longs in 
bound checks, when the API can prove that the segment is small - that 
work is described in this thread:

https://mail.openjdk.java.net/pipermail/panama-dev/2020-January/007081.html

And the corresponding, longer term C2 fix is captured here:

https://bugs.openjdk.java.net/browse/JDK-8223051

That said, even w/o that performance fix, I wouldn't expect the memory 
access API to be 4x slower. I'd start by dropping the acquire() [which 
you probably don't need and it's doing a CAS], and moving to indexed var 
handle (by replicating the benchmark code linked above) and see if that 
works better.

Maurizio

On 15/01/2020 18:00, Andrew Haley wrote:
> On 1/9/20 4:37 PM, Maurizio Cimadamore wrote:
>> There you go
>>
>> cr.openjdk.java.net/~mcimadamore/8235837_javadoc
> Thank you.
>
> So I've been kicking the tyres, and I'm rather surprised at how poor
> the performance seems to be. My simple test, like this:
>
>      @Benchmark
>      public void intHandleTest(BenchmarkState state) {
>          try (var segment = BenchmarkState.segment.acquire()) {
>              var base = segment.baseAddress();
>              final var byteSize = ARRAY_SIZE * 4;
>              for (int i = 0; i < byteSize; i += 4) {
>                  BenchmarkState.intHandle.set(base.offset(i), (int) 4);
>              }
>          }
>      }
>
> has a great deal of overhead. It was a bit of a struggle to get it to
> unroll nicely, and the best I could get was
>
>    6.90%  ?  0x00007faeeff7dec8:   mov    r9d,r11d
>           ?  0x00007faeeff7decb:   add    r9d,0x4                      ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>           ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 45 (line 34)
>           ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
>           ?  0x00007faeeff7decf:   mov    rdx,rbx
>           ?  0x00007faeeff7ded2:   add    rdx,0x10                     ;*i2l {reexecute=0 rethrow=0 return_oop=0}
>           ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 35 (line 35)
>           ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
>    0.06%  ?  0x00007faeeff7ded6:   cmp    rdx,rdi
>           ?  0x00007faeeff7ded9:   jg     0x00007faeeff7df94           ;*ifle {reexecute=0 rethrow=0 return_oop=0}
>           ?                                                            ; - jdk.internal.foreign.MemorySegmentImpl::checkBounds at 20 (line 196)
>           ?                                                            ; - jdk.internal.foreign.MemorySegmentImpl::checkRange at 29 (line 178)
>           ?                                                            ; - jdk.internal.foreign.MemoryAddressImpl::checkAccess at 21 (line 84)
>           ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts::checkAddress at 15 (line 50)
>           ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts::set0 at 7 (line 85)
>           ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts0/0x0000000800bc3840::set at 7
>           ?                                                            ; - java.lang.invoke.VarHandleGuards::guard_LI_V at 33 (line 114)
>           ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 42 (line 35)
>           ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
>           ?  0x00007faeeff7dedf:   mov    DWORD PTR [rsi+0x10],0x4     ;*invokevirtual putIntUnaligned {reexecute=0 rethrow=0 return_oop=0}
>           ?                                                            ; - jdk.internal.misc.Unsafe::putIntUnaligned at 10 (line 3693)
>           ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts::set0 at 38 (line 86)
>           ?                                                            ; - java.lang.invoke.VarHandleMemoryAddressAsInts0/0x0000000800bc3840::set at 7
>           ?                                                            ; - java.lang.invoke.VarHandleGuards::guard_LI_V at 33 (line 114)
>           ?                                                            ; - org.sample.MemoryHandlesTest::intHandleTest at 42 (line 35)
>           ?                                                            ; - org.sample.generated.MemoryHandlesTest_intHandleTest_jmhTest::intHandleTest_avgt_jmhStub at 17 (line 191)
>
> for every store. In contrast, similar ByteBuffer code looks like:
>
>
>    0.08%   ?  0x00007f3b5bf717c0:   movsxd r13,r8d
>    0.16%   ?  0x00007f3b5bf717c3:   mov    r14,rdx
>            ?  0x00007f3b5bf717c6:   add    r14,r13
>    1.00%   ?  0x00007f3b5bf717c9:   movsxd r13,r8d
>    0.04%   ?  0x00007f3b5bf717cc:   vmovdqu YMMWORD PTR [rdx+r13*1],ymm4
>    6.87%   ?  0x00007f3b5bf717d2:   vmovdqu YMMWORD PTR [r14+0x20],ymm4
>    5.77%   ?  0x00007f3b5bf717d8:   vmovdqu YMMWORD PTR [r14+0x40],ymm4
>    3.99%   ?  0x00007f3b5bf717de:   vmovdqu YMMWORD PTR [r14+0x60],ymm4
>    6.09%   ?  0x00007f3b5bf717e4:   vmovdqu YMMWORD PTR [r14+0x80],ymm4
>    4.97%   ?  0x00007f3b5bf717ed:   vmovdqu YMMWORD PTR [r14+0xa0],ymm4
>    4.93%   ?  0x00007f3b5bf717f6:   vmovdqu YMMWORD PTR [r14+0xc0],ymm4
>    5.07%   ?  0x00007f3b5bf717ff:   vmovdqu YMMWORD PTR [r14+0xe0],ymm4
>    4.87%   ?  0x00007f3b5bf71808:   vmovdqu YMMWORD PTR [r14+0x100],ymm4
>    7.39%   ?  0x00007f3b5bf71811:   vmovdqu YMMWORD PTR [r14+0x120],ymm4
>    5.19%   ?  0x00007f3b5bf7181a:   vmovdqu YMMWORD PTR [r14+0x140],ymm4
>    6.21%   ?  0x00007f3b5bf71823:   vmovdqu YMMWORD PTR [r14+0x160],ymm4
>    4.93%   ?  0x00007f3b5bf7182c:   vmovdqu YMMWORD PTR [r14+0x180],ymm4
>    5.69%   ?  0x00007f3b5bf71835:   vmovdqu YMMWORD PTR [r14+0x1a0],ymm4
>   11.28%   ?  0x00007f3b5bf7183e:   vmovdqu YMMWORD PTR [r14+0x1c0],ymm4
>    4.83%   ?  0x00007f3b5bf71847:   vmovdqu YMMWORD PTR [r14+0x1e0],ymm4;*invokevirtual putIntUnaligned {reexecute=0 rethrow=0 return_oop=0}
>            ?                                                            ; - jdk.internal.misc.Unsafe::putIntUnaligned at 10 (line 3693)
>            ?                                                            ; - java.nio.DirectByteBuffer::putInt at 18 (line 860)
>            ?                                                            ; - java.nio.DirectByteBuffer::putInt at 12 (line 881)
>            ?                                                            ; - org.sample.ByteBufferTest::floss at 15 (line 34)
>            ?                                                            ; - org.sample.ByteBufferTest::test at 14 (line 42)
>            ?                                                            ; - org.sample.generated.ByteBufferTest_test_jmhTest::test_avgt_jmhStub at 17 (line 241)
>    2.85%   ?  0x00007f3b5bf71850:   add    r8d,0x200                    ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>            ?                                                            ; - org.sample.ByteBufferTest::floss at 19 (line 33)
>            ?                                                            ; - org.sample.ByteBufferTest::test at 14 (line 42)
>            ?                                                            ; - org.sample.generated.ByteBufferTest_test_jmhTest::test_avgt_jmhStub at 17 (line 241)
>            ?  0x00007f3b5bf71857:   cmp    r8d,ecx
>            ?  0x00007f3b5bf7185a:   jl     0x00007f3b5bf717c0           ;*goto {reexecute=0 rethrow=0 return_oop=0}
>
> nice, eh?
>
> Benchmark                             Mode  Cnt     Score       Error  Units
> ByteBufferTest.test                   avgt    5   620.628 ?     2.947  ns/op
> MemoryHandlesTest.intHandleTest       avgt    5  2778.602 ? 10557.068  ns/op
>
> Could it be that some C2 improvements or similar are proposed?
>

From james at deepsymmetry.org  Wed Jan 15 19:05:07 2020
From: james at deepsymmetry.org (James Elliott)
Date: Wed, 15 Jan 2020 13:05:07 -0600
Subject: jpackage and macOS Catalina notarization
In-Reply-To: 
References: 
Message-ID: <4599FC2B-5342-4655-A7A3-8E9C2EA90298@deepsymmetry.org>

[Whoops, it seems that this list strips out image attachments, so my first attempt to send this message was pretty useless. Trying again, after uploading the screenshot to my web server so I can link to it instead.]

Ok, thanks for clarifying that, I will drop my expectations for Catalina happiness for the moment, and perhaps can help make things work better when I have some time. Is there a pointer at how one gets vetted for submitting pull requests? Or I could just look at the source and post ideas here if that is better.

For now, here is what a jpackage-created disk image looks like when I open it in Catalina: https://deepsymmetry.org/images/jpackage_dmg_screenshot.png

The command that generates this is:
https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_dmg.zsh#L37-L42 

There are no errors reported during the build

Cheers,

	-James

> Date: Wed, 15 Jan 2020 14:54:55 +0100
> From: Michael Paus >
> To: core-libs-dev at openjdk.java.net 
> Subject: Re: jpackage and macOS Catalina notarization
> Message-ID: <84d90e7b-fbc8-4be5-09a2-56457edf4e23 at jugs.org >
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
>> I also notice that the background image and Applications folder alias that are supposed to be in the disk image don?t seem to work in Catalina, so I may give up on having jpackage create my disk images as well, and do that using native tools, until that can be fixed. (I realize it is in early access still, and hope these issues are being worked on.)
> 
> What exactly is wrong with the background image? Were there any build
> errors reported during packaging?
> 
> The creation of the disk image is done via some script and you can tell
> jpackage via the
> option --temp  to dump that into a temporary folder. You
> can modify it
> and place it into another folder which you tell jpackage via
> --resource-dir 
> Maybe you can fix your issue that way or at least you can find out what
> the problem is.
> 
> I am still on the previous version of macOS until all these Catalina
> issues are sorted out.
> Java/JavaFX on Catalina is a mess right now.


From naoto.sato at oracle.com  Wed Jan 15 20:06:12 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jan 2020 12:06:12 -0800
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: 
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 
Message-ID: <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>

Hi Roger,

Thank you for the review. Please find my comments below:

On 1/15/20 10:30 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> Is it correct to say that there is no impact on startup until there is 
> an explicit reference to HijrahChronology?
> It would seem that the registering HijrahChronology would trigger all 
> the work and that happens when Chronology is initialized. (see below)

What I meant in the reply to Joe's email was that the data validity 
check done in loadCalendarData(), e.g., year value check, etc. which are 
not done at class init. But you are correct that the properties files 
are read twice (below). I thought it was fine as this is not a common 
case (not happened before, to be precise).

> 
> HijrahChronology.java:
> 
> 291-295: Since registerCustomChrono is the only place where CONF_PATH is 
> used,
>  ?? do all the work, including the property lookup in that method.
> 836:? If other chronologies are built-in this code will need to be changed.
>  ?? Can it do the getResourceAsStream first in all cases and fall back 
> to /conf/chronology?

Yes, it would have to be changed if we support built-in type other than 
umalqura. But I would think other code would have to anyways. I think we 
can take advantage of the fact that umalqura is the only built-in, and 
others come from /conf/chronology so that extra fallback is avoided.

> 
> 855: Since all the loading is triggered from a static initializer, is 
> there really any point in throwing an exception.
>  ? More useful would be a logging message (assuming logging is allowed 
> early in startup when Chronology is initialized)

Good point. I will replace UncheckedIOException with logging.

> 
> 1054: readConfigProperties: The case for the other HijrahChronologies 
> delays loading the data until it is needed.
> This is doing the work to read the file and create the properties 
> instance but then discards it to be read a second time later.
> 
> Perhaps we need to specify that the config file name includes both the 
> id and type so it can be registered without reading the file.

Should the file name like "Hijrah-config-_.properties" work?

Naoto

> 
> Regards, Roger
> 
> 
> On 1/14/20 9:37 PM, Joe Wang wrote:
>>
>>
>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for the review. Please find my comments below:
>>>
>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> Since it's dealing with non-standard properties files, is there a 
>>>> need to verify the files? The constructor (HijrahChronology) does 
>>>> check whether the id or type is empty. If there is no existing 
>>>> process to validate, it's probably not worth it to spend time as 
>>>> it's rare and it's config time.
>>>
>>> IIUC, the idea is to create the instance at class loading time (thus 
>>> the faster the better) and cache it, then check the validity later at 
>>> actual method invocation (cf. checkCalendarInit() method).
>>
>> Make sense.
>>>
>>>>
>>>> The test summary states "Test image creation", it may be better to 
>>>> say sth. like verifies custom configuration?
>>>
>>> Good catch! I was simply copying some portion from other test case. 
>>> Corrected:
>>>
>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>
>> Looks good to me.
>>
>> Best regards,
>> Joe
>>
>>>
>>> Naoto
>>>
>>>>
>>>> Best,
>>>> Joe
>>>>
>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix to the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>
>>>>> The proposed CSR and changeset are located at:
>>>>>
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>
>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>> could load custom variants of Hijirah calendar type using 
>>>>> properties files. However it does not work as designed. This change 
>>>>> intends to make it work.
>>>>>
>>>>> Naoto
>>>>
>>
> 

From roger.riggs at oracle.com  Wed Jan 15 20:37:41 2020
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Jan 2020 15:37:41 -0500
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
Message-ID: 

Hi,

On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thank you for the review. Please find my comments below:
>
> On 1/15/20 10:30 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> Is it correct to say that there is no impact on startup until there 
>> is an explicit reference to HijrahChronology?
>> It would seem that the registering HijrahChronology would trigger all 
>> the work and that happens when Chronology is initialized. (see below)
>
> What I meant in the reply to Joe's email was that the data validity 
> check done in loadCalendarData(), e.g., year value check, etc. which 
> are not done at class init. But you are correct that the properties 
> files are read twice (below). I thought it was fine as this is not a 
> common case (not happened before, to be precise).
Until it get used, there will still be a probe of the filesystem to see 
if a config directory/file exists
that would impact every startup. I don't see a way to mitigate that 
without making the config? more complex.
>
>>
>> HijrahChronology.java:
>>
>> 291-295: Since registerCustomChrono is the only place where CONF_PATH 
>> is used,
>> ??? do all the work, including the property lookup in that method.
>> 836:? If other chronologies are built-in this code will need to be 
>> changed.
>> ??? Can it do the getResourceAsStream first in all cases and fall 
>> back to /conf/chronology?
>
> Yes, it would have to be changed if we support built-in type other 
> than umalqura. But I would think other code would have to anyways. I 
> think we can take advantage of the fact that umalqura is the only 
> built-in, and others come from /conf/chronology so that extra fallback 
> is avoided.
Possibly, but could/would be more localized and consist of only the 
registerChronology call.
>
>>
>> 855: Since all the loading is triggered from a static initializer, is 
>> there really any point in throwing an exception.
>> ?? More useful would be a logging message (assuming logging is 
>> allowed early in startup when Chronology is initialized)
>
> Good point. I will replace UncheckedIOException with logging.
>
>>
>> 1054: readConfigProperties: The case for the other HijrahChronologies 
>> delays loading the data until it is needed.
>> This is doing the work to read the file and create the properties 
>> instance but then discards it to be read a second time later.
>>
>> Perhaps we need to specify that the config file name includes both 
>> the id and type so it can be registered without reading the file.
>
> Should the file name like "Hijrah-config-_.properties" work?
yes, its worth checking the valid characters in id and type.

Thanks, Roger

BTW, the test drive can be implemented using testng, only the test 
itself is easier as main().

>
> Naoto
>
>>
>> Regards, Roger
>>
>>
>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>
>>>
>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>> Hi Joe,
>>>>
>>>> Thank you for the review. Please find my comments below:
>>>>
>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> Since it's dealing with non-standard properties files, is there a 
>>>>> need to verify the files? The constructor (HijrahChronology) does 
>>>>> check whether the id or type is empty. If there is no existing 
>>>>> process to validate, it's probably not worth it to spend time as 
>>>>> it's rare and it's config time.
>>>>
>>>> IIUC, the idea is to create the instance at class loading time 
>>>> (thus the faster the better) and cache it, then check the validity 
>>>> later at actual method invocation (cf. checkCalendarInit() method).
>>>
>>> Make sense.
>>>>
>>>>>
>>>>> The test summary states "Test image creation", it may be better to 
>>>>> say sth. like verifies custom configuration?
>>>>
>>>> Good catch! I was simply copying some portion from other test case. 
>>>> Corrected:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>
>>> Looks good to me.
>>>
>>> Best regards,
>>> Joe
>>>
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Best,
>>>>> Joe
>>>>>
>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>
>>>>>> The proposed CSR and changeset are located at:
>>>>>>
>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>
>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>> properties files. However it does not work as designed. This 
>>>>>> change intends to make it work.
>>>>>>
>>>>>> Naoto
>>>>>
>>>
>>


From simonisv at amazon.de  Wed Jan 15 21:39:24 2020
From: simonisv at amazon.de (Volker Simonis)
Date: Wed, 15 Jan 2020 13:39:24 -0800
Subject: [zlib] Why do we make uLong a 32-bit int on 64-bit platforms?
Message-ID: <7feeba1c-ea43-adac-76d3-32e21fedb388@amazon.de>

Hi,

is there any reason why the bundled zlib is patched to make zlib's
"uLong" type a 32-bit int on 64-bit platforms [1]? This change to the
original zlib is there since the very first drop of OpenJDK 6 [2] (which
still had version 1.1.3 of zlib). Maybe it was required at that time
when it was still possible to create images with both, 32- and 64-bit
versions of the JDK and choose the one you want with -d64/-d32?

However, as of today, I can't imagine why this patch should be still
required? Especially taking into account that when the jdk is built with
"--with-zlib=system", it will use the systems version of "zconf.h"
anyway, which doesn't have this change. Nevertheless, jdk's using the
system zlib are being build and are in use since many years on all major
Linux distributions without any known zlib problems.

So if nobody objects, I'll file a RFE to remove this zlib patch.

Thank you and best regards,
Volker

[1]
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/native/libzip/zlib/patches/ChangeLog_java#l4
[2]
http://hg.openjdk.java.net/jdk6/jdk6/jdk/annotate/d7039bceb849/src/share/native/java/util/zip/zlib-1.1.3/zconf.h#l250




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From alexander.matveev at oracle.com  Wed Jan 15 22:20:19 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 15 Jan 2020 14:20:19 -0800
Subject: RFR: JDK-8236132: Add missing properties to msi installers
In-Reply-To: <5cfca416-d9d5-46cb-57d9-dc75b94201e1@oracle.com>
References: 
 
 <581fcb80-58a3-332c-5b28-7c95422caef0@oracle.com>
 <5cfca416-d9d5-46cb-57d9-dc75b94201e1@oracle.com>
Message-ID: <2141e838-0a11-ec30-86bb-94d2c24bc41d@oracle.com>

Hi Alexey,

Thanks for explanation, then current patch looks fine.

Thanks,
Alexander

On 1/14/2020 11:29 PM, Alexey Semenyuk wrote:
> Alexander,
>
> Icon can be configured on jpackage command line and should not be 
> overridden in custom overrides.wxi file. This is the reason why I 
> didn't put its description in the default overrides.wxi file.
> JpIcon is just one of WiX variables to pass configuration data from 
> jpackage Java into WiX toolset.
>
> - Alexey
>
> On 1/6/2020 7:36 PM, Alexander Matveev wrote:
>> Hi Alexey,
>>
>> Can you add description for JpIcon to overrides.wxi, otherwise looks 
>> fine.
>>
>> Thanks,
>> Alexander
>>
>> On 12/20/2019 12:16 PM, Alexey Semenyuk wrote:
>>> Please review fix [2] for jpackage bug [1].
>>>
>>> Add properties to msi installers to properly display installation 
>>> location and icon of the application in the list of installed 
>>> applications.
>>>
>>> - Alexey
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236132
>>>
>>> [2] http://cr.openjdk.java.net/~asemenyuk/8236132/webrev.00
>>
>


From lance.andersen at oracle.com  Wed Jan 15 22:21:43 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Jan 2020 17:21:43 -0500
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: 
References: 
Message-ID: 

Hi Joe,

This seems OK. 

> On Jan 14, 2020, at 3:08 PM, Joe Wang > wrote:
> 
> Hi,
> 
> Please review an update to BCEL 6.4.1.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368 
> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html 
> 
> Similar approach as the last update:
> 1. Format
>     All format changes are kept as they are in the source in order to reduce the amount of changes in future updates, the exceptions are extreme long lines.
> 
> 2. Exclusions
>     Contents that were not in the JDK or unnecessary for java.xml are excluded. This includes: the ability to load arbitrary classes and classes related to ClassLoader, ClassPath and JavaWrapper, and relevant methods and references in other classes; System Properties used to set cache sizes and track certain statistics (caches are set as in previous version); Deprecated classes and related contents.
> 
> 3. Warnings
>     Warnings were the main reason for the changes made to the original source. It has been done in the previous update. They are re-applied for this update. The LastModified field indicates such changes to the original source.
> 
> 4. Deprecated fields to private and references to deprecated methods
>    Deprecated fields in the original source were changed to private ones in previous update. References to deprecated methods were modified to use proper methods. These changes are inherited in this update.
> 
> 5. Test
>     Since the update does not affect java.xml's usage of the BCEL component, it is essential to pass all of the existing tests. I've run the tests multiple times and noted that all of the XML functional and unit tests passed, so were JCK XML tests. A performance test is running.
> 
> 
> 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 Jan 15 23:34:50 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 15 Jan 2020 15:34:50 -0800
Subject: RFR: JDK-8235955: [dmg] DMG creation fails without error message if
 previous DMG was not ejected
Message-ID: <6b8d6062-0492-a943-bf73-e5e129aeb344@oracle.com>

Please review the jpackage fix for bug [1] at [2].

- Modified customization script for DMG to use location where DMG is 
mounted to identify image that we need to customize, instead of using 
name which might not be unique.

[1] https://bugs.openjdk.java.net/browse/JDK-8235955

[2] http://cr.openjdk.java.net/~almatvee/8235955/webrev.00/

Thanks,
Alexander

From naoto.sato at oracle.com  Thu Jan 16 00:49:15 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jan 2020 16:49:15 -0800
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: 
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 
Message-ID: 

Updated:

https://cr.openjdk.java.net/~naoto/8187987/webrev.02/

The change includes the new naming convention, reduction of properties 
files reading to once, and utilization of logging.

Naoto

On 1/15/20 12:37 PM, Roger Riggs wrote:
> Hi,
> 
> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>> Hi Roger,
>>
>> Thank you for the review. Please find my comments below:
>>
>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>> Hi Naoto,
>>>
>>> Is it correct to say that there is no impact on startup until there 
>>> is an explicit reference to HijrahChronology?
>>> It would seem that the registering HijrahChronology would trigger all 
>>> the work and that happens when Chronology is initialized. (see below)
>>
>> What I meant in the reply to Joe's email was that the data validity 
>> check done in loadCalendarData(), e.g., year value check, etc. which 
>> are not done at class init. But you are correct that the properties 
>> files are read twice (below). I thought it was fine as this is not a 
>> common case (not happened before, to be precise).
> Until it get used, there will still be a probe of the filesystem to see 
> if a config directory/file exists
> that would impact every startup. I don't see a way to mitigate that 
> without making the config? more complex.
>>
>>>
>>> HijrahChronology.java:
>>>
>>> 291-295: Since registerCustomChrono is the only place where CONF_PATH 
>>> is used,
>>> ??? do all the work, including the property lookup in that method.
>>> 836:? If other chronologies are built-in this code will need to be 
>>> changed.
>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>> back to /conf/chronology?
>>
>> Yes, it would have to be changed if we support built-in type other 
>> than umalqura. But I would think other code would have to anyways. I 
>> think we can take advantage of the fact that umalqura is the only 
>> built-in, and others come from /conf/chronology so that extra fallback 
>> is avoided.
> Possibly, but could/would be more localized and consist of only the 
> registerChronology call.
>>
>>>
>>> 855: Since all the loading is triggered from a static initializer, is 
>>> there really any point in throwing an exception.
>>> ?? More useful would be a logging message (assuming logging is 
>>> allowed early in startup when Chronology is initialized)
>>
>> Good point. I will replace UncheckedIOException with logging.
>>
>>>
>>> 1054: readConfigProperties: The case for the other HijrahChronologies 
>>> delays loading the data until it is needed.
>>> This is doing the work to read the file and create the properties 
>>> instance but then discards it to be read a second time later.
>>>
>>> Perhaps we need to specify that the config file name includes both 
>>> the id and type so it can be registered without reading the file.
>>
>> Should the file name like "Hijrah-config-_.properties" work?
> yes, its worth checking the valid characters in id and type.
> 
> Thanks, Roger
> 
> BTW, the test drive can be implemented using testng, only the test 
> itself is easier as main().
> 
>>
>> Naoto
>>
>>>
>>> Regards, Roger
>>>
>>>
>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>
>>>>
>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>> Hi Joe,
>>>>>
>>>>> Thank you for the review. Please find my comments below:
>>>>>
>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> Since it's dealing with non-standard properties files, is there a 
>>>>>> need to verify the files? The constructor (HijrahChronology) does 
>>>>>> check whether the id or type is empty. If there is no existing 
>>>>>> process to validate, it's probably not worth it to spend time as 
>>>>>> it's rare and it's config time.
>>>>>
>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>> (thus the faster the better) and cache it, then check the validity 
>>>>> later at actual method invocation (cf. checkCalendarInit() method).
>>>>
>>>> Make sense.
>>>>>
>>>>>>
>>>>>> The test summary states "Test image creation", it may be better to 
>>>>>> say sth. like verifies custom configuration?
>>>>>
>>>>> Good catch! I was simply copying some portion from other test case. 
>>>>> Corrected:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>
>>>> Looks good to me.
>>>>
>>>> Best regards,
>>>> Joe
>>>>
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Best,
>>>>>> Joe
>>>>>>
>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the fix to the following issue:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>
>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>
>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>
>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>>> properties files. However it does not work as designed. This 
>>>>>>> change intends to make it work.
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>
>>>
> 

From stuart.marks at oracle.com  Thu Jan 16 01:46:14 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 15 Jan 2020 17:46:14 -0800
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
Message-ID: <9436d139-6f25-3101-cac8-f93e92ff0b77@oracle.com>



On 1/13/20 8:03 AM, Claes Redestad wrote:
> we're doing plenty of iterations over Set.of() instances during
> bootstrap, which makes these operations show up prominently in
> startup profiles. This patch refactors a few hot methods to get a
> measureable startup improvement without regressing on targeted
> microbenchmarks.
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236641
> Webrev: http://cr.openjdk.java.net/~redestad/8236641/open.00/

OK, interesting and promising. A potential pitfall and a nitpick, though perhaps 
an important one.

   65     static {
   66         long color = 0x243F_6A88_85A3_08D3L; // pi slice
   67         long seed = System.nanoTime();
   68         int salt = (int)((color * seed) >> 16);  // avoid LSB and MSB
   69         REVERSE = salt >= 0;
   70         // Force SALT to be positive so we can use modulo rather
   71         // than Math.floorMod
   72         SALT = Math.abs(salt);
   73     }

After this code runs I'm not convinced that SALT will be positive... consider 
Integer.MIN_VALUE! Maybe just mask off the top bit instead? Thirty-one bits of 
salt should be sufficient for our purposes here.

In SetNIterator::next there is this code:


  789                     do {
  790                         if (REVERSE) {
  791                             if (++idx >= len) {
  792                                 idx = 0;
  793                             }
  794                         } else {
  795                             if (--idx < 0) {
  796                                 idx = len - 1;
  797                             }
  798                         }
  799                     }
  800                     while ((element = elements[idx]) == null);

Ah, the rare do-while loop! I think this makes sense, but it reads oddly, 
because it looks like the trailing "while" starts a new statement when in fact 
it's part of the do-while statement. The trailing semicolon then makes this look 
like a mistake. I'd suggest merging 799 and 800 so the last line of the loop 
looks like this:

  799                     } while ((element = elements[idx]) == null);

It's a small thing, but the "} while" on a line should be a tip-off that this is 
the rare do-while loop and not something else.

Thanks,

s'marks

From john.r.rose at oracle.com  Thu Jan 16 02:29:41 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 15 Jan 2020 18:29:41 -0800
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <9436d139-6f25-3101-cac8-f93e92ff0b77@oracle.com>
References: <9436d139-6f25-3101-cac8-f93e92ff0b77@oracle.com>
Message-ID: <0F5A2F2D-2AB7-4798-82C1-AC58A2CE41DB@oracle.com>



> On Jan 15, 2020, at 5:46 PM, Stuart Marks  wrote:
> 
> ?
> 
>> On 1/13/20 8:03 AM, Claes Redestad wrote:
>> we're doing plenty of iterations over Set.of() instances during
>> bootstrap, which makes these operations show up prominently in
>> startup profiles. This patch refactors a few hot methods to get a
>> measureable startup improvement without regressing on targeted
>> microbenchmarks.
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8236641
>> Webrev: http://cr.openjdk.java.net/~redestad/8236641/open.00/
> 
> OK, interesting and promising. A potential pitfall and a nitpick, though perhaps an important one.
> 
>  65     static {
>  66         long color = 0x243F_6A88_85A3_08D3L; // pi slice
>  67         long seed = System.nanoTime();
>  68         int salt = (int)((color * seed) >> 16);  // avoid LSB and MSB
>  69         REVERSE = salt >= 0;
>  70         // Force SALT to be positive so we can use modulo rather
>  71         // than Math.floorMod
>  72         SALT = Math.abs(salt);
>  73     }
> 
> After this code runs I'm not convinced that SALT will be positive... consider Integer.MIN_VALUE! Maybe just mask off the top bit instead? Thirty-one bits of salt should be sufficient for our purposes here.

Good catch.  Should be:

SALT = salt >>> 1;

Pleasingly it uses exactly the 32 rando-bits. 

> 
> In SetNIterator::next there is this code:
> 
> 
> 789                     do {
> 790                         if (REVERSE) {
> 791                             if (++idx >= len) {
> 792                                 idx = 0;
> 793                             }
> 794                         } else {
> 795                             if (--idx < 0) {
> 796                                 idx = len - 1;
> 797                             }
> 798                         }
> 799                     }
> 800                     while ((element = elements[idx]) == null);
> 
> Ah, the rare do-while loop! I think this makes sense, but it reads oddly, because it looks like the trailing "while" starts a new statement when in fact it's part of the do-while statement. The trailing semicolon then makes this look like a mistake. I'd suggest merging 799 and 800 so the last line of the loop looks like this:
> 
> 799                     } while ((element = elements[idx]) == null);
> 
> It's a small thing, but the "} while" on a line should be a tip-off that this is the rare do-while loop and not something else.

+1

> 
> Thanks,
> 
> s'marks


From stuart.marks at oracle.com  Thu Jan 16 04:00:34 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 15 Jan 2020 20:00:34 -0800
Subject: RFR [15] 8161558: ListIterator should not discard cause on
 exception
In-Reply-To: 
References: 
 
Message-ID: <7924da3d-0fc8-3a97-d87d-2068908e0a2e@oracle.com>



On 1/15/20 4:46 AM, Martin Buchholz wrote:
> I would have documented whitebox test assumptions: that nCopies iterators
> are implemented via AbstractList, and that AbstractList's list iterator
> inherits behavior from iterator.
> 
> I probably would have added a plain iterator test, and might have
> refactored the code that tests the exception.

Hm. Thinking about this a bit more, it seems to me that this is a concern that 
we ought to deal with more effectively than just documenting it. The risk is 
that Collections.nCopies is reimplemented differently, which would render the 
useless as it's not testing the thing that it's intended to test. It would 
probably still pass, so nobody would ever look at it and see a comment 
documenting the assumptions, or even if they did they might not grasp the 
implications.

Fortunately it's possible to implement a concrete List implementation using 
AbstractList with just a few lines of code, so I think we should go ahead and do 
that.

For a similar reason I also agree that it would be wise to add a test of the 
plain Iterator as well as the ListIterator. Even though we "know" it's 
redundant, if the AbstractList iterator code were refactored in the future, it 
might invalidate assumptions the test is making.

I usually draw the refactoring line between two and three. With two cases I 
think a little duplication is sometimes reasonable, as the overhead of 
introducing sharing (both in the conceptual overhead of adding an abstraction 
layer, and the syntactic overhead of adding another method) offsets the savings. 
With three cases the case for extracting common is much stronger. Making the 
assertions be in common code will lose some customization of messages, but I 
don't think that's a great loss; there's already enough information to pinpoint 
which case is failing.

s'marks

From huizhe.wang at oracle.com  Thu Jan 16 04:04:35 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 15 Jan 2020 20:04:35 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: 
References: 
 
Message-ID: <8cea0280-a417-7d45-d677-b2e101a6bd5e@oracle.com>

Thanks Lance!

-Joe

On 1/15/20 2:21 PM, Lance Andersen wrote:
> Hi Joe,
>
> This seems OK.
>
>> On Jan 14, 2020, at 3:08 PM, Joe Wang > > wrote:
>>
>> Hi,
>>
>> Please review an update to BCEL 6.4.1.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
>>
>> Similar approach as the last update:
>> 1. Format
>> ??? All format changes are kept as they are in the source in order to 
>> reduce the amount of changes in future updates, the exceptions are 
>> extreme long lines.
>>
>> 2. Exclusions
>> ??? Contents that were not in the JDK or unnecessary for java.xml are 
>> excluded. This includes: the ability to load arbitrary classes and 
>> classes related to ClassLoader, ClassPath and JavaWrapper, and 
>> relevant methods and references in other classes; System Properties 
>> used to set cache sizes and track certain statistics (caches are set 
>> as in previous version); Deprecated classes and related contents.
>>
>> 3. Warnings
>> ??? Warnings were the main reason for the changes made to the 
>> original source. It has been done in the previous update. They are 
>> re-applied for this update. The LastModified field indicates such 
>> changes to the original source.
>>
>> 4. Deprecated fields to private and references to deprecated methods
>> ?? Deprecated fields in the original source were changed to private 
>> ones in previous update. References to deprecated methods were 
>> modified to use proper methods. These changes are inherited in this 
>> update.
>>
>> 5. Test
>> ??? Since the update does not affect java.xml's usage of the BCEL 
>> component, it is essential to pass all of the existing tests. I've 
>> run the tests multiple times and noted that all of the XML functional 
>> and unit tests passed, so were JCK XML tests. A performance test is 
>> running.
>>
>>
>> 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 aph at redhat.com  Thu Jan 16 09:24:02 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Jan 2020 09:24:02 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
 <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
 <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>
 
Message-ID: 

On 1/15/20 6:48 PM, Maurizio Cimadamore wrote:
> That said, even w/o that performance fix, I wouldn't expect the memory 
> access API to be 4x slower. I'd start by dropping the acquire() [which 
> you probably don't need and it's doing a CAS], and moving to indexed var 
> handle (by replicating the benchmark code linked above) and see if that 
> works better.

OK, I never found the indexed var handle.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From fweimer at redhat.com  Thu Jan 16 10:20:43 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 16 Jan 2020 11:20:43 +0100
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com> (Claes
 Redestad's message of "Mon, 13 Jan 2020 17:03:10 +0100")
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
Message-ID: <877e1rwvlw.fsf@oldenburg2.str.redhat.com>

* Claes Redestad:

> we're doing plenty of iterations over Set.of() instances during
> bootstrap, which makes these operations show up prominently in
> startup profiles. This patch refactors a few hot methods to get a
> measureable startup improvement without regressing on targeted
> microbenchmarks.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8236641
> Webrev: http://cr.openjdk.java.net/~redestad/8236641/open.00/
>
> (The patch is baselined against 8236850)

Would it be possible to replace

  idx = SALT % elements.length;

  idx = (SALT % (table.length >> 1)) << 1;

with this?

  idx = (int) ((elements.length * (long) SALT) >>> 32);

  idx = (int) (((table.length >> 1) * (long) SALT) >>> 31);

A long multiplication followed by a shift should be faster than an int
modulo.

See this thread for some background:



Thanks,
Florian


From daniel.fuchs at oracle.com  Thu Jan 16 10:35:04 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Jan 2020 10:35:04 +0000
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: 
References: 
Message-ID: <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>

Hi Joe,

Looks OK to me as well.
I am a bit surprised by the number of methods that are no longer
`final` though. Do you know what was the motivation for those
changes?

best regards,

-- daniel

On 14/01/2020 20:08, Joe Wang wrote:
> Hi,
> 
> Please review an update to BCEL 6.4.1.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
> 
> Similar approach as the last update:
> 1. Format
>  ??? All format changes are kept as they are in the source in order to 
> reduce the amount of changes in future updates, the exceptions are 
> extreme long lines.
> 
> 2. Exclusions
>  ??? Contents that were not in the JDK or unnecessary for java.xml are 
> excluded. This includes: the ability to load arbitrary classes and 
> classes related to ClassLoader, ClassPath and JavaWrapper, and relevant 
> methods and references in other classes; System Properties used to set 
> cache sizes and track certain statistics (caches are set as in previous 
> version); Deprecated classes and related contents.
> 
> 3. Warnings
>  ??? Warnings were the main reason for the changes made to the original 
> source. It has been done in the previous update. They are re-applied for 
> this update. The LastModified field indicates such changes to the 
> original source.
> 
> 4. Deprecated fields to private and references to deprecated methods
>  ?? Deprecated fields in the original source were changed to private 
> ones in previous update. References to deprecated methods were modified 
> to use proper methods. These changes are inherited in this update.
> 
> 5. Test
>  ??? Since the update does not affect java.xml's usage of the BCEL 
> component, it is essential to pass all of the existing tests. I've run 
> the tests multiple times and noted that all of the XML functional and 
> unit tests passed, so were JCK XML tests. A performance test is running.
> 
> 
> Thanks,
> Joe
> 
> 


From maurizio.cimadamore at oracle.com  Thu Jan 16 11:49:59 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Jan 2020 11:49:59 +0000
Subject: RFR (14) 8237348: Javadoc of MemorySegment::allocateNative should
 state that memory is zero-initialized
Message-ID: 

Hi,
there is a mistake in the javadoc of MemorySegment::allocateNative -as 
the javadoc says that the initialization state is unspecified, where in 
reality we do call setMemory on the allocated block (so that memory 
contents are set to zero).

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8237348/

Cheers
Maurizio


From chris.hegarty at oracle.com  Thu Jan 16 11:52:40 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 16 Jan 2020 11:52:40 +0000
Subject: RFR (14) 8237348: Javadoc of MemorySegment::allocateNative should
 state that memory is zero-initialized
In-Reply-To: 
References: 
Message-ID: <21715367-D82B-40F8-9EDF-B2EA913F9B53@oracle.com>



> On 16 Jan 2020, at 11:49, Maurizio Cimadamore  wrote:
> 
> Hi,
> there is a mistake in the javadoc of MemorySegment::allocateNative -as the javadoc says that the initialization state is unspecified, where in reality we do call setMemory on the allocated block (so that memory contents are set to zero).
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mcimadamore/8237348/

LGTM.

-Chris.


From alexey.semenyuk at oracle.com  Thu Jan 16 13:03:16 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 16 Jan 2020 08:03:16 -0500
Subject: RFR: JDK-8235955: [dmg] DMG creation fails without error message
 if previous DMG was not ejected
In-Reply-To: <6b8d6062-0492-a943-bf73-e5e129aeb344@oracle.com>
References: <6b8d6062-0492-a943-bf73-e5e129aeb344@oracle.com>
Message-ID: <23bc8e2b-ba04-c5fb-d0e4-aa2f5565ce18@oracle.com>

Looks good.

- Alexey

On 1/15/2020 6:34 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Modified customization script for DMG to use location where DMG is 
> mounted to identify image that we need to customize, instead of using 
> name which might not be unique.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8235955
>
> [2] http://cr.openjdk.java.net/~almatvee/8235955/webrev.00/
>
> Thanks,
> Alexander


From james.laskey at oracle.com  Thu Jan 16 13:58:38 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 16 Jan 2020 09:58:38 -0400
Subject: RFR (14) 8237348: Javadoc of MemorySegment::allocateNative should
 state that memory is zero-initialized
In-Reply-To: 
References: 
Message-ID: 

+1


> On Jan 16, 2020, at 7:49 AM, Maurizio Cimadamore  wrote:
> 
> Hi,
> there is a mistake in the javadoc of MemorySegment::allocateNative -as the javadoc says that the initialization state is unspecified, where in reality we do call setMemory on the allocated block (so that memory contents are set to zero).
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mcimadamore/8237348/
> 
> Cheers
> Maurizio
> 


From aph at redhat.com  Thu Jan 16 14:29:09 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Jan 2020 14:29:09 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: 
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
 <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
 <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>
 
Message-ID: <53095ad7-1764-b587-5a4a-71440d112743@redhat.com>

On 1/15/20 6:48 PM, Maurizio Cimadamore wrote:
> Maybe this would be best moved on panama-dev?

OK, I'll do that, but this affects everyone. It's one of the
difficulties of OpenJDK development that no-one sees the proposals of
projects like this except on the dev list; by the time everyone else
knows it's too late to change anything.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From maurizio.cimadamore at oracle.com  Thu Jan 16 14:51:47 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Jan 2020 14:51:47 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <53095ad7-1764-b587-5a4a-71440d112743@redhat.com>
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
 <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
 <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>
 
 <53095ad7-1764-b587-5a4a-71440d112743@redhat.com>
Message-ID: <5a995cdd-c5a1-7ad3-8e49-1610fe0387b4@oracle.com>

Hi Andrew,
I think characterizing this specific instance as a case of "too late to 
change anything" is a tad harsh. The memory access API has been made 
available via an _incubating_ module for precisely this reason - to make 
it more widely accessible, so that developers (like you!) could try it 
out (as we're well aware that not all the folks who might be interested 
in this API might not be on panama-dev) and report back on their 
experience. The API being incubating means that there's plenty of time 
to change and improve things, based on feedback - please do not assume 
that what we made available in JDK 14 is set in stone, as that's the 
opposite of what JEP 11 [1] is supposed to mean.

If you prefer to have this discussion in core-libs, feel free to do so - 
but I'd suggest to (1) keep panama-dev in CC and (2) start a new thread 
since the issue you raise has nothing to do with this RFR.

Cheers
Maurizio

[1] - https://openjdk.java.net/jeps/11

On 16/01/2020 14:29, Andrew Haley wrote:
> On 1/15/20 6:48 PM, Maurizio Cimadamore wrote:
>> Maybe this would be best moved on panama-dev?
> OK, I'll do that, but this affects everyone. It's one of the
> difficulties of OpenJDK development that no-one sees the proposals of
> projects like this except on the dev list; by the time everyone else
> knows it's too late to change anything.
>

From andy.herrick at oracle.com  Thu Jan 16 15:31:10 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 16 Jan 2020 10:31:10 -0500
Subject: RFR: JDK-8235955: [dmg] DMG creation fails without error message
 if previous DMG was not ejected
In-Reply-To: <6b8d6062-0492-a943-bf73-e5e129aeb344@oracle.com>
References: <6b8d6062-0492-a943-bf73-e5e129aeb344@oracle.com>
Message-ID: 

ok - looks good.

/Andy

On 1/15/2020 6:34 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Modified customization script for DMG to use location where DMG is 
> mounted to identify image that we need to customize, instead of using 
> name which might not be unique.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8235955
>
> [2] http://cr.openjdk.java.net/~almatvee/8235955/webrev.00/
>
> Thanks,
> Alexander

From maurizio.cimadamore at oracle.com  Thu Jan 16 15:40:08 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Jan 2020 15:40:08 +0000
Subject: RFR (14) 8237370: Javadoc of memory access API still refers to old
 MemoryAddress::offset method
Message-ID: <2f4e4997-ccd2-33d6-09ff-08d7e425563a@oracle.com>

Small patch which fixes some @code snippets still showing 
MemoryAddress::offset(long) instead of MemoryAddress::addOffset(long)

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8237370/

Cheers
Maurizio


From claes.redestad at oracle.com  Thu Jan 16 16:21:28 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 16 Jan 2020 17:21:28 +0100
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
 <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
Message-ID: <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>

Florian,

On 2020-01-16 11:20, Florian Weimer wrote:
> * Claes Redestad:
> 
>> we're doing plenty of iterations over Set.of() instances during
>> bootstrap, which makes these operations show up prominently in
>> startup profiles. This patch refactors a few hot methods to get a
>> measureable startup improvement without regressing on targeted
>> microbenchmarks.
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8236641
>> Webrev: http://cr.openjdk.java.net/~redestad/8236641/open.00/
>>
>> (The patch is baselined against 8236850)
> 
> Would it be possible to replace
> 
>    idx = SALT % elements.length;
> 
>    idx = (SALT % (table.length >> 1)) << 1;
> 
> with this?
> 
>    idx = (int) ((elements.length * (long) SALT) >>> 32);
> 
>    idx = (int) (((table.length >> 1) * (long) SALT) >>> 31);
> 
> A long multiplication followed by a shift should be faster than an int
> modulo.
> 
> See this thread for some background:
> 
> 

I must have missed this - very interesting!

I see there's been some discussion about using it more generally, with
well-founded concern that it will only work well if the hashCode is
well-conditioned. Still could be interesting as a means to speed up
SetN/MapN::probe:

  int idx = Math.floorMod(pe.hashCode(), elements.length);

As we probably need to up-mix the hashCode a bit, I did this quick test
guided by how well it manages to distributed various ranges of Integers:

             int h = pe.hashCode();
             // mix low bits into upper bits
             h ^= h << 3;
             h ^= h << 13;
             h ^= h << 27;
             h >>>= 1; // stay positive
             int idx = (int)(((long)h * elements.length) >> 31);

For the ranges of Integers I tested it distributes things (much) better.

And it speed up ImmutableColls.createSetOf by a factor ~1.6-1.7x
(uses constant Strings as payload, so hashCode overhead is downplayed).

While promising, any mixer is a trade-off between how well it mixes
(which is very hard to evaluate universally) and the performance hit it
incurs. A few shifts should remain faster than Math.floorMod while
hopefully improving distribution over the baseline in 99% of cases, but
this surely needs more investigation (above is most likely too naive).

Let's file a follow-up.

Regardless, your suggestion above ought to work great for SALT %
foo.length since SALT is just a pseudo-random number, which is likely to
have a good mix of high bits set, so we'll get a random number in the
[0..N-1] range for any table size N. (For MapN we can't simplify (x >>>
32) << 1 to x >> 31 like you did, though, since we need to mask out the
lowest bit to get an even index.). I don't see any significant
improvement in micros, but since we're no longer doing a division we can
remove the test for zero in the constructors, so it feels like a
cleanup.

I've cleaned up a bit (SALT can be made into a long to reduce casts
etc), and rolled it into the current patch:

http://cr.openjdk.java.net/~redestad/8236641/open.01/

Thanks!

/Claes

From chris.hegarty at oracle.com  Thu Jan 16 17:20:52 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 16 Jan 2020 17:20:52 +0000
Subject: RFR (14) 8237370: Javadoc of memory access API still refers to
 old MemoryAddress::offset method
In-Reply-To: <2f4e4997-ccd2-33d6-09ff-08d7e425563a@oracle.com>
References: <2f4e4997-ccd2-33d6-09ff-08d7e425563a@oracle.com>
Message-ID: <43413939-59D4-4CE2-861B-9EA80637E0D9@oracle.com>



> On 16 Jan 2020, at 15:40, Maurizio Cimadamore  wrote:
> 
> Small patch which fixes some @code snippets still showing MemoryAddress::offset(long) instead of MemoryAddress::addOffset(long)
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mcimadamore/8237370/

LGTM.

-Chris.


From huizhe.wang at oracle.com  Thu Jan 16 17:40:18 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 16 Jan 2020 09:40:18 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
Message-ID: <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>



On 1/16/20 2:35 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> Looks OK to me as well.

Thanks for the review!

> I am a bit surprised by the number of methods that are no longer
> `final` though. Do you know what was the motivation for those
> changes?

The original patch did not have any detailed comment or link to a bug 
report. The title was "Remove redundant modifiers. Minor Javadoc and 
formatting. "? So it seemed they were cleaning up "redundant modifiers". 
It would be interesting if that's the reason to remove 'final'. However, 
it has no impact on our usage of the library in java.xml.

Best regards,
Joe
>
> best regards,
>
> -- daniel
>
> On 14/01/2020 20:08, Joe Wang wrote:
>> Hi,
>>
>> Please review an update to BCEL 6.4.1.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
>> webrev: 
>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
>>
>> Similar approach as the last update:
>> 1. Format
>> ???? All format changes are kept as they are in the source in order 
>> to reduce the amount of changes in future updates, the exceptions are 
>> extreme long lines.
>>
>> 2. Exclusions
>> ???? Contents that were not in the JDK or unnecessary for java.xml 
>> are excluded. This includes: the ability to load arbitrary classes 
>> and classes related to ClassLoader, ClassPath and JavaWrapper, and 
>> relevant methods and references in other classes; System Properties 
>> used to set cache sizes and track certain statistics (caches are set 
>> as in previous version); Deprecated classes and related contents.
>>
>> 3. Warnings
>> ???? Warnings were the main reason for the changes made to the 
>> original source. It has been done in the previous update. They are 
>> re-applied for this update. The LastModified field indicates such 
>> changes to the original source.
>>
>> 4. Deprecated fields to private and references to deprecated methods
>> ??? Deprecated fields in the original source were changed to private 
>> ones in previous update. References to deprecated methods were 
>> modified to use proper methods. These changes are inherited in this 
>> update.
>>
>> 5. Test
>> ???? Since the update does not affect java.xml's usage of the BCEL 
>> component, it is essential to pass all of the existing tests. I've 
>> run the tests multiple times and noted that all of the XML functional 
>> and unit tests passed, so were JCK XML tests. A performance test is 
>> running.
>>
>>
>> Thanks,
>> Joe
>>
>>
>


From forax at univ-mlv.fr  Thu Jan 16 17:50:27 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 16 Jan 2020 18:50:27 +0100 (CET)
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
 <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
Message-ID: <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Joe Wang" 
> ?: "Daniel Fuchs" , "core-libs-dev" 
> Envoy?: Jeudi 16 Janvier 2020 18:40:18
> Objet: Re: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1

> On 1/16/20 2:35 AM, Daniel Fuchs wrote:
>> Hi Joe,
>>
>> Looks OK to me as well.
> 
> Thanks for the review!
> 
>> I am a bit surprised by the number of methods that are no longer
>> `final` though. Do you know what was the motivation for those
>> changes?
> 
> The original patch did not have any detailed comment or link to a bug
> report. The title was "Remove redundant modifiers. Minor Javadoc and
> formatting. "? So it seemed they were cleaning up "redundant modifiers".
> It would be interesting if that's the reason to remove 'final'. However,
> it has no impact on our usage of the library in java.xml.

It's because the class itself is declared final (at least on the few files I've taken a look), so final on a method is redundant.

> 
> Best regards,
> Joe

regards,
R?mi

>>
>> best regards,
>>
>> -- daniel
>>
>> On 14/01/2020 20:08, Joe Wang wrote:
>>> Hi,
>>>
>>> Please review an update to BCEL 6.4.1.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
>>> webrev:
>>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
>>>
>>> Similar approach as the last update:
>>> 1. Format
>>> ???? All format changes are kept as they are in the source in order
>>> to reduce the amount of changes in future updates, the exceptions are
>>> extreme long lines.
>>>
>>> 2. Exclusions
>>> ???? Contents that were not in the JDK or unnecessary for java.xml
>>> are excluded. This includes: the ability to load arbitrary classes
>>> and classes related to ClassLoader, ClassPath and JavaWrapper, and
>>> relevant methods and references in other classes; System Properties
>>> used to set cache sizes and track certain statistics (caches are set
>>> as in previous version); Deprecated classes and related contents.
>>>
>>> 3. Warnings
>>> ???? Warnings were the main reason for the changes made to the
>>> original source. It has been done in the previous update. They are
>>> re-applied for this update. The LastModified field indicates such
>>> changes to the original source.
>>>
>>> 4. Deprecated fields to private and references to deprecated methods
>>> ??? Deprecated fields in the original source were changed to private
>>> ones in previous update. References to deprecated methods were
>>> modified to use proper methods. These changes are inherited in this
>>> update.
>>>
>>> 5. Test
>>> ???? Since the update does not affect java.xml's usage of the BCEL
>>> component, it is essential to pass all of the existing tests. I've
>>> run the tests multiple times and noted that all of the XML functional
>>> and unit tests passed, so were JCK XML tests. A performance test is
>>> running.
>>>
>>>
>>> Thanks,
>>> Joe
>>>
>>>

From aph at redhat.com  Thu Jan 16 18:13:59 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Jan 2020 18:13:59 +0000
Subject: RFR (14) 8235837: Memory access API refinements
In-Reply-To: <5a995cdd-c5a1-7ad3-8e49-1610fe0387b4@oracle.com>
References: 
 <8fae8b22-786b-5185-a51e-68cef79711d5@redhat.com>
 <65f3cfce-1105-ed04-ae22-6ed6a6d7a1e6@oracle.com>
 <3ef43b90-7190-7ed5-1215-c0873b0a5023@redhat.com>
 
 <53095ad7-1764-b587-5a4a-71440d112743@redhat.com>
 <5a995cdd-c5a1-7ad3-8e49-1610fe0387b4@oracle.com>
Message-ID: <7f4bdcff-3e06-cd65-bd52-c9d2b5946a8a@redhat.com>

On 1/16/20 2:51 PM, Maurizio Cimadamore wrote:
> I think characterizing this specific instance as a case of "too late to
> change anything" is a tad harsh.

Sorry, I can be like that.  :-)

> The memory access API has been made available via an _incubating_
> module for precisely this reason - to make it more widely
> accessible, so that developers (like you!) could try it out (as
> we're well aware that not all the folks who might be interested in
> this API might not be on panama-dev) and report back on their
> experience. The API being incubating means that there's plenty of
> time to change and improve things, based on feedback - please do not
> assume that what we made available in JDK 14 is set in stone, as
> that's the opposite of what JEP 11 [1] is supposed to mean.

OK, I accept that.

>
> If you prefer to have this discussion in core-libs, feel free to do so -
> but I'd suggest to (1) keep panama-dev in CC and (2) start a new thread
> since the issue you raise has nothing to do with this RFR.

I'm over in panama-dev now.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From huizhe.wang at oracle.com  Thu Jan 16 18:22:27 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 16 Jan 2020 10:22:27 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
 <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
 <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>
Message-ID: <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>



On 1/16/20 9:50 AM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Joe Wang" 
>> ?: "Daniel Fuchs" , "core-libs-dev" 
>> Envoy?: Jeudi 16 Janvier 2020 18:40:18
>> Objet: Re: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
>> On 1/16/20 2:35 AM, Daniel Fuchs wrote:
>>> Hi Joe,
>>>
>>> Looks OK to me as well.
>> Thanks for the review!
>>
>>> I am a bit surprised by the number of methods that are no longer
>>> `final` though. Do you know what was the motivation for those
>>> changes?
>> The original patch did not have any detailed comment or link to a bug
>> report. The title was "Remove redundant modifiers. Minor Javadoc and
>> formatting. "? So it seemed they were cleaning up "redundant modifiers".
>> It would be interesting if that's the reason to remove 'final'. However,
>> it has no impact on our usage of the library in java.xml.
> It's because the class itself is declared final (at least on the few files I've taken a look), so final on a method is redundant.

Aha, indeed! I double-checked classes such as Code.java, 
CodeException.java, etc.


Meanwhile, I noticed I missed the new classes in the webrev. I used a 
changelist to create webrevs and forgot to add the new ones to the list. 
Sorry about that. Here's the updated webrev:

http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev_02/

Thanks,
Joe

>
>> Best regards,
>> Joe
> regards,
> R?mi
>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 14/01/2020 20:08, Joe Wang wrote:
>>>> Hi,
>>>>
>>>> Please review an update to BCEL 6.4.1.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
>>>> webrev:
>>>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
>>>>
>>>> Similar approach as the last update:
>>>> 1. Format
>>>>  ???? All format changes are kept as they are in the source in order
>>>> to reduce the amount of changes in future updates, the exceptions are
>>>> extreme long lines.
>>>>
>>>> 2. Exclusions
>>>>  ???? Contents that were not in the JDK or unnecessary for java.xml
>>>> are excluded. This includes: the ability to load arbitrary classes
>>>> and classes related to ClassLoader, ClassPath and JavaWrapper, and
>>>> relevant methods and references in other classes; System Properties
>>>> used to set cache sizes and track certain statistics (caches are set
>>>> as in previous version); Deprecated classes and related contents.
>>>>
>>>> 3. Warnings
>>>>  ???? Warnings were the main reason for the changes made to the
>>>> original source. It has been done in the previous update. They are
>>>> re-applied for this update. The LastModified field indicates such
>>>> changes to the original source.
>>>>
>>>> 4. Deprecated fields to private and references to deprecated methods
>>>>  ??? Deprecated fields in the original source were changed to private
>>>> ones in previous update. References to deprecated methods were
>>>> modified to use proper methods. These changes are inherited in this
>>>> update.
>>>>
>>>> 5. Test
>>>>  ???? Since the update does not affect java.xml's usage of the BCEL
>>>> component, it is essential to pass all of the existing tests. I've
>>>> run the tests multiple times and noted that all of the XML functional
>>>> and unit tests passed, so were JCK XML tests. A performance test is
>>>> running.
>>>>
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>


From Roger.Riggs at oracle.com  Thu Jan 16 20:06:01 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 16 Jan 2020 15:06:01 -0500
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: 
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 
 
Message-ID: 

Hi Naoto,

A couple of comments in the tests.

HijrahConfigTest:

72:? Since onExit() starts a task in some executor and in some context,
 ?? its not clear that an exception thrown in that task will be reported.
 ? Use the normal p.waitFor() and check the exit code.

73: include the failed exit value in the exception; It may have some use 
in debugging.

HijrahConfigCheck:

41: The data structure is a set; no entry can appear twice; there's no 
point to the text
 ? or the value of count should be included in the exception

44: typo: Instatiation

48: if they are different, print the two chronologies

hijrah-config-Hijrah-test_islamic-test.properties:
 ?I would include a comment to say the data does not represent an actual 
calendar.

Roger

p.s.
!! tests.Helper is a very uninformative class name (but that's not your 
doing).






On 1/15/20 7:49 PM, naoto.sato at oracle.com wrote:
> Updated:
>
> https://cr.openjdk.java.net/~naoto/8187987/webrev.02/
>
> The change includes the new naming convention, reduction of properties 
> files reading to once, and utilization of logging.
>
> Naoto
>
> On 1/15/20 12:37 PM, Roger Riggs wrote:
>> Hi,
>>
>> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>>> Hi Roger,
>>>
>>> Thank you for the review. Please find my comments below:
>>>
>>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> Is it correct to say that there is no impact on startup until there 
>>>> is an explicit reference to HijrahChronology?
>>>> It would seem that the registering HijrahChronology would trigger 
>>>> all the work and that happens when Chronology is initialized. (see 
>>>> below)
>>>
>>> What I meant in the reply to Joe's email was that the data validity 
>>> check done in loadCalendarData(), e.g., year value check, etc. which 
>>> are not done at class init. But you are correct that the properties 
>>> files are read twice (below). I thought it was fine as this is not a 
>>> common case (not happened before, to be precise).
>> Until it get used, there will still be a probe of the filesystem to 
>> see if a config directory/file exists
>> that would impact every startup. I don't see a way to mitigate that 
>> without making the config? more complex.
>>>
>>>>
>>>> HijrahChronology.java:
>>>>
>>>> 291-295: Since registerCustomChrono is the only place where 
>>>> CONF_PATH is used,
>>>> ??? do all the work, including the property lookup in that method.
>>>> 836:? If other chronologies are built-in this code will need to be 
>>>> changed.
>>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>>> back to /conf/chronology?
>>>
>>> Yes, it would have to be changed if we support built-in type other 
>>> than umalqura. But I would think other code would have to anyways. I 
>>> think we can take advantage of the fact that umalqura is the only 
>>> built-in, and others come from /conf/chronology so that extra 
>>> fallback is avoided.
>> Possibly, but could/would be more localized and consist of only the 
>> registerChronology call.
>>>
>>>>
>>>> 855: Since all the loading is triggered from a static initializer, 
>>>> is there really any point in throwing an exception.
>>>> ?? More useful would be a logging message (assuming logging is 
>>>> allowed early in startup when Chronology is initialized)
>>>
>>> Good point. I will replace UncheckedIOException with logging.
>>>
>>>>
>>>> 1054: readConfigProperties: The case for the other 
>>>> HijrahChronologies delays loading the data until it is needed.
>>>> This is doing the work to read the file and create the properties 
>>>> instance but then discards it to be read a second time later.
>>>>
>>>> Perhaps we need to specify that the config file name includes both 
>>>> the id and type so it can be registered without reading the file.
>>>
>>> Should the file name like "Hijrah-config-_.properties" work?
>> yes, its worth checking the valid characters in id and type.
>>
>> Thanks, Roger
>>
>> BTW, the test drive can be implemented using testng, only the test 
>> itself is easier as main().
>>
>>>
>>> Naoto
>>>
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>>
>>>>>
>>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> Thank you for the review. Please find my comments below:
>>>>>>
>>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>>> Hi Naoto,
>>>>>>>
>>>>>>> Since it's dealing with non-standard properties files, is there 
>>>>>>> a need to verify the files? The constructor (HijrahChronology) 
>>>>>>> does check whether the id or type is empty. If there is no 
>>>>>>> existing process to validate, it's probably not worth it to 
>>>>>>> spend time as it's rare and it's config time.
>>>>>>
>>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>>> (thus the faster the better) and cache it, then check the 
>>>>>> validity later at actual method invocation (cf. 
>>>>>> checkCalendarInit() method).
>>>>>
>>>>> Make sense.
>>>>>>
>>>>>>>
>>>>>>> The test summary states "Test image creation", it may be better 
>>>>>>> to say sth. like verifies custom configuration?
>>>>>>
>>>>>> Good catch! I was simply copying some portion from other test 
>>>>>> case. Corrected:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>>
>>>>> Looks good to me.
>>>>>
>>>>> Best regards,
>>>>> Joe
>>>>>
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>> Joe
>>>>>>>
>>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the fix to the following issue:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>>
>>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>>
>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>>
>>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>>>> properties files. However it does not work as designed. This 
>>>>>>>> change intends to make it work.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>
>>>>>
>>>>
>>


From naoto.sato at oracle.com  Thu Jan 16 21:08:53 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 16 Jan 2020 13:08:53 -0800
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: 
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 
 
 
Message-ID: <11107b9b-5c4f-8a60-642d-7341c63d7617@oracle.com>

Hi Roger,

Thanks. My comments are embedded below.

On 1/16/20 12:06 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> A couple of comments in the tests.
> 
> HijrahConfigTest:
> 
> 72:? Since onExit() starts a task in some executor and in some context,
>  ?? its not clear that an exception thrown in that task will be reported.
>  ? Use the normal p.waitFor() and check the exit code.

Hmm, I was using the example in onExit() method, which reads:

---
API Note:
Using onExit is an alternative to waitFor that enables both additional 
concurrency and convenient access to the result of the Process.
---

So "alternative" is not "interchangeable" in this context?

> 
> 73: include the failed exit value in the exception; It may have some use 
> in debugging.

Anyway, I changed the above code to p.waitFor() for this reason.

> 
> HijrahConfigCheck:
> 
> 41: The data structure is a set; no entry can appear twice; there's no 
> point to the text
>  ? or the value of count should be included in the exception

At first I thought the same, but realized there could be a error case 
where "calendar type" in returned objects are the same, but objects 
themselves are different (thus the Set could accommodate both), so the test.

> 
> 44: typo: Instatiation
> 
> 48: if they are different, print the two chronologies
> 
> hijrah-config-Hijrah-test_islamic-test.properties:
>  ?I would include a comment to say the data does not represent an actual 
> calendar.

Corrected.

> 
> Roger
> 
> p.s.
> !! tests.Helper is a very uninformative class name (but that's not your 
> doing).

"Helper" is not helping in that regard :-)

Updated webrev: http://cr.openjdk.java.net/~naoto/8187987/webrev.03/

Naoto
> 
> 
> 
> 
> 
> 
> On 1/15/20 7:49 PM, naoto.sato at oracle.com wrote:
>> Updated:
>>
>> https://cr.openjdk.java.net/~naoto/8187987/webrev.02/
>>
>> The change includes the new naming convention, reduction of properties 
>> files reading to once, and utilization of logging.
>>
>> Naoto
>>
>> On 1/15/20 12:37 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for the review. Please find my comments below:
>>>>
>>>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> Is it correct to say that there is no impact on startup until there 
>>>>> is an explicit reference to HijrahChronology?
>>>>> It would seem that the registering HijrahChronology would trigger 
>>>>> all the work and that happens when Chronology is initialized. (see 
>>>>> below)
>>>>
>>>> What I meant in the reply to Joe's email was that the data validity 
>>>> check done in loadCalendarData(), e.g., year value check, etc. which 
>>>> are not done at class init. But you are correct that the properties 
>>>> files are read twice (below). I thought it was fine as this is not a 
>>>> common case (not happened before, to be precise).
>>> Until it get used, there will still be a probe of the filesystem to 
>>> see if a config directory/file exists
>>> that would impact every startup. I don't see a way to mitigate that 
>>> without making the config? more complex.
>>>>
>>>>>
>>>>> HijrahChronology.java:
>>>>>
>>>>> 291-295: Since registerCustomChrono is the only place where 
>>>>> CONF_PATH is used,
>>>>> ??? do all the work, including the property lookup in that method.
>>>>> 836:? If other chronologies are built-in this code will need to be 
>>>>> changed.
>>>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>>>> back to /conf/chronology?
>>>>
>>>> Yes, it would have to be changed if we support built-in type other 
>>>> than umalqura. But I would think other code would have to anyways. I 
>>>> think we can take advantage of the fact that umalqura is the only 
>>>> built-in, and others come from /conf/chronology so that extra 
>>>> fallback is avoided.
>>> Possibly, but could/would be more localized and consist of only the 
>>> registerChronology call.
>>>>
>>>>>
>>>>> 855: Since all the loading is triggered from a static initializer, 
>>>>> is there really any point in throwing an exception.
>>>>> ?? More useful would be a logging message (assuming logging is 
>>>>> allowed early in startup when Chronology is initialized)
>>>>
>>>> Good point. I will replace UncheckedIOException with logging.
>>>>
>>>>>
>>>>> 1054: readConfigProperties: The case for the other 
>>>>> HijrahChronologies delays loading the data until it is needed.
>>>>> This is doing the work to read the file and create the properties 
>>>>> instance but then discards it to be read a second time later.
>>>>>
>>>>> Perhaps we need to specify that the config file name includes both 
>>>>> the id and type so it can be registered without reading the file.
>>>>
>>>> Should the file name like "Hijrah-config-_.properties" work?
>>> yes, its worth checking the valid characters in id and type.
>>>
>>> Thanks, Roger
>>>
>>> BTW, the test drive can be implemented using testng, only the test 
>>> itself is easier as main().
>>>
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>>>
>>>>>>
>>>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> Thank you for the review. Please find my comments below:
>>>>>>>
>>>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>>>> Hi Naoto,
>>>>>>>>
>>>>>>>> Since it's dealing with non-standard properties files, is there 
>>>>>>>> a need to verify the files? The constructor (HijrahChronology) 
>>>>>>>> does check whether the id or type is empty. If there is no 
>>>>>>>> existing process to validate, it's probably not worth it to 
>>>>>>>> spend time as it's rare and it's config time.
>>>>>>>
>>>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>>>> (thus the faster the better) and cache it, then check the 
>>>>>>> validity later at actual method invocation (cf. 
>>>>>>> checkCalendarInit() method).
>>>>>>
>>>>>> Make sense.
>>>>>>>
>>>>>>>>
>>>>>>>> The test summary states "Test image creation", it may be better 
>>>>>>>> to say sth. like verifies custom configuration?
>>>>>>>
>>>>>>> Good catch! I was simply copying some portion from other test 
>>>>>>> case. Corrected:
>>>>>>>
>>>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>>>
>>>>>> Looks good to me.
>>>>>>
>>>>>> Best regards,
>>>>>> Joe
>>>>>>
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review the fix to the following issue:
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>>>
>>>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>>>
>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>>>
>>>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>>>>> properties files. However it does not work as designed. This 
>>>>>>>>> change intends to make it work.
>>>>>>>>>
>>>>>>>>> Naoto
>>>>>>>>
>>>>>>
>>>>>
>>>
> 

From lance.andersen at oracle.com  Thu Jan 16 22:39:49 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 16 Jan 2020 17:39:49 -0500
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
 <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
 <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>
 <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>
Message-ID: <7DFFEF3D-91C6-48A6-95B1-52AEB396F835@oracle.com>

Hi Joe,

The additions look OK also

Best
Lance

> On Jan 16, 2020, at 1:22 PM, Joe Wang  wrote:
> 
> 
> 
> On 1/16/20 9:50 AM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Joe Wang" 
>>> ?: "Daniel Fuchs" , "core-libs-dev" 
>>> Envoy?: Jeudi 16 Janvier 2020 18:40:18
>>> Objet: Re: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
>>> On 1/16/20 2:35 AM, Daniel Fuchs wrote:
>>>> Hi Joe,
>>>> 
>>>> Looks OK to me as well.
>>> Thanks for the review!
>>> 
>>>> I am a bit surprised by the number of methods that are no longer
>>>> `final` though. Do you know what was the motivation for those
>>>> changes?
>>> The original patch did not have any detailed comment or link to a bug
>>> report. The title was "Remove redundant modifiers. Minor Javadoc and
>>> formatting. "  So it seemed they were cleaning up "redundant modifiers".
>>> It would be interesting if that's the reason to remove 'final'. However,
>>> it has no impact on our usage of the library in java.xml.
>> It's because the class itself is declared final (at least on the few files I've taken a look), so final on a method is redundant.
> 
> Aha, indeed! I double-checked classes such as Code.java, CodeException.java, etc.
> 
> 
> Meanwhile, I noticed I missed the new classes in the webrev. I used a changelist to create webrevs and forgot to add the new ones to the list. Sorry about that. Here's the updated webrev:
> 
> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev_02/
> 
> Thanks,
> Joe
> 
>> 
>>> Best regards,
>>> Joe
>> regards,
>> R?mi
>> 
>>>> best regards,
>>>> 
>>>> -- daniel
>>>> 
>>>> On 14/01/2020 20:08, Joe Wang wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review an update to BCEL 6.4.1.
>>>>> 
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
>>>>> 
>>>>> Similar approach as the last update:
>>>>> 1. Format
>>>>>      All format changes are kept as they are in the source in order
>>>>> to reduce the amount of changes in future updates, the exceptions are
>>>>> extreme long lines.
>>>>> 
>>>>> 2. Exclusions
>>>>>      Contents that were not in the JDK or unnecessary for java.xml
>>>>> are excluded. This includes: the ability to load arbitrary classes
>>>>> and classes related to ClassLoader, ClassPath and JavaWrapper, and
>>>>> relevant methods and references in other classes; System Properties
>>>>> used to set cache sizes and track certain statistics (caches are set
>>>>> as in previous version); Deprecated classes and related contents.
>>>>> 
>>>>> 3. Warnings
>>>>>      Warnings were the main reason for the changes made to the
>>>>> original source. It has been done in the previous update. They are
>>>>> re-applied for this update. The LastModified field indicates such
>>>>> changes to the original source.
>>>>> 
>>>>> 4. Deprecated fields to private and references to deprecated methods
>>>>>     Deprecated fields in the original source were changed to private
>>>>> ones in previous update. References to deprecated methods were
>>>>> modified to use proper methods. These changes are inherited in this
>>>>> update.
>>>>> 
>>>>> 5. Test
>>>>>      Since the update does not affect java.xml's usage of the BCEL
>>>>> component, it is essential to pass all of the existing tests. I've
>>>>> run the tests multiple times and noted that all of the XML functional
>>>>> and unit tests passed, so were JCK XML tests. A performance test is
>>>>> running.
>>>>> 
>>>>> 
>>>>> 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 brian.burkhalter at oracle.com  Fri Jan 17 01:35:37 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 16 Jan 2020 17:35:37 -0800
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
Message-ID: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>

This issue [1] attempts to reinstate the change for [2] which was backed out to fix [3] thereby maintaining longstanding behavior. The proposed change [4] modifies the specification to increment the line number also when EOF is encountered and is not immediately preceded by a line terminator. If this all seems reasonable then a CSR will be filed after the code review.

One thing I am uncertain about is the change to skip() at lines 293-295 of LineNumberReader. I am not sure that those  lines should be added.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8235792
[2] https://bugs.openjdk.java.net/browse/JDK-8230342
[3] https://bugs.openjdk.java.net/browse/JDK-8235668
[4] http://cr.openjdk.java.net/~bpb/8235792/webrev.00/

From mandy.chung at oracle.com  Fri Jan 17 01:43:22 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Jan 2020 17:43:22 -0800
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
Message-ID: 

Hi Bob, Severin,

On 1/9/20 11:51 AM, Severin Gehwolf wrote:
> Thanks for the review! Should all be fixed now. Updated webrev:
>
> incremental:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
> full:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/

This patch may be more appropriate to be reviewed by the serviceability 
group (cc'ed) as this is monitoring-related.

jdk.internal.platform.Metrics is an internal API that you are free to 
change the API as appropriate.? Given that 13 out of 38 metrics defined 
in Metrics are no longer supported by cgroups v2, it's cleaner to 
refactor Metrics interface to be implementable by cgroups v1 and v2 and 
then define a cgroups version-specific metrics to extend Metrics, which 
means that it seems reasonable to make it linux-only sub-interface.? 
Client can cast to cgroup v1 metrics interface if needed.? Sorry for not 
chiming in earlier and I am not following the cgroups v2 changes.? This 
should be a straight-forward change which will make the implementation 
cleaner.? You would no longer need the new *_UNLIMITED and 
*_NOT_SUPPORTED constants.

A couple of quick comments when skimming on the new files:

CgroupSubsystemController.java
    s/parm/param (including javadoc @param tag)

CgroupInfo.java
    cgroupPath is not used??

Mandy

From huizhe.wang at oracle.com  Fri Jan 17 02:22:06 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 16 Jan 2020 18:22:06 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <7DFFEF3D-91C6-48A6-95B1-52AEB396F835@oracle.com>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
 <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
 <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>
 <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>
 <7DFFEF3D-91C6-48A6-95B1-52AEB396F835@oracle.com>
Message-ID: <606802bd-b2d1-babd-6c3f-6ff5657aee72@oracle.com>

Thanks Lance, again :-)

-Joe

On 1/16/20 2:39 PM, Lance Andersen wrote:
> Hi Joe,
>
> The additions look OK also
>
> Best
> Lance
>
>> On Jan 16, 2020, at 1:22 PM, Joe Wang > > wrote:
>>
>>
>>
>> On 1/16/20 9:50 AM, Remi Forax wrote:
>>> ----- Mail original -----
>>>> De: "Joe Wang" >
>>>> ?: "Daniel Fuchs" >>> >, "core-libs-dev" 
>>>> >>> >
>>>> Envoy?: Jeudi 16 Janvier 2020 18:40:18
>>>> Objet: Re: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
>>>> On 1/16/20 2:35 AM, Daniel Fuchs wrote:
>>>>> Hi Joe,
>>>>>
>>>>> Looks OK to me as well.
>>>> Thanks for the review!
>>>>
>>>>> I am a bit surprised by the number of methods that are no longer
>>>>> `final` though. Do you know what was the motivation for those
>>>>> changes?
>>>> The original patch did not have any detailed comment or link to a bug
>>>> report. The title was "Remove redundant modifiers. Minor Javadoc and
>>>> formatting. "? So it seemed they were cleaning up "redundant 
>>>> modifiers".
>>>> It would be interesting if that's the reason to remove 'final'. 
>>>> However,
>>>> it has no impact on our usage of the library in java.xml.
>>> It's because the class itself is declared final (at least on the few 
>>> files I've taken a look), so final on a method is redundant.
>>
>> Aha, indeed! I double-checked classes such as Code.java, 
>> CodeException.java, etc.
>>
>>
>> Meanwhile, I noticed I missed the new classes in the webrev. I used a 
>> changelist to create webrevs and forgot to add the new ones to the 
>> list. Sorry about that. Here's the updated webrev:
>>
>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev_02/
>>
>> Thanks,
>> Joe
>>
>>>
>>>> Best regards,
>>>> Joe
>>> regards,
>>> R?mi
>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> On 14/01/2020 20:08, Joe Wang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review an update to BCEL 6.4.1.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
>>>>>>
>>>>>> Similar approach as the last update:
>>>>>> 1. Format
>>>>>> ???? All format changes are kept as they are in the source in order
>>>>>> to reduce the amount of changes in future updates, the exceptions are
>>>>>> extreme long lines.
>>>>>>
>>>>>> 2. Exclusions
>>>>>> ???? Contents that were not in the JDK or unnecessary for java.xml
>>>>>> are excluded. This includes: the ability to load arbitrary classes
>>>>>> and classes related to ClassLoader, ClassPath and JavaWrapper, and
>>>>>> relevant methods and references in other classes; System Properties
>>>>>> used to set cache sizes and track certain statistics (caches are set
>>>>>> as in previous version); Deprecated classes and related contents.
>>>>>>
>>>>>> 3. Warnings
>>>>>> ???? Warnings were the main reason for the changes made to the
>>>>>> original source. It has been done in the previous update. They are
>>>>>> re-applied for this update. The LastModified field indicates such
>>>>>> changes to the original source.
>>>>>>
>>>>>> 4. Deprecated fields to private and references to deprecated methods
>>>>>> ??? Deprecated fields in the original source were changed to private
>>>>>> ones in previous update. References to deprecated methods were
>>>>>> modified to use proper methods. These changes are inherited in this
>>>>>> update.
>>>>>>
>>>>>> 5. Test
>>>>>> ???? Since the update does not affect java.xml's usage of the BCEL
>>>>>> component, it is essential to pass all of the existing tests. I've
>>>>>> run the tests multiple times and noted that all of the XML functional
>>>>>> and unit tests passed, so were JCK XML tests. A performance test is
>>>>>> running.
>>>>>>
>>>>>>
>>>>>> 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 sean.coffey at oracle.com  Fri Jan 17 10:59:42 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 17 Jan 2020 10:59:42 +0000
Subject: RFR: 8218021: jarsigner strips the execute permission when signing a
 .zip file
Message-ID: 

Hi,

Looking to introduce some JDK private functionality which will help 
preserve internal zip file attribute permissions when jarsigner is run 
on a zip file. Some of the logic is taken from the recent work carried 
out in this area for zipfs API.

https://bugs.openjdk.java.net/browse/JDK-8218021
http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/

regards,
Sean.



From li.jiang at oracle.com  Fri Jan 17 11:31:34 2020
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Fri, 17 Jan 2020 19:31:34 +0800
Subject: RFR: 8237465: JDK 14 L10N resource files update - msg drop 10
Message-ID: <7166b01c-ccd4-204a-6620-5323c7ee952b@oracle.com>

Hi,

Please review the L10N resource files update for JDK 14 msg drop 10.

https://bugs.openjdk.java.net/browse/JDK-8237465
http://cr.openjdk.java.net/~ljiang/8237465/webrev/read/

This is the first msg drop for JDK 14 L10N resources files update, so 
this webrev would cover most of update for JDK 14. We still have the msg 
drop 20 in the next days, so pls commit the l10n related changes before 
Jan 23rd. After msg drop 20, we kick off the msg drop 30 only if 
necessary, showstopper only.

Note: some resource changes in preview features, like Record, Pattern 
Matching, are supported in this msg drop, also some new resource files 
for jpackager were added.

Thanks,
Leo


From daniel.fuchs at oracle.com  Fri Jan 17 11:57:07 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 17 Jan 2020 11:57:07 +0000
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
 <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
 <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>
 <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>
Message-ID: <8e5e22cd-5423-2fb7-e3d7-af4e64cd96d0@oracle.com>

On 16/01/2020 18:22, Joe Wang wrote:
>> It's because the class itself is declared final (at least on the few 
>> files I've taken a look), so final on a method is redundant.

Ah! I had missed that. Thaks R?mi!

> Meanwhile, I noticed I missed the new classes in the webrev. I used a 
> changelist to create webrevs and forgot to add the new ones to the list. 
> Sorry about that. Here's the updated webrev:
> 
> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev_02/

LGTM.

best regards,

-- daniel

From philipp.kunz at paratix.ch  Fri Jan 17 12:40:46 2020
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Fri, 17 Jan 2020 13:40:46 +0100
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: 
References: 
Message-ID: <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch>

Hi Sean,

Nice patch. I wonder why permissions should be preserved only in zip
files. Jar files also are zip files, according to the jar file specs,
and hence, shouldn't jar files benefit of preserving permissions, too?

The file name extension is most often zip for zip files and jar for jar
files but is that really a safe assumption? I would not expect it
always. Removing

> if (zf.getName().toLowerCase().endsWith(".zip")) {

along with similar code in ZipFile would avoid discussing that question
and the test would not have to check that files with another name
extension than zip don't preserve permissions.

Philipp


On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote:
> Hi,
> 
> Looking to introduce some JDK private functionality which will help 
> preserve internal zip file attribute permissions when jarsigner is
> run 
> on a zip file. Some of the logic is taken from the recent work
> carried 
> out in this area for zipfs API.
> 
> https://bugs.openjdk.java.net/browse/JDK-8218021
> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
> 
> regards,
> Sean.
> 
> 


From sean.coffey at oracle.com  Fri Jan 17 13:07:21 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 17 Jan 2020 13:07:21 +0000
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch>
References: 
 <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch>
Message-ID: <79146371-82a6-ea63-4f5a-5e9c3a719495@oracle.com>

Hi Philipp,

On 17/01/2020 12:40, Philipp Kunz wrote:
> Hi Sean,
>
> Nice patch. I wonder why permissions should be preserved only in zip
> files. Jar files also are zip files, according to the jar file specs,
> and hence, shouldn't jar files benefit of preserving permissions, too?
Thanks for your comments. The jar tool has never been interested in the 
posix
permissions fields for the individual entries. Such a change could yield 
more
interoperability issues. Such a change would also need much more 
consideration

The zip tool on the other hand has always populated this field and I 
think the case
at hand is unique here (preserving attributes already created by 
non-java tools)
>
> The file name extension is most often zip for zip files and jar for jar
> files but is that really a safe assumption? I would not expect it
> always. Removing
Yes, I didn't see any easy way to distinguish a zip file from a jar file 
without being
more invasive and scanning file attributes for that file. I could take 
that approach
if it's deemed necessary.

regards,
Sean.
>
>> if (zf.getName().toLowerCase().endsWith(".zip")) {
> along with similar code in ZipFile would avoid discussing that question
> and the test would not have to check that files with another name
> extension than zip don't preserve permissions.
>
> Philipp
>
>
> On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote:
>> Hi,
>>
>> Looking to introduce some JDK private functionality which will help
>> preserve internal zip file attribute permissions when jarsigner is
>> run
>> on a zip file. Some of the logic is taken from the recent work
>> carried
>> out in this area for zipfs API.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8218021
>> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
>>
>> regards,
>> Sean.
>>
>>

From sgehwolf at redhat.com  Fri Jan 17 13:31:53 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 17 Jan 2020 14:31:53 +0100
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: 
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
Message-ID: <48794a4124d7b9e27b011dd1a3f9f8a36ef8cf36.camel@redhat.com>

Hi Mandy,

On Thu, 2020-01-16 at 17:43 -0800, Mandy Chung wrote:
> Hi Bob, Severin,
> 
> On 1/9/20 11:51 AM, Severin Gehwolf wrote:
> > Thanks for the review! Should all be fixed now. Updated webrev:
> > 
> > incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
> > full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/
>  
> This patch may be more appropriate to be reviewed by the
> serviceability group (cc'ed) as this is monitoring-related.

Thanks for the review, Mandy.

> jdk.internal.platform.Metrics is an internal API that you are free to
> change the API as appropriate.  Given that 13 out of 38 metrics
> defined in Metrics are no longer supported by cgroups v2, it's
> cleaner to refactor Metrics interface to be implementable by cgroups
> v1 and v2 and then define a cgroups version-specific metrics to
> extend Metrics, which means that it seems reasonable to make it
> linux-only sub-interface.  Client can cast to cgroup v1 metrics
> interface if needed.  Sorry for not chiming in earlier and I am not
> following the cgroups v2 changes.  This should be a straight-forward
> change which will make the implementation cleaner.  You would no
> longer need the new *_UNLIMITED and *_NOT_SUPPORTED constants.

If I understand you correctly, then we'd have to change how
-XshowSettings:system works currently with it. Not all metrics as
currently printed via LauncherHelper.java are supported in both worlds
(cgroup v1 & v2). It would make handling of cgroup v1 and cgroup v2
specific metrics a little more awkward. Adding instanceof checks and
downcasting as you suggest the consequence for a client would be.

See:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/08/webrev/src/java.base/share/classes/sun/launcher/LauncherHelper.java.sdiff.html

Also, in order to not break cross platform promises we'd also have to
make the version specific interfaces available in shared code (or we'd
risk requiring the user to use reflection) to get the proper sub-
interface logic called.

I'll experiment with it, but I'm not convinced this makes the API any
nicer, really.

> A couple of quick comments when skimming on the new files:
>  CgroupSubsystemController.java
>    s/parm/param (including javadoc @param tag)
> 
> CgroupInfo.java
>    cgroupPath is not used??

Thanks, will update that in the next webrev.

Cheers,
Severin


From mandy.chung at oracle.com  Fri Jan 17 16:53:31 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 17 Jan 2020 08:53:31 -0800
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <48794a4124d7b9e27b011dd1a3f9f8a36ef8cf36.camel@redhat.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
 <48794a4124d7b9e27b011dd1a3f9f8a36ef8cf36.camel@redhat.com>
Message-ID: <906cb751-c63e-246d-6b6e-4dd27de46d3d@oracle.com>



On 1/17/20 5:31 AM, Severin Gehwolf wrote:
>
> If I understand you correctly, then we'd have to change how
> -XshowSettings:system works currently with it. Not all metrics as
> currently printed via LauncherHelper.java are supported in both worlds
> (cgroup v1 & v2). It would make handling of cgroup v1 and cgroup v2
> specific metrics a little more awkward. Adding instanceof checks and
> downcasting as you suggest the consequence for a client would be.
> See:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/08/webrev/src/java.base/share/classes/sun/launcher/LauncherHelper.java.sdiff.html
>
> Also, in order to not break cross platform promises we'd also have to
> make the version specific interfaces available in shared code (or we'd
> risk requiring the user to use reflection) to get the proper sub-
> interface logic called.

-XshowSettings:system output is implementation detail [1] and also 
linux-only option.?? jdk.internal.platform.Metrics is an internal API 
and there is no promise that it supports the union of all cgroups v1 and 
v2 metrics.? As you see, 1/3 of the metrics in v1 are not supported in 
v2.?? It's reasonable for -XshowSettings:system showing the metrics 
valid to the container.

thanks
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8204107

From Roger.Riggs at oracle.com  Fri Jan 17 18:25:11 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 Jan 2020 13:25:11 -0500
Subject: [14] 8237368: Problem with NullPointerException in RMI
 TCPEndpoint.read
Message-ID: 

Please review this fix to correctly allow null for a custom socket 
factory in TCPEndpoint.

issue: https://bugs.openjdk.java.net/browse/JDK-8237368
webrev: http://cr.openjdk.java.net/~rriggs/webrev-proxy-8237368/

Thanks, Roger


From mandy.chung at oracle.com  Fri Jan 17 18:27:28 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 17 Jan 2020 10:27:28 -0800
Subject: [14] 8237368: Problem with NullPointerException in RMI
 TCPEndpoint.read
In-Reply-To: 
References: 
Message-ID: 

This looks fine to me.

Mandy

On 1/17/20 10:25 AM, Roger Riggs wrote:
> Please review this fix to correctly allow null for a custom socket 
> factory in TCPEndpoint.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8237368
> webrev: http://cr.openjdk.java.net/~rriggs/webrev-proxy-8237368/
>
> Thanks, Roger
>


From naoto.sato at oracle.com  Fri Jan 17 18:31:50 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 17 Jan 2020 10:31:50 -0800
Subject: RFR: 8237465: JDK 14 L10N resource files update - msg drop 10
In-Reply-To: <7166b01c-ccd4-204a-6620-5323c7ee952b@oracle.com>
References: <7166b01c-ccd4-204a-6620-5323c7ee952b@oracle.com>
Message-ID: <9c5ca93c-47da-d1a0-cecd-a2d821f9346b@oracle.com>

Hi Leo,

The l10n files for HelpResources_*.properties in jpackage discard the 
format in the original English resource file where lines are nicely 
aligned. Can you please preserve the format?

Also, I find it odd to observe duplicated String literals in every 
XPATHErrorResources_*.java files. I think they should only be in the 
base resource bundles, but I guess that's in the original xml code and 
not l10n related.

Naoto

On 1/17/20 3:31 AM, li.jiang at oracle.com wrote:
> Hi,
> 
> Please review the L10N resource files update for JDK 14 msg drop 10.
> 
> https://bugs.openjdk.java.net/browse/JDK-8237465
> http://cr.openjdk.java.net/~ljiang/8237465/webrev/read/
> 
> This is the first msg drop for JDK 14 L10N resources files update, so 
> this webrev would cover most of update for JDK 14. We still have the msg 
> drop 20 in the next days, so pls commit the l10n related changes before 
> Jan 23rd. After msg drop 20, we kick off the msg drop 30 only if 
> necessary, showstopper only.
> 
> Note: some resource changes in preview features, like Record, Pattern 
> Matching, are supported in this msg drop, also some new resource files 
> for jpackager were added.
> 
> Thanks,
> Leo
> 

From Alan.Bateman at oracle.com  Fri Jan 17 18:48:44 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Jan 2020 18:48:44 +0000
Subject: [14] 8237368: Problem with NullPointerException in RMI
 TCPEndpoint.read
In-Reply-To: 
References: 
Message-ID: <701dd8cf-53cb-200e-e383-45fb2cc616e7@oracle.com>

On 17/01/2020 18:25, Roger Riggs wrote:
> Please review this fix to correctly allow null for a custom socket 
> factory in TCPEndpoint.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8237368
> webrev: http://cr.openjdk.java.net/~rriggs/webrev-proxy-8237368/
Looks good. As this is a P2 and regression in JDK 14 (and all the 
releases that got JDK-8230967) then I agree with the subject line that 
you should request approval for 14 (in RDP2).

-Alan.

From huizhe.wang at oracle.com  Fri Jan 17 18:51:42 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 17 Jan 2020 10:51:42 -0800
Subject: RFR: 8237465: JDK 14 L10N resource files update - msg drop 10
In-Reply-To: <9c5ca93c-47da-d1a0-cecd-a2d821f9346b@oracle.com>
References: <7166b01c-ccd4-204a-6620-5323c7ee952b@oracle.com>
 <9c5ca93c-47da-d1a0-cecd-a2d821f9346b@oracle.com>
Message-ID: <5e5ff38d-a0e8-cad1-ad40-8f8c35b89d88@oracle.com>



On 1/17/20 10:31 AM, naoto.sato at oracle.com wrote:
> Hi Leo,
>
> The l10n files for HelpResources_*.properties in jpackage discard the 
> format in the original English resource file where lines are nicely 
> aligned. Can you please preserve the format?
>
> Also, I find it odd to observe duplicated String literals in every 
> XPATHErrorResources_*.java files. I think they should only be in the 
> base resource bundles, but I guess that's in the original xml code and 
> not l10n related.

Yes, it's from Apache.

-Joe

>
> Naoto
>
> On 1/17/20 3:31 AM, li.jiang at oracle.com wrote:
>> Hi,
>>
>> Please review the L10N resource files update for JDK 14 msg drop 10.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8237465
>> http://cr.openjdk.java.net/~ljiang/8237465/webrev/read/
>>
>> This is the first msg drop for JDK 14 L10N resources files update, so 
>> this webrev would cover most of update for JDK 14. We still have the 
>> msg drop 20 in the next days, so pls commit the l10n related changes 
>> before Jan 23rd. After msg drop 20, we kick off the msg drop 30 only 
>> if necessary, showstopper only.
>>
>> Note: some resource changes in preview features, like Record, Pattern 
>> Matching, are supported in this msg drop, also some new resource 
>> files for jpackager were added.
>>
>> Thanks,
>> Leo
>>


From lance.andersen at oracle.com  Fri Jan 17 20:23:51 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 17 Jan 2020 15:23:51 -0500
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: 
References: 
Message-ID: 

HI Sean,

I think the change looks reasonable and I would keep it focused on its current intent for zip files given the problem you were addressing.

The test also looks reasonable.  Did you give any consideration to throwing a SkippedException if posixAttributes are not supported?

Also remember to update your copyright year prior to pushing?

Best
Lance

> On Jan 17, 2020, at 5:59 AM, Se?n Coffey  wrote:
> 
> Hi,
> 
> Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permissions when jarsigner is run on a zip file. Some of the logic is taken from the recent work carried out in this area for zipfs API.
> 
> https://bugs.openjdk.java.net/browse/JDK-8218021
> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
> 
> regards,
> Sean.
> 
> 

 
  
 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  Fri Jan 17 21:07:37 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 Jan 2020 16:07:37 -0500
Subject:  [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
In-Reply-To: <11107b9b-5c4f-8a60-642d-7341c63d7617@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 
 
 
 <11107b9b-5c4f-8a60-642d-7341c63d7617@oracle.com>
Message-ID: <84fc0c00-a0af-d7e5-99f7-40649530c667@oracle.com>

Hi Naoto,

Looks good.? Thanks for the updates.

Roger


On 1/16/20 4:08 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thanks. My comments are embedded below.
>
> On 1/16/20 12:06 PM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> A couple of comments in the tests.
>>
>> HijrahConfigTest:
>>
>> 72:? Since onExit() starts a task in some executor and in some context,
>> ??? its not clear that an exception thrown in that task will be 
>> reported.
>> ?? Use the normal p.waitFor() and check the exit code.
>
> Hmm, I was using the example in onExit() method, which reads:
>
> ---
> API Note:
> Using onExit is an alternative to waitFor that enables both additional 
> concurrency and convenient access to the result of the Process.
> ---
>
> So "alternative" is not "interchangeable" in this context?
onExit is useful to process the exit of a Process asynchronously.
>
>>
>> 73: include the failed exit value in the exception; It may have some 
>> use in debugging.
>
> Anyway, I changed the above code to p.waitFor() for this reason.
>
>>
>> HijrahConfigCheck:
>>
>> 41: The data structure is a set; no entry can appear twice; there's 
>> no point to the text
>> ?? or the value of count should be included in the exception
>
> At first I thought the same, but realized there could be a error case 
> where "calendar type" in returned objects are the same, but objects 
> themselves are different (thus the Set could accommodate both), so the 
> test.
I suppose that is up to the Chronology .equals method of each 
Chronology, I'd expect equals
to be checking all the fields of a Chronology.
>
>>
>> 44: typo: Instatiation
>>
>> 48: if they are different, print the two chronologies
>>
>> hijrah-config-Hijrah-test_islamic-test.properties:
>> ??I would include a comment to say the data does not represent an 
>> actual calendar.
>
> Corrected.
>
>>
>> Roger
>>
>> p.s.
>> !! tests.Helper is a very uninformative class name (but that's not 
>> your doing).
>
> "Helper" is not helping in that regard :-)
>
> Updated webrev: http://cr.openjdk.java.net/~naoto/8187987/webrev.03/
>
> Naoto
>>
>>
>>
>>
>>
>>
>> On 1/15/20 7:49 PM, naoto.sato at oracle.com wrote:
>>> Updated:
>>>
>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.02/
>>>
>>> The change includes the new naming convention, reduction of 
>>> properties files reading to once, and utilization of logging.
>>>
>>> Naoto
>>>
>>> On 1/15/20 12:37 PM, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Thank you for the review. Please find my comments below:
>>>>>
>>>>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> Is it correct to say that there is no impact on startup until 
>>>>>> there is an explicit reference to HijrahChronology?
>>>>>> It would seem that the registering HijrahChronology would trigger 
>>>>>> all the work and that happens when Chronology is initialized. 
>>>>>> (see below)
>>>>>
>>>>> What I meant in the reply to Joe's email was that the data 
>>>>> validity check done in loadCalendarData(), e.g., year value check, 
>>>>> etc. which are not done at class init. But you are correct that 
>>>>> the properties files are read twice (below). I thought it was fine 
>>>>> as this is not a common case (not happened before, to be precise).
>>>> Until it get used, there will still be a probe of the filesystem to 
>>>> see if a config directory/file exists
>>>> that would impact every startup. I don't see a way to mitigate that 
>>>> without making the config? more complex.
>>>>>
>>>>>>
>>>>>> HijrahChronology.java:
>>>>>>
>>>>>> 291-295: Since registerCustomChrono is the only place where 
>>>>>> CONF_PATH is used,
>>>>>> ??? do all the work, including the property lookup in that method.
>>>>>> 836:? If other chronologies are built-in this code will need to 
>>>>>> be changed.
>>>>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>>>>> back to /conf/chronology?
>>>>>
>>>>> Yes, it would have to be changed if we support built-in type other 
>>>>> than umalqura. But I would think other code would have to anyways. 
>>>>> I think we can take advantage of the fact that umalqura is the 
>>>>> only built-in, and others come from /conf/chronology so that extra 
>>>>> fallback is avoided.
>>>> Possibly, but could/would be more localized and consist of only the 
>>>> registerChronology call.
>>>>>
>>>>>>
>>>>>> 855: Since all the loading is triggered from a static 
>>>>>> initializer, is there really any point in throwing an exception.
>>>>>> ?? More useful would be a logging message (assuming logging is 
>>>>>> allowed early in startup when Chronology is initialized)
>>>>>
>>>>> Good point. I will replace UncheckedIOException with logging.
>>>>>
>>>>>>
>>>>>> 1054: readConfigProperties: The case for the other 
>>>>>> HijrahChronologies delays loading the data until it is needed.
>>>>>> This is doing the work to read the file and create the properties 
>>>>>> instance but then discards it to be read a second time later.
>>>>>>
>>>>>> Perhaps we need to specify that the config file name includes 
>>>>>> both the id and type so it can be registered without reading the 
>>>>>> file.
>>>>>
>>>>> Should the file name like "Hijrah-config-_.properties" 
>>>>> work?
>>>> yes, its worth checking the valid characters in id and type.
>>>>
>>>> Thanks, Roger
>>>>
>>>> BTW, the test drive can be implemented using testng, only the test 
>>>> itself is easier as main().
>>>>
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Regards, Roger
>>>>>>
>>>>>>
>>>>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>>>>> Hi Joe,
>>>>>>>>
>>>>>>>> Thank you for the review. Please find my comments below:
>>>>>>>>
>>>>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>>>>> Hi Naoto,
>>>>>>>>>
>>>>>>>>> Since it's dealing with non-standard properties files, is 
>>>>>>>>> there a need to verify the files? The constructor 
>>>>>>>>> (HijrahChronology) does check whether the id or type is empty. 
>>>>>>>>> If there is no existing process to validate, it's probably not 
>>>>>>>>> worth it to spend time as it's rare and it's config time.
>>>>>>>>
>>>>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>>>>> (thus the faster the better) and cache it, then check the 
>>>>>>>> validity later at actual method invocation (cf. 
>>>>>>>> checkCalendarInit() method).
>>>>>>>
>>>>>>> Make sense.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The test summary states "Test image creation", it may be 
>>>>>>>>> better to say sth. like verifies custom configuration?
>>>>>>>>
>>>>>>>> Good catch! I was simply copying some portion from other test 
>>>>>>>> case. Corrected:
>>>>>>>>
>>>>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>>>>
>>>>>>> Looks good to me.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Joe
>>>>>>>
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review the fix to the following issue:
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>>>>
>>>>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>>>>
>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>>>>
>>>>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that 
>>>>>>>>>> it could load custom variants of Hijirah calendar type using 
>>>>>>>>>> properties files. However it does not work as designed. This 
>>>>>>>>>> change intends to make it work.
>>>>>>>>>>
>>>>>>>>>> Naoto
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>


From Roger.Riggs at oracle.com  Fri Jan 17 21:30:15 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 Jan 2020 16:30:15 -0500
Subject: RFR 8236034 : Use optimized Ques node for curly {0,1} quantifier
In-Reply-To: 
References: 
Message-ID: 

Hi Ivan,

This refactoring looks fine.

Sorry for the long time to get to looking at this.

Thanks, Roger


On 12/16/19 7:03 PM, Ivan Gerasimov wrote:
> Hello!
>
> In the regular expressions, the quantifier ? can be equally written as 
> {0,1}.
>
> While for the former variant an optimized algorithm is used (coded in 
> the Pattern.Ques class), the later variant uses more general and less 
> efficient implementation (coded in the Pattern.Curly class).
>
> It would be beneficial, if we unify the implementation for these two 
> variants of quantifier and make them both use Ques node.
>
> Also, I couldn't resist to do some refactoring in the affected potion 
> of the code to eliminate the repetition of logics.
>
> The regression test was modified to exercise both forms of quantifiers 
> equally well.
>
> Would you please help review this enhancement?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236034
> WEBREV: http://cr.openjdk.java.net/~igerasim/8236034/00/webrev/
>
> Thanks in advance!
>


From 1983-01-06 at gmx.net  Fri Jan 17 11:10:53 2020
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Fri, 17 Jan 2020 12:10:53 +0100
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: 
References: 
Message-ID: <595ecc7e-7b63-9d4d-2548-f1d31b179687@gmx.net>

Am 2020-01-17 um 11:59 schrieb Se?n Coffey:
> Hi,
> 
> Looking to introduce some JDK private functionality which will help 
> preserve internal zip file attribute permissions when jarsigner is run 
> on a zip file. Some of the logic is taken from the recent work carried 
> out in this area for zipfs API.
> 
> https://bugs.openjdk.java.net/browse/JDK-8218021
> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/

Make sure that the following idiom also works on tr_TR or alike:

> if (this.name.toLowerCase().endsWith(ZIP_FILE_EXT)




From robert.olofsson at digpro.se  Fri Jan 17 15:26:25 2020
From: robert.olofsson at digpro.se (Robert Olofsson)
Date: Fri, 17 Jan 2020 16:26:25 +0100
Subject: Depth and String handling in ObjectInputFilter
Message-ID: <7fd6d2cbcd45d1a017bc8b71b9d29e32a6b3384e.camel@digpro.se>

Hi!

I hope this is the correct mailing list, if not please tell me.

I was looking into using a ObjectInputFilter and try to improve the
security in some old code that uses serialization. After reading and
testing a bit I think the filtering works a bit strange and that it
does not provide enough information.

I have added a small test program below that I think illustrates the
problem. Running this on java 11 or java 13 gives the same result. The
program writes a small data structure to a an ObjectOutputStream and
then reads it in again, just to see what we get from the
ObjectInputFilter.

Output of example program:
roberto at roberto-d4:~/src/java$ ~/pkg/java/jdk-13.0.1+9/bin/java SerializationTest
Depth: 1, class: class Payload, array: -1
Depth: 2, class: class java.util.ArrayList, array: -1
Depth: 2, class: class [Ljava.lang.Object;, array: 2
Depth: 3, class: class X, array: -1
Depth: 3, class: null, array: -1

Problems:
1) It is not possible to filter long strings. So even when using
   a filter a long string will lead to OutOfMemoryError. The
   javadoc for ObjectInputFilter clearly states that this is how
   it is supposed to work. My thoughts are that I ought to be
   able to reject too long strings, at least TC_LONGSTRING that
   have an 8 byte length if I understand how ObjectInputStream
   works internally.

2) I do not understand how the depth is supposed to work in the
   example program. I get depth 2 for both the ArrayList and its
   contained Object[]. My expectations is that I ought to get the
   array at depth 3. Is depth 2 how it is supposed to work?

Do you have any clarification how should I think regarding the
ObjectInputFilter?

Thanks!
/robo

----------------------------------------------------------------------
import java.io.*;
import java.util.*;

class SerializationTest {
    public static void main(String[] args)
	throws IOException, ReflectiveOperationException {
	Payload p = new Payload ();
	byte[] data;
	try (ByteArrayOutputStream baos = new ByteArrayOutputStream ();
	     ObjectOutputStream os = new ObjectOutputStream (baos)) {
	    os.writeObject (p);
	    data = baos.toByteArray ();
	}
	try (ByteArrayInputStream bais = new ByteArrayInputStream (data);
	     ObjectInputStream is = new ObjectInputStream (bais)) {
	    is.setObjectInputFilter (SerializationTest::logInput);
	    Payload pp = (Payload)is.readObject ();
	}
    }

    private static ObjectInputFilter.Status
	logInput (ObjectInputFilter.FilterInfo info) {
	System.out.println ("Depth: " + info.depth () +
			    ", class: " + info.serialClass () +
			    ", array: " + info.arrayLength ());
	return ObjectInputFilter.Status.ALLOWED;
    }
}

class Payload implements Serializable {
    List ls;

    public Payload () {
	ls = new ArrayList<> ();
	ls.add (new X ("one"));
	ls.add (new X ("two"));
    }
}

class X implements Serializable {
    String x;
    public X (String x) {
	this.x = x;
    }
}
----------------------------------------------------------------------


From forax at univ-mlv.fr  Fri Jan 17 23:36:54 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 18 Jan 2020 00:36:54 +0100 (CET)
Subject: Depth and String handling in ObjectInputFilter
In-Reply-To: <7fd6d2cbcd45d1a017bc8b71b9d29e32a6b3384e.camel@digpro.se>
References: <7fd6d2cbcd45d1a017bc8b71b9d29e32a6b3384e.camel@digpro.se>
Message-ID: <82337064.1190627.1579304214890.JavaMail.zimbra@u-pem.fr>

Hi Robert,
first this is the wrong mailing list,
this mailing list is about how to implement the JDK, not how it works,
usually stackoverflow is better for the kind of questions you are asking.

----- Mail original -----
> De: "Robert Olofsson" 
> ?: "core-libs-dev" 
> Envoy?: Vendredi 17 Janvier 2020 16:26:25
> Objet: Depth and String handling in ObjectInputFilter

> Hi!
> 
> I hope this is the correct mailing list, if not please tell me.
> 
> I was looking into using a ObjectInputFilter and try to improve the
> security in some old code that uses serialization. After reading and
> testing a bit I think the filtering works a bit strange and that it
> does not provide enough information.
> 
> I have added a small test program below that I think illustrates the
> problem. Running this on java 11 or java 13 gives the same result. The
> program writes a small data structure to a an ObjectOutputStream and
> then reads it in again, just to see what we get from the
> ObjectInputFilter.
> 
> Output of example program:
> roberto at roberto-d4:~/src/java$ ~/pkg/java/jdk-13.0.1+9/bin/java
> SerializationTest
> Depth: 1, class: class Payload, array: -1
> Depth: 2, class: class java.util.ArrayList, array: -1
> Depth: 2, class: class [Ljava.lang.Object;, array: 2
> Depth: 3, class: class X, array: -1
> Depth: 3, class: null, array: -1
> 
> Problems:
> 1) It is not possible to filter long strings. So even when using
>   a filter a long string will lead to OutOfMemoryError. The
>   javadoc for ObjectInputFilter clearly states that this is how
>   it is supposed to work. My thoughts are that I ought to be
>   able to reject too long strings, at least TC_LONGSTRING that
>   have an 8 byte length if I understand how ObjectInputStream
>   works internally.

If you want to avoid long strings, the best is to detect big array of char[],
so using a combination  of arrayLength() + serialClass() should give yo what you want.
A more brutal solution is to use streamBytes() and reject any big values, independent of the serialClass().

> 
> 2) I do not understand how the depth is supposed to work in the
>   example program. I get depth 2 for both the ArrayList and its
>   contained Object[]. My expectations is that I ought to get the
>   array at depth 3. Is depth 2 how it is supposed to work?

It's the depth of the serialized graph, not the depth of the object in memory.
ArrayList (like any lists) replace itself by an array of objects during the serialization,
that why the depth is 2 for ArrayList and LObject.

> 
> Do you have any clarification how should I think regarding the
> ObjectInputFilter?
> 
> Thanks!
> /robo

regards,
R?mi

From li.jiang at oracle.com  Sat Jan 18 02:10:50 2020
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Sat, 18 Jan 2020 10:10:50 +0800
Subject: RFR: 8237465: JDK 14 L10N resource files update - msg drop 10
In-Reply-To: <9c5ca93c-47da-d1a0-cecd-a2d821f9346b@oracle.com>
References: <7166b01c-ccd4-204a-6620-5323c7ee952b@oracle.com>
 <9c5ca93c-47da-d1a0-cecd-a2d821f9346b@oracle.com>
Message-ID: <7288b27e-521e-d188-c6b3-598920d64a95@oracle.com>

Hi Naoto,

Thank you for reviewing.

The eol characters were removed by t9n system, if I correct the format 
manually the next time we run the msg drop it would be back. Considering 
we need to kick off the next msg drop soon, I prefer not to fix it this 
time.

Regards,
Leo

On 1/18/20 2:31 AM, naoto.sato at oracle.com wrote:
> Hi Leo,
> 
> The l10n files for HelpResources_*.properties in jpackage discard the 
> format in the original English resource file where lines are nicely 
> aligned. Can you please preserve the format?
> 
> Also, I find it odd to observe duplicated String literals in every 
> XPATHErrorResources_*.java files. I think they should only be in the 
> base resource bundles, but I guess that's in the original xml code and 
> not l10n related.
> 
> Naoto
> 
> On 1/17/20 3:31 AM, li.jiang at oracle.com wrote:
>> Hi,
>>
>> Please review the L10N resource files update for JDK 14 msg drop 10.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8237465
>> http://cr.openjdk.java.net/~ljiang/8237465/webrev/read/
>>
>> This is the first msg drop for JDK 14 L10N resources files update, so 
>> this webrev would cover most of update for JDK 14. We still have the 
>> msg drop 20 in the next days, so pls commit the l10n related changes 
>> before Jan 23rd. After msg drop 20, we kick off the msg drop 30 only 
>> if necessary, showstopper only.
>>
>> Note: some resource changes in preview features, like Record, Pattern 
>> Matching, are supported in this msg drop, also some new resource files 
>> for jpackager were added.
>>
>> Thanks,
>> Leo
>>

From stuart.marks at oracle.com  Sat Jan 18 16:51:35 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 18 Jan 2020 08:51:35 -0800
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
 <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
 <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>
Message-ID: 



On 1/16/20 8:21 AM, Claes Redestad wrote:
> I've cleaned up a bit (SALT can be made into a long to reduce casts
> etc), and rolled it into the current patch:
> 
> http://cr.openjdk.java.net/~redestad/8236641/open.01/

OK, I think this makes sense. But I did have to stare at the code for a while to 
figure out what was going on. So, maybe a couple judicious comments would be 
helpful.

   68         SALT32L = (int)((color * seed) >> 16) & 0xFFFF_FFFFL; // avoid LSB 
and MSB

The comment "avoid LSB and MSB" isn't helping me here, and in fact it's 
confusing because I thought it applied to the "& 0xFFFF_FFFFL" part. Is there 
something else that ought to be said here, perhaps "select the middle 32 bits of 
the product"?

  770                 idx = (int) ((SALT32L * elements.length) >>> 32);
1063                 idx = (int) ((SALT32L * (table.length >> 1)) >>> 32) << 1;

These expressions replace floorMod(), which (at least to my brain) idiomatically 
ensures the return value is in the range [0..len-1]. It's not at all obvious 
what these do, although I think they do the same thing. Can we add a comment 
something like, "add a 'random' starting index based on the SALT"?

Thanks,

s'marks

From chris.hegarty at oracle.com  Sun Jan 19 15:25:13 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 19 Jan 2020 15:25:13 +0000
Subject: RFR [14] 8234782: Discuss evolution of records in serialization
 spec 
In-Reply-To: 
References: 
Message-ID: <29DF91D6-83D2-4508-BE62-1D7770CDCD0D@oracle.com>


> On 15 Jan 2020, at 15:01, Chris Hegarty  wrote:
> 
> As raised in the CSR feedback for records [1], evolution of serializable
> records should be discussed in the updates to the serialization spec.
> 
> The most significant aspects of serialization evolution concerning
> records are 1) adding and removing record components, and 2) the
> compatible scenarios where an ordinary class may be changed to a record
> class. The following is a proposal to address both.
> 
> Spec changes:
>  https://cr.openjdk.java.net/~chegar/records/spec/records-serialization-addendum.html
> 
> CSR:
>  https://bugs.openjdk.java.net/browse/JDK-8237202

The CSR has provided some feedback [1], and the above link has been
re-generate inline to reflect that.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8237202?focusedCommentId=14312038&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14312038

From philipp.kunz at paratix.ch  Sun Jan 19 16:09:25 2020
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Sun, 19 Jan 2020 17:09:25 +0100
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: <79146371-82a6-ea63-4f5a-5e9c3a719495@oracle.com>
References: 
 <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch>
 <79146371-82a6-ea63-4f5a-5e9c3a719495@oracle.com>
Message-ID: 

Hi Sean,

I figure that distinguishing zips and jars is ambiguous in a certain
way. After having signed a zip, it contains a manifest and is also a
jar file according to the specs. That would mean we would end up with
two kinds of jar files, those with permissions and those without,
depending on the file name extension of the files. That a tool named
jarsigner is successfully applied to a file is for me convincing enough
to consider that file a jar file or jarsigned would reject it however
it name ends.

Now when signing jar files (namely those with zip file name extension
but depending on the further discussion not necessary limited to those)
with permissions, I wonder if those permissions should also be subject
of the signature. I would consider a change of an executable flag for
example a change of the signed file just the same as a changed byte of
contents. The way jarsigner works now, loosing the permissions, we know
at least that the files contained in signed jars have certain
permission flags (none or defaults) immediately after having signed
them even though later manipulation would not be detected and, hence,
cannot be trusted even with a valid signature.

Far as I understand the current situation, jars and zips could be told
from one another only before signing depending on the presence or
absence of a manifest. After signing, however, a manifest is always
there. Looking at it that way, the "much more consideration" you
mention would have to take place now, wouldn't it?

I also wonder why the "if (filename.endsWith(".zip"))" piece of code
does not occur only in JarSigner. Why is it in ZipFile, too? One such
kind of if statement should have been enough, at first glance. There
may be a good and convincing explanation but I don't see it just like
that. On the other hand, having this if condition duplicated into
ZipFile looks like it could have an undesired side-effect elsewhere. I
also kind of miss another test case to make sure permission flags
continue to be disregarded for "non-zip" jar files.

And the comment of Michael Osipov is really frightening. Did you know
that i and I are two different characters in turkish both of which have
yet other capital/small counterparts? At that point maybe discussing
the file name extension distinction could easily become lengthier than
a discussion about consequences of supporting permissions for all jar
files.

You mention "the case, at hand is unique here" and that made to occur
to me that if there is maybe only one person affected that he or she
could work around it more easily than changing the jdk. Is it really
important for most others? And is it really a bug at all?

Another idea to work around compatibility issues would be to introduce
a flag for jarsigner, for example -p like with tar. Yet another idea
could be to refire the jar file specs and jar and jarsigner tools docs
accordingly.

Regards,
Philipp


On Fri, 2020-01-17 at 13:07 +0000, Se?n Coffey wrote:
> Hi Philipp,
> 
> On 17/01/2020 12:40, Philipp Kunz wrote:
> > Hi Sean,
> > 
> > Nice patch. I wonder why permissions should be preserved only in
> > zip
> > files. Jar files also are zip files, according to the jar file
> > specs,
> > and hence, shouldn't jar files benefit of preserving permissions,
> > too?
> Thanks for your comments. The jar tool has never been interested in
> the 
> posix
> permissions fields for the individual entries. Such a change could
> yield 
> more
> interoperability issues. Such a change would also need much more 
> consideration
> 
> The zip tool on the other hand has always populated this field and I 
> think the case
> at hand is unique here (preserving attributes already created by 
> non-java tools)
> > The file name extension is most often zip for zip files and jar for
> > jar
> > files but is that really a safe assumption? I would not expect it
> > always. Removing
> Yes, I didn't see any easy way to distinguish a zip file from a jar
> file 
> without being
> more invasive and scanning file attributes for that file. I could
> take 
> that approach
> if it's deemed necessary.
> 
> regards,
> Sean.
> > > if (zf.getName().toLowerCase().endsWith(".zip")) {
> > along with similar code in ZipFile would avoid discussing that
> > question
> > and the test would not have to check that files with another name
> > extension than zip don't preserve permissions.
> > 
> > Philipp
> > 
> > 
> > On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote:
> > > Hi,
> > > 
> > > Looking to introduce some JDK private functionality which will
> > > help
> > > preserve internal zip file attribute permissions when jarsigner
> > > is
> > > run
> > > on a zip file. Some of the logic is taken from the recent work
> > > carried
> > > out in this area for zipfs API.
> > > 
> > > https://bugs.openjdk.java.net/browse/JDK-8218021
> > > http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
> > > 
> > > regards,
> > > Sean.
> > > 
> > > 


From claes.redestad at oracle.com  Sun Jan 19 19:03:14 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 19 Jan 2020 20:03:14 +0100
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: 
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
 <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
 <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>
 
Message-ID: <606b326b-eeec-fc8c-35bd-68efd672d7a9@oracle.com>

On 2020-01-18 17:51, Stuart Marks wrote:
> 
> 
> On 1/16/20 8:21 AM, Claes Redestad wrote:
>> I've cleaned up a bit (SALT can be made into a long to reduce casts
>> etc), and rolled it into the current patch:
>>
>> http://cr.openjdk.java.net/~redestad/8236641/open.01/
> 
> OK, I think this makes sense. But I did have to stare at the code for a 
> while to figure out what was going on. So, maybe a couple judicious 
> comments would be helpful.
> 
>  ? 68???????? SALT32L = (int)((color * seed) >> 16) & 0xFFFF_FFFFL; // 
> avoid LSB and MSB
> 
> The comment "avoid LSB and MSB" isn't helping me here, and in fact it's 
> confusing because I thought it applied to the "& 0xFFFF_FFFFL" part. Is 
> there something else that ought to be said here, perhaps "select the 
> middle 32 bits of the product"?
> 
>  ?770???????????????? idx = (int) ((SALT32L * elements.length) >>> 32);
> 1063???????????????? idx = (int) ((SALT32L * (table.length >> 1)) >>> 
> 32) << 1;
> 
> These expressions replace floorMod(), which (at least to my brain) 
> idiomatically ensures the return value is in the range [0..len-1]. It's 
> not at all obvious what these do, although I think they do the same 
> thing. Can we add a comment something like, "add a 'random' starting 
> index based on the SALT"?

Thanks for reviewing!

Uploaded new version with improved comments here:

http://cr.openjdk.java.net/~redestad/8236641/open.01/

/Claes

From claes.redestad at oracle.com  Sun Jan 19 19:04:48 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 19 Jan 2020 20:04:48 +0100
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <606b326b-eeec-fc8c-35bd-68efd672d7a9@oracle.com>
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
 <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
 <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>
 
 <606b326b-eeec-fc8c-35bd-68efd672d7a9@oracle.com>
Message-ID: 



On 2020-01-19 20:03, Claes Redestad wrote:
> 
> 
> Uploaded new version with improved comments here:

http://cr.openjdk.java.net/~redestad/8236641/open.02/

From claes.redestad at oracle.com  Mon Jan 20 11:16:31 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Jan 2020 12:16:31 +0100
Subject: RFR: 8237508: Simplify JarFile.isInitializing
Message-ID: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>

Hi,

JDK-8234466[1] introduced isInitializing to JarFile, which cause a small
startup regression in various tests due increasing the number of classes
loaded and earlier lambda bootstrapping. The regression can be resolved
by not explicitly initializing the thread local variable to a non-null
value.

Webrev: http://cr.openjdk.java.net/~redestad/8237508/open.00/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8237508

Testing: tier1-3

Thanks!

/Claes

[1] https://bugs.openjdk.java.net/browse/JDK-8234466

From daniel.fuchs at oracle.com  Mon Jan 20 11:35:08 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 20 Jan 2020 11:35:08 +0000
Subject: RFR: 8237508: Simplify JarFile.isInitializing
In-Reply-To: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>
References: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>
Message-ID: 

Hi Claes,

Looks OK to me but I'd have a slight preference to a solution
that confines the hack to the JarFile class.

Would making the isIntializing field private and introducing
a static boolean isInitializing() method in JarFile bring the
same benefits WRT startup?

best regards,

-- daniel

On 20/01/2020 11:16, Claes Redestad wrote:
> Hi,
> 
> JDK-8234466[1] introduced isInitializing to JarFile, which cause a small
> startup regression in various tests due increasing the number of classes
> loaded and earlier lambda bootstrapping. The regression can be resolved
> by not explicitly initializing the thread local variable to a non-null
> value.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8237508/open.00/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8237508
> 
> Testing: tier1-3
> 
> Thanks!
> 
> /Claes
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8234466


From claes.redestad at oracle.com  Mon Jan 20 12:15:35 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Jan 2020 13:15:35 +0100
Subject: RFR: 8237508: Simplify JarFile.isInitializing
In-Reply-To: 
References: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>
 
Message-ID: <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>

Makes sense to keep even trivial logic out of the access bridge. Let's
also clean up the placement of the static variable and the pre-existing
use of the unconventional "final static" combo:

http://cr.openjdk.java.net/~redestad/8237508/open.01/

/Claes

On 2020-01-20 12:35, Daniel Fuchs wrote:
> Hi Claes,
> 
> Looks OK to me but I'd have a slight preference to a solution
> that confines the hack to the JarFile class.
> 
> Would making the isIntializing field private and introducing
> a static boolean isInitializing() method in JarFile bring the
> same benefits WRT startup?
> 
> best regards,
> 
> -- daniel
> 
> On 20/01/2020 11:16, Claes Redestad wrote:
>> Hi,
>>
>> JDK-8234466[1] introduced isInitializing to JarFile, which cause a small
>> startup regression in various tests due increasing the number of classes
>> loaded and earlier lambda bootstrapping. The regression can be resolved
>> by not explicitly initializing the thread local variable to a non-null
>> value.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8237508/open.00/
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8237508
>>
>> Testing: tier1-3
>>
>> Thanks!
>>
>> /Claes
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8234466
> 

From sean.coffey at oracle.com  Mon Jan 20 12:24:11 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 20 Jan 2020 12:24:11 +0000
Subject: RFR: 8237508: Simplify JarFile.isInitializing
In-Reply-To: <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
References: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>
 
 <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
Message-ID: 

Looks good to me Claes - thanks for fixing.

Regards,
Sean.

On 20/01/20 12:15, Claes Redestad wrote:
> Makes sense to keep even trivial logic out of the access bridge. Let's
> also clean up the placement of the static variable and the pre-existing
> use of the unconventional "final static" combo:
>
> http://cr.openjdk.java.net/~redestad/8237508/open.01/
>
> /Claes
>
> On 2020-01-20 12:35, Daniel Fuchs wrote:
>> Hi Claes,
>>
>> Looks OK to me but I'd have a slight preference to a solution
>> that confines the hack to the JarFile class.
>>
>> Would making the isIntializing field private and introducing
>> a static boolean isInitializing() method in JarFile bring the
>> same benefits WRT startup?
>>
>> best regards,
>>
>> -- daniel
>>
>> On 20/01/2020 11:16, Claes Redestad wrote:
>>> Hi,
>>>
>>> JDK-8234466[1] introduced isInitializing to JarFile, which cause a 
>>> small
>>> startup regression in various tests due increasing the number of 
>>> classes
>>> loaded and earlier lambda bootstrapping. The regression can be resolved
>>> by not explicitly initializing the thread local variable to a non-null
>>> value.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8237508/open.00/
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8237508
>>>
>>> Testing: tier1-3
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234466
>>


From takiguc at linux.vnet.ibm.com  Mon Jan 20 12:30:51 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 20 Jan 2020 21:30:51 +0900
Subject: RFR: CSR JDK-8233385 Align some one-way conversion in MS950
 charset with Windows
In-Reply-To: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
References: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
Message-ID: 

Hello.
This is just a gentle reminder.

Could you review CSR JDK-8233385 [1] ?

[1] https://bugs.openjdk.java.net/browse/JDK-8233385

Thanks,
Ichiroh Takiguchi

On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review CSR JDK-8233385 [1] ?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From lance.andersen at oracle.com  Mon Jan 20 12:34:44 2020
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Mon, 20 Jan 2020 07:34:44 -0500
Subject: RFR: 8237508: Simplify JarFile.isInitializing
In-Reply-To: <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
References: <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
Message-ID: 

Looks good Claes

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
Sent from my iPad

> On Jan 20, 2020, at 7:12 AM, Claes Redestad  wrote:
> 
> ?Makes sense to keep even trivial logic out of the access bridge. Let's
> also clean up the placement of the static variable and the pre-existing
> use of the unconventional "final static" combo:
> 
> http://cr.openjdk.java.net/~redestad/8237508/open.01/
> 
> /Claes
> 
>> On 2020-01-20 12:35, Daniel Fuchs wrote:
>> Hi Claes,
>> Looks OK to me but I'd have a slight preference to a solution
>> that confines the hack to the JarFile class.
>> Would making the isIntializing field private and introducing
>> a static boolean isInitializing() method in JarFile bring the
>> same benefits WRT startup?
>> best regards,
>> -- daniel
>>> On 20/01/2020 11:16, Claes Redestad wrote:
>>> Hi,
>>> 
>>> JDK-8234466[1] introduced isInitializing to JarFile, which cause a small
>>> startup regression in various tests due increasing the number of classes
>>> loaded and earlier lambda bootstrapping. The regression can be resolved
>>> by not explicitly initializing the thread local variable to a non-null
>>> value.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~redestad/8237508/open.00/
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8237508
>>> 
>>> Testing: tier1-3
>>> 
>>> Thanks!
>>> 
>>> /Claes
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234466

From daniel.fuchs at oracle.com  Mon Jan 20 12:37:50 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 20 Jan 2020 12:37:50 +0000
Subject: RFR: 8237508: Simplify JarFile.isInitializing
In-Reply-To: <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
References: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>
 
 <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
Message-ID: <65b66630-0579-8e17-3c01-3b1e3ca6f040@oracle.com>

On 20/01/2020 12:15, Claes Redestad wrote:
> Makes sense to keep even trivial logic out of the access bridge. Let's
> also clean up the placement of the static variable and the pre-existing
> use of the unconventional "final static" combo:
> 
> http://cr.openjdk.java.net/~redestad/8237508/open.01/

+1

Thanks Claes!

best regards,

-- daniel


From takiguc at linux.vnet.ibm.com  Mon Jan 20 12:40:54 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 20 Jan 2020 21:40:54 +0900
Subject: 8236548 Concern about CLDR Timezone translated data
Message-ID: <5351cf9432d980e9e1e86a9e6458bf2f@linux.vnet.ibm.com>

Hello.

I have 2 concerns about CLDR Timezone translated data.
The detail information is in JDK-8236548 [1].

Can you show me how to solve this kind of ICU related issue ?

[1] https://bugs.openjdk.java.net/browse/JDK-8236548

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From claes.redestad at oracle.com  Mon Jan 20 13:16:01 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Jan 2020 14:16:01 +0100
Subject: RFR: 8237508: Simplify JarFile.isInitializing
In-Reply-To: <65b66630-0579-8e17-3c01-3b1e3ca6f040@oracle.com>
References: <2709810d-6906-e541-195d-dea59896a47b@oracle.com>
 
 <4e4f7580-6d44-ba08-b446-7dee830b3e81@oracle.com>
 <65b66630-0579-8e17-3c01-3b1e3ca6f040@oracle.com>
Message-ID: <35c01bd7-ffa9-570f-2152-22bd3be13ba9@oracle.com>

Daniel, Lance, Se?n,

thanks for reviewing!

/Claes

On 2020-01-20 13:37, Daniel Fuchs wrote:
> On 20/01/2020 12:15, Claes Redestad wrote:
>> Makes sense to keep even trivial logic out of the access bridge. Let's
>> also clean up the placement of the static variable and the pre-existing
>> use of the unconventional "final static" combo:
>>
>> http://cr.openjdk.java.net/~redestad/8237508/open.01/
> 
> +1
> 
> Thanks Claes!
> 
> best regards,
> 
> -- daniel
> 

From sean.coffey at oracle.com  Mon Jan 20 15:42:47 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 20 Jan 2020 15:42:47 +0000
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: 
References: 
 <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch>
 <79146371-82a6-ea63-4f5a-5e9c3a719495@oracle.com>
 
Message-ID: <41864c0e-fa66-047f-be66-a2dd1d94d463@oracle.com>

Hi Philipp,

thanks for the reply .. comments inline

On 19/01/20 16:09, Philipp Kunz wrote:
> Hi Sean,
>
> I figure that distinguishing zips and jars is ambiguous in a certain
> way. After having signed a zip, it contains a manifest and is also a
> jar file according to the specs. That would mean we would end up with
> two kinds of jar files, those with permissions and those without,
> depending on the file name extension of the files. That a tool named
> jarsigner is successfully applied to a file is for me convincing enough
> to consider that file a jar file or jarsigned would reject it however
> it name ends.
Yes, both zip and jar files enjoy the same format. jar files being created
predominantly with the java based API/tools.
>
> Now when signing jar files (namely those with zip file name extension
> but depending on the further discussion not necessary limited to those)
> with permissions, I wonder if those permissions should also be subject
> of the signature. I would consider a change of an executable flag for
> example a change of the signed file just the same as a changed byte of
> contents. The way jarsigner works now, loosing the permissions, we know
> at least that the files contained in signed jars have certain
> permission flags (none or defaults) immediately after having signed
> them even though later manipulation would not be detected and, hence,
> cannot be trusted even with a valid signature.
historically, jar tool never recorded these permissions. As such, it 
should make
no difference to how jarsigner operates on such files. The original report
highlights the loss of data on files created with the zip utility. It 
think it's reasonable
for jarsigner to preserve attributes in such a case.
>
> Far as I understand the current situation, jars and zips could be told
> from one another only before signing depending on the presence or
> absence of a manifest. After signing, however, a manifest is always
> there. Looking at it that way, the "much more consideration" you
> mention would have to take place now, wouldn't it?
I'm not sure if there's much change in this area post fix. The classic
jar tool doesn't add or read the file attributes at hand. The name check
was useful to prevent any unintended behavioural changes in this area.
>
> I also wonder why the "if (filename.endsWith(".zip"))" piece of code
> does not occur only in JarSigner. Why is it in ZipFile, too? One such
> kind of if statement should have been enough, at first glance. There
> may be a good and convincing explanation but I don't see it just like
> that. On the other hand, having this if condition duplicated into
> ZipFile looks like it could have an undesired side-effect elsewhere. I
> also kind of miss another test case to make sure permission flags
> continue to be disregarded for "non-zip" jar files.
fair point. I should be able to remove this code. I can also improve the
test case.
>
> And the comment of Michael Osipov is really frightening. Did you know
> that i and I are two different characters in turkish both of which have
> yet other capital/small counterparts? At that point maybe discussing
> the file name extension distinction could easily become lengthier than
> a discussion about consequences of supporting permissions for all jar
> files.
frightening ??  Yes, I've worked on such issues before. Thanks to Michael
for pointing that out. I should be able to do a comparison using Locale.ROOT
>
> You mention "the case, at hand is unique here" and that made to occur
> to me that if there is maybe only one person affected that he or she
> could work around it more easily than changing the jdk. Is it really
> important for most others? And is it really a bug at all?
>
> Another idea to work around compatibility issues would be to introduce
> a flag for jarsigner, for example -p like with tar. Yet another idea
> could be to refire the jar file specs and jar and jarsigner tools docs
> accordingly.
Let me have a think about this. A new flag in jarsigner may help.

regards,
Sean.
>
> Regards,
> Philipp
>
>
> On Fri, 2020-01-17 at 13:07 +0000, Se?n Coffey wrote:
>> Hi Philipp,
>>
>> On 17/01/2020 12:40, Philipp Kunz wrote:
>>> Hi Sean,
>>>
>>> Nice patch. I wonder why permissions should be preserved only in
>>> zip
>>> files. Jar files also are zip files, according to the jar file
>>> specs,
>>> and hence, shouldn't jar files benefit of preserving permissions,
>>> too?
>> Thanks for your comments. The jar tool has never been interested in
>> the
>> posix
>> permissions fields for the individual entries. Such a change could
>> yield
>> more
>> interoperability issues. Such a change would also need much more
>> consideration
>>
>> The zip tool on the other hand has always populated this field and I
>> think the case
>> at hand is unique here (preserving attributes already created by
>> non-java tools)
>>> The file name extension is most often zip for zip files and jar for
>>> jar
>>> files but is that really a safe assumption? I would not expect it
>>> always. Removing
>> Yes, I didn't see any easy way to distinguish a zip file from a jar
>> file
>> without being
>> more invasive and scanning file attributes for that file. I could
>> take
>> that approach
>> if it's deemed necessary.
>>
>> regards,
>> Sean.
>>>> if (zf.getName().toLowerCase().endsWith(".zip")) {
>>> along with similar code in ZipFile would avoid discussing that
>>> question
>>> and the test would not have to check that files with another name
>>> extension than zip don't preserve permissions.
>>>
>>> Philipp
>>>
>>>
>>> On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote:
>>>> Hi,
>>>>
>>>> Looking to introduce some JDK private functionality which will
>>>> help
>>>> preserve internal zip file attribute permissions when jarsigner
>>>> is
>>>> run
>>>> on a zip file. Some of the logic is taken from the recent work
>>>> carried
>>>> out in this area for zipfs API.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8218021
>>>> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>>


From claes.redestad at oracle.com  Mon Jan 20 15:54:46 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Jan 2020 16:54:46 +0100
Subject: RFR: 8236075: Minor bootstrap improvements
Message-ID: 

Hi,

some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:

- Remove use of Vector/Hashtable from ClassLoader, along with a few
   other improvements/modernizations.
- Refactor ClassLoader::sys_paths/user_paths so that they're initialized
lazily but also published safely

Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8236075

Testing: tier1-3

Thanks!

/Claes

From mandy.chung at oracle.com  Mon Jan 20 19:30:52 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Jan 2020 11:30:52 -0800
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: 
References: 
Message-ID: <9c42fe79-606f-ae17-4805-384564a6d5c9@oracle.com>

Hi Claes,

On 1/20/20 7:54 AM, Claes Redestad wrote:
> Hi,
>
> some minor cleanups and enhancements in and around java.lang.ClassLoader
> which add up to a small startup improvement:
>
> - Remove use of Vector/Hashtable from ClassLoader, along with a few
> ? other improvements/modernizations.
> - Refactor ClassLoader::sys_paths/user_paths so that they're initialized
> lazily but also published safely
>
> Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236075

This patch looks okay in general.?? Below are some small comments:

ClassLoaderHelper.java
 ?? Moving ClassLoader::initializePath path-parsing method to 
ClassLoaderHelper is okay while duplicating the code in macOS and unix 
CLH implementation is less ideal.?? One option to consider is to add a 
utility method in a shared class like parsePath(String paths, boolean 
allowQuote).

OTOH, it's also okay to me since this duplicated code is small for now 
that we can follow up as part of the native library handling refactoring 
I'm working on.? But I will suggest to use the same pathStart and 
pathEnd variable names as in the windows implementation.

StaticProperty.java
 ???? I believe "java.library.path" and "sun.boot.library.path" are 
always set to non-null.? Since the existing code assumes them that may 
be null, I agree with you to keep the existing logic as we discussed.?? 
We will follow up this later.

You added getProperty(Properties props, String key).?? Do you see the 
change to replace System.getProperty calls with one single call to 
System.getProperties and Properties.getProperty is significant to 
performance??? i.e.? what if you keep the static method to 
getProperty(String key) (was initProperty before your patch) and? add 
getProperty(String key, String defaultValue) where the defaultValue may 
be null.

Mandy

From Alan.Bateman at oracle.com  Mon Jan 20 20:46:09 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Jan 2020 20:46:09 +0000
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: 
References: 
Message-ID: 

On 20/01/2020 15:54, Claes Redestad wrote:
> Hi,
>
> some minor cleanups and enhancements in and around java.lang.ClassLoader
> which add up to a small startup improvement:
>
> - Remove use of Vector/Hashtable from ClassLoader, along with a few
> ? other improvements/modernizations.
> - Refactor ClassLoader::sys_paths/user_paths so that they're initialized
> lazily but also published safely
>
> Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236075
>
I went through the changes too and they mostly look good to me. I have 
the same reaction to Mandy about the duplication of parsePath in the 
unix and macos versions of ClassLoaderHelper. The outlier is 
mapAlternativeName and maybe that might move elsewhere in time but I 
think what you have is okay.

For userPath/sysPath then I think those methods were okay when they were 
in ClassLoader (and close to their usage) but I think we should choose 
better names for the methods in StaticProperty, also better names for 
USER_PATH and SYS_PATH because they don't obvious map to the values of 
java.library.path and sun.boot.library.path. What would you think about 
rename them so that the usages in ClassLibrary.LibraryPath are 
StaticProperty.javaLibraryPath() and StaticProperty.sunBootLibrayPath() ?

Minor nit but the comment at (old) line 446 of 
BuiltinClassLoader/findMiscResources has been deleted, I think we should 
keep that to remind the reader why map may be null.

-Alan

From mandy.chung at oracle.com  Mon Jan 20 21:00:36 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Jan 2020 13:00:36 -0800
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: 
References: 
 
Message-ID: <866a5d20-1b4e-8165-193f-b8574ead3e03@oracle.com>



On 1/20/20 12:46 PM, Alan Bateman wrote:
> On 20/01/2020 15:54, Claes Redestad wrote:
>> Hi,
>>
>> some minor cleanups and enhancements in and around java.lang.ClassLoader
>> which add up to a small startup improvement:
>>
>> - Remove use of Vector/Hashtable from ClassLoader, along with a few
>> ? other improvements/modernizations.
>> - Refactor ClassLoader::sys_paths/user_paths so that they're initialized
>> lazily but also published safely
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236075
>>
> I went through the changes too and they mostly look good to me. I have 
> the same reaction to Mandy about the duplication of parsePath in the 
> unix and macos versions of ClassLoaderHelper. The outlier is 
> mapAlternativeName and maybe that might move elsewhere in time but I 
> think what you have is okay.
>
> For userPath/sysPath then I think those methods were okay when they 
> were in ClassLoader (and close to their usage) but I think we should 
> choose better names for the methods in StaticProperty, also better 
> names for USER_PATH and SYS_PATH because they don't obvious map to the 
> values of java.library.path and sun.boot.library.path. What would you 
> think about rename them so that the usages in ClassLibrary.LibraryPath 
> are StaticProperty.javaLibraryPath() and 
> StaticProperty.sunBootLibrayPath() ?
>

I like your suggested names, very clear what properties they are.

Thanks
Mandy

From robert.olofsson at digpro.se  Mon Jan 20 12:56:15 2020
From: robert.olofsson at digpro.se (Robert Olofsson)
Date: Mon, 20 Jan 2020 13:56:15 +0100
Subject: Depth and String handling in ObjectInputFilter
In-Reply-To: <82337064.1190627.1579304214890.JavaMail.zimbra@u-pem.fr>
References: <7fd6d2cbcd45d1a017bc8b71b9d29e32a6b3384e.camel@digpro.se>
 <82337064.1190627.1579304214890.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Hi!

First of I want to say thank you Remi, for at least trying to answer.

On Sat, 2020-01-18 at 00:36 +0100, Remi Forax wrote:
> Hi Robert,
> first this is the wrong mailing list, ...

Ok. I was hoping to get in contact with the people behind the
ObjectInputFilter and discuss how it is supposed to be used. My
question was not meant to be a "how do I implement an 
ObjectInputFilter".

I do not think StackOverflow is the rigth place for my question.
I guess I will have to try to open a bug for a better filtering mechanism
instead then.

> If you want to avoid long strings, the best is to detect big array of char[],

Except that Strings are not reported at all by ObjectInputFilter. The 
test program I had and the output did show this. Strings are serialized
and deserialized with the writeUTF and readUTF methods and these do not
report the String instance nor the internal array (char[] or byte[]).

So to me this looks like a giant problem for anyone that wants to write a
filter. Using streamBytes() is a no go as well, the best you can do with it
is to check it _after_ a String has been read, but then you have already
had the OOME, so no go.

> It's the depth of the serialized graph, not the depth of the object in memory.
> ArrayList (like any lists) replace itself by an array of objects during the
> serialization,
> that why the depth is 2 for ArrayList and LObject.

So if serialization is used for heterogeneous objects it is not really possible
to filter based on depth. As an implementor of a filter I can never trust depth
unless I have access to all code of all serialized objects. Again, this was 
my point: ObjectInputFilter tries to look like it is usable, but in reality it is
only usable for filtering based on classes.

/robo



From claes.redestad at oracle.com  Mon Jan 20 22:16:07 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Jan 2020 23:16:07 +0100
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: <866a5d20-1b4e-8165-193f-b8574ead3e03@oracle.com>
References: 
 
 <866a5d20-1b4e-8165-193f-b8574ead3e03@oracle.com>
Message-ID: <2ce7d017-b21d-d46c-b085-f8534673bfd9@oracle.com>



On 2020-01-20 22:00, Mandy Chung wrote:
> 
> 
> On 1/20/20 12:46 PM, Alan Bateman wrote:
>> On 20/01/2020 15:54, Claes Redestad wrote:
>>> Hi,
>>>
>>> some minor cleanups and enhancements in and around java.lang.ClassLoader
>>> which add up to a small startup improvement:
>>>
>>> - Remove use of Vector/Hashtable from ClassLoader, along with a few
>>> ? other improvements/modernizations.
>>> - Refactor ClassLoader::sys_paths/user_paths so that they're initialized
>>> lazily but also published safely
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236075
>>>
>> I went through the changes too and they mostly look good to me. I have 
>> the same reaction to Mandy about the duplication of parsePath in the 
>> unix and macos versions of ClassLoaderHelper. The outlier is 
>> mapAlternativeName and maybe that might move elsewhere in time but I 
>> think what you have is okay.
>>
>> For userPath/sysPath then I think those methods were okay when they 
>> were in ClassLoader (and close to their usage) but I think we should 
>> choose better names for the methods in StaticProperty, also better 
>> names for USER_PATH and SYS_PATH because they don't obvious map to the 
>> values of java.library.path and sun.boot.library.path. What would you 
>> think about rename them so that the usages in ClassLibrary.LibraryPath 
>> are StaticProperty.javaLibraryPath() and 
>> StaticProperty.sunBootLibrayPath() ?
>>
> 
> I like your suggested names, very clear what properties they are.

Ok, new version here:

http://cr.openjdk.java.net/~redestad/8236075/open.02/

/Claes

From mandy.chung at oracle.com  Mon Jan 20 22:52:38 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Jan 2020 14:52:38 -0800
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: <2ce7d017-b21d-d46c-b085-f8534673bfd9@oracle.com>
References: 
 
 <866a5d20-1b4e-8165-193f-b8574ead3e03@oracle.com>
 <2ce7d017-b21d-d46c-b085-f8534673bfd9@oracle.com>
Message-ID: <5e72b264-02ba-7ff5-48d2-db4237533b29@oracle.com>



On 1/20/20 2:16 PM, Claes Redestad wrote:
>
> Ok, new version here:
>
> http://cr.openjdk.java.net/~redestad/8236075/open.02/

+1

Mnady

From Sergey.Bylokhov at oracle.com  Tue Jan 21 00:59:18 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 20 Jan 2020 16:59:18 -0800
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: 
References: 
Message-ID: <89fa596d-404a-83c0-2350-d9e22cb2f6e4@oracle.com>

Hi Claes,

How did you measure this performance improvement?

On 1/20/20 7:54 am, Claes Redestad wrote:
> Hi,
> 
> some minor cleanups and enhancements in and around java.lang.ClassLoader
> which add up to a small startup improvement:
> 
> - Remove use of Vector/Hashtable from ClassLoader, along with a few
>  ? other improvements/modernizations.
> - Refactor ClassLoader::sys_paths/user_paths so that they're initialized
> lazily but also published safely
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236075
> 
> Testing: tier1-3
> 
> Thanks!
> 
> /Claes


-- 
Best regards, Sergey.

From Alan.Bateman at oracle.com  Tue Jan 21 07:58:41 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Jan 2020 07:58:41 +0000
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: <2ce7d017-b21d-d46c-b085-f8534673bfd9@oracle.com>
References: 
 
 <866a5d20-1b4e-8165-193f-b8574ead3e03@oracle.com>
 <2ce7d017-b21d-d46c-b085-f8534673bfd9@oracle.com>
Message-ID: <7f03ee6f-6375-b6bf-2bf1-a7101bfb3ec0@oracle.com>

On 20/01/2020 22:16, Claes Redestad wrote:
> :
>
> Ok, new version here:
>
> http://cr.openjdk.java.net/~redestad/8236075/open.02/
>
Good look.

-Alan.


From claes.redestad at oracle.com  Tue Jan 21 11:25:35 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 21 Jan 2020 12:25:35 +0100
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: <89fa596d-404a-83c0-2350-d9e22cb2f6e4@oracle.com>
References: 
 <89fa596d-404a-83c0-2350-d9e22cb2f6e4@oracle.com>
Message-ID: <08c85b12-af7b-6a9b-b1c2-851122dfba2b@oracle.com>

Hi Sergey,

as per usual: verification mainly by running a "Hello World"-style apps
repeatedly via:

perf stat -r 250 $JAVA_HOME/bin/java Hello

(FTR, this is one of the least impactful startup improvements I've 
shepherded, on my machine the net effect is ~0.1-0.2% reduction on Hello
World; more impactful things are in the pipeline)

Majority of the changes in this patch is neutral w.r.t. startup, in
particular the refactoring of library paths, which is motivated more by
it eliminating a (mostly theoretical) initialization race.

In this case I also verified the default CDS archive shrinks by ~20Kb
thanks to not having to include the Vector class.

/Claes

On 2020-01-21 01:59, Sergey Bylokhov wrote:
> Hi Claes,
> 
> How did you measure this performance improvement?
> 
> On 1/20/20 7:54 am, Claes Redestad wrote:
>> Hi,
>>
>> some minor cleanups and enhancements in and around java.lang.ClassLoader
>> which add up to a small startup improvement:
>>
>> - Remove use of Vector/Hashtable from ClassLoader, along with a few
>> ?? other improvements/modernizations.
>> - Refactor ClassLoader::sys_paths/user_paths so that they're initialized
>> lazily but also published safely
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8236075/open.01/
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8236075
>>
>> Testing: tier1-3
>>
>> Thanks!
>>
>> /Claes
> 
> 

From claes.redestad at oracle.com  Tue Jan 21 11:26:39 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 21 Jan 2020 12:26:39 +0100
Subject: RFR: 8236075: Minor bootstrap improvements
In-Reply-To: <7f03ee6f-6375-b6bf-2bf1-a7101bfb3ec0@oracle.com>
References: 
 
 <866a5d20-1b4e-8165-193f-b8574ead3e03@oracle.com>
 <2ce7d017-b21d-d46c-b085-f8534673bfd9@oracle.com>
 <7f03ee6f-6375-b6bf-2bf1-a7101bfb3ec0@oracle.com>
Message-ID: <1a5000f3-ad27-873a-7746-0a26e2932e8a@oracle.com>

Mandy, Alan,

thank you for reviewing!

/Claes

On 2020-01-21 08:58, Alan Bateman wrote:
> On 20/01/2020 22:16, Claes Redestad wrote:
>> :
>>
>> Ok, new version here:
>>
>> http://cr.openjdk.java.net/~redestad/8236075/open.02/
>>
> Good look.
> 
> -Alan.
> 

From Alan.Bateman at oracle.com  Tue Jan 21 13:49:06 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Jan 2020 13:49:06 +0000
Subject: RFR: 8218021: jarsigner strips the execute permission when
 signing a .zip file
In-Reply-To: 
References: 
Message-ID: 

On 17/01/2020 10:59, Se?n Coffey wrote:
> Hi,
>
> Looking to introduce some JDK private functionality which will help 
> preserve internal zip file attribute permissions when jarsigner is run 
> on a zip file. Some of the logic is taken from the recent work carried 
> out in this area for zipfs API.
>
> https://bugs.openjdk.java.net/browse/JDK-8218021
> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
The jarsigner tool is for signing JAR files so it does look strange that 
it only preserves the permissions when signing a zip file.? So I think I 
agree with the other comments that that part of the proposal should be 
examined again. If you don't special case then the concerns about the 
toLowerCase() usage go away too.

The bigger issue with the proposal is that the signing doesn't cover the 
information in the extended extra blocks so they can be tampered with.? 
I think we need to heard from security-dev on this point. One option 
might be to emit a warning when there are permissions. Another is a 
jarsigner option to opt-in to preserve the permissions.

-Alan


From naoto.sato at oracle.com  Tue Jan 21 17:47:35 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jan 2020 09:47:35 -0800
Subject:  RFR: CSR JDK-8233385 Align some one-way conversion in
 MS950 charset with Windows
In-Reply-To: 
References: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
 
Message-ID: <5c110af7-15de-dce1-5396-0a1b96bf5221@oracle.com>

Looks good to me.

Naoto

On 1/20/20 4:30 AM, Ichiroh Takiguchi wrote:
> Hello.
> This is just a gentle reminder.
> 
> Could you review CSR JDK-8233385 [1] ?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
>> Hello.
>>
>> Could you review CSR JDK-8233385 [1] ?
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Tue Jan 21 17:52:21 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jan 2020 09:52:21 -0800
Subject:  8236548 Concern about CLDR Timezone translated data
In-Reply-To: <5351cf9432d980e9e1e86a9e6458bf2f@linux.vnet.ibm.com>
References: <5351cf9432d980e9e1e86a9e6458bf2f@linux.vnet.ibm.com>
Message-ID: 

Hi Takiguchi-san,

We are aware of some discrepancy between English time zone display names 
and other languages' ones, as CLDR converter uses English display names 
of COMPAT provider, for performance/compatibility reasons.

Please assign the issue to me. I will look into it.

Naoto

On 1/20/20 4:40 AM, Ichiroh Takiguchi wrote:
> Hello.
> 
> I have 2 concerns about CLDR Timezone translated data.
> The detail information is in JDK-8236548 [1].
> 
> Can you show me how to solve this kind of ICU related issue ?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8236548
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From huizhe.wang at oracle.com  Tue Jan 21 18:11:30 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 21 Jan 2020 10:11:30 -0800
Subject: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
In-Reply-To: <8e5e22cd-5423-2fb7-e3d7-af4e64cd96d0@oracle.com>
References: 
 <15e95659-00bf-4045-af2c-0b6e3392bf9c@oracle.com>
 <8fec76f5-b0a8-2035-1fd2-65ecf638d57d@oracle.com>
 <734888553.553082.1579197027736.JavaMail.zimbra@u-pem.fr>
 <39e32050-be0e-ba7d-718e-7a6527e72b01@oracle.com>
 <8e5e22cd-5423-2fb7-e3d7-af4e64cd96d0@oracle.com>
Message-ID: 

Thanks Daniel!

-Joe

On 1/17/20 3:57 AM, Daniel Fuchs wrote:
> On 16/01/2020 18:22, Joe Wang wrote:
>>> It's because the class itself is declared final (at least on the few 
>>> files I've taken a look), so final on a method is redundant.
>
> Ah! I had missed that. Thaks R?mi!
>
>> Meanwhile, I noticed I missed the new classes in the webrev. I used a 
>> changelist to create webrevs and forgot to add the new ones to the 
>> list. Sorry about that. Here's the updated webrev:
>>
>> http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev_02/
>
> LGTM.
>
> best regards,
>
> -- daniel


From sgehwolf at redhat.com  Tue Jan 21 19:30:08 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 21 Jan 2020 20:30:08 +0100
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: 
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
Message-ID: <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com>

Hi Mandy,

On Thu, 2020-01-16 at 17:43 -0800, Mandy Chung wrote:
> Hi Bob, Severin,
> 
> On 1/9/20 11:51 AM, Severin Gehwolf wrote:
> > Thanks for the review! Should all be fixed now. Updated webrev:
> > 
> > incremental: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/
> > full: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/
>  
> This patch may be more appropriate to be reviewed by the
> serviceability group (cc'ed) as this is monitoring-related.
> 
> jdk.internal.platform.Metrics is an internal API that you are free to
> change the API as appropriate.  Given that 13 out of 38 metrics
> defined in Metrics are no longer supported by cgroups v2, it's
> cleaner to refactor Metrics interface to be implementable by cgroups
> v1 and v2 and then define a cgroups version-specific metrics to
> extend Metrics, which means that it seems reasonable to make it
> linux-only sub-interface.  Client can cast to cgroup v1 metrics
> interface if needed.  Sorry for not chiming in earlier and I am not
> following the cgroups v2 changes.  This should be a straight-forward
> change which will make the implementation cleaner.  You would no
> longer need the new *_UNLIMITED and *_NOT_SUPPORTED constants.

Like this?

Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/webrev/
incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/incremental/webrev/

> A couple of quick comments when skimming on the new files:
>  CgroupSubsystemController.java
>    s/parm/param (including javadoc @param tag)
> 
> CgroupInfo.java
>    cgroupPath is not used??

Should both be fixed, thanks!

Thanks,
Severin


From Roger.Riggs at oracle.com  Tue Jan 21 20:36:00 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 21 Jan 2020 15:36:00 -0500
Subject: RFR [15] 8236825: Reading output from ... using
 ProcessBuilder/Process might hang
Message-ID: <56162036-deb9-0ffa-6988-07d84a4979f4@oracle.com>

Please review a potential way to address two issues of java.lang.Process 
deadlocks during process exit. [1] [2]
(Linxu OS process expertise appreciated).

The deadlock is between some thread reading process output from a 
process that has exited
and the processExited thread that is attempting to buffer any remaining 
output so
the file descriptor for the pipe can be closed.? The methods involved 
are synchronized
on a ProcessPipeInputStream instance.

The hard case arises infrequently since the pipe streams are closed by 
the OS
normally (or within a few seconds) and the readXXX completes.
However, the case causing trouble is when the subprocess has spawned
another process and both processes are using the same file 
descriptor/stream for output.
Though the process that exits doesn't have the fd open anymore the extra 
subprocess does.
And if that subprocess does not exit, then the read and deadlock does 
not get resolved.

The approach proposed is to use a semaphore to guard the readXXX and
providing some non-blocking logic in processExited to forcibly close
the pipe if it detects that there is a conflicting read in progress.
(And remove the synchronized on processExited).

This solution works ok on MacOSX, where one of the issues occurred 
frequently.
Closing the pipe unblocks the reading thread.

On Linux, it appears that the blocking read (in native code) does not 
unblock
unless a signal occurs; so the solution does not fix the problem 
adqurated/completely.

Having a non-blocking native read would be the next step of complexity.
The problem has been around for a while so it may be an option to wait
for additional work on non-blocking pipe reads, the direction that Loom 
is moving.

Suggestions welcome,

Thanks, Roger

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-hdiutil-8236825/

Issues:
[1] https://bugs.openjdk.java.net/browse/JDK-8236825
[2] https://bugs.openjdk.java.net/browse/JDK-8169565

From stuart.marks at oracle.com  Tue Jan 21 20:39:40 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 21 Jan 2020 12:39:40 -0800
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: 
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
 <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
 <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>
 
 <606b326b-eeec-fc8c-35bd-68efd672d7a9@oracle.com>
 
Message-ID: <8278d8f7-3f22-97cf-4a60-f7b8c3203eca@oracle.com>

On 1/19/20 11:04 AM, Claes Redestad wrote:
> On 2020-01-19 20:03, Claes Redestad wrote:
>>
>> Uploaded new version with improved comments here:
> 
> http://cr.openjdk.java.net/~redestad/8236641/open.02/

The new version looks great. Thanks for the update.

s'marks

From aeubanks at google.com  Tue Jan 21 21:00:32 2020
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 21 Jan 2020 13:00:32 -0800
Subject: RFR [15] 8236825: Reading output from ... using
 ProcessBuilder/Process might hang
In-Reply-To: <56162036-deb9-0ffa-6988-07d84a4979f4@oracle.com>
References: <56162036-deb9-0ffa-6988-07d84a4979f4@oracle.com>
Message-ID: 

We've seen TSAN (ThreadSanitizer) for Java complain about this in some
internal tests. I never managed to reproduce an actual issue with file
descriptors being reused and there was skepticism that this would actually
cause observable issues, but these bugs indicate that there are indeed real
world issues.

On Tue, Jan 21, 2020 at 12:37 PM Roger Riggs  wrote:

> Please review a potential way to address two issues of java.lang.Process
> deadlocks during process exit. [1] [2]
> (Linxu OS process expertise appreciated).
>
> The deadlock is between some thread reading process output from a
> process that has exited
> and the processExited thread that is attempting to buffer any remaining
> output so
> the file descriptor for the pipe can be closed.  The methods involved
> are synchronized
> on a ProcessPipeInputStream instance.
>
> The hard case arises infrequently since the pipe streams are closed by
> the OS
> normally (or within a few seconds) and the readXXX completes.
> However, the case causing trouble is when the subprocess has spawned
> another process and both processes are using the same file
> descriptor/stream for output.
> Though the process that exits doesn't have the fd open anymore the extra
> subprocess does.
> And if that subprocess does not exit, then the read and deadlock does
> not get resolved.
>
> The approach proposed is to use a semaphore to guard the readXXX and
> providing some non-blocking logic in processExited to forcibly close
> the pipe if it detects that there is a conflicting read in progress.
> (And remove the synchronized on processExited).
>
> This solution works ok on MacOSX, where one of the issues occurred
> frequently.
> Closing the pipe unblocks the reading thread.
>
> On Linux, it appears that the blocking read (in native code) does not
> unblock
> unless a signal occurs; so the solution does not fix the problem
> adqurated/completely.
>
> Having a non-blocking native read would be the next step of complexity.
> The problem has been around for a while so it may be an option to wait
> for additional work on non-blocking pipe reads, the direction that Loom
> is moving.
>
> Suggestions welcome,
>
> Thanks, Roger
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-hdiutil-8236825/
>
> Issues:
> [1] https://bugs.openjdk.java.net/browse/JDK-8236825
> [2] https://bugs.openjdk.java.net/browse/JDK-8169565
>

From naoto.sato at oracle.com  Tue Jan 21 21:50:14 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jan 2020 13:50:14 -0800
Subject: [15] RFR: 8236903: ZoneRules#getOffset throws DateTimeException for
 rules with last rules
Message-ID: <15df95d8-235c-0eed-c07c-cf8e3adbfdd4@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8236903

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8236903/webrev.00/

This edge case throws an out-of-bounds DateTimeException in 
ZoneRules.findYear() on calculating the year. Instead of relying on 
LocalDate.ofEpochDay(), inlining the year caluculation from that method, 
and cap to the MAX value if needed, will solve the issue.

Naoto

From claes.redestad at oracle.com  Tue Jan 21 22:43:37 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 21 Jan 2020 23:43:37 +0100
Subject: RFR: 8236641: Improve Set.of(...).iterator() warmup
 characteristics
In-Reply-To: <8278d8f7-3f22-97cf-4a60-f7b8c3203eca@oracle.com>
References: <07ba3f92-7407-bd0f-eff0-3a2b235ed09e@oracle.com>
 <877e1rwvlw.fsf@oldenburg2.str.redhat.com>
 <14366d8e-aab8-e2cf-7d63-c5d2b049a0a7@oracle.com>
 
 <606b326b-eeec-fc8c-35bd-68efd672d7a9@oracle.com>
 
 <8278d8f7-3f22-97cf-4a60-f7b8c3203eca@oracle.com>
Message-ID: 



On 2020-01-21 21:39, Stuart Marks wrote:
>>
>> http://cr.openjdk.java.net/~redestad/8236641/open.02/
> 
> The new version looks great. Thanks for the update.

Thanks! Pushed.

/Claes

From mandy.chung at oracle.com  Wed Jan 22 00:09:06 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 21 Jan 2020 16:09:06 -0800
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
 <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com>
Message-ID: <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com>

Hi Severin,

Thanks for the update.

On 1/21/20 11:30 AM, Severin Gehwolf wrote:
>
> Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/webrev/
> incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/incremental/webrev/
>

I have answered my own question.?? Most of the metrics used to return 0 
if unavailable due to IOException reading a file or malformed content 
and now are changed to return -2 due to error fetching the metric.

The following are about limits which used to return -1 if unlimited or 
no limit set.
 ??? public long getCpuQuota();
 ??? public long getCpuShares();
 ??? public long getMemoryLimit();
 ??? public long getMemoryAndSwapLimit();
 ??? public long getMemorySoftLimit();

With this patch, only getMemoryLimit and getMemoryAndSwapLimit specify 
to return -1 if unlimited or no limit set.? However the implementation 
does return -1.? All of the above specify to return -2 if unavailable 
due to error fetching the metric.

I found the implementation quite hard to follow.? I spent some time 
reviewing the code to see if the implementation matches the spec but I 
can't easily tell yet.? For example,

CgroupSubsystemController::getLongValueMatchingLine returns -1 when IOException occurs.
CgroupSubsystemController::getLongEntry returns 0L if IOException occurs.

CgroupV1SubsystemController::convertStringToLong returns Long.MAX_VALUE
when value overflows

CgroupV2SubsystemController::convertStringToLong returns -1 when IOException occurs

CgroupV1Subsystem::getCpuShares return -1 if cpu.shares == 0 or 1024
CgroupV2Subsystem::getCpuShares returns -1 if cpu.weight == 100 or 0
CgroupV2Subsystem::getFromCpuMax returns -1 if error in reading cpu.max or malformed content
CgroupV2Subsystem::sumTokensIOStat returns -2 if IOException error This 
is called by getBlkIOServiceCount and getBlkIOServiced I think this can 
be improved and add the documentation to describe what the methods do. 
Since Metrics APIs consistently return -2 if unavailable due to error in 
fetching the metric, why some utility methods in *Subsystem and 
*SubsystemController return -1 upon error and 0 when unlimited? I 
suspect if the getXXXValue and other methods are clearly documented with 
the error cases (possibly renaming the method name if appropriate) 
CgroupV1Subsystem and CgroupV2SubSystem will become very explicit to 
understand. CgroupSubsystem.java
   44     public static final double DOUBLE_RETVAL_NOT_SUPPORTED = LONG_RETVAL_NOT_SUPPORTED;
49 public static final Boolean BOOL_RETVAL_NOT_SUPPORTED = null; They 
are no longer needed, right?
CgroupSubsystemFactory.java 89 System.err.println("Warning: Mixed 
cgroupv1 and cgroupv2 not supported. Metrics disabled.");
I expect this be a System.Logger log 114 if 
(!Integer.valueOf(0).toString().equals(tokens[0])) { This can be 
simplified to if (!"0".equals(tokens[0])) LauncherHelper.java

407 // Extended cgroupv1 specific metrics
408 if (c instanceof MetricsCgroupV1) {
409 MetricsCgroupV1 cgroupV1 = (MetricsCgroupV1)c;
410 limit = cgroupV1.getKernelMemoryLimit();
411 ostream.println(formatLimitString(limit, INDENT + "Kernel Memory 
Limit: "));
412 limit = cgroupV1.getTcpMemoryLimit();
413 ostream.println(formatLimitString(limit, INDENT + "TCP Memory Limit: 
"));
414 Boolean value = cgroupV1.isMemoryOOMKillEnabled();
415 ostream.println(formatBoolean(value, INDENT + "Out Of Memory Killer 
Enabled: "));
416 value = cgroupV1.isCpuSetMemoryPressureEnabled();
417 ostream.println(formatBoolean(value, INDENT + "CPUSet Memory 
Pressure Enabled: "));
418 }

MetricsCgroupV1 is linux-only.  It will fail the compilation when
building on non-linux.  One option is to move this code to
    src/java.base/linux/share/sun/launcher/CgroupMetrics.java

Are they continued to be interesting metrics to be output from
-XshowSetting?  I wonder if they can simply be dropped from the output.
Bob will have an opinion.

Mandy


From nick.gasson at arm.com  Wed Jan 22 08:43:50 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 22 Jan 2020 16:43:50 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
Message-ID: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>

Hi,

Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/

This is a follow-up to JDK-8236634 which just contained changes to the 
tests to make them build/pass on 32-bit systems for JDK 14. This patch 
removes the test workarounds and fixes two things to make them pass:

* In Unsafe_AllocateMemory0 handle the case where the aligned-up size 
overflows a 32-bit size_t and throw an OutOfMemoryError instead of 
calling os::malloc(0).

* Change the value of Utils.MAX_ALIGN from 16 to 8 on 32-bit systems, as 
malloc can return addresses that are only 8-byte aligned.

Tested jdk_foreign on x86_32, arm32, aarch64, x86_64.


Thanks,
Nick

From sgehwolf at redhat.com  Wed Jan 22 09:53:46 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 22 Jan 2020 10:53:46 +0100
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com>
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
 <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com>
 <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com>
Message-ID: 

Hi Mandy,

Thanks again for the review! I'll be sure to fix things. Some of the
issues you've pointed out probably pre-existed in old code. Some became
more complicated since unlimited in cgroupv1 is a large long value in
files. Anyway, I'll update it.

On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote:
> MetricsCgroupV1 is linux-only.  It will fail the compilation when
> building on non-linux.

I don't think so. MetricsCgroupV1 is a new interface in shared code
just like Metrics itself:
 src/java.base/share/classes/jdk/internal/platform/MetricsCgroupV1.java

I've put it there for the exact reason to NOT break compilation on non-
Linux. We could call it ExtendedMetrics or something, though. Pondered
that for a bit, but it wasn't important enough so I've kept it.

> One option is to move this code to 
>    src/java.base/linux/share/sun/launcher/CgroupMetrics.java

Not sure if that would help. MetricsCgropuV1 is being used in
LauncherHelper.java which itself is available on all platforms, no?

> Are they continued to be interesting metrics to be output from
> -XshowSetting?  I wonder if they can simply be dropped from the output.
> Bob will have an opinion.

I think they are. At least it prints the same metrics as were printed
before this patch on cgroupv1. What's the rationale of not printing
them any longer? My premise was, they were useful before and they
continue to be useful. For cgroupv2 they're not configurable so they're
not printed (and not useful as they'd show up as N/A anyway).

Thanks,
Severin


From scolebourne at joda.org  Wed Jan 22 09:55:39 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 22 Jan 2020 09:55:39 +0000
Subject: [15] RFR: 8236903: ZoneRules#getOffset throws DateTimeException
 for rules with last rules
In-Reply-To: <15df95d8-235c-0eed-c07c-cf8e3adbfdd4@oracle.com>
References: <15df95d8-235c-0eed-c07c-cf8e3adbfdd4@oracle.com>
Message-ID: 

Looks good
Stephen

On Tue, 21 Jan 2020 at 21:53,  wrote:
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8236903
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8236903/webrev.00/
>
> This edge case throws an out-of-bounds DateTimeException in
> ZoneRules.findYear() on calculating the year. Instead of relying on
> LocalDate.ofEpochDay(), inlining the year caluculation from that method,
> and cap to the MAX value if needed, will solve the issue.
>
> Naoto

From ivan.gerasimov at oracle.com  Wed Jan 22 11:17:48 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 22 Jan 2020 03:17:48 -0800
Subject: RFR 8236034 : Use optimized Ques node for curly {0,1} quantifier
In-Reply-To: 
References: 
 
Message-ID: 

Thank you Roger for review!

Pushed.

-- 
With kind regards,
Ivan Gerasimov


From maurizio.cimadamore at oracle.com  Wed Jan 22 12:46:33 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 22 Jan 2020 12:46:33 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
Message-ID: 

Fixes look good to me - I assume this is for JDK 15, right?

Maurizio

On 22/01/2020 08:43, Nick Gasson wrote:
> Hi,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
> Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/
>
> This is a follow-up to JDK-8236634 which just contained changes to the 
> tests to make them build/pass on 32-bit systems for JDK 14. This patch 
> removes the test workarounds and fixes two things to make them pass:
>
> * In Unsafe_AllocateMemory0 handle the case where the aligned-up size 
> overflows a 32-bit size_t and throw an OutOfMemoryError instead of 
> calling os::malloc(0).
>
> * Change the value of Utils.MAX_ALIGN from 16 to 8 on 32-bit systems, 
> as malloc can return addresses that are only 8-byte aligned.
>
> Tested jdk_foreign on x86_32, arm32, aarch64, x86_64.
>
>
> Thanks,
> Nick

From Roger.Riggs at oracle.com  Wed Jan 22 15:18:51 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jan 2020 10:18:51 -0500
Subject: [15] RFR: 8236903: ZoneRules#getOffset throws DateTimeException
 for rules with last rules
In-Reply-To: 
References: <15df95d8-235c-0eed-c07c-cf8e3adbfdd4@oracle.com>
 
Message-ID: 

+1, looks good

On 1/22/20 4:55 AM, Stephen Colebourne wrote:
> Looks good
> Stephen
>
> On Tue, 21 Jan 2020 at 21:53,  wrote:
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8236903
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8236903/webrev.00/
>>
>> This edge case throws an out-of-bounds DateTimeException in
>> ZoneRules.findYear() on calculating the year. Instead of relying on
>> LocalDate.ofEpochDay(), inlining the year caluculation from that method,
>> and cap to the MAX value if needed, will solve the issue.
>>
>> Naoto


From mandy.chung at oracle.com  Wed Jan 22 16:06:16 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Jan 2020 08:06:16 -0800
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: 
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
 <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com>
 <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com>
 
Message-ID: 



On 1/22/20 1:53 AM, Severin Gehwolf wrote:
> Hi Mandy,
>
> Thanks again for the review! I'll be sure to fix things. Some of the
> issues you've pointed out probably pre-existed in old code. Some became
> more complicated since unlimited in cgroupv1 is a large long value in
> files. Anyway, I'll update it.

Thank you.
> On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote:
>> MetricsCgroupV1 is linux-only.  It will fail the compilation when
>> building on non-linux.
> I don't think so. MetricsCgroupV1 is a new interface in shared code
> just like Metrics itself:
>   src/java.base/share/classes/jdk/internal/platform/MetricsCgroupV1.java

Ah, I mis-read that was placed under src/java.base/linux/classes. OK.
> I've put it there for the exact reason to NOT break compilation on non-
> Linux. We could call it ExtendedMetrics or something, though. Pondered
> that for a bit, but it wasn't important enough so I've kept it.
>> One option is to move this code to
>>     src/java.base/linux/share/sun/launcher/CgroupMetrics.java
> Not sure if that would help. MetricsCgropuV1 is being used in
> LauncherHelper.java which itself is available on all platforms, no?

-XshowSettings:system is a linux-only option.
>> Are they continued to be interesting metrics to be output from
>> -XshowSetting?  I wonder if they can simply be dropped from the output.
>> Bob will have an opinion.
> I think they are. At least it prints the same metrics as were printed
> before this patch on cgroupv1. What's the rationale of not printing
> them any longer? My premise was, they were useful before and they
> continue to be useful. For cgroupv2 they're not configurable so they're
> not printed (and not useful as they'd show up as N/A anyway).

Bob can advice on the usefulness of these metrics.??? I have no 
objection to print them on cgroup v1.? On v2,? they are not shown (not 
even N/A, right?)

Mandy

From bob.vandette at oracle.com  Wed Jan 22 16:19:07 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 22 Jan 2020 11:19:07 -0500
Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so
 as to recognize unified hierarchy
In-Reply-To: 
References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>
 <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com>
 <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com>
 <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com>
 <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com>
 <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com>
 
 <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com>
 <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com>
 
 
Message-ID: <80051010-726E-4349-9C65-4804A27E6F5E@oracle.com>


> On Jan 22, 2020, at 11:06 AM, Mandy Chung  wrote:
> 
> 
> 
> On 1/22/20 1:53 AM, Severin Gehwolf wrote:
>> Hi Mandy,
>> 
>> Thanks again for the review! I'll be sure to fix things. Some of the
>> issues you've pointed out probably pre-existed in old code. Some became
>> more complicated since unlimited in cgroupv1 is a large long value in
>> files. Anyway, I'll update it.
> 
> Thank you.
>> On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote:
>>> MetricsCgroupV1 is linux-only.  It will fail the compilation when
>>> building on non-linux.
>> I don't think so. MetricsCgroupV1 is a new interface in shared code
>> just like Metrics itself:
>>  src/java.base/share/classes/jdk/internal/platform/MetricsCgroupV1.java
> 
> Ah, I mis-read that was placed under src/java.base/linux/classes. OK.
>> I've put it there for the exact reason to NOT break compilation on non-
>> Linux. We could call it ExtendedMetrics or something, though. Pondered
>> that for a bit, but it wasn't important enough so I've kept it.
>>> One option is to move this code to
>>>    src/java.base/linux/share/sun/launcher/CgroupMetrics.java
>> Not sure if that would help. MetricsCgropuV1 is being used in
>> LauncherHelper.java which itself is available on all platforms, no?
> 
> -XshowSettings:system is a linux-only option.
>>> Are they continued to be interesting metrics to be output from
>>> -XshowSetting?  I wonder if they can simply be dropped from the output.
>>> Bob will have an opinion.
>> I think they are. At least it prints the same metrics as were printed
>> before this patch on cgroupv1. What's the rationale of not printing
>> them any longer? My premise was, they were useful before and they
>> continue to be useful. For cgroupv2 they're not configurable so they're
>> not printed (and not useful as they'd show up as N/A anyway).
> 
> Bob can advice on the usefulness of these metrics.    I have no objection to print them on cgroup v1.  On v2,  they are not shown (not even N/A, right?)

These metrics are not that useful in the -XshowSettings context.  I?d just drop them from the output.

Bob.


> 
> Mandy


From paul.sandoz at oracle.com  Wed Jan 22 20:31:32 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 22 Jan 2020 12:31:32 -0800
Subject: RFR [15] 8236825: Reading output from ... using
 ProcessBuilder/Process might hang
In-Reply-To: <56162036-deb9-0ffa-6988-07d84a4979f4@oracle.com>
References: <56162036-deb9-0ffa-6988-07d84a4979f4@oracle.com>
Message-ID: 

My sense is it is fixing a marginal case for the less dominant platform where this is less likely arise, whereas for the dominant platform there is still an issue.

Waiting for a non-blocking native read is a reasonable approach (IIUC that is required for the desired proper fix).  It would be useful to assess any time-frame of such support to plan ahead?

?

ProcessImpl
?

 665         void processExited() {
 666             synchronized (closeLock) {
 667                 try {
 668                     InputStream in = this.in;
 669                     // this stream is closed if and only if: in == null
 670                     if (in != null) {
 671                         boolean noCompete = false;
 672                         try {
 673                             // Briefly, wait for competing read to complete
 674                             noCompete = readLock.tryAcquire(500L, TimeUnit.MILLISECONDS);
 675                             if (noCompete) {
 676                                 // no competing read, buffer any pending input
 677                                 this.in = drainInputStream(in);
 678                             }
 679                         } catch (InterruptedException ie) {
 680                             // Ignore interrupt and release and close always
 681                         } finally {
 682                             readAborted = !noCompete;
 683                             in.close();     // close the original underlying input stream
 684                             if (noCompete)
 685                                 readLock.release();
 686                         }
 687                     }
 688                 } catch (IOException ignored) {}
 689             }
 690         }


Do you need to move the code at lines 684-685 to occur before line 683? since in.close() could throw.

Paul.


> On Jan 21, 2020, at 12:36 PM, Roger Riggs  wrote:
> 
> Please review a potential way to address two issues of java.lang.Process deadlocks during process exit. [1] [2]
> (Linxu OS process expertise appreciated).
> 
> The deadlock is between some thread reading process output from a process that has exited
> and the processExited thread that is attempting to buffer any remaining output so
> the file descriptor for the pipe can be closed.  The methods involved are synchronized
> on a ProcessPipeInputStream instance.
> 
> The hard case arises infrequently since the pipe streams are closed by the OS
> normally (or within a few seconds) and the readXXX completes.
> However, the case causing trouble is when the subprocess has spawned
> another process and both processes are using the same file descriptor/stream for output.
> Though the process that exits doesn't have the fd open anymore the extra subprocess does.
> And if that subprocess does not exit, then the read and deadlock does not get resolved.
> 
> The approach proposed is to use a semaphore to guard the readXXX and
> providing some non-blocking logic in processExited to forcibly close
> the pipe if it detects that there is a conflicting read in progress.
> (And remove the synchronized on processExited).
> 
> This solution works ok on MacOSX, where one of the issues occurred frequently.
> Closing the pipe unblocks the reading thread.
> 
> On Linux, it appears that the blocking read (in native code) does not unblock
> unless a signal occurs; so the solution does not fix the problem adqurated/completely.
> 
> Having a non-blocking native read would be the next step of complexity.
> The problem has been around for a while so it may be an option to wait
> for additional work on non-blocking pipe reads, the direction that Loom is moving.
> 
> Suggestions welcome,
> 
> Thanks, Roger
> 
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-hdiutil-8236825/
> 
> Issues:
> [1] https://bugs.openjdk.java.net/browse/JDK-8236825
> [2] https://bugs.openjdk.java.net/browse/JDK-8169565


From ivan.gerasimov at oracle.com  Thu Jan 23 04:23:41 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 22 Jan 2020 20:23:41 -0800
Subject: RFR 8237599 : Greedy matching against supplementary chars fails to
 respect the region
Message-ID: <88a8bdd6-0791-0539-ff46-cf6441b13f3c@oracle.com>

Hello everyone!

When the input of a j.u.regex.Matcher is restricted with .region() 
method, it can possibly cut off a half of a surrogate pair.

It turns out that greedy matching implemented in the 
Pattern.CharPropertyGreedy class fails to recognize this edge case in 
two scenarios:

1) When it greedily consumes the input and meets a higher half of a 
surrogate pair that was cut off at the end of input, and

2) When it backs off and meets a lower half of a surrogate pair at the 
very beginning of input.

In both cases, the engine reads the entire codepoint, crossing the 
boundaries of the set region.

Instead, it should only read the half of the surrogate pair that lies 
inside the region and ignore the other half.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8237599
WEBREV: http://cr.openjdk.java.net/~igerasim/8237599/00/webrev/

Thanks in advance!

-- 
With kind regards,
Ivan Gerasimov


From alexander.matveev at oracle.com  Thu Jan 23 04:37:38 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 22 Jan 2020 20:37:38 -0800
Subject: RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails if
 runtime is already signed
Message-ID: 

Please review the jpackage fix for bug [1] at [2].

- Fixed by forcing signing even if runtime already signed.
- Original implementation was not taken in consideration that runtime 
can be signed (JDK itself is signed from which jpackage is used or 
runtime provided via --runtime-image).
- Signature of binaries files in runtime will not be change, with this 
fix we will generate new _CodeSignature/CodeResources file which 
contains signatures of all files inside runtime folder signed with user 
provided certificate.

[1] https://bugs.openjdk.java.net/browse/JDK-8237607

[2] http://cr.openjdk.java.net/~almatvee/8237607/webrev.00/

Thanks,
Alexander

From nick.gasson at arm.com  Thu Jan 23 07:08:31 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Thu, 23 Jan 2020 15:08:31 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: 
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
Message-ID: <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>

Hi Maurizio,

Yes, for jdk/jdk. Do I need another Reviewer?


Thanks,
Nick


On 01/22/20 20:46 pm, Maurizio Cimadamore wrote:
> Fixes look good to me - I assume this is for JDK 15, right?
>
> Maurizio
>
> On 22/01/2020 08:43, Nick Gasson wrote:
>> Hi,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
>> Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/
>>
>> This is a follow-up to JDK-8236634 which just contained changes to the 
>> tests to make them build/pass on 32-bit systems for JDK 14. This patch 
>> removes the test workarounds and fixes two things to make them pass:
>>
>> * In Unsafe_AllocateMemory0 handle the case where the aligned-up size 
>> overflows a 32-bit size_t and throw an OutOfMemoryError instead of 
>> calling os::malloc(0).
>>
>> * Change the value of Utils.MAX_ALIGN from 16 to 8 on 32-bit systems, 
>> as malloc can return addresses that are only 8-byte aligned.
>>
>> Tested jdk_foreign on x86_32, arm32, aarch64, x86_64.
>>
>>
>> Thanks,
>> Nick


From david.holmes at oracle.com  Thu Jan 23 07:25:42 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2020 17:25:42 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: 

On 23/01/2020 5:08 pm, Nick Gasson wrote:
> Hi Maurizio,
> 
> Yes, for jdk/jdk. Do I need another Reviewer?

Yes - specifically you need a reviewer from Hotspot! cc'ing 
hotspot-runtime-dev :)

Cheers,
David

> 
> Thanks,
> Nick
> 
> 
> On 01/22/20 20:46 pm, Maurizio Cimadamore wrote:
>> Fixes look good to me - I assume this is for JDK 15, right?
>>
>> Maurizio
>>
>> On 22/01/2020 08:43, Nick Gasson wrote:
>>> Hi,
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
>>> Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/
>>>
>>> This is a follow-up to JDK-8236634 which just contained changes to the
>>> tests to make them build/pass on 32-bit systems for JDK 14. This patch
>>> removes the test workarounds and fixes two things to make them pass:
>>>
>>> * In Unsafe_AllocateMemory0 handle the case where the aligned-up size
>>> overflows a 32-bit size_t and throw an OutOfMemoryError instead of
>>> calling os::malloc(0).
>>>
>>> * Change the value of Utils.MAX_ALIGN from 16 to 8 on 32-bit systems,
>>> as malloc can return addresses that are only 8-byte aligned.
>>>
>>> Tested jdk_foreign on x86_32, arm32, aarch64, x86_64.
>>>
>>>
>>> Thanks,
>>> Nick
> 

From david.holmes at oracle.com  Thu Jan 23 07:46:45 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2020 17:46:45 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: 
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
Message-ID: <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>

Hi Nick :)

On 23/01/2020 5:25 pm, David Holmes wrote:
> On 23/01/2020 5:08 pm, Nick Gasson wrote:
>> Hi Maurizio,
>>
>> Yes, for jdk/jdk. Do I need another Reviewer?
> 
> Yes - specifically you need a reviewer from Hotspot! cc'ing 
> hotspot-runtime-dev :)

So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed 
for by the jlong size variable. On 64-bit overflow is not possible 
because jlong is signed and size_t is not.

So we only need an overflow check on 32-bit.

But your checks don't look correct to me. If size is already aligned to 
HeapWordSize then "sz < (size_t)size" won't be true but you already have 
a completely bogus value for sz when you truncated size to 32-bits.

Cheers,
David

> Cheers,
> David
> 
>>
>> Thanks,
>> Nick
>>
>>
>> On 01/22/20 20:46 pm, Maurizio Cimadamore wrote:
>>> Fixes look good to me - I assume this is for JDK 15, right?
>>>
>>> Maurizio
>>>
>>> On 22/01/2020 08:43, Nick Gasson wrote:
>>>> Hi,
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
>>>> Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/
>>>>
>>>> This is a follow-up to JDK-8236634 which just contained changes to the
>>>> tests to make them build/pass on 32-bit systems for JDK 14. This patch
>>>> removes the test workarounds and fixes two things to make them pass:
>>>>
>>>> * In Unsafe_AllocateMemory0 handle the case where the aligned-up size
>>>> overflows a 32-bit size_t and throw an OutOfMemoryError instead of
>>>> calling os::malloc(0).
>>>>
>>>> * Change the value of Utils.MAX_ALIGN from 16 to 8 on 32-bit systems,
>>>> as malloc can return addresses that are only 8-byte aligned.
>>>>
>>>> Tested jdk_foreign on x86_32, arm32, aarch64, x86_64.
>>>>
>>>>
>>>> Thanks,
>>>> Nick
>>

From nick.gasson at arm.com  Thu Jan 23 08:02:26 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Thu, 23 Jan 2020 16:02:26 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
Message-ID: <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>

Hi David,

On 01/23/20 15:46 pm, David Holmes wrote:
>
> So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed 
> for by the jlong size variable. On 64-bit overflow is not possible 
> because jlong is signed and size_t is not.
>
> So we only need an overflow check on 32-bit.

OK. So wrap the check in #ifndef _LP64?

>
> But your checks don't look correct to me. If size is already aligned to 
> HeapWordSize then "sz < (size_t)size" won't be true but you already have 
> a completely bogus value for sz when you truncated size to 32-bits.
>

On a 32-bit system we already know the upper 32-bits of `size' are zero
because Unsafe.checkSize() checks this prior to calling the native
function, so I think the cast is OK.

Thanks,
Nick

From david.holmes at oracle.com  Thu Jan 23 10:22:32 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jan 2020 20:22:32 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>

Hi Nick,

I've cc'd Kim as our C++ expert.

Kim I have a query below if we're entering UB territory ...

On 23/01/2020 6:02 pm, Nick Gasson wrote:
> Hi David,
> 
> On 01/23/20 15:46 pm, David Holmes wrote:
>>
>> So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed
>> for by the jlong size variable. On 64-bit overflow is not possible
>> because jlong is signed and size_t is not.
>>
>> So we only need an overflow check on 32-bit.
> 
> OK. So wrap the check in #ifndef _LP64?

Yes please.

>>
>> But your checks don't look correct to me. If size is already aligned to
>> HeapWordSize then "sz < (size_t)size" won't be true but you already have
>> a completely bogus value for sz when you truncated size to 32-bits.
>>
> 
> On a 32-bit system we already know the upper 32-bits of `size' are zero
> because Unsafe.checkSize() checks this prior to calling the native
> function, so I think the cast is OK.

That precondition needs to be documented in this method then. Hmmm so 
you have a guaranteed 32-bit value, but it might act like an unsigned 
32-bit value - is that the case? Any reason not to have the Java code 
ensure the size acts like a 32-bit signed int? Then no overflow is possible.

That aside IIRC the overflow check is not ideal here because we already 
enter undefined behaviour territory inside align_up if we actually 
overflow. I'm not sure what the officially sanctioned mechanism for 
avoiding overflow would be here given the addition is hidden inside 
align_up. Hopefully Kim can clarify this aspect.

Thanks,
David

> Thanks,
> Nick
> 

From kevin.rushforth at oracle.com  Thu Jan 23 12:39:44 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 23 Jan 2020 04:39:44 -0800
Subject: RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails
 if runtime is already signed
In-Reply-To: 
References: 
Message-ID: <02b7c40a-12a1-ba33-f89b-f6a37a4b4b99@oracle.com>

Looks good to me.

+1

-- Kevin


On 1/22/2020 8:37 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Fixed by forcing signing even if runtime already signed.
> - Original implementation was not taken in consideration that runtime 
> can be signed (JDK itself is signed from which jpackage is used or 
> runtime provided via --runtime-image).
> - Signature of binaries files in runtime will not be change, with this 
> fix we will generate new _CodeSignature/CodeResources file which 
> contains signatures of all files inside runtime folder signed with 
> user provided certificate.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8237607
>
> [2] http://cr.openjdk.java.net/~almatvee/8237607/webrev.00/
>
> Thanks,
> Alexander


From adam.farley at uk.ibm.com  Thu Jan 23 13:41:18 2020
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Thu, 23 Jan 2020 13:41:18 +0000
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <13ce2eb6-40d9-d7e3-e084-44a413aa1f5b@oracle.com>
References: 
 
 
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
 
 <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>
 
 
 
 <13ce2eb6-40d9-d7e3-e084-44a413aa1f5b@oracle.com>
Message-ID: 

Hi Mandy,

Thanks for your thoughts. :)

I've asked around, and there don't appear to be any details
regarding real-life customer scenarios that can be shared.

I realise this doesn't exactly help my case.

As for the volume of output, I hoped to address that via the
inclusion of the regex check, thus allowing us to limit the
output to things affecting the specific class, or group of
classes.

In any event, while this feature makes sense to me, I understand
not every new idea gets to be a real boy. C'est la vie.

Thanks for your time. :)

Best Regards

Adam Farley 
IBM Runtimes

P.S. On a related note, if anyone more familiar with jcmd and 
Unified VM Logging wants to drop me some hints regarding 
getting the info in this issue's first bulleted list, it'd be
appreciated. :)

Issue: https://bugs.openjdk.java.net/browse/JDK-8232773



Mandy Chung  wrote on 06/01/2020 23:36:14:

> From: Mandy Chung 
> To: Adam Farley8 
> Cc: core-libs-dev 
> Date: 06/01/2020 23:38
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output 
> for Specific Classes
> 
> Hi Adam,
> 
> Thanks for the examples. I was hoping for some customer issues and 
> how they identified the root causes to understand if there is any 
> specific problem to be considered than improving the overall class 
> loading diagnosability.
> 
> The solution you propose is to add debug/trace statements in the 
> class loading implementation to improve diagnosability.   I concern 
> the volume of trace output could make it hard to troubleshoot.    
> There are existing class loading traces with unified VM logging, JFR
> events and also jcmd that also output class loading information.   
> Adding a new class loading tracing mechanism isn't a good option.   
> Alan mentioned that discussion at OpenJDK worshop [1] about 
> improving the serviceability and diagnosibility in the java.base 
> module.  I think that'd better guide you if that makes further 
discussion.
> 
> Mandy
> [1] https://mail.openjdk.java.net/pipermail/workshop-discuss/2019-
> August/000078.html

> On 11/8/19 5:49 AM, Adam Farley8 wrote:
> Hi Mandy,
> 
> Sorry for the delay in responding. 
> 
> Mandy Chung  wrote on 29/10/2019 19:30:55:
> 
> > From: Mandy Chung  
> > To: Adam Farley8  
> > Cc: core-libs-dev  
> > Date: 29/10/2019 19:31 
> > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output 
> > for Specific Classes 
> > 
> > Hi Adam,
> > 
> > It'd be useful to provide a few typical scenarios that customers run 
into.
> > 
> > That would give better understanding on the problem "hard to diagnose 
> > why a given class was not loaded" and help the consideration on 
> > alternatives.   
> 
> I'm happy to provide some hypothetical example scenarios, which I've 
> included below. We should note that this is not limited to customers, 
and 
> that this sort of diagnostic output is also extremely useful for people 
> helping customers to resolve issues. 

> 
> When a class cannot be found, it's a configuration issue and Class-Path 
hell

> I've also included the way the webrev's debug output aids people trying 
> to reproduce this problem. 
> 
> Scenario 1: A user gets a ClassNotFoundException because the location 
> of the class is not on the classpath used by the ClassLoader/s that 
> attempted to load it, despite the fact that one ClassLoader definitely 
> has the location of the class on its classpath. 
> 
> Aid: This webrev's debug output tells the user, or the tech support 
> aiding the user: 
> - If the ClassLoader with the classpath location for that class is 
> ever tasked with trying to load that class. 
> - If the ClassLoader with the classpath location for that class 
> actually tries to load that class from the classpath (vs a module). 
> - If the ClassLoader with the classpath location actually checks that 
> location at all. 
> - What other ClassLoaders are used to attempt to load that class, 
> allowing the user/support agent to adjust the classpath for another 
> ClassLoader if needed. 
> 
> Scenario 2: A program uses the wrong version of a class. 
> 
> Aid: This webrev's debug output tells the user, or the tech support 
> aiding the user: 
> - Which classpath was used by the ClassLoader that loaded the class 
> at the time that the class was loaded. 
> - Which locations were checked by that ClassLoader before finding the 
> wrong version of the class. This, among other things, helps identify 
> access issues for the location of the correct class. 
> - Which ClassLoaders attempted to load the class, and in which order, 
> (increasingly useful in the current "nested" ClassLoading model). 
> 
> Scenario 3: A program is unable to find a class because none of the 
> ClassLoaders could find it, and you lack both familiarity with the 
> ClassLoader code, and the time to figure out how all of the different 
> ones work. 
> 
> Aid: This webrev's debug output tells the user, or the tech support 
> aiding the user: 
> - Which ClassLoaders were involved in each attempt to load the class. 
> - What the logic path was for each ClassLoader asked to load the 
> class. 
> - Which module/s, if any, were identified by the ClassLoader as the 
> potential owner/s of the class, and how that worked out in each 
> case. 
> 
> > The debug output could produce lots of trace output but 
> > the output does not clearly indicate the initiating class is.  
> 
> Correct. The scope of my debug output was limited to the actions 
> of the ClassLoader/s attempting to load a class that matches a 
> specific regex. 
> 
> > I wonder 
> > if the problem you are looking at is related to JDK-6747450 [1] or 
> > really tracing the class loader delegation and search path.  
> 
> The latter. If I implied that I was interested in the initiating class, 
> then I was wrong. Also, though I am not fundamentally opposed to 
> expanding the scope to incorporate JDK-6747450, the fact that it's been 
> drifting for nine years tells me I'd just be adding complexity without 
> adding anything that would support the inclusion of the change. 
> 
> Short version: I think this issue's scope should not include details 
> of the initiating class. 
> 
> > Or maybe 
> > Java Flight Recorder is a better candidate?  
> 
> I don't know much about Java Flight Recorder, as it currently only 
> supports one of the VMs I work with. 
> 
> >  Without knowing specific 
> > of the problems customers have, perhaps VM logging can be enhanced to 
> > trace the initiating class and class loader?
> > 
> > Mandy
> 
> It's possible. I wouldn't know where to start with that. The simplest, 
> and most straight-forward approach (in my mind) is to add the debug 
> code directly to the code we're debugging. 
> 
> Plus, using a Class Library -based approach ensures that the debug 
> output is available regardless of the VM being used, or the user's 
> familiarity with Flight Recorder. 
> 
> Though this might just be a "me" problem. ;) 
> 
> What do you think? 
> 
> 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 aph at redhat.com  Thu Jan 23 14:41:39 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Jan 2020 14:41:39 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
Message-ID: <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>

On 1/23/20 10:22 AM, David Holmes wrote:
> That aside IIRC the overflow check is not ideal here because we already 
> enter undefined behaviour territory inside align_up if we actually 
> overflow.

How is that possible? size_t is an unsigned type, and unsigned types
never overflow. On a 32-bit box, 0 <= size < 2**32. So -- in theory at
least -- you could allocate more than 2G.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From andy.herrick at oracle.com  Thu Jan 23 14:42:00 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 23 Jan 2020 09:42:00 -0500
Subject: RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails
 if runtime is already signed
In-Reply-To: 
References: 
Message-ID: <8f12f59c-91e3-d788-b8fe-2d4ba9cb7784@oracle.com>

looks good.

/Andy

On 1/22/2020 11:37 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Fixed by forcing signing even if runtime already signed.
> - Original implementation was not taken in consideration that runtime 
> can be signed (JDK itself is signed from which jpackage is used or 
> runtime provided via --runtime-image).
> - Signature of binaries files in runtime will not be change, with this 
> fix we will generate new _CodeSignature/CodeResources file which 
> contains signatures of all files inside runtime folder signed with 
> user provided certificate.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8237607
>
> [2] http://cr.openjdk.java.net/~almatvee/8237607/webrev.00/
>
> Thanks,
> Alexander

From Roger.Riggs at oracle.com  Thu Jan 23 14:49:38 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jan 2020 09:49:38 -0500
Subject: RFR [15] 8236825: Reading output from ... using
 ProcessBuilder/Process might hang
In-Reply-To: 
References: <56162036-deb9-0ffa-6988-07d84a4979f4@oracle.com>
 
Message-ID: <963965b3-47b7-9a42-f7cb-8a1c65c9f94b@oracle.com>

Hi Paul,

yes, other potential changes in low level I/O should probably happen 
first.? Will check.

On 1/22/20 3:31 PM, Paul Sandoz wrote:
> My sense is it is fixing a marginal case for the less dominant platform where this is less likely arise, whereas for the dominant platform there is still an issue.
>
> Waiting for a non-blocking native read is a reasonable approach (IIUC that is required for the desired proper fix).  It would be useful to assess any time-frame of such support to plan ahead?
>
> ?
>
> ProcessImpl
> ?
>
>   665         void processExited() {
>   666             synchronized (closeLock) {
>   667                 try {
>   668                     InputStream in = this.in;
>   669                     // this stream is closed if and only if: in == null
>   670                     if (in != null) {
>   671                         boolean noCompete = false;
>   672                         try {
>   673                             // Briefly, wait for competing read to complete
>   674                             noCompete = readLock.tryAcquire(500L, TimeUnit.MILLISECONDS);
>   675                             if (noCompete) {
>   676                                 // no competing read, buffer any pending input
>   677                                 this.in = drainInputStream(in);
>   678                             }
>   679                         } catch (InterruptedException ie) {
>   680                             // Ignore interrupt and release and close always
>   681                         } finally {
>   682                             readAborted = !noCompete;
>   683                             in.close();     // close the original underlying input stream
>   684                             if (noCompete)
>   685                                 readLock.release();
>   686                         }
>   687                     }
>   688                 } catch (IOException ignored) {}
>   689             }
>   690         }
>
>
> Do you need to move the code at lines 684-685 to occur before line 683? since in.close() could throw.
Good catch.
A try/catch/ignore block around the close would also address it.
If the readLock.release()happens after the close(), then a pending read 
won't be in a race with the close.

Thanks, Roger

>
> Paul.
>
>
>> On Jan 21, 2020, at 12:36 PM, Roger Riggs  wrote:
>>
>> Please review a potential way to address two issues of java.lang.Process deadlocks during process exit. [1] [2]
>> (Linxu OS process expertise appreciated).
>>
>> The deadlock is between some thread reading process output from a process that has exited
>> and the processExited thread that is attempting to buffer any remaining output so
>> the file descriptor for the pipe can be closed.  The methods involved are synchronized
>> on a ProcessPipeInputStream instance.
>>
>> The hard case arises infrequently since the pipe streams are closed by the OS
>> normally (or within a few seconds) and the readXXX completes.
>> However, the case causing trouble is when the subprocess has spawned
>> another process and both processes are using the same file descriptor/stream for output.
>> Though the process that exits doesn't have the fd open anymore the extra subprocess does.
>> And if that subprocess does not exit, then the read and deadlock does not get resolved.
>>
>> The approach proposed is to use a semaphore to guard the readXXX and
>> providing some non-blocking logic in processExited to forcibly close
>> the pipe if it detects that there is a conflicting read in progress.
>> (And remove the synchronized on processExited).
>>
>> This solution works ok on MacOSX, where one of the issues occurred frequently.
>> Closing the pipe unblocks the reading thread.
>>
>> On Linux, it appears that the blocking read (in native code) does not unblock
>> unless a signal occurs; so the solution does not fix the problem adqurated/completely.
>>
>> Having a non-blocking native read would be the next step of complexity.
>> The problem has been around for a while so it may be an option to wait
>> for additional work on non-blocking pipe reads, the direction that Loom is moving.
>>
>> Suggestions welcome,
>>
>> Thanks, Roger
>>
>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-hdiutil-8236825/
>>
>> Issues:
>> [1] https://bugs.openjdk.java.net/browse/JDK-8236825
>> [2] https://bugs.openjdk.java.net/browse/JDK-8169565


From alexey.semenyuk at oracle.com  Thu Jan 23 16:25:12 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 23 Jan 2020 11:25:12 -0500
Subject: RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails
 if runtime is already signed
In-Reply-To: 
References: 
Message-ID: <059bf34f-9d96-fef2-df9f-fd9174de7711@oracle.com>

Looks good.

- Alexey

On 1/22/2020 11:37 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Fixed by forcing signing even if runtime already signed.
> - Original implementation was not taken in consideration that runtime 
> can be signed (JDK itself is signed from which jpackage is used or 
> runtime provided via --runtime-image).
> - Signature of binaries files in runtime will not be change, with this 
> fix we will generate new _CodeSignature/CodeResources file which 
> contains signatures of all files inside runtime folder signed with 
> user provided certificate.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8237607
>
> [2] http://cr.openjdk.java.net/~almatvee/8237607/webrev.00/
>
> Thanks,
> Alexander


From james at deepsymmetry.org  Thu Jan 23 16:49:07 2020
From: james at deepsymmetry.org (James Elliott)
Date: Thu, 23 Jan 2020 10:49:07 -0600
Subject: RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails
 if runtime is already signed
In-Reply-To: 
References: 
Message-ID: <9DF75D74-7441-4F6F-AC20-5EA7CB1424D5@deepsymmetry.org>

I am glad to see that people are making progress on this front. Did you see the points I raised about the new arguments and inputs that need to be provided in order to build code-signed packages that can pass Apple?s current notarization requirements in Catalina? I am currently successfully notarizing a Java disk image created by the early access version of jpackage, but I need to do the signing and notarizing myself because jpackage does not yet support specifying use of the hardened runtime, nor the necessary entitlements for the JVM to run properly in that hardened environment. I would be happy to share what I found works whenever that might be helpful.

Cheers,

	-James

On 1/22/2020 11:37 PM, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
- Fixed by forcing signing even if runtime already signed. - Original implementation was not taken in consideration that runtime can be signed (JDK itself is signed from which jpackage is used or runtime provided via --runtime-image). - Signature of binaries files in runtime will not be change, with this fix we will generate new _CodeSignature/CodeResources file which contains signatures of all files inside runtime folder signed with user provided certificate.
[1] https://bugs.openjdk.java.net/browse/JDK-8237607
[2] http://cr.openjdk.java.net/~almatvee/8237607/webrev.00/
Thanks, Alexander

From Roger.Riggs at oracle.com  Thu Jan 23 20:18:17 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jan 2020 15:18:17 -0500
Subject: [14] 8215361 (doc) Cleanup package-info markup - smartcardio,
 java.sql, java.sql.rowset
Message-ID: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>

Please review cleanup of package-info.java files use of  -> {@code}.

Webrev:
 ? http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/

Issue:
 ? https://bugs.openjdk.java.net/browse/JDK-8215361

Thanks, Roger


From lance.andersen at oracle.com  Thu Jan 23 21:05:30 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Jan 2020 16:05:30 -0500
Subject: [14] 8215361 (doc) Cleanup package-info markup - smartcardio,
 java.sql, java.sql.rowset
In-Reply-To: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
References: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
Message-ID: 

Hi Roger

Overall looks OK with the exception of
java.sql.rowset/share/classes/com/sun/rowset/package-info.java
??????
- * CachedRowSetImpl - The javax.sql.rowset.CachedRowSet interface
+ * {@code CachedRowSetImpl} - The javax.sql.rowset.CachedRowSet interface
????????

There are a few  entries that seemed to be missed, but all good otherwise 

HTH
Lance

> On Jan 23, 2020, at 3:18 PM, Roger Riggs  wrote:
> 
> Please review cleanup of package-info.java files use of  -> {@code}.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8215361
> 
> 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 naoto.sato at oracle.com  Thu Jan 23 21:08:06 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 23 Jan 2020 13:08:06 -0800
Subject: [14] 8215361 (doc) Cleanup package-info markup - smartcardio,
 java.sql, java.sql.rowset
In-Reply-To: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
References: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
Message-ID: <8c938856-caa7-4536-4064-9b844e632c25@oracle.com>

Hi Roger,

Looks good to me.

Although they are in the original src, I would put spaces between 
"{@code SerialBlob}" and "class"/"object", at line 50,52 in 
javax/sql/rowset/serial/package-info.java

Naoto

On 1/23/20 12:18 PM, Roger Riggs wrote:
> Please review cleanup of package-info.java files use of  -> {@code}.
> 
> Webrev:
>  ? http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/
> 
> Issue:
>  ? https://bugs.openjdk.java.net/browse/JDK-8215361
> 
> Thanks, Roger
> 

From pavel.rappo at oracle.com  Thu Jan 23 21:24:26 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 23 Jan 2020 21:24:26 +0000
Subject: [14] 8215361 (doc) Cleanup package-info markup - smartcardio,
 java.sql, java.sql.rowset
In-Reply-To: 
References: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
 
Message-ID: <49122F7C-2C52-4FFA-98BA-47C8B69CB937@oracle.com>

Yes, I can see those too. That suggests that the change was not performed automatically. Which makes sense, since sometimes nested tags need to be "turned inside out", e.g. ... -> {@code ...}.

    {@code     java.net.URL url = rowset.getURL(1);}

Will it be rendered as intended? Otherwise looks good.

> On 23 Jan 2020, at 21:05, Lance Andersen  wrote:
> 
> Hi Roger
> 
> Overall looks OK with the exception of
> java.sql.rowset/share/classes/com/sun/rowset/package-info.java
> ??????
> - * CachedRowSetImpl - The javax.sql.rowset.CachedRowSet interface
> + * {@code CachedRowSetImpl} - The javax.sql.rowset.CachedRowSet interface
> ????????
> 
> There are a few  entries that seemed to be missed, but all good otherwise 
> 
> HTH
> Lance
> 
>> On Jan 23, 2020, at 3:18 PM, Roger Riggs  wrote:
>> 
>> Please review cleanup of package-info.java files use of  -> {@code}.
>> 
>> Webrev:
>>  http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/
>> 
>> Issue:
>>  https://bugs.openjdk.java.net/browse/JDK-8215361
>> 
>> 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 david.holmes at oracle.com  Thu Jan 23 22:59:17 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jan 2020 08:59:17 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
Message-ID: <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>

On 24/01/2020 12:41 am, Andrew Haley wrote:
> On 1/23/20 10:22 AM, David Holmes wrote:
>> That aside IIRC the overflow check is not ideal here because we already
>> enter undefined behaviour territory inside align_up if we actually
>> overflow.
> 
> How is that possible? size_t is an unsigned type, and unsigned types
> never overflow.

Yes you are right, I was not recalling the rules correctly. So the 
addition to the size_t is guaranteed to wrap and so the < test is valid.

Sorry for the noise on that.

It may still be cleaner if the Java side enforces a maximum of 
Integer.MAX_VALUE for 32-bit.

Thanks,
David

> On a 32-bit box, 0 <= size < 2**32. So -- in theory at
> least -- you could allocate more than 2G.
> 

From maurizio.cimadamore at oracle.com  Thu Jan 23 23:27:36 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 23 Jan 2020 23:27:36 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
Message-ID: 


On 23/01/2020 22:59, David Holmes wrote:
> On 24/01/2020 12:41 am, Andrew Haley wrote:
>> On 1/23/20 10:22 AM, David Holmes wrote:
>>> That aside IIRC the overflow check is not ideal here because we already
>>> enter undefined behaviour territory inside align_up if we actually
>>> overflow.
>>
>> How is that possible? size_t is an unsigned type, and unsigned types
>> never overflow.
>
> Yes you are right, I was not recalling the rules correctly. So the 
> addition to the size_t is guaranteed to wrap and so the < test is valid.
>
> Sorry for the noise on that.
>
> It may still be cleaner if the Java side enforces a maximum of 
> Integer.MAX_VALUE for 32-bit.

I have no objections in adding an extra check where the native memory 
segment is created - perhaps we should just do that.

That said, memory segments are not the only clients of 
Unsafe::allocateMemory - so if we decided that overflow is an issue that 
should be handled in clients, fine, but at least it should be evident 
somewhere in the javadoc of Unsafe::allocateMemory?

Maurizio

>
> Thanks,
> David
>
>> On a 32-bit box, 0 <= size < 2**32. So -- in theory at
>> least -- you could allocate more than 2G.
>>

From david.holmes at oracle.com  Fri Jan 24 04:17:44 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jan 2020 14:17:44 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: 
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
Message-ID: <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>

Hi Maurizio,

On 24/01/2020 9:27 am, Maurizio Cimadamore wrote:
> 
> On 23/01/2020 22:59, David Holmes wrote:
>> On 24/01/2020 12:41 am, Andrew Haley wrote:
>>> On 1/23/20 10:22 AM, David Holmes wrote:
>>>> That aside IIRC the overflow check is not ideal here because we already
>>>> enter undefined behaviour territory inside align_up if we actually
>>>> overflow.
>>>
>>> How is that possible? size_t is an unsigned type, and unsigned types
>>> never overflow.
>>
>> Yes you are right, I was not recalling the rules correctly. So the 
>> addition to the size_t is guaranteed to wrap and so the < test is valid.
>>
>> Sorry for the noise on that.
>>
>> It may still be cleaner if the Java side enforces a maximum of 
>> Integer.MAX_VALUE for 32-bit.
> 
> I have no objections in adding an extra check where the native memory 
> segment is created - perhaps we should just do that.
> 
> That said, memory segments are not the only clients of 
> Unsafe::allocateMemory - so if we decided that overflow is an issue that 
> should be handled in clients, fine, but at least it should be evident 
> somewhere in the javadoc of Unsafe::allocateMemory?

I'm glad you raised that as it prompted me to examine Unsafe in more 
detail. :)

The onus is put on the caller to ensure arguments are valid. Unsafe 
class docs state, and a number of methods like allocateMemory repeat:

      * Note: It is the resposibility of the caller to make
      * sure arguments are checked before the methods are called. While
      * some rudimentary checks are performed on the input, the checks
      * are best effort and when performance is an overriding priority,
      * as when methods of this class are optimized by the runtime
      * compiler, some or all checks (if any) may be elided. Hence, the
      * caller must not rely on the checks and corresponding
      * exceptions!

So although allocateMemory explicitly checks for size_t related overflow:

      * @throws RuntimeException if the size is negative or too large
      *         for the native size_t type

the caller should not be relying on that.

The existing overflow check is done by checkSize(long size) which has:

  if (ADDRESS_SIZE == 4) {
     // Note: this will also check for negative sizes
     if (!is32BitClean(size)) {
         throw invalidInput();
     }
  }

where is32BitClean is defined as:

value >>> 32 == 0;

and so is incomplete as this doesn't take into account the possible 
align up of "size" that the JVM allocation routine actually performs. 
But even if we fix this, the caller is not supposed to rely on it.

In terms of fixing it ... it isn't clear to me whether this case should 
be detected in the VM as Nick's patch does, or whether it should be 
caught before hand in the checkSize Java code (though we don't really 
know what the alignment requirement may be in the Java code). A 
difference is that if we catch it in checkSize then we will throw 
IllegalArgumentException, whereas Nick's approach results in 
OutOfMemoryError. I think the IllegalArgumentException is actually 
preferable here.

David
-----

> Maurizio
> 
>>
>> Thanks,
>> David
>>
>>> On a 32-bit box, 0 <= size < 2**32. So -- in theory at
>>> least -- you could allocate more than 2G.
>>>

From nick.gasson at arm.com  Fri Jan 24 05:32:35 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Fri, 24 Jan 2020 13:32:35 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
Message-ID: <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>

Hi David,

On 01/24/20 12:17 pm, David Holmes wrote:
>>
>> That said, memory segments are not the only clients of
>> Unsafe::allocateMemory - so if we decided that overflow is an issue
>> that should be handled in clients, fine, but at least it should be
>> evident somewhere in the javadoc of Unsafe::allocateMemory?
>
> I'm glad you raised that as it prompted me to examine Unsafe in more
> detail. :)
>
> The onus is put on the caller to ensure arguments are valid. Unsafe
> class docs state, and a number of methods like allocateMemory repeat:
>
>      * Note: It is the resposibility of the caller to make
>      * sure arguments are checked before the methods are called. While
>      * some rudimentary checks are performed on the input, the checks
>      * are best effort and when performance is an overriding priority,
>      * as when methods of this class are optimized by the runtime
>      * compiler, some or all checks (if any) may be elided. Hence, the
>      * caller must not rely on the checks and corresponding
>      * exceptions!
>
> So although allocateMemory explicitly checks for size_t related overflow:
>
>      * @throws RuntimeException if the size is negative or too large
>      *         for the native size_t type
>
> the caller should not be relying on that.
>
> The existing overflow check is done by checkSize(long size) which has:
>
>  if (ADDRESS_SIZE == 4) {
>     // Note: this will also check for negative sizes
>     if (!is32BitClean(size)) {
>         throw invalidInput();
>     }
>  }
>
> where is32BitClean is defined as:
>
> value >>> 32 == 0;
>
> and so is incomplete as this doesn't take into account the possible
> align up of "size" that the JVM allocation routine actually
> performs. But even if we fix this, the caller is not supposed to rely on
> it.
>
> In terms of fixing it ... it isn't clear to me whether this case should
> be detected in the VM as Nick's patch does, or whether it should be
> caught before hand in the checkSize Java code (though we don't really
> know what the alignment requirement may be in the Java code). A
> difference is that if we catch it in checkSize then we will throw
> IllegalArgumentException, whereas Nick's approach results in
> OutOfMemoryError. I think the IllegalArgumentException is actually
> preferable here.
>

How about we align the size up to ADDRESS_SIZE (== HeapWordSize) in
Unsafe.allocateMemory() before the call to allocateMemoryChecks(). Like:

  bytes = ((bytes + ADDRESS_SIZE - 1) & ~(ADDRESS_SIZE - 1));

Then it will throw an IllegalArgumentException if the result is outside
the size_t range. And in the native code we can just assert that the
`size' argument is already aligned:

  assert(is_aligned(sz, HeapWordSize), "sz not aligned");


Thanks,
Nick

From david.holmes at oracle.com  Fri Jan 24 06:35:42 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jan 2020 16:35:42 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>

Hi Nick,

On 24/01/2020 3:32 pm, Nick Gasson wrote:
> Hi David,
> 
> On 01/24/20 12:17 pm, David Holmes wrote:
>>>
>>> That said, memory segments are not the only clients of
>>> Unsafe::allocateMemory - so if we decided that overflow is an issue
>>> that should be handled in clients, fine, but at least it should be
>>> evident somewhere in the javadoc of Unsafe::allocateMemory?
>>
>> I'm glad you raised that as it prompted me to examine Unsafe in more
>> detail. :)
>>
>> The onus is put on the caller to ensure arguments are valid. Unsafe
>> class docs state, and a number of methods like allocateMemory repeat:
>>
>>       * Note: It is the resposibility of the caller to make
>>       * sure arguments are checked before the methods are called. While
>>       * some rudimentary checks are performed on the input, the checks
>>       * are best effort and when performance is an overriding priority,
>>       * as when methods of this class are optimized by the runtime
>>       * compiler, some or all checks (if any) may be elided. Hence, the
>>       * caller must not rely on the checks and corresponding
>>       * exceptions!
>>
>> So although allocateMemory explicitly checks for size_t related overflow:
>>
>>       * @throws RuntimeException if the size is negative or too large
>>       *         for the native size_t type
>>
>> the caller should not be relying on that.
>>
>> The existing overflow check is done by checkSize(long size) which has:
>>
>>   if (ADDRESS_SIZE == 4) {
>>      // Note: this will also check for negative sizes
>>      if (!is32BitClean(size)) {
>>          throw invalidInput();
>>      }
>>   }
>>
>> where is32BitClean is defined as:
>>
>> value >>> 32 == 0;
>>
>> and so is incomplete as this doesn't take into account the possible
>> align up of "size" that the JVM allocation routine actually
>> performs. But even if we fix this, the caller is not supposed to rely on
>> it.
>>
>> In terms of fixing it ... it isn't clear to me whether this case should
>> be detected in the VM as Nick's patch does, or whether it should be
>> caught before hand in the checkSize Java code (though we don't really
>> know what the alignment requirement may be in the Java code). A
>> difference is that if we catch it in checkSize then we will throw
>> IllegalArgumentException, whereas Nick's approach results in
>> OutOfMemoryError. I think the IllegalArgumentException is actually
>> preferable here.
>>
> 
> How about we align the size up to ADDRESS_SIZE (== HeapWordSize) in
> Unsafe.allocateMemory() before the call to allocateMemoryChecks(). Like:
> 
>    bytes = ((bytes + ADDRESS_SIZE - 1) & ~(ADDRESS_SIZE - 1));
> 
> Then it will throw an IllegalArgumentException if the result is outside
> the size_t range. And in the native code we can just assert that the
> `size' argument is already aligned:
> 
>    assert(is_aligned(sz, HeapWordSize), "sz not aligned");

That seems quite reasonable.

Thanks,
David

> 
> Thanks,
> Nick
> 

From nick.gasson at arm.com  Fri Jan 24 09:58:53 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Fri, 24 Jan 2020 17:58:53 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
Message-ID: <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>

Hi David,

On 01/24/20 14:35 pm, David Holmes wrote:
>>
>> How about we align the size up to ADDRESS_SIZE (== HeapWordSize) in
>> Unsafe.allocateMemory() before the call to allocateMemoryChecks(). Like:
>>
>>    bytes = ((bytes + ADDRESS_SIZE - 1) & ~(ADDRESS_SIZE - 1));
>>
>> Then it will throw an IllegalArgumentException if the result is outside
>> the size_t range. And in the native code we can just assert that the
>> `size' argument is already aligned:
>>
>>    assert(is_aligned(sz, HeapWordSize), "sz not aligned");
>
> That seems quite reasonable.
>

I've done this here:

http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/

Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
still throws an IllegalArgumentException.

Tested with jdk_foreign and runtime/Unsafe/.


Thanks,
Nick

From Alan.Bateman at oracle.com  Fri Jan 24 11:16:54 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Jan 2020 11:16:54 +0000
Subject: [zlib] Why do we make uLong a 32-bit int on 64-bit platforms?
In-Reply-To: <7feeba1c-ea43-adac-76d3-32e21fedb388@amazon.de>
References: <7feeba1c-ea43-adac-76d3-32e21fedb388@amazon.de>
Message-ID: 

On 15/01/2020 21:39, Volker Simonis wrote:
> Hi,
>
> is there any reason why the bundled zlib is patched to make zlib's
> "uLong" type a 32-bit int on 64-bit platforms [1]? This change to the
> original zlib is there since the very first drop of OpenJDK 6 [2] (which
> still had version 1.1.3 of zlib). Maybe it was required at that time
> when it was still possible to create images with both, 32- and 64-bit
> versions of the JDK and choose the one you want with -d64/-d32?
I vaguely remember a few issues with uLong not being defined for some 
build configurations. Sherman might remember more but I suspect we've 
been carrying that typedef for a long time even though it is not needed. 
So I think it should be okay to remove that.

-Alan.

From maurizio.cimadamore at oracle.com  Fri Jan 24 11:56:42 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Jan 2020 11:56:42 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: <2d372f70-d425-d00b-cedc-0d9925b8de96@oracle.com>

Changes to the Java code looks fine to me - (and the overall approach in 
Unsafe seems sensible, but I'll defer to David for that)

Thanks
Maurizio

On 24/01/2020 09:58, Nick Gasson wrote:
> Hi David,
>
> On 01/24/20 14:35 pm, David Holmes wrote:
>>> How about we align the size up to ADDRESS_SIZE (== HeapWordSize) in
>>> Unsafe.allocateMemory() before the call to allocateMemoryChecks(). Like:
>>>
>>>     bytes = ((bytes + ADDRESS_SIZE - 1) & ~(ADDRESS_SIZE - 1));
>>>
>>> Then it will throw an IllegalArgumentException if the result is outside
>>> the size_t range. And in the native code we can just assert that the
>>> `size' argument is already aligned:
>>>
>>>     assert(is_aligned(sz, HeapWordSize), "sz not aligned");
>> That seems quite reasonable.
>>
> I've done this here:
>
> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
>
> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
> still throws an IllegalArgumentException.
>
> Tested with jdk_foreign and runtime/Unsafe/.
>
>
> Thanks,
> Nick

From Roger.Riggs at oracle.com  Fri Jan 24 19:28:16 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 24 Jan 2020 14:28:16 -0500
Subject: [14] 8215361 (doc) Cleanup package-info markup - smartcardio,
 java.sql, java.sql.rowset
In-Reply-To: <8c938856-caa7-4536-4064-9b844e632c25@oracle.com>
References: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
 <8c938856-caa7-4536-4064-9b844e632c25@oracle.com>
Message-ID: <0e697c24-41d8-947b-d21b-230f2ef1f4b1@oracle.com>

Hi,

Corrections for the observed flaws:

 ? http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-2/

Thanks, Roger


On 1/23/20 4:08 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Looks good to me.
>
> Although they are in the original src, I would put spaces between 
> "{@code SerialBlob}" and "class"/"object", at line 50,52 in 
> javax/sql/rowset/serial/package-info.java
>
> Naoto
>
> On 1/23/20 12:18 PM, Roger Riggs wrote:
>> Please review cleanup of package-info.java files use of  -> 
>> {@code}.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/
>>
>> Issue:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8215361
>>
>> Thanks, Roger
>>


From Roger.Riggs at oracle.com  Fri Jan 24 19:51:51 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 24 Jan 2020 14:51:51 -0500
Subject: [14] RFR (doc) 8237651 Clarify initialization of jdk.serialFilter
Message-ID: <2a07ddb1-7c7b-ba7d-5fa1-5e8120221106@oracle.com>

Please review a doc change in the description of the initialization of 
the jdk.serialFilter from
a system property to generalize it beyond only command line invocation.

diff a/src/java.base/share/classes/java/io/ObjectInputFilter.java b/src/java.base/share/classes/java/io/ObjectInputFilter.java
--- a/src/java.base/share/classes/java/io/ObjectInputFilter.java
+++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java
@@ -204,15 +204,14 @@
       * When setting the filter, it should be stateless and idempotent,
       * reporting the same result when passed the same arguments.
       * 
    
       * The filter is configured during the initialization of the {@code ObjectInputFilter.Config}
       * class. For example, by calling {@link #getSerialFilter() Config.getSerialFilter}.
-     * If the system property {@systemProperty jdk.serialFilter} is defined on the command line,
-     * it is used to configure the filter.
-     * If the system property is not defined on the command line, and the
-     * {@link java.security.Security} property {@code jdk.serialFilter} is defined
-     * then it is used to configure the filter.
+     * If the Java virtual machine is started with the system property
+     * {@systemProperty jdk.serialFilter}, its value is used to configure the filter.
+     * If the system property is not defined, and the {@link java.security.Security} property
+     * {@code jdk.serialFilter} is defined then it is used to configure the filter.
       * Otherwise, the filter is not configured during initialization and
       * can be set with {@link #setSerialFilter(ObjectInputFilter) Config.setSerialFilter}.
       * Setting the {@code jdk.serialFilter} with {@link System#setProperty(String, String)
       * System.setProperty} does not set the filter.

Thanks, Roger

Issue:
 ?? https://bugs.openjdk.java.net/browse/JDK-8237651

Webrev:
 ??? http://cr.openjdk.java.net/~rriggs/webrev-filter-8237651/

From brent.christian at oracle.com  Fri Jan 24 20:43:14 2020
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 24 Jan 2020 12:43:14 -0800
Subject: [14] RFR (doc) 8237651 Clarify initialization of jdk.serialFilter
In-Reply-To: <2a07ddb1-7c7b-ba7d-5fa1-5e8120221106@oracle.com>
References: <2a07ddb1-7c7b-ba7d-5fa1-5e8120221106@oracle.com>
Message-ID: 

Looks fine to me, Roger.

-Brent

On 1/24/20 11:51 AM, Roger Riggs wrote:
> Please review a doc change in the description of the initialization of 
> the jdk.serialFilter from
> a system property to generalize it beyond only command line invocation.
> 
> diff a/src/java.base/share/classes/java/io/ObjectInputFilter.java 
> b/src/java.base/share/classes/java/io/ObjectInputFilter.java
> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java
> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java
> @@ -204,15 +204,14 @@
>  ????? * When setting the filter, it should be stateless and idempotent,
>  ????? * reporting the same result when passed the same arguments.
>  ????? * 
    
>  ????? * The filter is configured during the initialization of the 
> {@code ObjectInputFilter.Config}
>  ????? * class. For example, by calling {@link #getSerialFilter() 
> Config.getSerialFilter}.
> -???? * If the system property {@systemProperty jdk.serialFilter} is 
> defined on the command line,
> -???? * it is used to configure the filter.
> -???? * If the system property is not defined on the command line, and the
> -???? * {@link java.security.Security} property {@code jdk.serialFilter} 
> is defined
> -???? * then it is used to configure the filter.
> +???? * If the Java virtual machine is started with the system property
> +???? * {@systemProperty jdk.serialFilter}, its value is used to 
> configure the filter.
> +???? * If the system property is not defined, and the {@link 
> java.security.Security} property
> +???? * {@code jdk.serialFilter} is defined then it is used to configure 
> the filter.
>  ????? * Otherwise, the filter is not configured during initialization and
>  ????? * can be set with {@link #setSerialFilter(ObjectInputFilter) 
> Config.setSerialFilter}.
>  ????? * Setting the {@code jdk.serialFilter} with {@link 
> System#setProperty(String, String)
>  ????? * System.setProperty} does not set the filter.
> 
> Thanks, Roger
> 
> Issue:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8237651
> 
> Webrev:
>  ??? http://cr.openjdk.java.net/~rriggs/webrev-filter-8237651/

From naoto.sato at oracle.com  Fri Jan 24 20:57:12 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 24 Jan 2020 12:57:12 -0800
Subject: [14] 8215361 (doc) Cleanup package-info markup - smartcardio,
 java.sql, java.sql.rowset
In-Reply-To: <0e697c24-41d8-947b-d21b-230f2ef1f4b1@oracle.com>
References: <29b4b553-95d5-539e-10bc-f7793d5f86e7@oracle.com>
 <8c938856-caa7-4536-4064-9b844e632c25@oracle.com>
 <0e697c24-41d8-947b-d21b-230f2ef1f4b1@oracle.com>
Message-ID: <44ce7417-283a-3e52-3fb5-642859d59448@oracle.com>

Looks good. Thank you for the update.

Naoto

On 1/24/20 11:28 AM, Roger Riggs wrote:
> Hi,
> 
> Corrections for the observed flaws:
> 
>  ? http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-2/
> 
> Thanks, Roger
> 
> 
> On 1/23/20 4:08 PM, naoto.sato at oracle.com wrote:
>> Hi Roger,
>>
>> Looks good to me.
>>
>> Although they are in the original src, I would put spaces between 
>> "{@code SerialBlob}" and "class"/"object", at line 50,52 in 
>> javax/sql/rowset/serial/package-info.java
>>
>> Naoto
>>
>> On 1/23/20 12:18 PM, Roger Riggs wrote:
>>> Please review cleanup of package-info.java files use of  -> 
>>> {@code}.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/
>>>
>>> Issue:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8215361
>>>
>>> Thanks, Roger
>>>
> 

From david.holmes at oracle.com  Fri Jan 24 22:34:10 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 25 Jan 2020 08:34:10 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>

On 24/01/2020 7:58 pm, Nick Gasson wrote:
> Hi David,
> 
> On 01/24/20 14:35 pm, David Holmes wrote:
>>>
>>> How about we align the size up to ADDRESS_SIZE (== HeapWordSize) in
>>> Unsafe.allocateMemory() before the call to allocateMemoryChecks(). Like:
>>>
>>>     bytes = ((bytes + ADDRESS_SIZE - 1) & ~(ADDRESS_SIZE - 1));
>>>
>>> Then it will throw an IllegalArgumentException if the result is outside
>>> the size_t range. And in the native code we can just assert that the
>>> `size' argument is already aligned:
>>>
>>>     assert(is_aligned(sz, HeapWordSize), "sz not aligned");
>>
>> That seems quite reasonable.
>>
> 
> I've done this here:
> 
> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
> 
> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
> still throws an IllegalArgumentException.

That looks good to me.

> Tested with jdk_foreign and runtime/Unsafe/.

Probably needs a bit more testing. IIRC the direct buffers use this API 
so they would be a good test subject. Or perhaps Maurizio can run this 
through our CI tier1-3 before pushing?

Thanks,
David

> 
> Thanks,
> Nick
> 

From david.holmes at oracle.com  Fri Jan 24 22:56:07 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 25 Jan 2020 08:56:07 +1000
Subject: Fwd: New candidate JEP: 371: Hidden Classes
In-Reply-To: <20200124210734.D1173315210@eggemoggin.niobe.net>
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
Message-ID: 

FYI.

Cheers,
David
-------------- next part --------------
An embedded message was scrubbed...
From: mark.reinhold at oracle.com
Subject: New candidate JEP: 371: Hidden Classes
Date: Fri, 24 Jan 2020 13:07:34 -0800 (PST)
Size: 3883
URL: 

From brian.burkhalter at oracle.com  Sat Jan 25 02:49:36 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 24 Jan 2020 18:49:36 -0800
Subject: [15] 8219567: One of the RandomAccessFile constructor's parameter is
 not properly named
Message-ID: 

Please review this minor change [1] to address [2]. If it looks worthwhile to address then a CSR will be filed.

Thanks,

Brian

[1] http://cr.openjdk.java.net/~bpb/8219567/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8219567

From ecki at zusammenkunft.net  Sat Jan 25 05:15:32 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 25 Jan 2020 05:15:32 +0000
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: 
References: <20200124210734.D1173315210@eggemoggin.niobe.net>,
 
Message-ID: 

Hello,

I wonder will this (weak class) be useful for reflective method accessors and even be able to reduce/remove the need of jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good example to mention in the JEP (it only mentions Proxies).

(And I was really surprised to see Nashorn mentioned after it is deprecated, even when it is certainly a good Test bed).

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev  im Auftrag von David Holmes 
Gesendet: Friday, January 24, 2020 11:56:07 PM
An: hotspot-dev developers ; core-libs-dev Libs 
Betreff: Fwd: New candidate JEP: 371: Hidden Classes

FYI.

Cheers,
David

From mandy.chung at oracle.com  Sat Jan 25 17:07:23 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 25 Jan 2020 09:07:23 -0800
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: 
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
 
 
Message-ID: 



On 1/24/20 9:15 PM, Bernd Eckenfels wrote:
> Hello,
> 
> I wonder will this (weak class) be useful for reflective method 
> accessors and even be able to reduce/remove the need of 
> jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good 
> example to mention in the JEP (it only mentions Proxies).

The other alternative is to change core reflection to use MethodHandle
where Peter Levart has a prototype:
    https://bugs.openjdk.java.net/browse/JDK-6824466

This would help the reflective support for inline classes and
new VM/language feature such that adding support in MethodHandle
will work both both.

> (And I was really surprised to see Nashorn mentioned after it is 
> deprecated, even when it is certainly a good Test bed).

Yes Roger brought that up too. It can be taken out.

thanks
Mandy

> Gruss
> Bernd
> 
> 
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* core-libs-dev  im Auftrag 
> von David Holmes 
> *Gesendet:* Friday, January 24, 2020 11:56:07 PM
> *An:* hotspot-dev developers ; 
> core-libs-dev Libs 
> *Betreff:* Fwd: New candidate JEP: 371: Hidden Classes
> FYI.
> 
> Cheers,
> David

From mp at jugs.org  Sun Jan 26 12:18:29 2020
From: mp at jugs.org (Michael Paus)
Date: Sun, 26 Jan 2020 13:18:29 +0100
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: 
References: 
Message-ID: <2c71301e-6f68-5111-4084-33f397d74347@jugs.org>

Am 26.01.20 um 13:00 schrieb core-libs-dev-request at openjdk.java.net:
> Message: 1
> Date: Sat, 25 Jan 2020 09:07:23 -0800
> From: Mandy Chung 
> To: Bernd Eckenfels 
> Cc: core-libs-dev Libs 
> Subject: Re: New candidate JEP: 371: Hidden Classes
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> On 1/24/20 9:15 PM, Bernd Eckenfels wrote:
>> Hello,
>>
>> I wonder will this (weak class) be useful for reflective method
>> accessors and even be able to reduce/remove the need of
>> jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good
>> example to mention in the JEP (it only mentions Proxies).
> The other alternative is to change core reflection to use MethodHandle
> where Peter Levart has a prototype:
>      https://bugs.openjdk.java.net/browse/JDK-6824466
>
> This would help the reflective support for inline classes and
> new VM/language feature such that adding support in MethodHandle
> will work both both.

In that case watch out for GraalVM. Native-image does not fully support 
MethodHandles.

See: 
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#invokedynamic-bytecode-and-method-handles


From adinn at redhat.com  Sun Jan 26 17:24:19 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Sun, 26 Jan 2020 17:24:19 +0000
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: <2c71301e-6f68-5111-4084-33f397d74347@jugs.org>
References: 
 <2c71301e-6f68-5111-4084-33f397d74347@jugs.org>
Message-ID: <257b1bc6-d422-5613-f424-7a823fc97abe@redhat.com>

On 26/01/2020 12:18, Michael Paus wrote:
> Am 26.01.20 um 13:00 schrieb core-libs-dev-request at openjdk.java.net:
>> This would help the reflective support for inline classes and
>> new VM/language feature such that adding support in MethodHandle
>> will work both both.
> 
> In that case watch out for GraalVM. Native-image does not fully support
> MethodHandles.
> 
> See:
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#invokedynamic-bytecode-and-method-handles
I think you have put the cart before the horse here. Surely, it is the
Graal project that needs to watch out.

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


From mp at jugs.org  Sun Jan 26 21:31:17 2020
From: mp at jugs.org (Michael Paus)
Date: Sun, 26 Jan 2020 22:31:17 +0100
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: <257b1bc6-d422-5613-f424-7a823fc97abe@redhat.com>
References: 
 <2c71301e-6f68-5111-4084-33f397d74347@jugs.org>
 <257b1bc6-d422-5613-f424-7a823fc97abe@redhat.com>
Message-ID: 

Am 26.01.20 um 18:24 schrieb Andrew Dinn:
> On 26/01/2020 12:18, Michael Paus wrote:
>> Am 26.01.20 um 13:00 schrieb core-libs-dev-request at openjdk.java.net:
>>> This would help the reflective support for inline classes and
>>> new VM/language feature such that adding support in MethodHandle
>>> will work both both.
>> In that case watch out for GraalVM. Native-image does not fully support
>> MethodHandles.
>>
>> See:
>> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#invokedynamic-bytecode-and-method-handles
> I think you have put the cart before the horse here. Surely, it is the
> Graal project that needs to watch out.

If everybody firmly relies on everybody else watching out, then most
certainly nothing can go wrong. Sorry I dared to point out a potential
trouble spot.


From nick.gasson at arm.com  Mon Jan 27 06:41:48 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 27 Jan 2020 14:41:48 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
Message-ID: <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>

Hi David,

On 01/25/20 06:34 am, David Holmes wrote:
>>
>> I've done this here:
>>
>> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
>>
>> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
>> still throws an IllegalArgumentException.
>
> That looks good to me.
>
>> Tested with jdk_foreign and runtime/Unsafe/.
>
> Probably needs a bit more testing. IIRC the direct buffers use this API
> so they would be a good test subject. Or perhaps Maurizio can run this
> through our CI tier1-3 before pushing?
>

I tested again with jdk_core and hotspot_all_no_apps with no new
failures.

Would you or Maurizio mind sponsoring this for me if your testing is OK?


Thanks,
Nick

From thomas.stuefe at gmail.com  Mon Jan 27 08:39:07 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 27 Jan 2020 09:39:07 +0100
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: 
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
 
 
 
Message-ID: 

On Sat, Jan 25, 2020 at 6:09 PM Mandy Chung  wrote:

>
>
> On 1/24/20 9:15 PM, Bernd Eckenfels wrote:
> > Hello,
> >
> > I wonder will this (weak class) be useful for reflective method
> > accessors and even be able to reduce/remove the need of
> > jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good
> > example to mention in the JEP (it only mentions Proxies).
>
> The other alternative is to change core reflection to use MethodHandle
> where Peter Levart has a prototype:
>     https://bugs.openjdk.java.net/browse/JDK-6824466
>
> This would help the reflective support for inline classes and
> new VM/language feature such that adding support in MethodHandle
> will work both both.
>
>
Oh this is neat. We would also save Metaspace since we would not need
accessor classes and their loaders. Also reduces Metaspace fragmentation.

> (And I was really surprised to see Nashorn mentioned after it is
> > deprecated, even when it is certainly a good Test bed).
>
> Yes Roger brought that up too. It can be taken out.
>
> thanks
> Mandy
>
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> > ------------------------------------------------------------------------
> > *Von:* core-libs-dev  im
> Auftrag
> > von David Holmes 
> > *Gesendet:* Friday, January 24, 2020 11:56:07 PM
> > *An:* hotspot-dev developers ;
> > core-libs-dev Libs 
> > *Betreff:* Fwd: New candidate JEP: 371: Hidden Classes
> > FYI.
> >
> > Cheers,
> > David
>

From claes.redestad at oracle.com  Mon Jan 27 09:07:36 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 27 Jan 2020 10:07:36 +0100
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: <2c71301e-6f68-5111-4084-33f397d74347@jugs.org>
References: 
 <2c71301e-6f68-5111-4084-33f397d74347@jugs.org>
Message-ID: 



On 2020-01-26 13:18, Michael Paus wrote:
> Am 26.01.20 um 13:00 schrieb core-libs-dev-request at openjdk.java.net:
>> Message: 1
>> Date: Sat, 25 Jan 2020 09:07:23 -0800
>> From: Mandy Chung 
>>
>> This would help the reflective support for inline classes and
>> new VM/language feature such that adding support in MethodHandle
>> will work both both.
> 
> In that case watch out for GraalVM. Native-image does not fully support 
> MethodHandles.
> 
> See: 
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#invokedynamic-bytecode-and-method-handles 
> 
> 

I think the issue for native-image is to add generic support for
indy/MH, since you can combine these to do all manner of dynamic things,
which makes them very hard to statically reason about in the general
case.

For specific things, like lambdas and this reflection proposal, they can
(and in the case of lambdas already do) desugar the simple and
straightforward indy/MH usage into something that can be statically
compiled.

Their reflection implementation is probably already implemented
differently from the OpenJDK, though, so my guess is that if something
along the lines of Peter's prototype is brought in, they likely won't
need to pick up the changes and native-image users wouldn't notice
anything's changed.

/Claes

From maurizio.cimadamore at oracle.com  Mon Jan 27 10:59:18 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Jan 2020 10:59:18 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
 <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: <764a162e-1e44-0d55-445a-7c591e1f564f@oracle.com>


On 27/01/2020 06:41, Nick Gasson wrote:
> Hi David,
>
> On 01/25/20 06:34 am, David Holmes wrote:
>>> I've done this here:
>>>
>>> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
>>>
>>> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
>>> still throws an IllegalArgumentException.
>> That looks good to me.
>>
>>> Tested with jdk_foreign and runtime/Unsafe/.
>> Probably needs a bit more testing. IIRC the direct buffers use this API
>> so they would be a good test subject. Or perhaps Maurizio can run this
>> through our CI tier1-3 before pushing?
>>
> I tested again with jdk_core and hotspot_all_no_apps with no new
> failures.
>
> Would you or Maurizio mind sponsoring this for me if your testing is OK?

All Mach5 tier1,2,3 tests come up good (I've submitted a job two days ago).

Cheers
Maurizio

>
>
> Thanks,
> Nick

From david.lloyd at redhat.com  Mon Jan 27 13:56:57 2020
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 27 Jan 2020 07:56:57 -0600
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: 
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
 
Message-ID: 

On Fri, Jan 24, 2020 at 4:56 PM David Holmes  wrote:
>
> FYI.

I'm a bit curious about this:

> To invoke private nestmate instance methods from code in the hidden class, use invokevirtual or invokeinterface instead of invokespecial. Generated bytecode that uses invokespecial to invoke a private nestmate instance method will fail verification. invokespecial should only be used to invoke private nestmate constructors.

This seems pretty unusual.  Don't we normally use invokespecial for
private method invocations?  What is the reasoning for this?

-- 
- DML


From forax at univ-mlv.fr  Mon Jan 27 14:31:38 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 27 Jan 2020 15:31:38 +0100 (CET)
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: 
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
 
 
Message-ID: <1721041649.427206.1580135498603.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Lloyd" 
> ?: "David Holmes" 
> Cc: "hotspot-dev" , "core-libs-dev" 
> Envoy?: Lundi 27 Janvier 2020 14:56:57
> Objet: Re: New candidate JEP: 371: Hidden Classes

> On Fri, Jan 24, 2020 at 4:56 PM David Holmes  wrote:
>>
>> FYI.
> 
> I'm a bit curious about this:
> 
>> To invoke private nestmate instance methods from code in the hidden class, use
>> invokevirtual or invokeinterface instead of invokespecial. Generated bytecode
>> that uses invokespecial to invoke a private nestmate instance method will fail
>> verification. invokespecial should only be used to invoke private nestmate
>> constructors.
> 
> This seems pretty unusual.  Don't we normally use invokespecial for
> private method invocations?  What is the reasoning for this?

It's the new usual since 11 and the introduction of nestmates,
before javac was generating an accessor method (the access$000 methods).

class Foo {
  private void privateMethod() {
  }

  public static class Bar {
    public void m() {
      new Foo().privateMethod();
    }
  }

  public static void main(String[] args) {
    new Bar().m();
  }
}

The bytecode of 'm()' is

public void m();
    Code:
       0: new           #7                  // class Foo
       3: dup
       4: invokespecial #9                  // Method Foo."":()V
       7: invokevirtual #10                 // Method Foo.privateMethod:()V
      10: return

When calling a method (this is different for constructor),  invokespecial semantics has no been extended to be able to call private method of classes of the same nest, only invokevirtual/invokeinterface and invokestatic have that capability. 

The reason is that invokespecial semantics is already a patchwork of several semantics, you can call a constructor, a private method of the same class and a method of the super class and each semantics has it's own verification rule.
Given that invokevirtual already had to be extended, adding a new mode for invokespecial was not necessary.

As a trivia, if you take a look to the dex file used by Android, the opcode invokespecial doesn't exist, instead you have several other opcodes, one for each semantics.

> 
> --
> - DML

R?mi

From naoto.sato at oracle.com  Mon Jan 27 17:09:42 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 27 Jan 2020 09:09:42 -0800
Subject: [15] 8219567: One of the RandomAccessFile constructor's parameter
 is not properly named
In-Reply-To: 
References: 
Message-ID: <541ae61b-6bbb-f01a-53a0-daf5975e99ba@oracle.com>

LGTM.

Naoto

On 1/24/20 6:49 PM, Brian Burkhalter wrote:
> Please review this minor change [1] to address [2]. If it looks worthwhile to address then a CSR will be filed.
> 
> Thanks,
> 
> Brian
> 
> [1] http://cr.openjdk.java.net/~bpb/8219567/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8219567
> 

From mandy.chung at oracle.com  Mon Jan 27 18:29:51 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 27 Jan 2020 10:29:51 -0800
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: <1721041649.427206.1580135498603.JavaMail.zimbra@u-pem.fr>
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
 
 
 <1721041649.427206.1580135498603.JavaMail.zimbra@u-pem.fr>
Message-ID: <76d55980-1e9e-5f3c-1340-6784448496c1@oracle.com>



On 1/27/20 6:31 AM, Remi Forax wrote:
>> I'm a bit curious about this:
>>
>>> To invoke private nestmate instance methods from code in the hidden class, use
>>> invokevirtual or invokeinterface instead of invokespecial. Generated bytecode
>>> that uses invokespecial to invoke a private nestmate instance method will fail
>>> verification. invokespecial should only be used to invoke private nestmate
>>> constructors.
>> This seems pretty unusual.  Don't we normally use invokespecial for
>> private method invocations?  What is the reasoning for this?
> It's the new usual since 11 and the introduction of nestmates,
> before javac was generating an accessor method (the access$000 methods).
>
> :
>

As Remi said, this feature has been there since 11.? You can reference 
JEP 181 for more details.

Mandy
[1] https://openjdk.java.net/jeps/181


From david.lloyd at redhat.com  Mon Jan 27 19:58:25 2020
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 27 Jan 2020 13:58:25 -0600
Subject: New candidate JEP: 371: Hidden Classes
In-Reply-To: <76d55980-1e9e-5f3c-1340-6784448496c1@oracle.com>
References: <20200124210734.D1173315210@eggemoggin.niobe.net>
 
 
 <1721041649.427206.1580135498603.JavaMail.zimbra@u-pem.fr>
 <76d55980-1e9e-5f3c-1340-6784448496c1@oracle.com>
Message-ID: 

On Mon, Jan 27, 2020 at 12:30 PM Mandy Chung  wrote:
>
>
>
> On 1/27/20 6:31 AM, Remi Forax wrote:
>
> I'm a bit curious about this:
>
> To invoke private nestmate instance methods from code in the hidden class, use
> invokevirtual or invokeinterface instead of invokespecial. Generated bytecode
> that uses invokespecial to invoke a private nestmate instance method will fail
> verification. invokespecial should only be used to invoke private nestmate
> constructors.
>
> This seems pretty unusual.  Don't we normally use invokespecial for
> private method invocations?  What is the reasoning for this?
>
> It's the new usual since 11 and the introduction of nestmates,
> before javac was generating an accessor method (the access$000 methods).
>
> :
>
>
>
> As Remi said, this feature has been there since 11.  You can reference JEP 181 for more details.
>
> Mandy
> [1] https://openjdk.java.net/jeps/181

This is very helpful, thanks!
-- 
- DML


From sean.mullan at oracle.com  Mon Jan 27 20:17:27 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 27 Jan 2020 15:17:27 -0500
Subject: [14] RFR (doc) 8237651 Clarify initialization of jdk.serialFilter
In-Reply-To: <2a07ddb1-7c7b-ba7d-5fa1-5e8120221106@oracle.com>
References: <2a07ddb1-7c7b-ba7d-5fa1-5e8120221106@oracle.com>
Message-ID: <9d9baf0a-1542-6b5e-f50a-c2061b685ed2@oracle.com>

Hi Roger,

Does setting jdk.serialFilter with Security.setProperty() work, or must 
it only be pre-configured in the java.security file?

--Sean

On 1/24/20 2:51 PM, Roger Riggs wrote:
> Please review a doc change in the description of the initialization of 
> the jdk.serialFilter from
> a system property to generalize it beyond only command line invocation.
>
> diff a/src/java.base/share/classes/java/io/ObjectInputFilter.java 
> b/src/java.base/share/classes/java/io/ObjectInputFilter.java
> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java
> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java
> @@ -204,15 +204,14 @@
> ????? * When setting the filter, it should be stateless and idempotent,
> ????? * reporting the same result when passed the same arguments.
> ????? * 
    
> ????? * The filter is configured during the initialization of the 
> {@code ObjectInputFilter.Config}
> ????? * class. For example, by calling {@link #getSerialFilter() 
> Config.getSerialFilter}.
> -???? * If the system property {@systemProperty jdk.serialFilter} is 
> defined on the command line,
> -???? * it is used to configure the filter.
> -???? * If the system property is not defined on the command line, and 
> the
> -???? * {@link java.security.Security} property {@code 
> jdk.serialFilter} is defined
> -???? * then it is used to configure the filter.
> +???? * If the Java virtual machine is started with the system property
> +???? * {@systemProperty jdk.serialFilter}, its value is used to 
> configure the filter.
> +???? * If the system property is not defined, and the {@link 
> java.security.Security} property
> +???? * {@code jdk.serialFilter} is defined then it is used to 
> configure the filter.
> ????? * Otherwise, the filter is not configured during initialization and
> ????? * can be set with {@link #setSerialFilter(ObjectInputFilter) 
> Config.setSerialFilter}.
> ????? * Setting the {@code jdk.serialFilter} with {@link 
> System#setProperty(String, String)
> ????? * System.setProperty} does not set the filter.
>
> Thanks, Roger
>
> Issue:
> ?? https://bugs.openjdk.java.net/browse/JDK-8237651
>
> Webrev:
> ??? http://cr.openjdk.java.net/~rriggs/webrev-filter-8237651/

From alexander.matveev at oracle.com  Mon Jan 27 23:00:55 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 27 Jan 2020 15:00:55 -0800
Subject: RFR: JDK-8235954: [dmg] Default DMG background tiff of jpackage not
 retina ready
Message-ID: <0c0cd924-679e-f6cb-b4c9-c615504fe70b@oracle.com>

Please review the jpackage fix for bug [1] at [2].

- Updated background image with one which supports retina display.

[1] https://bugs.openjdk.java.net/browse/JDK-8235954

[2] http://cr.openjdk.java.net/~almatvee/8235954/webrev.00/

Thanks,
Alexander

From alexey.semenyuk at oracle.com  Tue Jan 28 00:14:06 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 27 Jan 2020 19:14:06 -0500
Subject: RFR: JDK-8235954: [dmg] Default DMG background tiff of jpackage
 not retina ready
In-Reply-To: <0c0cd924-679e-f6cb-b4c9-c615504fe70b@oracle.com>
References: <0c0cd924-679e-f6cb-b4c9-c615504fe70b@oracle.com>
Message-ID: <9b616b11-4e2a-5810-2b0d-95594b7d77be@oracle.com>

Looks good.

- Alexey

On 1/27/2020 6:00 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Updated background image with one which supports retina display.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8235954
>
> [2] http://cr.openjdk.java.net/~almatvee/8235954/webrev.00/
>
> Thanks,
> Alexander


From andy.herrick at oracle.com  Tue Jan 28 01:43:09 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 27 Jan 2020 20:43:09 -0500
Subject: RFR: JDK-8235954: [dmg] Default DMG background tiff of jpackage
 not retina ready
In-Reply-To: <0c0cd924-679e-f6cb-b4c9-c615504fe70b@oracle.com>
References: <0c0cd924-679e-f6cb-b4c9-c615504fe70b@oracle.com>
Message-ID: <691bd74a-e8f8-7750-2b95-a2eec15c8e46@oracle.com>

looks good.

/Andy

On 1/27/2020 6:00 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Updated background image with one which supports retina display.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8235954
>
> [2] http://cr.openjdk.java.net/~almatvee/8235954/webrev.00/
>
> Thanks,
> Alexander

From sean.coffey at oracle.com  Tue Jan 28 13:13:43 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 28 Jan 2020 13:13:43 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
Message-ID: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>

Looks like we can improve performance in this area. I've put together a 
testcase which exercises the ServiceLoader and keeps track of whether 
we're able to cache or not.

https://bugs.openjdk.java.net/browse/JDK-8223260
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/

regards,
Sean.


From Roger.Riggs at oracle.com  Tue Jan 28 14:59:50 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 28 Jan 2020 09:59:50 -0500
Subject: [14] RFR (doc) 8237651 Clarify initialization of jdk.serialFilter
In-Reply-To: <9d9baf0a-1542-6b5e-f50a-c2061b685ed2@oracle.com>
References: <2a07ddb1-7c7b-ba7d-5fa1-5e8120221106@oracle.com>
 <9d9baf0a-1542-6b5e-f50a-c2061b685ed2@oracle.com>
Message-ID: <4d5a9677-61fe-6491-c4f0-579048b9d6f8@oracle.com>

Hi Sean,

On 1/27/20 3:17 PM, Sean Mullan wrote:
> Hi Roger,
>
> Does setting jdk.serialFilter with Security.setProperty() work, or 
> must it only be pre-configured in the java.security file?
Assuming the System property is not defined, then setting the Security 
property
with Security.setProperty before the ObjectInputFilter.Config class is 
initialized will affect the filter defined.

Thanks, Roger


>
> --Sean
>
> On 1/24/20 2:51 PM, Roger Riggs wrote:
>> Please review a doc change in the description of the initialization 
>> of the jdk.serialFilter from
>> a system property to generalize it beyond only command line invocation.
>>
>> diff a/src/java.base/share/classes/java/io/ObjectInputFilter.java 
>> b/src/java.base/share/classes/java/io/ObjectInputFilter.java
>> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java
>> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java
>> @@ -204,15 +204,14 @@
>> ????? * When setting the filter, it should be stateless and idempotent,
>> ????? * reporting the same result when passed the same arguments.
>> ????? * 
    
>> ????? * The filter is configured during the initialization of the 
>> {@code ObjectInputFilter.Config}
>> ????? * class. For example, by calling {@link #getSerialFilter() 
>> Config.getSerialFilter}.
>> -???? * If the system property {@systemProperty jdk.serialFilter} is 
>> defined on the command line,
>> -???? * it is used to configure the filter.
>> -???? * If the system property is not defined on the command line, 
>> and the
>> -???? * {@link java.security.Security} property {@code 
>> jdk.serialFilter} is defined
>> -???? * then it is used to configure the filter.
>> +???? * If the Java virtual machine is started with the system property
>> +???? * {@systemProperty jdk.serialFilter}, its value is used to 
>> configure the filter.
>> +???? * If the system property is not defined, and the {@link 
>> java.security.Security} property
>> +???? * {@code jdk.serialFilter} is defined then it is used to 
>> configure the filter.
>> ????? * Otherwise, the filter is not configured during initialization 
>> and
>> ????? * can be set with {@link #setSerialFilter(ObjectInputFilter) 
>> Config.setSerialFilter}.
>> ????? * Setting the {@code jdk.serialFilter} with {@link 
>> System#setProperty(String, String)
>> ????? * System.setProperty} does not set the filter.
>>
>> Thanks, Roger
>>
>> Issue:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8237651
>>
>> Webrev:
>> ??? http://cr.openjdk.java.net/~rriggs/webrev-filter-8237651/


From Alan.Bateman at oracle.com  Tue Jan 28 19:29:43 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Jan 2020 19:29:43 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
Message-ID: <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>

On 28/01/2020 13:13, Se?n Coffey wrote:
> Looks like we can improve performance in this area. I've put together 
> a testcase which exercises the ServiceLoader and keeps track of 
> whether we're able to cache or not.
>
> https://bugs.openjdk.java.net/browse/JDK-8223260
> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
A WeakHashKey with the TCCL as the key should be okay here. It might be 
cleaner to move the adding to the map to after the two lookups so that 
it's one place rather than two.? ServiceLoader has a stream method so 
the while could be replaced to improve the readability but that is 
probably beyond what you want to do on this issue.

In the test it will spin calling System.gc. Can you put the System.gc() 
before the while lookup and just Thread.sleep(100) instead. There may be 
something in the test infrastructure libs that could use if you want.

-Alan.

From david.holmes at oracle.com  Tue Jan 28 23:31:17 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Jan 2020 09:31:17 +1000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
 <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
Message-ID: <81903083-17d1-9816-bd51-22bff460bf15@oracle.com>

Hi Nick,

On 27/01/2020 4:41 pm, Nick Gasson wrote:
> Hi David,
> 
> On 01/25/20 06:34 am, David Holmes wrote:
>>>
>>> I've done this here:
>>>
>>> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
>>>
>>> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
>>> still throws an IllegalArgumentException.
>>
>> That looks good to me.
>>
>>> Tested with jdk_foreign and runtime/Unsafe/.
>>
>> Probably needs a bit more testing. IIRC the direct buffers use this API
>> so they would be a good test subject. Or perhaps Maurizio can run this
>> through our CI tier1-3 before pushing?
>>
> 
> I tested again with jdk_core and hotspot_all_no_apps with no new
> failures.
> 
> Would you or Maurizio mind sponsoring this for me if your testing is OK?

Sorry, as the bulk of this change is core-libs code you'll need to find 
a core-libs sponsor.

David

> 
> Thanks,
> Nick
> 

From stuart.marks at oracle.com  Tue Jan 28 23:41:02 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 28 Jan 2020 15:41:02 -0800
Subject: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be
 clarified
Message-ID: <79eda482-2708-699f-51f2-9f5e642d5d58@oracle.com>

Hi all,

I was looking through the bug database and I got nerd-sniped this bug report, 
which requests clarifying a comment in IdentityHashMap. Once I figured out what 
was going on, I decided I might as well just go ahead and fix it.

This changeset improves (I hope) the comment in the IdentityHashSet.hash() 
method. In addition, I've also clarified the note in the class documentation to 
make the keys/values at even/odd indexes arrangement in the array more explicit, 
which has also been a source of some confusion.

This changes only non-normative portions of the specification, so I don't 
believe a CSR is necessary.

As an aside, I don't know whether the linear-probing (open addressed) 
arrangement of IdentityHashMap is in fact faster than the separate chaining 
approach of HashMap. Perhaps investigating that could be a side project for someone.

Changeset appended below.

Bug: https://bugs.openjdk.java.net/browse/JDK-8046362

Thanks,

s'marks



# HG changeset patch
# User smarks
# Date 1580167577 28800
#      Mon Jan 27 15:26:17 2020 -0800
# Node ID 0e08ce23484ca42597105225ffa3dd0827cb4b60
# Parent  981f6982717a7df4a2a43dd0ae6b2c2389e683f9
8046362: IdentityHashMap.hash comments should be clarified
Reviewed-by: XXX

diff -r 981f6982717a -r 0e08ce23484c 
src/java.base/share/classes/java/util/IdentityHashMap.java
--- a/src/java.base/share/classes/java/util/IdentityHashMap.java	Mon Jan 27 
14:03:58 2020 -0800
+++ b/src/java.base/share/classes/java/util/IdentityHashMap.java	Mon Jan 27 
15:26:17 2020 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2000, 2020, 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
@@ -115,17 +115,19 @@
   * exception for its correctness: fail-fast iterators should be used only
   * to detect bugs.
   *
- * 
    Implementation note: This is a simple linear-probe hash table,
- * as described for example in texts by Sedgewick and Knuth.  The array
- * alternates holding keys and values.  (This has better locality for large
- * tables than does using separate arrays.)  For many JRE implementations
- * and operation mixes, this class will yield better performance than
- * {@link HashMap} (which uses chaining rather than linear-probing).
- *
   * 
    This class is a member of the
   * 
   * Java Collections Framework.
   *
+ * @implNote
+ * 
    This is a simple linear-probe hash table,
+ * as described for example in texts by Sedgewick and Knuth.  The array
+ * contains alternating keys and values, with keys at even indexes and values
+ * at odd indexes. (This arrangement has better locality for large
+ * tables than does using separate arrays.)  For many JRE implementations
+ * and operation mixes, this class will yield better performance than
+ * {@link HashMap}, which uses chaining rather than linear-probing.
+ *
   * @see     System#identityHashCode(Object)
   * @see     Object#hashCode()
   * @see     Collection
@@ -293,7 +295,7 @@
       */
      private static int hash(Object x, int length) {
          int h = System.identityHashCode(x);
-        // Multiply by -127, and left-shift to use least bit as part of hash
+        // Multiply by -254 to use the hash LSB and to ensure index is even
          return ((h << 1) - (h << 8)) & (length - 1);
      }



From daniel.fuchs at oracle.com  Wed Jan 29 15:55:21 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jan 2020 15:55:21 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
Message-ID: <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>

Hi Se?n,

> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
> A WeakHashKey with the TCCL as the key should be okay here.

If the TCCL is the key then there are good chances that the
concrete factory class is expected to be loaded by the TCCL.

If that happens then the value will reference the key and
nothing will ever get garbage collected.

So if I'm reading things rights this will not work as expected?

best regards,

-- daniel

From Alan.Bateman at oracle.com  Wed Jan 29 16:27:51 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jan 2020 16:27:51 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
Message-ID: <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>

On 29/01/2020 15:55, Daniel Fuchs wrote:
> Hi Se?n,
>
>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
>> A WeakHashKey with the TCCL as the key should be okay here.
>
> If the TCCL is the key then there are good chances that the
> concrete factory class is expected to be loaded by the TCCL.
>
> If that happens then the value will reference the key and
> nothing will ever get garbage collected.
I don't know how much JNDI is used much beyond LDAP these days but you 
are right that a factory with a strong ref to the TCCL would prevent it 
from being GC'ed.? The internal WeakPairMap might be useful here.

-Alan

From maurizio.cimadamore at oracle.com  Wed Jan 29 16:32:18 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Jan 2020 16:32:18 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <81903083-17d1-9816-bd51-22bff460bf15@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
 <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <81903083-17d1-9816-bd51-22bff460bf15@oracle.com>
Message-ID: <51b68fae-fff1-0ee8-c521-8ad6ede6e17a@oracle.com>


On 28/01/2020 23:31, David Holmes wrote:
> Hi Nick,
>
> On 27/01/2020 4:41 pm, Nick Gasson wrote:
>> Hi David,
>>
>> On 01/25/20 06:34 am, David Holmes wrote:
>>>>
>>>> I've done this here:
>>>>
>>>> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
>>>>
>>>> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
>>>> still throws an IllegalArgumentException.
>>>
>>> That looks good to me.
>>>
>>>> Tested with jdk_foreign and runtime/Unsafe/.
>>>
>>> Probably needs a bit more testing. IIRC the direct buffers use this API
>>> so they would be a good test subject. Or perhaps Maurizio can run this
>>> through our CI tier1-3 before pushing?
>>>
>>
>> I tested again with jdk_core and hotspot_all_no_apps with no new
>> failures.
>>
>> Would you or Maurizio mind sponsoring this for me if your testing is OK?
>
> Sorry, as the bulk of this change is core-libs code you'll need to 
> find a core-libs sponsor.

Since I'm the one who wrote the core-libs part of the memory access API 
- I think that should be enough :-) ?

I'm happy to sponsor, until somebody has objections.

Maurizio

>
> David
>
>>
>> Thanks,
>> Nick
>>

From sean.coffey at oracle.com  Wed Jan 29 17:22:38 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 29 Jan 2020 17:22:38 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
 <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
Message-ID: <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>

Thanks for the reviews. I found an issue with the new test also -

it's loading the custom factory class via the non-serviceloader 
approach. I was hoping to exercise ServiceLoader here. I'll address this 
and the comments raised and revert with a new patch shortly.

Regards,
Sean.

On 29/01/20 16:27, Alan Bateman wrote:
> On 29/01/2020 15:55, Daniel Fuchs wrote:
>> Hi Se?n,
>>
>>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
>>> A WeakHashKey with the TCCL as the key should be okay here.
>>
>> If the TCCL is the key then there are good chances that the
>> concrete factory class is expected to be loaded by the TCCL.
>>
>> If that happens then the value will reference the key and
>> nothing will ever get garbage collected.
> I don't know how much JNDI is used much beyond LDAP these days but you 
> are right that a factory with a strong ref to the TCCL would prevent 
> it from being GC'ed.  The internal WeakPairMap might be useful here.
>
> -Alan


From mandy.chung at oracle.com  Wed Jan 29 17:55:31 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 29 Jan 2020 09:55:31 -0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <51b68fae-fff1-0ee8-c521-8ad6ede6e17a@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
 <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <81903083-17d1-9816-bd51-22bff460bf15@oracle.com>
 <51b68fae-fff1-0ee8-c521-8ad6ede6e17a@oracle.com>
Message-ID: 



On 1/29/20 8:32 AM, Maurizio Cimadamore wrote:
>
> On 28/01/2020 23:31, David Holmes wrote:
>>> I tested again with jdk_core and hotspot_all_no_apps with no new
>>> failures.
>>>
>>> Would you or Maurizio mind sponsoring this for me if your testing is 
>>> OK?
>>
>> Sorry, as the bulk of this change is core-libs code you'll need to 
>> find a core-libs sponsor.
>
> Since I'm the one who wrote the core-libs part of the memory access 
> API - I think that should be enough :-) ?

Yes, of course.?? This patch is specific to the memory access API and 
unsafe.? You can also count me as the reviewer.

>
> I'm happy to sponsor, until somebody has objections.

No objection.? Thank you for doing that.

Mandy

From andy.herrick at oracle.com  Wed Jan 29 18:34:35 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 29 Jan 2020 13:34:35 -0500
Subject: RFR: JDK-8238168: Remove Copyright from WinLauncher.template
Message-ID: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>

Please review trivial jpackage fix to [1] at [2]

[1] https://bugs.openjdk.java.net/browse/JDK-8238168

[2] http://cr.openjdk.java.net/~herrick/8238168/webrev.01/


/Andy


From kevin.rushforth at oracle.com  Wed Jan 29 18:39:06 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 29 Jan 2020 10:39:06 -0800
Subject: RFR: JDK-8238168: Remove Copyright from WinLauncher.template
In-Reply-To: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>
References: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>
Message-ID: <8cd19e90-a424-8664-496f-d07de3daec60@oracle.com>

Looks good.

+1

-- Kevin

On 1/29/2020 10:34 AM, Andy Herrick wrote:
> Please review trivial jpackage fix to [1] at [2]
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8238168
>
> [2] http://cr.openjdk.java.net/~herrick/8238168/webrev.01/
>
>
> /Andy
>


From alexey.semenyuk at oracle.com  Wed Jan 29 18:57:42 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 29 Jan 2020 13:57:42 -0500
Subject: RFR: JDK-8238168: Remove Copyright from WinLauncher.template
In-Reply-To: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>
References: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>
Message-ID: <198b56ef-1681-eac0-bb32-930d371b6335@oracle.com>

Looks good.

- Alexey

On 1/29/2020 1:34 PM, Andy Herrick wrote:
> Please review trivial jpackage fix to [1] at [2]
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8238168
>
> [2] http://cr.openjdk.java.net/~herrick/8238168/webrev.01/
>
>
> /Andy
>


From philip.race at oracle.com  Wed Jan 29 19:01:43 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 29 Jan 2020 11:01:43 -0800
Subject: RFR: JDK-8238168: Remove Copyright from WinLauncher.template
In-Reply-To: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>
References: <017b79db-263d-5bee-dc29-1920c856b122@oracle.com>
Message-ID: <5E31D697.3000301@oracle.com>

+1

-phil.

On 1/29/20, 10:34 AM, Andy Herrick wrote:
> Please review trivial jpackage fix to [1] at [2]
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8238168
>
> [2] http://cr.openjdk.java.net/~herrick/8238168/webrev.01/
>
>
> /Andy
>

From alexander.matveev at oracle.com  Wed Jan 29 21:02:16 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 29 Jan 2020 13:02:16 -0800
Subject: RFR: 8233166: jpackage tool skips empty directories
Message-ID: 

Please review the jpackage fix for bug [1] at [2].

- Fixed code which enumerates folders and files to include empty folders.
- Added EmptyFolderTest.

[1] https://bugs.openjdk.java.net/browse/JDK-8233166

[2] http://cr.openjdk.java.net/~almatvee/8233166/webrev.00/

Thanks,
Alexander

From alexey.semenyuk at oracle.com  Wed Jan 29 21:15:32 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 29 Jan 2020 16:15:32 -0500
Subject: RFR: 8233166: jpackage tool skips empty directories
In-Reply-To: 
References: 
Message-ID: 

I guess we need tests for empty folders in packages on all platforms. 
They can be a part of the fix or a follow up CR. Whatever your prefer.

- Alexey

On 1/29/2020 4:02 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Fixed code which enumerates folders and files to include empty folders.
> - Added EmptyFolderTest.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233166
>
> [2] http://cr.openjdk.java.net/~almatvee/8233166/webrev.00/
>
> Thanks,
> Alexander


From andy.herrick at oracle.com  Wed Jan 29 21:36:42 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 29 Jan 2020 16:36:42 -0500
Subject: RFR: 8233166: jpackage tool skips empty directories
In-Reply-To: 
References: 
Message-ID: 

looks good.

/Andy

On 1/29/2020 4:02 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - Fixed code which enumerates folders and files to include empty folders.
> - Added EmptyFolderTest.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233166
>
> [2] http://cr.openjdk.java.net/~almatvee/8233166/webrev.00/
>
> Thanks,
> Alexander

From leventov.ru at gmail.com  Thu Jan 30 05:56:35 2020
From: leventov.ru at gmail.com (Roman Leventov)
Date: Thu, 30 Jan 2020 08:56:35 +0300
Subject: ZoneRules.of() implies that transitionList is a superset of
 standardOffsetTransitionList but doesn't check that
Message-ID: 

1) ZoneRules.of() implies that transitionList is a superset of
standardOffsetTransitionList but doesn't check that. Then it's possible to
construct ZoneRules instances that don't work correctly:
    @Test
    public void zoneRulesTest() {
        LocalDateTime transitionDay = LocalDateTime.of(2020, 1, 1, 2, 0);
        ZoneOffsetTransition trans = ZoneOffsetTransition.of(
                transitionDay,
                ZoneOffset.ofHours(1),
                ZoneOffset.ofHours(2)
        );
        ZoneRules rules = ZoneRules.of(ZoneOffset.ofHours(1),
ZoneOffset.ofHours(1),
                Arrays.asList(trans),
                Collections.emptyList(), Collections.emptyList());

        Assert.assertEquals(ZoneOffset.ofHours(2), rules.getOffset(
                transitionDay.plusDays(7).toInstant(ZoneOffset.UTC)));
    }

2) Unrelated issue in java-time code: in ZoneOffsetTransitionRule, there is
a typo, some variables are called "timeDefnition" (missed "i") and it leaks
to public Javadoc.

From peter.levart at gmail.com  Thu Jan 30 07:59:58 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jan 2020 08:59:58 +0100
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
 <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
 <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>
Message-ID: <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>

Hi Se?n,

WeakHashMap is not safe to be called concurrently. Even get() method, 
although it may seem read-only, can modify internal state (expunging 
stale Weak entries), so holding a READ lock while accessing WeakHashMap 
it is wrong.

getInitialContext() static method is called with an env Hashtable which 
means it can be called with different keys/values for the same TCCL. So 
caching of InitialContextFactory is just performed for the 1st call for 
a particular TCCL. Subsequent calls for the same TCCL and different 
class names are not cached. Is this the behavior you are pursuing? You 
could cache the factory using (TCCL, class name) as a compound key.

Also, by caching in a WeakHashMap, 
you make a strong reference to InitialContextFactory from class loader 
of the NamingManager.class and such InitialContextFactory may indirectly 
reference the ClassLoader key of the same entry, so it will never go 
away because NamingManager class is never going away. You should at 
least use a WeakHashMap> for that.

Shameless plug: there is a JDK internal class 
jdk.internal.loader.ClassLoaderValue which you might be able to use for 
caching if a part of your key is a ClassLoader. From the javadoc:

 ?* ClassLoaderValue allows associating a
 ?* {@link #computeIfAbsent(ClassLoader, BiFunction) computed} non-null 
value with
 ?* a {@code (ClassLoader, keys...)} tuple. The associated value, as 
well as the
 ?* keys are strongly reachable from the associated ClassLoader so care 
should be
 ?* taken to use such keys and values that only reference types 
resolvable from
 ?* the associated ClassLoader. Failing that, ClassLoader leaks are 
inevitable.

So if you know that the InitialContextFactory instance is always 
resolvable (by class name) from the ClassLoader you are using for the 
caching key (the TCCL), then this utility might be just right for your 
purpose.

Regards, Peter


On 1/29/20 6:22 PM, Se?n Coffey wrote:
> Thanks for the reviews. I found an issue with the new test also -
>
> it's loading the custom factory class via the non-serviceloader 
> approach. I was hoping to exercise ServiceLoader here. I'll address 
> this and the comments raised and revert with a new patch shortly.
>
> Regards,
> Sean.
>
> On 29/01/20 16:27, Alan Bateman wrote:
>> On 29/01/2020 15:55, Daniel Fuchs wrote:
>>> Hi Se?n,
>>>
>>>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
>>>> A WeakHashKey with the TCCL as the key should be okay here.
>>>
>>> If the TCCL is the key then there are good chances that the
>>> concrete factory class is expected to be loaded by the TCCL.
>>>
>>> If that happens then the value will reference the key and
>>> nothing will ever get garbage collected.
>> I don't know how much JNDI is used much beyond LDAP these days but 
>> you are right that a factory with a strong ref to the TCCL would 
>> prevent it from being GC'ed.? The internal WeakPairMap might be 
>> useful here.
>>
>> -Alan
>


From peter.levart at gmail.com  Thu Jan 30 08:56:15 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jan 2020 09:56:15 +0100
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
 <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
 <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>
 <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>
Message-ID: <6087ec94-5107-0d4d-a11f-7373da850c29@gmail.com>



On 1/30/20 8:59 AM, Peter Levart wrote:
> So if you know that the (implementation class of) 
> InitialContextFactory instance is always resolvable (by class name) 
> from the ClassLoader you are using for the caching key (the TCCL), 
> then this utility might be just right for your purpose.

Thinking of the above, your code may obtain the InitialContextFactory 
via two mechanicms:

a) via ServiceLoader.load(InitialContextFactory.class)
b) via the VersionHelper.loadClass(className)


In case of a, the TCCL is used to load the implementation class by the 
ServiceLoader spec:

 ???? * Creates a new service loader for the given service type, using the
 ???? * current thread's {@linkplain java.lang.Thread#getContextClassLoader
 ???? * context class loader}.

In case TCCL is null, the system class loader is tried and failing that, 
bootstrap class loader.

In case of b, the TCCL is used too, if it is set to a non-null value. 
Else the system class loader is used.


So in both cases you should be safe to use the system class loader 
returned from ClassLoader.getSystemClassLoader() if TCCL is null as a 
key for caching and the InitialContextFactory implementation class will 
be resolvable from such key ClassLoader.

Regards, Peter


From maurizio.cimadamore at oracle.com  Thu Jan 30 15:57:18 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 30 Jan 2020 15:57:18 +0000
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: 
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
 <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <81903083-17d1-9816-bd51-22bff460bf15@oracle.com>
 <51b68fae-fff1-0ee8-c521-8ad6ede6e17a@oracle.com>
 
Message-ID: <79d12e80-e0db-f6f1-5bd0-d3f1845eb4a8@oracle.com>

Pushed to jdk/jdk

Thanks
Maurizio

On 29/01/2020 17:55, Mandy Chung wrote:
>
>
> On 1/29/20 8:32 AM, Maurizio Cimadamore wrote:
>>
>> On 28/01/2020 23:31, David Holmes wrote:
>>>> I tested again with jdk_core and hotspot_all_no_apps with no new
>>>> failures.
>>>>
>>>> Would you or Maurizio mind sponsoring this for me if your testing 
>>>> is OK?
>>>
>>> Sorry, as the bulk of this change is core-libs code you'll need to 
>>> find a core-libs sponsor.
>>
>> Since I'm the one who wrote the core-libs part of the memory access 
>> API - I think that should be enough :-) ?
>
> Yes, of course.?? This patch is specific to the memory access API and 
> unsafe.? You can also count me as the reviewer.
>
>>
>> I'm happy to sponsor, until somebody has objections.
>
> No objection.? Thank you for doing that.
>
> Mandy

From nick.gasson at arm.com  Fri Jan 31 01:57:29 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Fri, 31 Jan 2020 09:57:29 +0800
Subject: RFR: 8237521: Memory Access API fixes for 32-bit
In-Reply-To: <79d12e80-e0db-f6f1-5bd0-d3f1845eb4a8@oracle.com>
References: <437dcd23-d912-bd25-1a4b-a793b67371f6@arm.com>
 <85y2ty1wgg.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 
 <200d4d5a-9459-8414-40a1-dbfe0215d740@oracle.com>
 <85wo9i1tyl.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <377ac9c4-df00-092c-9df0-13334f4d1341@oracle.com>
 <7bc12e1b-0c8c-89de-60b0-54b71e2acb40@redhat.com>
 <542a6cb5-d6d9-e6cd-88b4-71022460c02a@oracle.com>
 
 <662e3349-7064-2bc9-6995-a4589a32b037@oracle.com>
 <85v9p11kss.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <54954f6b-8166-c033-41b1-444bc364bb58@oracle.com>
 <85tv4l18gy.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <068a99bc-1141-9c37-8d6e-c36c423ed2c3@oracle.com>
 <85sgk11jv7.fsf@nicgas01-03-arm-vm.shanghai.arm.com>
 <81903083-17d1-9816-bd51-22bff460bf15@oracle.com>
 <51b68fae-fff1-0ee8-c521-8ad6ede6e17a@oracle.com>
 
 <79d12e80-e0db-f6f1-5bd0-d3f1845eb4a8@oracle.com>
Message-ID: 

On 30/01/2020 23:57, Maurizio Cimadamore wrote:
> Pushed to jdk/jdk
> 

Great, thanks for your help!


Nick

From sean.coffey at oracle.com  Fri Jan 31 13:16:10 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 31 Jan 2020 13:16:10 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
 <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
 <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>
 <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>
Message-ID: <6a923a69-c8f1-2d6b-ff64-2ba53ad0d483@oracle.com>

Thanks for the review Peter. All good points! My latest patch contains 
adjustments based on feedback from you and others to date.

* Incorporate use of ClassLoaderValue -
 ?-- I'd appreciate feedback on whether I'm using it correctly.
* Use of ServiceLoader.stream()
* adjusted test for both the ServiceLoader and legacy classpath load 
approach
* insert use of sleep which testing GC.

http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/

regards,
Sean.

On 30/01/2020 07:59, Peter Levart wrote:
> Hi Se?n,
>
> WeakHashMap is not safe to be called concurrently. Even get() method, 
> although it may seem read-only, can modify internal state (expunging 
> stale Weak entries), so holding a READ lock while accessing 
> WeakHashMap it is wrong.
>
> getInitialContext() static method is called with an env Hashtable 
> which means it can be called with different keys/values for the same 
> TCCL. So caching of InitialContextFactory is just performed for the 
> 1st call for a particular TCCL. Subsequent calls for the same TCCL and 
> different class names are not cached. Is this the behavior you are 
> pursuing? You could cache the factory using (TCCL, class name) as a 
> compound key.
>
> Also, by caching in a WeakHashMap, 
> you make a strong reference to InitialContextFactory from class loader 
> of the NamingManager.class and such InitialContextFactory may 
> indirectly reference the ClassLoader key of the same entry, so it will 
> never go away because NamingManager class is never going away. You 
> should at least use a WeakHashMap WeakReference> for that.
>
> Shameless plug: there is a JDK internal class 
> jdk.internal.loader.ClassLoaderValue which you might be able to use 
> for caching if a part of your key is a ClassLoader. From the javadoc:
>
> ?* ClassLoaderValue allows associating a
> ?* {@link #computeIfAbsent(ClassLoader, BiFunction) computed} non-null 
> value with
> ?* a {@code (ClassLoader, keys...)} tuple. The associated value, as 
> well as the
> ?* keys are strongly reachable from the associated ClassLoader so care 
> should be
> ?* taken to use such keys and values that only reference types 
> resolvable from
> ?* the associated ClassLoader. Failing that, ClassLoader leaks are 
> inevitable.
>
> So if you know that the InitialContextFactory instance is always 
> resolvable (by class name) from the ClassLoader you are using for the 
> caching key (the TCCL), then this utility might be just right for your 
> purpose.
>
> Regards, Peter
>
>
> On 1/29/20 6:22 PM, Se?n Coffey wrote:
>> Thanks for the reviews. I found an issue with the new test also -
>>
>> it's loading the custom factory class via the non-serviceloader 
>> approach. I was hoping to exercise ServiceLoader here. I'll address 
>> this and the comments raised and revert with a new patch shortly.
>>
>> Regards,
>> Sean.
>>
>> On 29/01/20 16:27, Alan Bateman wrote:
>>> On 29/01/2020 15:55, Daniel Fuchs wrote:
>>>> Hi Se?n,
>>>>
>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
>>>>> A WeakHashKey with the TCCL as the key should be okay here.
>>>>
>>>> If the TCCL is the key then there are good chances that the
>>>> concrete factory class is expected to be loaded by the TCCL.
>>>>
>>>> If that happens then the value will reference the key and
>>>> nothing will ever get garbage collected.
>>> I don't know how much JNDI is used much beyond LDAP these days but 
>>> you are right that a factory with a strong ref to the TCCL would 
>>> prevent it from being GC'ed.? The internal WeakPairMap might be 
>>> useful here.
>>>
>>> -Alan
>>
>

From naoto.sato at oracle.com  Fri Jan 31 13:57:17 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 31 Jan 2020 05:57:17 -0800
Subject: ZoneRules.of() implies that transitionList is a superset of
 standardOffsetTransitionList but doesn't check that
In-Reply-To: 
References: 
Message-ID: 

Hi Roman,

Please file a JBS issue for this.

Naoto

On 1/29/20 9:56 PM, Roman Leventov wrote:
> 1) ZoneRules.of() implies that transitionList is a superset of
> standardOffsetTransitionList but doesn't check that. Then it's possible to
> construct ZoneRules instances that don't work correctly:
>      @Test
>      public void zoneRulesTest() {
>          LocalDateTime transitionDay = LocalDateTime.of(2020, 1, 1, 2, 0);
>          ZoneOffsetTransition trans = ZoneOffsetTransition.of(
>                  transitionDay,
>                  ZoneOffset.ofHours(1),
>                  ZoneOffset.ofHours(2)
>          );
>          ZoneRules rules = ZoneRules.of(ZoneOffset.ofHours(1),
> ZoneOffset.ofHours(1),
>                  Arrays.asList(trans),
>                  Collections.emptyList(), Collections.emptyList());
> 
>          Assert.assertEquals(ZoneOffset.ofHours(2), rules.getOffset(
>                  transitionDay.plusDays(7).toInstant(ZoneOffset.UTC)));
>      }
> 
> 2) Unrelated issue in java-time code: in ZoneOffsetTransitionRule, there is
> a typo, some variables are called "timeDefnition" (missed "i") and it leaks
> to public Javadoc.
> 

From raffaello.giulietti at gmail.com  Fri Jan 31 15:02:26 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 31 Jan 2020 16:02:26 +0100
Subject: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double)
 sometimes produces incorrect results
Message-ID: <2e5aa310-4e1e-97ef-ebe4-357988798996@gmail.com>

This is the usual, familiar monthly reminder that the latest patches of 
[1] have been submitted more than 9 months ago [2] and still need a review.
Full background documentation is available at [3].


Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8202555
[2] http://cr.openjdk.java.net/~bpb/4511638/webrev.03/
[3] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058

From erik.joelsson at oracle.com  Fri Jan 31 15:31:35 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 31 Jan 2020 07:31:35 -0800
Subject: RFR: JDK-8238225: Issues reported after replacing symlink at
 Contents/MacOS/libjli.dylib with binary
Message-ID: 

In JDK-8235687 the MacOS bundle distribution of the JDK was changed to 
conform to Apple requirements by changing Contents/MacOS/libjli.dylib 
from a symlink into ../Home/lib/libjli.dylib to a copy of that file. The 
problem with having a symlink there is that Contents/MacOS/libjli.dylib 
is the declared CFBundleExecutable of the bundle and that executable may 
not be a symlink. The history around why that particular library was put 
there seems lost in ancient history. All we know is that it was there 
when Apple donated the Mac port and according to this bug report, there 
are users out there relying on it.

When changing Contents/MacOS/libjli.dylib to a copy, loading that dylib 
and using it to launch a JVM no longer works. This patch fixes that by 
making libjli.dylib aware of potentially being located there and if so, 
finding the JDK home dir in ../Home.

I've also expanded the existing test for launching a JVM through 
libjli.dylib directly to also test this location when possible. In local 
testing, this will not be covered unless the user explicitly specifies 
that the JDK under test should be the bundle image on the command line 
like this:

$ make test-only TEST=open/test/jdk/tools/launcher/JliLaunchTest.java 
JDK_IMAGE_DIR=$PWD/build/macosx-x64/images/jdk-bundle/jdk-15.jdk/Contents/Home

But, at least in Oracle's distributed testing, the JDK on MacOS is 
distributed in the bundle layout, so there this functionality will be 
tested.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238225

Webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.01/

/Erik


From brian.burkhalter at oracle.com  Fri Jan 31 16:02:36 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 Jan 2020 08:02:36 -0800
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
Message-ID: <5E9FFC49-3E7B-4298-BA8C-344109CE1B8B@oracle.com>

Ping ...

> On Jan 16, 2020, at 5:35 PM, Brian Burkhalter  wrote:
> 
> This issue [1] attempts to reinstate the change for [2] which was backed out to fix [3] thereby maintaining longstanding behavior. The proposed change [4] modifies the specification to increment the line number also when EOF is encountered and is not immediately preceded by a line terminator. If this all seems reasonable then a CSR will be filed after the code review.
> 
> One thing I am uncertain about is the change to skip() at lines 293-295 of LineNumberReader. I am not sure that those  lines should be added.
> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8235792
> [2] https://bugs.openjdk.java.net/browse/JDK-8230342
> [3] https://bugs.openjdk.java.net/browse/JDK-8235668
> [4] http://cr.openjdk.java.net/~bpb/8235792/webrev.00/


From peter.levart at gmail.com  Fri Jan 31 17:16:22 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 31 Jan 2020 18:16:22 +0100
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: <6a923a69-c8f1-2d6b-ff64-2ba53ad0d483@oracle.com>
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
 <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
 <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>
 <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>
 <6a923a69-c8f1-2d6b-ff64-2ba53ad0d483@oracle.com>
Message-ID: 

Hi Se?n,

On 1/31/20 2:16 PM, Se?n Coffey wrote:
> Thanks for the review Peter. All good points! My latest patch contains 
> adjustments based on feedback from you and others to date.
>
> * Incorporate use of ClassLoaderValue -
> ?-- I'd appreciate feedback on whether I'm using it correctly.

Yes, you used it correctly. You are very verbose about using it, but 
that's just style. I, for example, would re-write this:

 ?712 ClassLoaderValue.Sub key = 
FACTORIES_CACHE.sub(className);
 ?713???????????? try {
 ?714???????????????? factory = key.computeIfAbsent(loader, (ld, ky) -> {
 ?715???????????????????? String cn = ky.key();
 ?716???????????????????? InitialContextFactory fac = getFactory(cn);
 ?717???????????????????? return fac;
 ?718???????????????? });
 ?719???????????? } catch (UndeclaredThrowableException e) {
 ?720???????????????? if (e.getUndeclaredThrowable() instanceof 
NoInitialContextException) {
 ?721???????????????????? throw (NoInitialContextException) 
e.getUndeclaredThrowable();
 ?722???????????????? }
 ?723???????????? }

... into this:

 ??????????? var key = FACTORIES_CACHE.sub(className);
 ??????????? try {
 ??????????????? factory = key.computeIfAbsent(loader, (ld, ky) -> 
getFactory(ky.key()));
 ??????????? } catch (UndeclaredThrowableException e) {
 ??????????????? if (e.getUndeclaredThrowable() instanceof 
NoInitialContextException) {
 ??????????????????? throw (NoInitialContextException) 
e.getUndeclaredThrowable();
 ??????????????? } else {
 ??????????????????? throw e;
 ??????????????? }
 ??????????? }

Notice also that I added:

 ??????????????? } else {
 ??????????????????? throw e;
 ??????????????? }

You have two options. Either UndeclaredThrowableException is possible 
only when you wrap NoInitialContextException with it in getFactory() in 
which case you could simply do unconditional:

 ??????????? } catch (UndeclaredThrowableException e) {
 ??????????????? throw (NoInitialContextException) 
e.getUndeclaredThrowable();
 ??????????? }

...or UndeclaredThrowableException is possible also to be thrown from 
code called by getFactory() (in theory, it is). In this case you would 
want to re-throw it here instead of swallowing it.

> * Use of ServiceLoader.stream()

 ?737???????????? factory = loader
 ?738???????????????????? .stream()
 ?739???????????????????? .map(ServiceLoader.Provider::get)
 ?740???????????????????? .filter(f -> 
f.getClass().getName().equals(className))
 ?741???????????????????? .findFirst()
 ?742???????????????????? .orElse(null);

Here you instantiate InitialContextFactory instances until you get one 
with implementation class with correct className. But Provider.type() 
should already return the type of the service without instantiating it. 
So you could write the following instead:

 ??????????? factory = loader
 ??????????????? .stream()
 ??????????????? .filter(p -> p.type().getName().equals(className))
 ??????????????? .findFirst()
 ??????????????? .map(ServiceLoader.Provider::get)
 ??????????????? .orElse(null);

This should instantiate just the service that is found and not any 
other. ServiceLoader.Provider.type() is specified to return:

 ???????? * Returns the provider type. There is no guarantee that this 
type is
 ???????? * accessible or that it has a public no-args constructor. The 
{@link
 ???????? * #get() get()} method should be used to obtain the provider 
instance.
 ???????? *
 ???????? * 
     When a module declares that the provider class is 
created by a
 ???????? * provider factory then this method returns the return type of its
 ???????? * public static "{@code provider()}" method.

So in theory this method could return a super-type of the service 
implementation class. But one could argue that the name of the service 
provider type is the one we should be searching for, not the 
implementation class of the service. Perhaps the service declares a 
single provider type and then at instantiation time it dynamically 
chooses an implementation class depending on the environment 
(architecture perhaps). It would be interesting to see whether provider 
types in real service implementations differ from service implementation 
classes or are they usually the same.

The following is also possible:

 ??????????? // 1st try finding a ServiceLoader.Provider with type() of 
correct name
 ??????????? factory = loader
 ??????????????? .stream()
 ??????????????? .filter(p -> p.type().getName().equals(className))
 ??????????????? .findFirst()
 ??????????????? .map(ServiceLoader.Provider::get)
 ??????????????? .or( // if that doesn't yield any result, instantiate 
the services
 ???????????????????? // one by one and search for implementation class 
of correct name
 ??????????????????? () -> loader
 ??????????????????????? .stream()
 ??????????????????????? .map(ServiceLoader.Provider::get)
 ??????????????????????? .filter(f -> 
f.getClass().getName().equals(className))
 ??????????????????????? .findFirst()
 ??????????????? ).orElse(null);

So what do you think?

Regards, Peter

> * adjusted test for both the ServiceLoader and legacy classpath load 
> approach
> * insert use of sleep which testing GC.
>
> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
>
> regards,
> Sean.
>
> On 30/01/2020 07:59, Peter Levart wrote:
>> Hi Se?n,
>>
>> WeakHashMap is not safe to be called concurrently. Even get() method, 
>> although it may seem read-only, can modify internal state (expunging 
>> stale Weak entries), so holding a READ lock while accessing 
>> WeakHashMap it is wrong.
>>
>> getInitialContext() static method is called with an env Hashtable 
>> which means it can be called with different keys/values for the same 
>> TCCL. So caching of InitialContextFactory is just performed for the 
>> 1st call for a particular TCCL. Subsequent calls for the same TCCL 
>> and different class names are not cached. Is this the behavior you 
>> are pursuing? You could cache the factory using (TCCL, class name) as 
>> a compound key.
>>
>> Also, by caching in a WeakHashMap> InitialContextFactory>, you make a strong reference to 
>> InitialContextFactory from class loader of the NamingManager.class 
>> and such InitialContextFactory may indirectly reference the 
>> ClassLoader key of the same entry, so it will never go away because 
>> NamingManager class is never going away. You should at least use a 
>> WeakHashMap> for that.
>>
>> Shameless plug: there is a JDK internal class 
>> jdk.internal.loader.ClassLoaderValue which you might be able to use 
>> for caching if a part of your key is a ClassLoader. From the javadoc:
>>
>> ?* ClassLoaderValue allows associating a
>> ?* {@link #computeIfAbsent(ClassLoader, BiFunction) computed} 
>> non-null value with
>> ?* a {@code (ClassLoader, keys...)} tuple. The associated value, as 
>> well as the
>> ?* keys are strongly reachable from the associated ClassLoader so 
>> care should be
>> ?* taken to use such keys and values that only reference types 
>> resolvable from
>> ?* the associated ClassLoader. Failing that, ClassLoader leaks are 
>> inevitable.
>>
>> So if you know that the InitialContextFactory instance is always 
>> resolvable (by class name) from the ClassLoader you are using for the 
>> caching key (the TCCL), then this utility might be just right for 
>> your purpose.
>>
>> Regards, Peter
>>
>>
>> On 1/29/20 6:22 PM, Se?n Coffey wrote:
>>> Thanks for the reviews. I found an issue with the new test also -
>>>
>>> it's loading the custom factory class via the non-serviceloader 
>>> approach. I was hoping to exercise ServiceLoader here. I'll address 
>>> this and the comments raised and revert with a new patch shortly.
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 29/01/20 16:27, Alan Bateman wrote:
>>>> On 29/01/2020 15:55, Daniel Fuchs wrote:
>>>>> Hi Se?n,
>>>>>
>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
>>>>>> A WeakHashKey with the TCCL as the key should be okay here.
>>>>>
>>>>> If the TCCL is the key then there are good chances that the
>>>>> concrete factory class is expected to be loaded by the TCCL.
>>>>>
>>>>> If that happens then the value will reference the key and
>>>>> nothing will ever get garbage collected.
>>>> I don't know how much JNDI is used much beyond LDAP these days but 
>>>> you are right that a factory with a strong ref to the TCCL would 
>>>> prevent it from being GC'ed.? The internal WeakPairMap might be 
>>>> useful here.
>>>>
>>>> -Alan
>>>
>>


From naoto.sato at oracle.com  Fri Jan 31 17:17:23 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 31 Jan 2020 09:17:23 -0800
Subject: ZoneRules.of() implies that transitionList is a superset of
 standardOffsetTransitionList but doesn't check that
In-Reply-To: 
References: 
 
 
Message-ID: <1ab54338-1fb2-e6ea-8cb6-0131b7d5848d@oracle.com>

I meant the JDK Bug System:

https://bugs.openjdk.java.net/

All the issues in the JDK is tracked here.

As to the issues themselves, you would want to specify 
Arrays.asList(trans) in place for the 4th argument on ZoneRules.of(), so 
that the transition happens on the transition day?

For 2), good catch for the missing 'i', we need a JBS issue for that to 
fix it.

Naoto

On 1/31/20 6:08 AM, Roman Leventov wrote:
> java.bugs.com  you mean? Not long ago I reported a 
> similar issue about core libs and they recommended me to write to list 
> directly, so that's why I wrote directly here this time.
> 
> On Fri, 31 Jan 2020 at 16:57,  > wrote:
> 
>     Hi Roman,
> 
>     Please file a JBS issue for this.
> 
>     Naoto
> 
>     On 1/29/20 9:56 PM, Roman Leventov wrote:
>      > 1) ZoneRules.of() implies that transitionList is a superset of
>      > standardOffsetTransitionList but doesn't check that. Then it's
>     possible to
>      > construct ZoneRules instances that don't work correctly:
>      >? ? ? @Test
>      >? ? ? public void zoneRulesTest() {
>      >? ? ? ? ? LocalDateTime transitionDay = LocalDateTime.of(2020, 1,
>     1, 2, 0);
>      >? ? ? ? ? ZoneOffsetTransition trans = ZoneOffsetTransition.of(
>      >? ? ? ? ? ? ? ? ? transitionDay,
>      >? ? ? ? ? ? ? ? ? ZoneOffset.ofHours(1),
>      >? ? ? ? ? ? ? ? ? ZoneOffset.ofHours(2)
>      >? ? ? ? ? );
>      >? ? ? ? ? ZoneRules rules = ZoneRules.of(ZoneOffset.ofHours(1),
>      > ZoneOffset.ofHours(1),
>      >? ? ? ? ? ? ? ? ? Arrays.asList(trans),
>      >? ? ? ? ? ? ? ? ? Collections.emptyList(), Collections.emptyList());
>      >
>      >? ? ? ? ? Assert.assertEquals(ZoneOffset.ofHours(2), rules.getOffset(
>      >                 
>     transitionDay.plusDays(7).toInstant(ZoneOffset.UTC)));
>      >? ? ? }
>      >
>      > 2) Unrelated issue in java-time code: in
>     ZoneOffsetTransitionRule, there is
>      > a typo, some variables are called "timeDefnition" (missed "i")
>     and it leaks
>      > to public Javadoc.
>      >
> 

From leventov.ru at gmail.com  Fri Jan 31 14:08:33 2020
From: leventov.ru at gmail.com (Roman Leventov)
Date: Fri, 31 Jan 2020 17:08:33 +0300
Subject: ZoneRules.of() implies that transitionList is a superset of
 standardOffsetTransitionList but doesn't check that
In-Reply-To: 
References: 
 
Message-ID: 

java.bugs.com you mean? Not long ago I reported a similar issue about core
libs and they recommended me to write to list directly, so that's why I
wrote directly here this time.

On Fri, 31 Jan 2020 at 16:57,  wrote:

> Hi Roman,
>
> Please file a JBS issue for this.
>
> Naoto
>
> On 1/29/20 9:56 PM, Roman Leventov wrote:
> > 1) ZoneRules.of() implies that transitionList is a superset of
> > standardOffsetTransitionList but doesn't check that. Then it's possible
> to
> > construct ZoneRules instances that don't work correctly:
> >      @Test
> >      public void zoneRulesTest() {
> >          LocalDateTime transitionDay = LocalDateTime.of(2020, 1, 1, 2,
> 0);
> >          ZoneOffsetTransition trans = ZoneOffsetTransition.of(
> >                  transitionDay,
> >                  ZoneOffset.ofHours(1),
> >                  ZoneOffset.ofHours(2)
> >          );
> >          ZoneRules rules = ZoneRules.of(ZoneOffset.ofHours(1),
> > ZoneOffset.ofHours(1),
> >                  Arrays.asList(trans),
> >                  Collections.emptyList(), Collections.emptyList());
> >
> >          Assert.assertEquals(ZoneOffset.ofHours(2), rules.getOffset(
> >                  transitionDay.plusDays(7).toInstant(ZoneOffset.UTC)));
> >      }
> >
> > 2) Unrelated issue in java-time code: in ZoneOffsetTransitionRule, there
> is
> > a typo, some variables are called "timeDefnition" (missed "i") and it
> leaks
> > to public Javadoc.
> >
>

From leventov.ru at gmail.com  Fri Jan 31 18:05:54 2020
From: leventov.ru at gmail.com (Roman Leventov)
Date: Fri, 31 Jan 2020 21:05:54 +0300
Subject: ZoneRules.of() implies that transitionList is a superset of
 standardOffsetTransitionList but doesn't check that
In-Reply-To: <1ab54338-1fb2-e6ea-8cb6-0131b7d5848d@oracle.com>
References: 
 
 
 <1ab54338-1fb2-e6ea-8cb6-0131b7d5848d@oracle.com>
Message-ID: 

I cannot create an issue because I'm not an OpenJDK process member.

Yes, the test constructs an invalid ZoneRules, the point is to demonstrate
that this is possible and IAE is not thrown upon construction. I don't
think this is a good principle for immutable classes. Once they are
constructed, their state must be verified to be correct.

On Fri, 31 Jan 2020 at 20:17,  wrote:

> I meant the JDK Bug System:
>
> https://bugs.openjdk.java.net/
>
> All the issues in the JDK is tracked here.
>
> As to the issues themselves, you would want to specify
> Arrays.asList(trans) in place for the 4th argument on ZoneRules.of(), so
> that the transition happens on the transition day?
>
> For 2), good catch for the missing 'i', we need a JBS issue for that to
> fix it.
>
> Naoto
>
> On 1/31/20 6:08 AM, Roman Leventov wrote:
> > java.bugs.com  you mean? Not long ago I reported
> a
> > similar issue about core libs and they recommended me to write to list
> > directly, so that's why I wrote directly here this time.
> >
> > On Fri, 31 Jan 2020 at 16:57,  > > wrote:
> >
> >     Hi Roman,
> >
> >     Please file a JBS issue for this.
> >
> >     Naoto
> >
> >     On 1/29/20 9:56 PM, Roman Leventov wrote:
> >      > 1) ZoneRules.of() implies that transitionList is a superset of
> >      > standardOffsetTransitionList but doesn't check that. Then it's
> >     possible to
> >      > construct ZoneRules instances that don't work correctly:
> >      >      @Test
> >      >      public void zoneRulesTest() {
> >      >          LocalDateTime transitionDay = LocalDateTime.of(2020, 1,
> >     1, 2, 0);
> >      >          ZoneOffsetTransition trans = ZoneOffsetTransition.of(
> >      >                  transitionDay,
> >      >                  ZoneOffset.ofHours(1),
> >      >                  ZoneOffset.ofHours(2)
> >      >          );
> >      >          ZoneRules rules = ZoneRules.of(ZoneOffset.ofHours(1),
> >      > ZoneOffset.ofHours(1),
> >      >                  Arrays.asList(trans),
> >      >                  Collections.emptyList(),
> Collections.emptyList());
> >      >
> >      >          Assert.assertEquals(ZoneOffset.ofHours(2),
> rules.getOffset(
> >      >
> >     transitionDay.plusDays(7).toInstant(ZoneOffset.UTC)));
> >      >      }
> >      >
> >      > 2) Unrelated issue in java-time code: in
> >     ZoneOffsetTransitionRule, there is
> >      > a typo, some variables are called "timeDefnition" (missed "i")
> >     and it leaks
> >      > to public Javadoc.
> >      >
> >
>

From Roger.Riggs at oracle.com  Fri Jan 31 20:05:25 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 31 Jan 2020 15:05:25 -0500
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
Message-ID: <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>

Hi Brian,

The spec text describing the current behavior is ok.

On 1/16/20 8:35 PM, Brian Burkhalter wrote:
> This issue [1] attempts to reinstate the change for [2] which was backed out to fix [3] thereby maintaining longstanding behavior. The proposed change [4] modifies the specification to increment the line number also when EOF is encountered and is not immediately preceded by a line terminator. If this all seems reasonable then a CSR will be filed after the code review.

LineNumberReader:

55: I would probably use 'EOL' instead of 'TERM'.

>
> One thing I am uncertain about is the change to skip() at lines 293-295 of LineNumberReader. I am not sure that those  lines should be added.
Leave them in.
Not changing prevChar would be misleading since the prevChar isn't adjecent
to the next read.

Roger

>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8235792
> [2] https://bugs.openjdk.java.net/browse/JDK-8230342
> [3] https://bugs.openjdk.java.net/browse/JDK-8235668
> [4] http://cr.openjdk.java.net/~bpb/8235792/webrev.00/


From brian.burkhalter at oracle.com  Fri Jan 31 20:10:42 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 Jan 2020 12:10:42 -0800
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
 <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>
Message-ID: <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com>

Hi Roger,

Thanks for the review.

> On Jan 31, 2020, at 12:05 PM, Roger Riggs  wrote:
> 
> The spec text describing the current behavior is ok.
> 
> On 1/16/20 8:35 PM, Brian Burkhalter wrote:
>> This issue [1] attempts to reinstate the change for [2] which was backed out to fix [3] thereby maintaining longstanding behavior. The proposed change [4] modifies the specification to increment the line number also when EOF is encountered and is not immediately preceded by a line terminator. If this all seems reasonable then a CSR will be filed after the code review.
> 
> LineNumberReader:
> 
> 55: I would probably use 'EOL' instead of 'TERM?.

Yes, that is better.

>> 
>> One thing I am uncertain about is the change to skip() at lines 293-295 of LineNumberReader. I am not sure that those  lines should be added.
> Leave them in.
> Not changing prevChar would be misleading since the prevChar isn't adjecent
> to the next read.

OK. I?ll change /TERM/EOL/ but not post another webrev unless there are further comments. I will wait to check it in until Monday in case someone has comments.

Thanks,

Brian

From Alan.Bateman at oracle.com  Fri Jan 31 20:20:23 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 31 Jan 2020 20:20:23 +0000
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com>
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
 <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>
 <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com>
Message-ID: 

On 31/01/2020 20:10, Brian Burkhalter wrote:
> :
> OK. I?ll change /TERM/EOL/ but not post another webrev unless there are further comments. I will wait to check it in until Monday in case someone has comments.
>
I think it would be good to more eyes on this as LNR has a history of 
resisting change. I think you'll need a CSR too this re-specifies when 
the conditions when the line number is incremented.

-Alan.

From brian.burkhalter at oracle.com  Fri Jan 31 20:21:44 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 Jan 2020 12:21:44 -0800
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: 
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
 <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>
 <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com>
 
Message-ID: 


> On Jan 31, 2020, at 12:20 PM, Alan Bateman  wrote:
> 
> On 31/01/2020 20:10, Brian Burkhalter wrote:
>> :
>> OK. I?ll change /TERM/EOL/ but not post another webrev unless there are further comments. I will wait to check it in until Monday in case someone has comments.
>> 
> I think it would be good to more eyes on this as LNR has a history of resisting change.

I?ll hold off on it then for a while.

> I think you'll need a CSR too this re-specifies when the conditions when the line number is incremented.

Yes, I agree.

Thanks,

Brian

From sean.coffey at oracle.com  Fri Jan 31 23:22:52 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 31 Jan 2020 23:22:52 +0000
Subject: RFR: 8223260: NamingManager should cache InitialContextFactory
In-Reply-To: 
References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com>
 <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com>
 <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com>
 <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com>
 <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com>
 <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com>
 <6a923a69-c8f1-2d6b-ff64-2ba53ad0d483@oracle.com>
 
Message-ID: <7da546ba-3e9d-08d9-56e0-b5bfd8e13703@oracle.com>

Peter,

thanks again for your review. comments inline..

On 31/01/2020 17:16, Peter Levart wrote:
> Hi Se?n,
>
> On 1/31/20 2:16 PM, Se?n Coffey wrote:
>> Thanks for the review Peter. All good points! My latest patch 
>> contains adjustments based on feedback from you and others to date.
>>
>> * Incorporate use of ClassLoaderValue -
>> ?-- I'd appreciate feedback on whether I'm using it correctly.
>
> Yes, you used it correctly. You are very verbose about using it, but 
> that's just style. I, for example, would re-write this:
>
> ?712 ClassLoaderValue.Sub key = 
> FACTORIES_CACHE.sub(className);
> ?713???????????? try {
> ?714???????????????? factory = key.computeIfAbsent(loader, (ld, ky) -> {
> ?715???????????????????? String cn = ky.key();
> ?716???????????????????? InitialContextFactory fac = getFactory(cn);
> ?717???????????????????? return fac;
> ?718???????????????? });
> ?719???????????? } catch (UndeclaredThrowableException e) {
> ?720???????????????? if (e.getUndeclaredThrowable() instanceof 
> NoInitialContextException) {
> ?721???????????????????? throw (NoInitialContextException) 
> e.getUndeclaredThrowable();
> ?722???????????????? }
> ?723???????????? }
>
> ... into this:
>
> ??????????? var key = FACTORIES_CACHE.sub(className);
> ??????????? try {
> ??????????????? factory = key.computeIfAbsent(loader, (ld, ky) -> 
> getFactory(ky.key()));
> ??????????? } catch (UndeclaredThrowableException e) {
> ??????????????? if (e.getUndeclaredThrowable() instanceof 
> NoInitialContextException) {
> ??????????????????? throw (NoInitialContextException) 
> e.getUndeclaredThrowable();
> ??????????????? } else {
> ??????????????????? throw e;
> ??????????????? }
> ??????????? }
Yes - looks much neater. I've edited the patch to that effect.
>
> Notice also that I added:
>
> ??????????????? } else {
> ??????????????????? throw e;
> ??????????????? }
>
> You have two options. Either UndeclaredThrowableException is possible 
> only when you wrap NoInitialContextException with it in getFactory() 
> in which case you could simply do unconditional:
>
> ??????????? } catch (UndeclaredThrowableException e) {
> ??????????????? throw (NoInitialContextException) 
> e.getUndeclaredThrowable();
> ??????????? }
>
> ...or UndeclaredThrowableException is possible also to be thrown from 
> code called by getFactory() (in theory, it is). In this case you would 
> want to re-throw it here instead of swallowing it.
Yes - I was wondering if I should be concerned about other call sites 
that might throw UndeclaredThrowableException. You're right, best to be 
on the safe side and re-throw. Code edited.
>
>> * Use of ServiceLoader.stream()
>
> ?737???????????? factory = loader
> ?738???????????????????? .stream()
> ?739???????????????????? .map(ServiceLoader.Provider::get)
> ?740???????????????????? .filter(f -> 
> f.getClass().getName().equals(className))
> ?741???????????????????? .findFirst()
> ?742???????????????????? .orElse(null);
>
> Here you instantiate InitialContextFactory instances until you get one 
> with implementation class with correct className. But Provider.type() 
> should already return the type of the service without instantiating 
> it. So you could write the following instead:
>
> ??????????? factory = loader
> ??????????????? .stream()
> ??????????????? .filter(p -> p.type().getName().equals(className))
> ??????????????? .findFirst()
> ??????????????? .map(ServiceLoader.Provider::get)
> ??????????????? .orElse(null);
That makes sense. It actually explains a test failure I was seeing 
earlier today while trying to expand test coverage for this issue. Off 
mail thread, Daniel Fuchs suggested I use a more concrete URLClassLoader 
example. I've introduced extra testing to test for multiple 
Context.INITIAL_CONTEXT_FACTORY values. I was getting unexpected 
initialization values since the stream function was instantiating 
DummyContextFactory for filter function (when in fact 
DummyContextFactory2 ended up being the correct Factory) . Thanks! I've 
adopted this change.
>
> This should instantiate just the service that is found and not any 
> other. ServiceLoader.Provider.type() is specified to return:
>
> ???????? * Returns the provider type. There is no guarantee that this 
> type is
> ???????? * accessible or that it has a public no-args constructor. The 
> {@link
> ???????? * #get() get()} method should be used to obtain the provider 
> instance.
> ???????? *
> ???????? * 
     When a module declares that the provider class is 
> created by a
> ???????? * provider factory then this method returns the return type 
> of its
> ???????? * public static "{@code provider()}" method.
>
> So in theory this method could return a super-type of the service 
> implementation class. But one could argue that the name of the service 
> provider type is the one we should be searching for, not the 
> implementation class of the service. Perhaps the service declares a 
> single provider type and then at instantiation time it dynamically 
> chooses an implementation class depending on the environment 
> (architecture perhaps). It would be interesting to see whether 
> provider types in real service implementations differ from service 
> implementation classes or are they usually the same.
>
> The following is also possible:
>
> ??????????? // 1st try finding a ServiceLoader.Provider with type() of 
> correct name
> ??????????? factory = loader
> ??????????????? .stream()
> ??????????????? .filter(p -> p.type().getName().equals(className))
> ??????????????? .findFirst()
> ??????????????? .map(ServiceLoader.Provider::get)
> ??????????????? .or( // if that doesn't yield any result, instantiate 
> the services
> ???????????????????? // one by one and search for implementation class 
> of correct name
> ??????????????????? () -> loader
> ??????????????????????? .stream()
> ??????????????????????? .map(ServiceLoader.Provider::get)
> ??????????????????????? .filter(f -> 
> f.getClass().getName().equals(className))
> ??????????????????????? .findFirst()
> ??????????????? ).orElse(null);
>
> So what do you think?

ok - possible I guess but I think it's highly unlikely ? It looks like 
alot of extra care for a case that shouldn't happen. I'll stick with 
your earlier suggestion unless you or others object.

current webrev: 
https://cr.openjdk.java.net/~coffeys/webrev.8223260.v3/webrev/

regards,
Sean.

>
> Regards, Peter
>
>> * adjusted test for both the ServiceLoader and legacy classpath load 
>> approach
>> * insert use of sleep which testing GC.
>>
>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
>>
>> regards,
>> Sean.
>>
>> On 30/01/2020 07:59, Peter Levart wrote:
>>> Hi Se?n,
>>>
>>> WeakHashMap is not safe to be called concurrently. Even get() 
>>> method, although it may seem read-only, can modify internal state 
>>> (expunging stale Weak entries), so holding a READ lock while 
>>> accessing WeakHashMap it is wrong.
>>>
>>> getInitialContext() static method is called with an env Hashtable 
>>> which means it can be called with different keys/values for the same 
>>> TCCL. So caching of InitialContextFactory is just performed for the 
>>> 1st call for a particular TCCL. Subsequent calls for the same TCCL 
>>> and different class names are not cached. Is this the behavior you 
>>> are pursuing? You could cache the factory using (TCCL, class name) 
>>> as a compound key.
>>>
>>> Also, by caching in a WeakHashMap>> InitialContextFactory>, you make a strong reference to 
>>> InitialContextFactory from class loader of the NamingManager.class 
>>> and such InitialContextFactory may indirectly reference the 
>>> ClassLoader key of the same entry, so it will never go away because 
>>> NamingManager class is never going away. You should at least use a 
>>> WeakHashMap> for 
>>> that.
>>>
>>> Shameless plug: there is a JDK internal class 
>>> jdk.internal.loader.ClassLoaderValue which you might be able to use 
>>> for caching if a part of your key is a ClassLoader. From the javadoc:
>>>
>>> ?* ClassLoaderValue allows associating a
>>> ?* {@link #computeIfAbsent(ClassLoader, BiFunction) computed} 
>>> non-null value with
>>> ?* a {@code (ClassLoader, keys...)} tuple. The associated value, as 
>>> well as the
>>> ?* keys are strongly reachable from the associated ClassLoader so 
>>> care should be
>>> ?* taken to use such keys and values that only reference types 
>>> resolvable from
>>> ?* the associated ClassLoader. Failing that, ClassLoader leaks are 
>>> inevitable.
>>>
>>> So if you know that the InitialContextFactory instance is always 
>>> resolvable (by class name) from the ClassLoader you are using for 
>>> the caching key (the TCCL), then this utility might be just right 
>>> for your purpose.
>>>
>>> Regards, Peter
>>>
>>>
>>> On 1/29/20 6:22 PM, Se?n Coffey wrote:
>>>> Thanks for the reviews. I found an issue with the new test also -
>>>>
>>>> it's loading the custom factory class via the non-serviceloader 
>>>> approach. I was hoping to exercise ServiceLoader here. I'll address 
>>>> this and the comments raised and revert with a new patch shortly.
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>> On 29/01/20 16:27, Alan Bateman wrote:
>>>>> On 29/01/2020 15:55, Daniel Fuchs wrote:
>>>>>> Hi Se?n,
>>>>>>
>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
>>>>>>> A WeakHashKey with the TCCL as the key should be okay here.
>>>>>>
>>>>>> If the TCCL is the key then there are good chances that the
>>>>>> concrete factory class is expected to be loaded by the TCCL.
>>>>>>
>>>>>> If that happens then the value will reference the key and
>>>>>> nothing will ever get garbage collected.
>>>>> I don't know how much JNDI is used much beyond LDAP these days but 
>>>>> you are right that a factory with a strong ref to the TCCL would 
>>>>> prevent it from being GC'ed.? The internal WeakPairMap might be 
>>>>> useful here.
>>>>>
>>>>> -Alan
>>>>
>>>
>